The RISKS Digest
Volume 5 Issue 54

Wednesday, 4th November 1987

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Erroneous $1M overdraft — plus interest
Dave Horsfall
o Wrongful Traffic Tickets & Changing Computers
David A. Honig
o Weather — or not to blame the computer?
Stephen Colwill
o Re: Computer's Normal Operation Delays Royal Visit
Henry Spencer
o Auto-pilot Problems and Hardware Reliability
Craig Johnson
o Minuteman III
Bryce Nesbitt
o Info on RISKS (comp.risks)

Erroneous $1M overdraft — plus interest

Dave Horsfall <munnari!!dave@uunet.UU.NET>
4 Nov 87 13:13:34 +1100 (Wed)
From the Sydney Sun-Herald, 19th October 1987:

``The bank manager panicked when he saw the size of Brian Jamieson's
overdraft - all $100 million of it!  To add to the horror, an
additional $53,000 interest debt was accruing daily on the account.

But Mr Jamieson ... was the last to panic, thanks to a frantic
telephone call from his Westpac bank manager who told him to take
no notice of any statement - it was all a mistake.  [...]

The bank manager said he was not sure how the error had occurred.
"Something happened with the computer and it went through" he said.  [...]

Curiosity has since got the better of Mr Jamieson.  He has requested
a copy of the offending bank statement so he can frame it.

Dave Horsfall  (VK2KFU)        ACS:  dave@astra.necisa.OZ.AU
NEC Information Systems Aust.  ARPA: dave%astra.necisa.OZ.AU@uunet.UU.NET
3rd Floor, 99 Nicholson St     UUCP: {enea,hplabs,mcvax,uunet,ukc}!\
St. Leonards NSW 2064 AUSTRALIA       munnari!astra.necisa.OZ.AU!dave

Wrongful Traffic Tickets & Changing Computers

"David A. Honig" <honig@CIP.UCI.EDU>
Mon, 02 Nov 87 11:50:02 -0800
A month ago, I received a notice stating that I had two outstanding parking
tickets (delivered on successive days) for violations occuring in UC Irvine
parking lots, and that if I didn't pay over $100 I would have a warrant out
for my arrest.  As I didn't know about the tickets, I made some phone calls
and was told to send the tickets to the Parking & Transportation office here.

Today I called them to find out what my status was.  I told them the date of
the citation, and was told "just to trash them".  They claimed it was a
"computer error".  I asked them for more details: they had "changed computer
companies" and the new system had different codes, causing paid tickets look
unpaid and vice-versa, and confusing other information besides (apparently
including sending out tickets to the wrong people).  The person on the phone
told me that they had to erase three month's worth of tapes due to these

Weather — or not to blame the computer?

Stephen Colwill <mcvax!praxis!steve@uunet.UU.NET>
Mon, 2 Nov 87 13:17:35 BST
I would like to make some observations on the subject of the recent storm.

The remarks about mesoscale weather systems seem to be relevant though I was
under the impression that the model used by the Met Office took into account
surface features (mountains etc) so it cannot be completely restricted to high
altitude (and therefore large-scale) effects.

The paucity of weather stations in the sea is a difficulty that the
forecasters have to live with, almost all the weather that England has builds
over the Atlantic and it seems to me that ships caught in a system like that
are going to have more problems to deal with then relaying detailed data on
the atmospheric conditions to the mainland. This situation is distinct from
those countries with a continental weather pattern and poses more problems for
the modellers.

Another point worth noting is that in this country we are not really "geared
up" to such unusual weather, whenever there are severe snowstorms for example
the parts of the country affected are generally brought to a complete
standstill. In America, on the other hand, a whole infrastructure exists for
closely monitoring the progress of hurricanes etc, and the people are prepared
(as far as they can be) for them.

On the storm itself, it seems to have followed a rather peculiar path of
evolution. As I understand from the subsequent reports it started as two
centres of depression which amalgamated suddenly in the Bay of Biscay. After
this point it reached its unprecedented violence, up to this point the
depressions would have been on the nasty side of normal. These depressions
were fuelled by colliding air masses which had a high temperature difference.
Any model which could have predicted *that* gets *my* respect. In its new
state the storm was so energetic that (on the scale of the Paris-London
distance) it could have gone anywhere and only swung over the SE of England at
the last moment.

A consequence of the storm was that the power loss in the SE significantly
disrupted network communication overseas since ukc (I guess) had some power

In my opinion, these observations completely exonerate the model-makers and
their machines. If this storm had been predicted there would have been a good
case, on the other hand, for their extensive congratulation.

There is a body of thought that has it that such violent weather is on the
increase as the average land-sea temperature difference increases (the
greenhouse effect apparently) so it seems that computer models will have to
get to grips with it eventually :-)

Steve Colwill, Praxis, Bath, England.

Re: Computer's Normal Operation Delays Royal Visit

Tue, 3 Nov 87 13:59:08 EST
  > ... As the royal party was early, the control room dispatched
  > the train manually rather than keep Her Majesty waiting for five minutes.

It's noteworthy that this means that the ultimate cause of the foulup was
elsewhere.  The royal party is not supposed to arrive early.  One reason why
the Queen's Flight aircraft always carry navigators (not normally found on
civil aircraft nowadays) is that their arrivals must be precisely on time --
neither late *nor* early.
                Henry Spencer @ U of Toronto Zoology

Auto-pilot Problems and Hardware Reliability

Craig Johnson <vince@tc.fluke.COM>
Tue, 3 Nov 87 10:55:01 PST
The discussion about alleged auto-pilot failures has reminded me of a
discovery I made a few years ago with regard to hardware reliability
which has serious implications for many applications and may certainly
be a risk to many people.

I was involved at the time with a design which used a very common,
inexpensive single-chip processor made by a major manufacturer.  My
application was such that I was able to observe the behavior of this
processor when very frequently reset with an asynchronous signal, on
the order of 10-50 times a second.  Even though the manufacture's
literature claimed that the reset input was asynchronous and even had
schmitt-trigger-like conditioning, much to my consternation I found
that once every few minutes the processor would go crazy and my system
would hang.

After much hair pulling and careful scrutiny, I found that indeed once
in a great while a reset would fail to properly initialize the
processor and the thing would actually start fetching code at some
bogus address rather than at its reset address.  The failure was
duplicated with several different processor chips, confirming that the
behavior was a characteristic of that processor.  Synchronizing the
reset signal to the bus cycle completely cured the problem and it was
never seen again.

It may be conjecture, but my conclusion was that this was a classic
case of meta-stable states in flip-flops.  Regardless of the
schmitt-trigger conditioning, there was an internal latch which was
supposed to sample the reset input which if clocked at just the right
moment during the transition of the reset signal would go meta-stable,
"balanced" between states and slow to "fall" to a valid state.  When
the transition was too slow, incorrect and incomplete processor
initialization would take place.

I felt fortunate to have discovered this flaw in the processor behavior
before my application went to market.  I have often wondered how many
other systems out there suffer from the same kind of flaw and are prone
to unexplained failures "one in a thousand" times.

Minuteman III (RISKS-5.53)

Bryce Nesbitt <bryce%hoser.Berkeley.EDU@Berkeley.EDU>
Wed, 4 Nov 87 00:46:19 PST
>RISKS-LIST: RISKS-FORUM Digest  Monday, 2 November 1987  Volume 5 : Issue 53
>In regards to the post that talked about parking a vehicle on top of a
>Minuteman III silo to prevent it's launch...
>...If that did indeed occur, it would be questionable
>to it's effect. The silo door is approximately 5 feet of hardened
>concrete and is designed to open even when buried under a substantial
>amount dirt and rubble.

The local journal of mis-information claims that the truck was
parked oriented in the direction of door opening with the brakes
off.  The theory was that the "rug", so to speak, would be pulled
out from under the vehicle which would drop and damage the missile.

The net result might range from launch failure, to fireball,
to local radioactive contamination (or even local detonation,
just possibly).  Any of those alternatives would be better than
dropping a nuke on some *other* country.

Rather than just spread this rumor, I'd rather hear from someone
who knows about how this silo door is designed to keep "a substantial
amount of dirt and rubble" from falling into the silo.

Assume the contingency that the silo commanders must have faced...
an electrical malfunction that they felt *might* cause an unintended
launch, no matter how unreasonable you may think that is.

   [Marginally relevant, but it has intriguing systems implications!

   Bryce's subtle comment of appending the results — which I have omitted 
   here — of a spelling corrector applied to RISKS-5.53 suggests that the
   spelling in that issue was execrable.  (And of course his spelling corrector
   missed the two "it's" above.)  In case you haven't noticed, I have eased
   up somewhat in trying to correct contributed typos and grammatical
   horrors.  (It should reflect on the author, not on me?)  But I certainly
   echo the implied grumble that the contributed writings are getting
   sloppy.  I try not to squelch an interesting contribution just because of
   its writing, but please remember the word "coherent" in the masthead.  PGN]

Please report problems with the web pages to the maintainer