RISKS-LIST: RISKS-FORUM Digest Wednesday, 4 November 1987 Volume 5 : Issue 54 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Erroneous $1M overdraft -- plus interest (Dave Horsfall) Wrongful Traffic Tickets & Changing Computers (David A. Honig) Weather -- or not to blame the computer? (Stephen Colwill) Re: Computer's Normal Operation Delays Royal Visit (Henry Spencer) Auto-pilot Problems and Hardware Reliability (Craig Johnson) Minuteman III (Bryce Nesbitt) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: 4 Nov 87 13:13:34 +1100 (Wed) From: munnari!astra.necisa.oz.au!dave@uunet.UU.NET (Dave Horsfall) To: risks@uunet.UU.NET Subject: Erroneous $1M overdraft -- plus interest 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 ------------------------------ To: risks@CIP.UCI.EDU Subject: Wrongful Traffic Tickets & Changing Computers Date: Mon, 02 Nov 87 11:50:02 -0800 From: "David A. Honig" 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 problems. ------------------------------ From: Stephen Colwill To: RISKS@csl.sri.com Date: Mon, 2 Nov 87 13:17:35 BST Subject: Weather -- or not to blame the computer? 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 outages. 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. ------------------------------ Date: Tue, 3 Nov 87 13:59:08 EST From: mnetor!utzoo!henry@uunet.UU.NET To: RISKS@kl.sri.com Subject: Re: Computer's Normal Operation Delays Royal Visit > ... 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 {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Tue, 3 Nov 87 10:55:01 PST From: vince@tc.fluke.COM (Craig Johnson) To: RISKS@KL.SRI.COM Subject: Auto-pilot Problems and Hardware Reliability Organization: John Fluke Mfg. Co., Inc., Everett, WA 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. ------------------------------ Date: Wed, 4 Nov 87 00:46:19 PST From: bryce%hoser.Berkeley.EDU@Berkeley.EDU (Bryce Nesbitt) To: RISKS@KL.SRI.COM@ucbvax.Berkeley.EDU Subject: Minuteman III (RISKS-5.53) Organization: University of California at Berkeley >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] ------------------------------ End of RISKS-FORUM Digest ************************