From: turner@lanl.gov (John A. Turner)
Date: 28 Feb 1995 23:31:39 GMT
Organization: Los Alamos National Laboratory
In article <1995Feb27.143252.2189@driftwood.cray.com> jjd@cray.com (Jeff Drummond) writes:

 > The oft-repeated myth of the Venus probe lost due to a missing Fortran
 > comma been debunked in alt.folklore.computers and elsewhere.

Here's something Dan Pop posted back in September (yeah, I'm an e-mail
packrat).  I hope he won't mind me re-posting it (maybe it'll save him
the trouble)...

----------------------- Begin Included Message -------------------------

Newsgroups: comp.lang.fortran
From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Re: Urban myth?
Organization: CERN European Lab for Particle Physics
Date: Mon, 19 Sep 1994 10:56:50 GMT

In <kemidb.779968115@aau> kemidb@aau.dk (Dieter Britz) writes:

>Over the years, I have several times seen reference to this piece of code:
>
>      DO 10 I = 1.10
>      ...
>10    CONTINUE
>
>It is said that this error (which the compiler, of course, interprets as
>the assignment statement DO10I=1.10) was made in a space program program,
>and led to a rocket crash. Is this factual, or is this an urban myth in
>the computer world? 

>From the alt.folklore.computers FAQ:

III.1 - I heard that one of the NASA space probes went off course and
        had to be destroyed because of a typo in a FORTRAN DO loop.
        Is there any truth to this rumor?

As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other newsgroups, this turns
out to be a confusion of two separate events.

The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not Mars).  Several
incorrect or partially correct versions of what really happened were
posted in comp.risks; the best of these cited a NASA publication called
"Far Travelers" by Oran W. Nicks, but still did not have the whole story.

Then in issue 8.75 we found out what really happened...

|  Date: Sat, 27 May 1989 15:34:33 PDT
|  From: Peter Neumann <neumann@csl.sri.com>
|  Subject: Mariner I -- no holds BARred
|  
|  Paul Ceruzzi has written a truly outstanding book for the new show
|  that opened two weeks ago at the Smithsonian National Air and Space
|  Museum.  The exhibit and the book are both entitled "Beyond the Limits
|  -- Flight Enters the Computer Age".  Both are superb.  Go for it (them).
|  
|  Paul has dug into several cases treated previously in RISKS and in
|  issues of the ACM Software Engineering Notes, and has been able to
|  resolve several mysteries.  In particular he considers the case of
|  Mariner I, about which various inaccurate stories have been told.
|  Intended to be the first US spacecraft to visit another planet, it was
|  destroyed by a range officer on 22 July 1962 when it behaved
|  erratically four minutes after launch.  The alleged missing `hyphen'
|  was really a missing `bar'.  I quote from Paul's book, pp. 202-203:
|  
| #  During the launch the Atlas booster rocket was guided with the help
| #  of two radar systems.  One, the Rate System, measured the velocity of
| #  the rocket as it ascended through the atmosphere.  The other, the
| #  Track System, measured its distance and angle from a tracking
| #  antenna near the launch site.  At the Cape a guidance computer
| #  processed these signals and sent control signals back to the
| #  tracking system, which in turn sent signals to the rocket.  Its
| #  primary function was to ensure a proper separation from the Atlas
| #  booster and ignition of the Agena upper stage, which was to carry
| #  the Mariner Spacecraft to Venus.
| #  
| #  Timing for the two radar systems was separated by a difference of
| #  forty-three milliseconds.  To compensate, the computer was instructed
| #  to add forty-three milliseconds to the data from the Rate System
| #  during the launch.  This action, which set both systems to the same
| #  sampling time base, required smoothed, or averaged, track data,
| #  obtained by an earlier computation, not the raw velocity data
| #  relayed directly from the track radar.  The symbol for this smoothed
| #  data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n],
| #  where R stands for the radius, the dot for the first derivative
| #  (i.e., the velocity), the bar for smoothed data, and n for the
| #  increment.
| #  
| #  The bar was left out of the hand-written guidance equations.  [A
| #  footnote cites interviews with John Norton and General Jack Albert.]
| #  Then during launch the on-board Rate System hardware failed.  That in
| #  itself should not have jeopardized the mission, as the Track System
| #  radar was working and could have handled the ascent.  But because of
| #  the missing bar in the guidance equations, the computer was
| #  processing the track data incorrectly.  [Paul's EndNote amplifies:
| #  The Mariner I failure was thus a {\it combination} of a hardware
| #  failure and the software bug.  The same flawed program had been used
| #  in several earlier Ranger launches with no ill effects.]  The result
| #  was erroneous information that velocity was fluctuating in an
| #  erratic and unpredictable manner, for which the computer tried to
| #  compensate by sending correction signals back to the rocket.  In fact
| #  the rocket was ascending smoothly and needed no such correction.  The
| #  result was {\it genuine} instead of phantom erratic behavior, which
| #  led the range safety officer to destroy the missile, and with it the
| #  Mariner spacecraft.  Mariner I, its systems functioning normally,
| #  plunged into the Atlantic.

The DO-loop incident did happen at NASA, and at about the same time.
As told by Fred Webb in alt.folklore.computers in 1990:

|  I worked at Nasa during the summer of 1963.  The group I was working
|  in was doing preliminary work on the Mission Control Center computer
|  systems and programs.  My office mate had the job of testing out an
|  orbit computation program which had been used during the Mercury
|  flights.  Running some test data with known answers through it, he was
|  getting answers that were close, but not accurate enough.  So, he
|  started looking for numerical problems in the algorithm, checking to
|  make sure his tests data was really correct, etc.
|
|  After a couple of weeks with no results, he came across a DO
|  statement, in the form:
|       DO 10 I=1.10
|  This statement was interpreted by the compiler (correctly) as:
|       DO10I = 1.10
|  The programmer had clearly intended:
|       DO 10 I = 1, 10
|
|  After changing the `.' to a `,' the program results were correct to
|  the desired accuracy.  Apparently, the program's answers had been
|  "good enough" for the sub-orbital Mercury flights, so no one suspected
|  a bug until they tried to get greater accuracy, in anticipation of
|  later orbital and moon flights.  As far as I know, this particular bug
|  was never blamed for any actual failure of a space flight, but the
|  other details here seem close enough that I'm sure this incident is the
|  source of the DO story.

Project Mercury's sub-orbital flights were in 1961, and its orbital
flights began in 1962.  I forwarded the above to comp.risks, slightly
abridged, and it appeared there in issue 9.54.

The erroneous claim that the DO-loop bug was the bug that killed Mariner I
apparently originated with, and certainly was propagated by, the book
"Software Reliability: Principles and Practices" by G(lenford) J. Myers
(John Wiley & Sons, 1976).  I haven't read it myself; I've seen the page
numbers 7 and 275 attributed to the assertion.  I expect both are right.
This book also describes the bug as a "billion-dollar error", which is
too large by a factor of about 50.

In some earlier postings it was suggested that Myers be located and
asked about his sources (the book gives none), but nobody successfully
did this; his employer at the time of publication didn't have his
current address.  My guess is that he simply made an error or more
likely accepted someone else's wrong recollection, and didn't feel
it necessary to go to original sources to verify what was only an
illustrative point anyway.

This answer by Mark Brader <msb@sq.com>.  Quoted items in it have been
reformatted but not abridged.

--
Dan Pop 
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

----------------------- Begin Included Message -------------------------

+---------------------------------------------------------------+
| John A. Turner                                                |
| Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 |
| Group: X-6 (Radiation Transport)                              |
| Location: TA-3, Bldg. 43, Rm. D263                            |
| Phone: 505-665-1303                   e-mail: turner@lanl.gov |
+---------------------------------------------------------------+