Subject: RISKS DIGEST 11.68 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 16 May 1991 Volume 11 : Issue 68 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Is fuzzy control more suitable for nuclear reactors? (Paul Eggert) Of Two Minds about Privacy??? (David States) Re: Horible Speling (Adam Engst) Re: Changing class grades in Alaska (Scott Barman) Re: Emergency off switch - IBM 1620 (Doug Hardie, Bob Wilson) Re: Emergency off switches (Robert E. Van Cleef, Al Donaldson, S. H. Schwartz, Dick Hamlet) RISKS of redistributing SF-LOVERS Digest (Roger H. Goun) Re: case of the replicated errors (Joe Buck, John R MacMillan) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 11, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Tue, 14 May 91 18:25:27 PDT From: eggert@twinsun.com (Paul Eggert) Subject: Is fuzzy control more suitable for nuclear reactors? Japan's Power Reactor and Nuclear Fuel Development Corporation, an R&D organization supervised by the Science and Technology Agency, is now using fuzzy logic to control the water temperature of a tank in the Fugen prototype heavy water reactor operating in the Fukui prefecture. The fuzzy device, an Omron FZ-1000, is not used in normal, stable operation, but only when the reactor starts or shuts down, under the argument that in these conditions fuzzy logic is more suitable for the large amounts of information generated and is less prone to phenomena like overshooting. The fuzzy control is monitored by a human operator and is not yet used in critical places. Further details can be found in Thomas Hagemann's report ``Visit to Omron's Fuzzy Business Promotion Center, Kyoto'', comp.research.japan <4702@gmdzi.gmd.de>, 14 May 1991. The fuzzy device is not yet being used for critical operations here. But the implication is that fuzzy logic is better than conventional logic precisely when safety is most at risk, i.e. when the reactor is not in normal, stable operation. I'm skeptical. But if true, there may soon be a pressing need for formal verification of fuzzy systems, whatever that may mean. Paul Eggert [It better be better, or else someone will be guilty of Zadehmy. PGN] ------------------------------ Date: Wed, 15 May 91 00:42:58 EDT From: states@ncbi.nlm.nih.gov (David States) Subject: Of Two Minds about Privacy??? An article in this month's Scientific American states that "privacy legislation has been nickeled and dimed to death" ... but "Maybe that is the way most Americans want it. According to a survey commissioned by Equifax, one of the three major credit reporting bureaus ..." The article then goes on to cite a Harris survey that lists credit reports and loan approvals as examples where most Americans accept invasion of their privacy. Beyond being an obviously self-serving conclusion, it misses the point. A loan request is initiated by the individual and most people would distinguish between a credit check that you have authorized and one done without your knowledge. Is this an isolated incident or the opening salvo in a PR blitz designed to systematically undermine our privacy rights? David States ------------------------------ Date: Tue, May 14, 1991 9:24:57 AM From: Adam Engst Subject: Re: Horible Speling (RISKS-11.66) I must argue slightly with the story of the teacher who can't spell because he's used to having his computer do it for him. The spell check is a crutch for some, but for many of us it is merely an aid to prevent irritating and subtle errors from finding their way into our texts. Almost no words flagged by my spell checker are words I don't know how to spell, and if they happen to be, I usually figure it out after a while. For some strange reason my fingers wanted to type "propoganda" instead of the correct "propaganda" for a while, but thanks to the continued vigilance of Nisus's excellent spell checker, I've gotten over that unfortunate problem. My point is that the spell checker does not have to be crutch. It can be a learning tool as well, but only if the companies producing word processors design it as such. Complain to them if the teachers of today cannot spell without that electronic crutch. Adam C. Engst Editor of TidBITS, the weekly electronic Macintosh journal ------------------------------ Date: Tue, 14 May 91 20:15:16 EDT From: Scott Barman Subject: Re: Changing class grades in Alaska (Gottehrer, RISKS-11.62) There were things that happened a long time ago (10 years??) when I was a student at the University of Georgia. They ran what was called the University System Computer Network which basically was leased lines and terminal controllers to connect the state universities to a CDC Cyber (70/74 then a 170) running NOS sitting in the computer center at UGA. I don't have to tell RISKS followers about the security problems under NOS! The unfortunate thing about is that this machine was used by University System schools for more than just student computing. There was one "rumor" that allegedly someone at (I think) Georgia Southern changed grades for students at schools other than GSC. I remember assisting a friend who was working for the campus newspaper (the Red and Black) and getting hung up on by several computer center and university officials when we called for information. We were later lectured by the director of the computer center at that time about minding our own business. The other "rumor" could not be confirmed by print and electronic media since it was a case settled out of court and the records sealed (allegedly because it contained a record of exactly what happened and they determined it to be a risk to the USCN). Allegedly, someone at West Georgia College broke into thier payroll system and had some checks printed in his name--not an alias. Both of these happened sometime around 1980-82, before computer-related laws made it to the books. I hope there's someone in Georgia who remembers these and can give better details! [...] scott barman scott@nbc1.ge.com ------------------------------ Date: Tue, 14 May 91 14:27:49 PDT From: doug@NISD.CAM.UNISYS.COM (Doug Hardie) Subject: Re: Emergency off switch - IBM 1620 (RISKS-11.66) I ran a large college computer center many years ago with an IBM 1620. Because the machine was easily accessible by students, we had numerous instances of someone pulling the emergency off switch. The IBM maintenance man got tired of coming out to put it back in. There was a small pin that fell down to the bottom of the cabinet that prevented you from pushing it back in. He showed us how to reset it so he wouldn't be bothered by that anymore. We never encountered any equipment damage from these incidents. We did encounter another "feature" of the 1620 that was destructive of hardware. Two of us developed a 3 or 4 instruction program that generated some number series. The object was to find the millionth number in the series, or something like that. The program consisted of several instructions that executed quickly (for a 1620) and one divide instruction that was about 100 times longer. We started it running on a Friday evening expecting it would run most of the weekend. After checking some of the early values, we decided to go out to a fast food joint for dinner. We returned about 2300 to find smoke pouring out of the computer room windows. We pulled the emergency power off switch and opened the windows. Didn't want to call the fire department - too much paperwork and embarrassing questions. After the room cleared so we could see, we opened the swinging racks in the back of the control unit. On the end of the innermost one was a Bud box bolted on with a power transistor heat sinked to the outside. That transistor was bubbling some kind of ooze and lots of smoke. We called our maintenance man who came right away. The transistor was part of the divide logic (a late add-on in the design). He first asked what program we were running. Then he asked why we were violating the divide instruction duty cycle. We had never heard of any such restriction, but he was insistent and spent hours searching through the volumes of schematics looking for it. Finally, he grabbed a marker and wrote a divide instruction duty cycle on the cover of one and said something to the effect of there it is, I told you so... > Men were men in those days, and giants strode the earth. and students caused them all to crash regularly. -- Doug ------------------------------ Date: Tue, 14 May 91 15:16:48 cdt From: Bob Wilson Subject: The big red switch on old IBM systems The big red power-off switch which used to appear on the panel of the 1620 and earlier machines (650, 70x) came with lots of warnings to the users NEVER to use it, as has been mentioned here recently. As so often happens, it was a device which started out serving a real need and lived beyond it. On machines like the 650, where ALL storage was on a magnetic drum enclosed in the main cabinet (mag core was added later), slow warming up and cooling off was critical. The drum heads were fixed over the magnetic surface, not floating like current disk heads, and of course had to be close to the surface. They were mounted to rigid metal bars to keep the distance fixed, but of course all the various materials had different coefficients of thermal expansion. If you used the "correct" power down procedure, all the cooling air would keep flowing and the system could come down without turning new grooves in the drum. If there were to be a fire, however, of course you wouldn't want to keep pumping in air! Hence the emergency switch. Since it was (we were told) sure to damage the machine if you turned it off with the emergency switch, the switch could not be turned back on without a call from your friendly customer service engineer. The switch had a little pin inside which had to be retracted before you could flip the switch back to the on position. All of that made pretty good sense for the 650 and similar machines. By the 1620, though: The logic was solid state rather than tubes, and hence generated much less heat. The main memory was core. The interior air driving was reduced to biscuit fans similar to present practice. BUT the same old switch was installed, so that in theory if it got flipped you had to call for service. Most of us found out how to reset it, because some novice was sure to use it sooner or later. Bob Wilson Math. Dept., Univ. of Wisconsin wilson@math.wisc.edu ------------------------------ Date: Wed, 15 May 91 08:24:54 -0700 From: vancleef@garg.nas.nasa.gov (Robert E. Van Cleef) Subject: Re: Emergency off switch... (RISKS-11.66) On the console of our Amdahl mainframe system, there is a large button labled "Emergency Pull", which had an equivalent function to the one described by Martin Ewing in RISKS-11.66. One weekend we had a problem with the system that the assigned Customer Engineer did not consider serious enough to justify leaving home, inspite of the arguments from the local Site Manager that the primary subsystem could not run. The Site Manager then called him from the phone adjacent to the console. He mentioned this switch to the CE, casually asking what would happen if it was pulled. Upon confirmation that is a priority service call would be required to reset the switch, the Site Manager calmly pulled the switch and said "Gee; the system seems to be dead!" The CE sighed, and came in... Bob Van Cleef vancleef@nas.nasa.gov NASA Ames Research Center (415) 604-4366 ------------------------------ Date: Wed, 15 May 91 01:00:41 EDT From: al@escom.com (Al Donaldson) Subject: Re: Emergency off switches R. I. Cook mentions the elaborate power control systems for old-time computer centers. This reminds me of the time I worked as a transmitter engineer for a UHF TV station (~1 megawatt). The transmitter was housed in a Butler building out in the boonies, with the transmitter enclosure in the middle of the floor. The enclosure was perhaps 15 by 20 feet, water-cooled, and you could enter the enclosure through a door to perform maintenance. Other amenities were real primitive, with the toilet facilities sort of hidden in a back corner behind the transmitter enclosure. This was a family operation and one day the owners were in town to do some work on the antenna (nosir, I don't climb 1100 feet in the air for $3/hour...) The wife of one of the owners came along, and after a while, she excused herself to go to the "ladies room." I guess no one must have told her where the toilet was located, because the next thing we heard was this incredibly loud BANG as she tripped the interlocks to the transmitter door and shut down the transmitter. Al ------------------------------ Date: Wed, 15 May 91 17:03:40 GMT From: schwartz@nynexst.com (S. H. Schwartz) Subject: Re: Emergency off switch - IBM 1620 We had an IBM 1130 in high school (late 70s). One day a student noticed smoke coming out of the rear of the console. He naturally pulled the EMERGENCY STOP switch. We later discovered that someone had dropped a smoldering cigarette behind the console. Moral: When that big, red button is staring you in the face, day after day, it's easy to find an excuse to use it. S. H. Schwartz Expert Systems Laboratory NYNEX Science and Technology Center White Plains NY 10604 914-683-2960 ------------------------------ Date: Wed, 15 May 91 11:36:47 -0700 From: hamlet@eecs.ee.pdx.edu (Dick Hamlet) Subject: Real men and the IBM 1620 Recalling the IBM 1620 destructive power switch and the days of "real men" is too good an opening to resist. That machine had a console table on which was mounted a printer for the operator, the only i/o device that a human could read directly. It was used to print error messages, or for low-volume output from programs. (For REAL output, one punched cards and listed them off line on tab equipment.) Later versions of the 1620 used an IBM Selectric typewriter for console i/o, but in 1965 I used an older machine at Argonne National Labs that was fitted with a standard IBM model C electric typewriter. The unit was mounted near the right edge of the table, in such a way that when the carriage returned (under program control!), it was capable of dealing a passing human a nasty blow in the groin. (Not so many real men among the long-term users!) But not to worry, IBM soon recognized the risk, and made available for lease a sort of bent wire guard that delimited the area in which it was unsafe to pass. I wish I knew how much this guard leased for, and what it was called in the 1620 parts list. ------------------------------ Date: Wed, 15 May 91 16:20:51 PDT From: "Roger H. Goun 13-May-1991 2100" Subject: RISKS of redistributing SF-LOVERS Digest I maintain a distribution list with which I redistribute SF-LOVERS Digest to a large number of DECcies. While less convenient than direct mailing from the moderator, this arrangement avoids clogging Digital's Internet gateway with nonessential messages. Today I accidentally forwarded another, completely unrelated message to the distribution list. The circumstances may be of interest to RISKS readers. I have a VMS command procedure that does most of the work of archiving and mailing an issue of the digest. When I'm using DECwindows Mail, as I normally do, I fire the command procedure off from FileView, a GUI for manipulating programs and other files. When I'm logged in from home, I can do it by pressing a couple of keypad keys in character-cell Mail. I haven't done it from character-cell Mail in quite some time, but I was working at home this afternoon, and there was a backlog of digests since I'd been out of town for a few days, so I thought I'd clear out the digests awaiting redistribution. Unfortunately, I fumble-fingered the keypad and dispatched the wrong message. Now I'm not entirely stupid, so I built some sanity-checking into this command procedure. The first thing it does is search for the "Volume m : Issue n" string in the digest, and it dies with a warning if the string can't be found. Unfortunately, my command procedure had no trouble finding the magic string in this particular message. Next, the command procedure searches the archive for a file called m.SFL, where m is the issue number extracted from the message in hand, and dies if it finds such a file, assuming that this message must be a duplicate. (The archive gets purged every month, so volume/issue rollover isn't a problem.) No such archive file was found, so the unrelated message was sent out. What WAS this bogus message? Why, an issue of RISKS, of course! RISKS and SF-LOVERS share a common digest format, which defeated the first check. SF-LOVERS publishes more frequently than does RISKS, so the corresponding issue of SF-LOVERS had already been purged from the archive. So much for the sanity checks. Lessons learned: - use of a less familiar user interface (in this case, a different mail program) can be error prone. - sanity-checking doesn't, perhaps because the world isn't sane. - God is an iron (how else to explain the irony?). Roger H. Goun, Digital Equipment Corporation, Nashua, NH 03062, +1 603 881 0022, goun%ddif.enet@decwrl.dec.com, {uunet,sun,pyramid}!decwrl!ddif.enet!goun ------------------------------ Date: Tue, 14 May 91 13:12:59 PDT From: jbuck@ohm.berkeley.edu (Joe Buck) Subject: re: case of the replicated errors Erik Fair reports on an e-mail disaster that generated tens of thousands of mail messages reporting errors, all directed at his site. Neil Rickert summarizes the conditions that produced the error roughly as follows 1) The To: line had a syntax error (a missing ">" character) 2) The mail was deliverable, so sendmail delivered it. 3) Sendmail reported the error to the originator by mail. 4) Sendmail did not "repair" the error. 5) The message went to a mailing list with many recipients. Erik Fair's diagnosis: the combination of #2 and #3 caused the disaster (by causing every sendmail program on the net that saw the message to produce an additional error report). Neil Rickert wants to focus on #1 and #5, putting blame on either the sender, the originating mailer, or the mailing list maintainer, and admonishing people not to ever generate bogus mail messages and, if that fails, have mailing list maintainers make sure that it never happens. Sorry, Neil. Robust software does not cause disasters when presented with bad input, and many mailing list maintainers are not experts in network protocols. This kind of disaster has happened before, on Usenet. Someone, somewhere, managed to inject a tab into the Message-ID header field, and the offending message (called an "article" in Usenet-speak) got transmitted all over the net. When this message was received by a site running the standard Usenet news software (version 2.11 of B news at whatever patch level was current at the time), its Message-ID was inserted into the history file, which uses tabs to delimit fields. This had two results: 1) The "duplicate article" check broke: the software "believed" that it had no copy of the article, and pairs of sites that used the "ihave/sendme" protocol generated thousands of duplicate copies. 2) The "expire" program also could not parse the history file entry (this program is responsible for deleting old news), so it was incapable of removing the offending articles, and it generated verbose error messages on the log file. The combination caused an explosion of Usenet traffic, limited only when major sites' disk partitions filled up completely, preventing them from accepting any more. Thousands of hours were spent all over the net cleaning up after this disaster. Rick Adams (head maintainer of 2.11 news) then issued an emergency patch that, on receipt of an article with whitespace in the Message-ID, would change the whitespace to "?" characters (or some other character). Notice that this solution violates the "Thou shalt not rewrite a header" holy writ, but I'm for it. Neil, do you think that exhorting people to make sure that their software never put a tab in their message-ID, and assigning moderators special responsibility, is a satisfactory solution to problems like this? Of course not. Once in a while we'll find that our software systems permit disasters to happen. It's not good enough to try to prevent bad input from ever reaching a system; it must be able to deal with any input. The problem with making software idiot-proof is that the idiots are so damn clever. ------------------------------ Date: Wed, 15 May 91 16:56:20 -0400 From: John R MacMillan Subject: Re: Case of the Replicated Errors | In spite of the syntax error, it is correct to attempt to deliver the mail |if this is still possible. Robustness requires this. I disagree. As you pointed out, the message violated the message standard, and so should NOT be passed on. | Once a serious error has been discovered, it is correct to report this. |Reliability of systems depends on reporting of errors. | | Items 2 and 3, then are just plain good programming practice. They cannot |be blamed for this problem. Individually, in the correct circumstances, this is true. But to do both in this situation was not. As you pointed out, sendmail could not correct the header, so the MTA should have either passed the mail (perhap annotating it with some sort of error header, as MMDF would do in this same case), or bounced it with a complaint. ------------------------------ End of RISKS-FORUM Digest 11.68 ************************