The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 11 Issue 68

Thursday 16 May 1991

Contents

o Is fuzzy control more suitable for nuclear reactors?
Paul Eggert
o Of Two Minds about Privacy???
David States
o Re: Horible Speling
Adam Engst
o Re: Changing class grades in Alaska
Scott Barman
o Re: Emergency off switch - IBM 1620
Doug Hardie
Bob Wilson
o Re: Emergency off switches
Robert E. Van Cleef
Al Donaldson
S. H. Schwartz
Dick Hamlet
o RISKS of redistributing SF-LOVERS Digest
Roger H. Goun
o Re: case of the replicated errors
Joe Buck
John R MacMillan
o Info on RISKS (comp.risks)

Is fuzzy control more suitable for nuclear reactors?

Paul Eggert <eggert@twinsun.com>
Tue, 14 May 91 18:25:27 PDT
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]


Of Two Minds about Privacy???

David States <states@ncbi.nlm.nih.gov>
Wed, 15 May 91 00:42:58 EDT
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


Re: Horible Speling (RISKS-11.66)

Adam Engst <ace@tidbits.UUCP>
Tue, May 14, 1991 9:24:57 AM
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


Re: Changing class grades in Alaska (Gottehrer, RISKS-11.62)

Scott Barman <scott@nbc1.ge.com>
Tue, 14 May 91 20:15:16 EDT
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


Re: Emergency off switch - IBM 1620 (RISKS-11.66)

Doug Hardie <doug@NISD.CAM.UNISYS.COM>
Tue, 14 May 91 14:27:49 PDT
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


The big red switch on old IBM systems

Bob Wilson <wilson@math.wisc.edu>
Tue, 14 May 91 15:16:48 cdt
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


Re: Emergency off switch... (RISKS-11.66)

Robert E. Van Cleef <vancleef@garg.nas.nasa.gov>
Wed, 15 May 91 08:24:54 -0700
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


Re: Emergency off switches

Al Donaldson <al@escom.com>
Wed, 15 May 91 01:00:41 EDT
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


Re: Emergency off switch - IBM 1620

S. H. Schwartz <schwartz@nynexst.com>
Wed, 15 May 91 17:03:40 GMT
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


Real men and the IBM 1620

Dick Hamlet <hamlet@eecs.ee.pdx.edu>
Wed, 15 May 91 11:36:47 -0700
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.


RISKS of redistributing SF-LOVERS Digest

"Roger H. Goun 13-May-1991 2100" <goun@ddif.enet.dec.com>
Wed, 15 May 91 16:20:51 PDT
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


re: case of the replicated errors

Joe Buck <jbuck@ohm.berkeley.edu>
Tue, 14 May 91 13:12:59 PDT
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.


Re: Case of the Replicated Errors

John R MacMillan <john@scocan.sco.com>
Wed, 15 May 91 16:56:20 -0400
| 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.

Please report problems with the web pages to the maintainer

Top