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 3 Issue 71

Tuesday, 30 September 1986


o Deliberate overrides?
Herb Lin
Alan M. Marcum
Eugene Miya
o "Friendly" missiles and computer error - more on the Exocet
Robert Stroud
o Re: Reliability, complexity, and confidence in SDI
Michal Young
o My understanding of "path" and "bathtub curve"
Bob Estell
o More artificial than intelligent? (Autokeywords)
Bob Estell
o A Viking lander query
o Note on ARPANET congestion
Nancy Cassidy
o Indeed, the network is getting old
Jonathan Young
o [MULTIPLE COPIES OF RISKS-3.70? Some of you were lucky enough to get 4 | copies, 2 after last reboot! Foonly Wizard David Poole strikes again? / Retries may also be due to net delays, timeouts in ACKS? Sorry. PGN] /
o Info on RISKS (comp.risks)

Deliberate overrides?

Tue, 30 Sep 1986 00:58 EDT
    From: Scott E. Preece 

Deliberate Overrides - mechanical, even

Alan M. Marcum, Consulting <marcum@Sun.COM>
Tue, 30 Sep 86 09:56:41 PDT
Though perhaps not strictly computer related, I thought the following
might be of interest to the Risks forum.

The Piper Arrow is a four-place, single-engine airplane with retractable
landing gear.  Piper has a wonderful airspeed switch in the landing
gear system which will automatically lower the gear if the airspeed is
too low.  One side effect of this is that during a low-speed climb, the
gear may drop (or might never come up during takeoff).  Climbing with
the gear down will seriously erode climb performance (up to 500 feet
per minute, with max. climb around 1000 fpm), just when you want
MAXIMUM climb performance!

To overcome this, Piper installed a "gear override" handle, which can
be latched in the OVERRIDE position.  Many, many Arrow pilots routinely
take off with the override engaged, to ensure that the gear retract
when the pilot wants them up.

Why did Piper install this mechanism?  The reason most often cited is
to help prevent gear-up landings.  It is interesting that a number of
Arrow pilots have landed gear-up, having forgotten to disengage the
override after having gotten into the habit of depending on it.

I've flown retractable singles built by Piper, Cessna, Beech, and
Mooney.  Piper is the only one with the airspeed override.  All
manufacturers, including Piper, have a warning horn which sounds if
power is reduced past some threshhold with the gear up, though.

What's the point?  In my opinion, the automatic system increases pilot
workload during a critical time (takeoff and initial climb).  It's not
something on which one should EVER depend: it might fail.  It's prone
to lower the gear at inopportune moments — times a pilot would
absolutely never lower the gear; times when having the gear down is
seriously more dangerous than having the gear up (certain emergency
situations, for example).  And, you need the override.

Certainly, performance- or functionality-limiting devices can be
useful.  They must be thought through carefully, and considered as part
of the whole, rather than as an isolated system.

Alan M. Marcum              Sun Microsystems, Technical Consulting
...!{dual,decvax}!sun!nescorna!marcum   Mountain View, California

Re: Deliberate overrides and multiple causes (blame)

Eugene Miya <eugene@AMES-NAS.ARPA>
30 Sep 1986 1330-PDT (Tuesday)
  From: "Scott E. Preece" <preece%ccvaxa@GSWD-VMS.ARPA>
  >  /**** ccvaxa:fa.risks / LIN@XX.LCS.MI /  2:47 am  Sep 29, 1986 ****/
  >  > From: Charles R. Fry <Chucko at GODZILLA.SCH.Symbolics.COM> [...]
  >  > From: LIN@XX.LCS.MIT.EDU [...]

Just a point of information: the Soviets just announced that they planned
to get rid of reactor control rod overrides, and that one manual override
at TMI accentuated the problem ("But overall system worked" summarizing
the pro-nuclear viewpoint).

Is it possible to write a rule without exception?

  >"You know, if I do what you've asked, the bomb is going to fall on the wing 
  > and probably strip off your starboard control surfaces."
  >"Yes, I know, do it anyway."

Yes, I can see this happening, but it reminds me of the film Dark Star.

"Talk to the bomb . . . about phenomenology....."

--eugene miya,   NASA Ames Research Center,   eugene@ames-aurora.ARPA

Re: "Friendly" missiles and computer error - more on the Exocet

Robert Stroud <>
Tue, 30 Sep 86 14:43:24 gmt
There is a very interesting BBC TV documentary in the Horizon series called
"In the wake of HMS Sheffield" which is well worth seeing if you get the
chance. It discusses the failures in technology during the Falklands war
and the lessons which have been learnt from them, and includes interviews
with participants on both sides.

Naturally the fate of HMS Sheffield features prominently, and the chronology
given by Rob MacLachlan matches the program in most respects. However, I'm
afraid it says nothing about the Exocet homing signal being friendly - I was
specifically looking out for this. Instead, according to the documentary, the
device which should have detected the homing signal is situated next to the
satellite transmission device and was simply swamped by the signal from a
telephone call to London in progress at the time - this backs up Peter's
definitive account.

A couple of other points from the documentary are worth mentioning. Chaff
was indeed effective in helping one ship avoid an Exocet (I forget which one)
but it is by no means fool proof. The fuse needs to be set manually on deck
and must be exact, taking into account lots of factors like wind direction,
ship's course, distance from missile, etc. If you get it wrong, the distraction
comes too early or too late. There was a nice piece of computer graphics
showing the difference half a second could make - needless to say, they are
working on an automatic fuse!

The Argentinian planes were able to avoid radar detection using a technique
called "pecking the lobes". Basically they exploit the shape of the radar
cone and the curvature of the earth by flying level until they detect
a radar signal, then losing height and repeating the process. As Rob said,
they only need to rise up high enough to be detected at the last minute
when they fire the Exocets and turn for home - even this trace would only
be visible very briefly on the radar display and could easily be missed.
Thereafter the Exocets are silent until the last few seconds when they
lock onto the target to make last minute course corrections.

This problem has been dealt with by building radar devices that can be used
from helicopters several thousand feet up so they can see further over the

There was also a discussion about whether it would be feasible to install
anti-missile weapons in cargo ships such as the Atlantic Conveyor (sunk
twice by the Argentinians with Exocets who mistook it for one of the aircraft
carriers). Apparently, installing a weapon would be possible, but to be
effective it would need all the command & control computer systems as well to
keep track of everything else that was going on, and that would not be

Robert Stroud, Computing Laboratory, University of Newcastle upon Tyne.

ARPA (or ucl-cs.ARPA)
UUCP ...!ukc!cheviot!robert

Re: Reliability, complexity, and confidence in SDI software

Michal Young <young@ICSC.UCI.EDU>
Mon, 29 Sep 86 22:57:46 -0800
Bob's message, and some of the replies, seem to be using the term `path' in
a sense I am unfamiliar with, since they refer to (large but) finite numbers
of paths in software.  If software contains loops, isn't the number of paths
infinite?  And therefore, after any finite amount of use, isn't the percentage
of paths tested actually zero?  If there is another commonly accepted
meaning of `path' through a piece of software, please fill me in on it.

I have a similar problem with the term `state.'  It seems to be used to
refer to major states like `ready to run' and `running', whereas a fault may
be sensitive to smaller-grain state like `i = 0 and j > 999'.  It may be 
possible to design software to have a small number of major states, but 
the number of possible data+control states of any useful program is very
large indeed.

>    1. The curve for debugging software has a DOWNslope and length that is 
>    some function of the number of possible paths through the code.
>    ... 
>    3. Confidence builds as one approaches the 90% [or other arbitrary level]
>    point in testing the number of possible paths.
>    4. The reason that we haven't built confidence in the past is that we've
>    often run thousands of hours, without knowing either:
>     a. how many paths got tested; or
>     b. how many paths remained untested.

By the terminology I am familiar with, 3 is "never" and 4(b) is 
"an infinite number" for every useful piece of software, always.

--Michal Young,   UC Irvine,

My understanding of "path" and "bathtub curve"

"ESTELL ROBERT G" <estell@nwc-143b.ARPA>
30 Sep 86 09:04:00 PST
I don't claim to use "path" in a way that may be common in graduate courses
in software engineering.  My use is based on the highway map analog; e.g.,
there are many paths through the LA freeway system that one might take
from Irvine to Mammoth on a ski weekend.  One can drive any of the paths
any number of times [loops?]; for lack of good all-way interchanges, some
paths might not work well [design errors?]; because of temporary traffic 
congestion, some paths might be troublesome on some days [data sensitivity?].

I agree that software *is* sensitive to "minor" state conditions; e.g., loop
counts of "zero" and "n+1" [where "n" was the intended limit] are notorious.
I contend that it *should NOT* be; i.e., that proper design and testing can
reduce such errors to a tolerable range.  A goal of good software design is 
to construct "modules" whose internal states are insensitive to all legal
arguments, and whose entry code screens out all illegal arguments; at least
that's my personal understanding of one [of several] key benefits of "data 
hiding" and "defensive programming."

Another respondent disputed the "downslope" claim, because his experience
was that the error rate degenerates to some constant level.  Well, all the
bathtubs I've seen do have bottoms.  One can expect some non-zero number of
bugs to persist; let's only hope that it's tolerably low - lower than during
"alpha testing."  Finally, if some "new release" goes badly sour [e.g., the
"new" ARPANET s/w?]  because it tries to "add on" [vice "design in?"] new
features, maybe that's the equivalent to the "wear out" upslope in mechanical 
designs.  That may be what we've seen with some older operating systems that 
tried to "add on" time sharing, security, or multi-processor logic.


More artificial than intelligent? (Autokeywords)

"ESTELL ROBERT G" <estell@nwc-143b.ARPA>
30 Sep 86 10:14:00 PST
Computer titles on documents are going to take over. Don't fight it.
It could be worse; they might have to be "bar coded."  
Instead, just use "human" sub-titles; e.g.
ANTLERS, TREETOPS, MYSTERY; (or "Who Goosed the Moose?")

A Viking lander query

Peter G. Neumann <Neumann@CSL.SRI.COM>
Tue 30 Sep 86 20:26:06-PDT
Is there a RISKS reader who can report on what the Viking lander software
really did?  Was it used for landing? or just for communication and control
of onboard equipment?  "Working the first time" would be much more
impressive if it were for landing, whereas the rest is more easily testable
on the ground.

Note on ARPANET congestion

Nancy Cassidy <>
Mon, 22 Sep 86 12:22:13 EDT
Report on Investigation Request #: IR86-0051-ARPANET-SY   Report #: 1
Date of Report:  9/22/86                                  Priority: 2
Reporting:  open

IR Title:  ARPANET congestion

Summary of Problem:

Another problem exists for users on MILNET who must access the  BBNNET
(especially  users  on DDN1 and DDN2).  Currently, there is no gateway
between the MILNET and BBNNET.  Instead, traffic  passes  through  the
ARPANET  to  an  ARPANET  Gateway  in  order to reach the BBNNET.  The
critical congestion problems the ARPANET is experiencing causes TELNET
and FTP connections to time out and mail messages from MILNET hosts to
take up to 2-3 days to be delivered to BBNNET hosts.

One other result of network  congestion  is  the  Monitoring  Center's
ability  to  effectively  monitor operations.  The number of traps and
status messages has increased proportionately to the severity  of  the
congestion.   This  dramatic  increase in network messages received by
the MC consumes CPU space and slows down C/70 performance to the point
where it affects monitoring and control of the network.

        [Further reporting and recommendations truncated...]

Indeed, the network is getting old

Jonathan Young <young-jonathan@YALE.ARPA>
Tue, 30 Sep 86 12:59:47 edt
Here at Yale we have been aware of two problems:  host tables are
overflowing and mail is bouncing.  Actually, we think that SENDMAIL
connections (more often from BSD4.3 machines) are timing out and retrying.
This has resulted in dozens of copies of certain messages.  I enclose a copy
of a message from our network administrator.

I'm very surprised that others haven't commented about the virtual
unavailability of the ARPANET.  On the other hand, Yale's connection is via
a 9600 BAUD LINE to Harvard.  Sigh.
                                        Jonathan (YOUNG-JONATHAN@YALE.ARPA)

              [Is that anywhere near the 50 YARD LINE?  (rELIability!)  PGN]

  From: Morrow Long <long@YALE.ARPA>
  To: department
  Subject: ARPAnet mail problems

  We began to see a large problem with repeating incoming arpanet mail
  messages in August (when cheops was still - the mail name host) -
  especially in the department bboard where a MIT site was flooding our
  newsgroups and bulletin boards with the mail internet bulletin board
  messages.  After christening Yale-Eli as Yale.ARPA (a dedicated SMTP mail
  server) we have continued to experience the problem with repeating messages
  emanating from some hosts.

  From statistics we have gathered on the problem we have noticed that many of
  the problem hosts are running 4.3bsd.  Our problem may not be due to 4.3bsd
  TCP/IP (nor Sendmail/SMTP) but may be brought on by problems with arpanet
  congestion/delays wrecking session protocols.

  To alleviate and eventually rectify the problem we have taken the following

  1. We have notified the administrators of the remote sites to
     remove the repeating messages from their spool queues.

  2. We are tracing Sendmail/SMTP debugging messages to session
     logfiles to capture maximum information.

  3. Luis has agreed to act as moderator for one of the most troublesome
     groups ('apollo@yale'), screening out duplicates before reposting them
     to the world.

  4. A 'sweep' daemon has been created and installed on Eli to check for
     duplicate messages to bboards and mailing list in the mail queue and
     remove them for exact matches on Message-ID, sender and subject.  At least
     one copy is always allowed through.  Even this drastic program will allow
     repeat messages if they arrive outside of the queue sweep window for

  5. We will be investigating the 4.3bsd Unix sendmail program for
     incompatibilities with our SMTP servers.

                H. Morrow Long, Computing Facility

       [This is just the tip of the iceberg on reports and messages.  The
        TCP-IP BBOARD IS OVERFLOWING.  All sorts of contributing factors are
        being discussed.  Dramatic increase in net traffic, total saturation of
        the IMPs, hosts that stick with 4.2bsd instead of 4.3, weak gateways,
        mail distributions to multiple users at the same site, etc.  Who knows?
        No one yet.  The total collapse of the ARPANET on 27 Oct 1980 was only 
        for four hours or so, and has not happened since; this fiasco has been 
        going on for at least three weeks, and the network seems to be
        rotting completely.

        So, if you got this far in the issue, and are getting a private
        copy of RISKS, please let me know if your site now has a BBOARD or
        redistribution and you can live without a private copy of RISKS.
        (Each time I suggest that I actually do get a few willing people.)

Please report problems with the web pages to the maintainer