Conference turris::languages

    The story I heard many years ago was that a space probe was lost
    due to a sign error in a FORTRAN program.
    
    When the probe began drifting off course, the attempted course
    correction procedure sent the probe even further off course.  After a
    couple of attempts, the probe was lost for good.  The FORTRAN bug
    was discovered during a post-mortem investigation.
    
    -- Ward

In FORTRAN, spaces are not treated as delimiters. On most FORTRAN 
compilers, the lexical analyzer will remove all spaces from the input 
stream. 

This makes a FORTRAN program harder to parse than most other languages. For
example, if I do the following: 

    DO 10 I = J , K
                
the compiler does not know that this is a DO loop until it sees the comma. 
If the comma was missing, this would be parsed as:

    DO10I = JK

which assigns the value of JK to the variable called DO10I.

Note: FORTRAN was designed before compiler technology had gotten very far. 
Language designers now know how to avoid pitfalls like this.

Jack

P.S. Also, it's not quite as easy as scanning for a statement that starts 
with DO and has a comma following it. You could have something like this:

    DO 10 I = A(J,K)
    
which would assign the value of A(J,K) to the value of DO10I. 

The name of the spacecraft (which I believe was a Mariner, headed for
Venus), was posted at least twice in the Software Engineering Digest
on the ARPAnet.  I haven't yet found a copy of the message.

It is entirely possible a different satellite was lost because of a
sign error, but I don't recall it.  Some fighter (F-15 or F-16, I think)
was discovered during simulation to have a bug which caused it to roll 180
degrees when the avionics detected a crossing of the equator.
				/AHM

    	Fortran can be even more beautiful, if you really try.
    
    	CALL P1(4H)=4H)   
    is of course a procedure call, while
    
    	CALL P1(4*H)=4H)
    is obviously an assignment statement.
    
    		Dave :-)

	     -< It's easy to sneer at 30 year old languages,
		I just wish people would stop using them >-

I started  writing an article - coincidentally, for the Languages notes file
-  concerning  the  evolution of programming languages. Alas, the article is
likely to never be completed but, on seeing this note, I thought I'd post as
far  as  I had gotten. The weather balloon accident mentioned was the result
of a Do loop similar to the following:

	DO 3 I=1.100

The period, of course, should have been a comma.

(I cancelled  the  article  for  religious reasons; i.e. I didn't want to be
burned  at the stake by offended zealots. :-) For the record: I had intended
to offend far more than just the FORTRAN camp. :-))

============================================================================

BACKGROUND

  The first  programming  language was discovered in 1954. Its name was FORTRAN
  and it was instanty hailed as the greatest thing since assembly language, and
  quite  deservedly  so.  People quickly realized the big advantage programming
  languages  had  over  assembly  language  was that programmers were no longer
  restricted  to  one language per machine architecture. As a result, compilers
  for  a  multitude  of  languages  with widely varying characteristics quickly
  sprang into existence. For the first time, it was possible for just about any
  programmer  to  find  a  language that suited his own personal idiom, and the
  effect  of  this  new  freedom  of  expression  on  programmer creativity was
  incalculable. Many of these languages were called FORTRAN.

  Languages of  this  time  had  other  merits too. Back then, programmers were
  still real men with penchants for consuming large quantities of beer together
  on  Friday  nights while recounting tales of programmer error amidst gales of
  hilarity.  Stories like the brace of weather balloons that self-destructed at
  the START of the experiment instead of at completion; or the Venus probe that
  flew  directly into the Sun. FORTRAN was especially suited for providing this
  kind  of  Friday-night  entertainment and people soon became very fond of it.
  Variables with names like "DO3I" were very popular at the time.

Re earlier ditties, i worked for an Aircraft Manufacturer some years ago,
and found a similar problem to that described for the F15/F16 with the
computer controlled GYRO Compass when the aircraft flew inverted over
the 0/360 mark. The Compass went screwy at a cost to $20K a time, as the
synchro burnt out trying to correct an error which was opposite to what
was wanted. This was due to the partichlar fortran compiler not allowing -ve
do loop increments, and the programmer forgot a statement like

	i0=-(i0)

at the critical point.


I had a lot of fun up in the air flying upside down behind a wizzard test
pilot trying to debug this fault. Needless to say, the next aircraft
produced by this manufacturer had all its avionics tested on the ground 
with the aid of an 11/45 controlled simulator.

( if anyone wants to know the name of the company and the aircraft concerned,
i will only say that this beast "flies like a bird, & stings like a bee,
and is unique in the western world"

Guesses please ?
/Stephen

    General Dynamics' F111 fighter-bomber.

Hummm... Do you know Dunsfold airfield well?
I would guess that you flew in a Hawker Hunter pretending to be
a Harrier.

    Re: .0
    
    I am personally aware of one instance were the exact opposite of
    this occured. The satellite was lost because a Fortran program was
    working right!
    
    While I was working at Goddard Space Flight Center a few years back,
    TRW launched a bird called SEASAT. The ground control center was
    in the same building that I worked in so I got to see alot of what
    was going on with the project. The development of the ground control
    computer had been a nightmare. They were using a Xerox Sigma 5 (this
    was some two-three years after Xerox pulled out of the business)
    and Fortran. They were still working on it weeks after launch. In
    fact, hardly a day went by that a new problem was not found and
    a fix put in (always between passes). 
    
    One night, on the graveyard shift, an operator noticed the spacecraft
    temperature data on his screen was begining to rise sharply. It
    soon went above the alarm stage where the computer was supposed
    to shut down the satellite. The operator, knowing full well that
    this was just another program bug, halted the ground computer and
    started a reboot. By the time it was up again the pass was over
    and they settled back to wait for the next one. It never came.
    
    TRW had saved themselves some bucks by not putting any fuseable
    links (the same kind you find in every automobile) in the battery
    circuit. When the solar pannels went into an overload condition
    there was no place else for the power to go but into the batteries.
    They started to heat up and eventually exploded. The ground control
    computer had been correct and could have stopped the overload and
    maybe saved the satellite.
    
    There were alot of very unhappy TRW people shuffling there feet
    the next morning. The only ones that didn't look like death warmed
    over were the Fortran programers. The same program was later put
    into use to support the Solar-Max project and was in use during
    the Shuttle referb mission. When the astronaught performing the
    retrieval of the satellite tried to grab it by one of the solar
    pannels to try and stop it from spining (he should have known better,
    you just can't do that with something that has five times your mass)
    the only one in the control center to detect the error and shut
    down the bird's gyros was that same Fortran program.
    
    Paul.

    Re 90.9:

    >I am  personally  aware  of one instance were the exact opposite of this
    >occured.  The  satellite  was lost because a Fortran program was working
    >right!

    I'd say the satellite was lost because the software was believed to be so
    unreliable that it was unusable even when it was operating correctly.

The story of the DO 100 I=1.10 statement causing the Atlas booster carrying
Mariner I to fail is in ACM SIGSOFT Software Engineering News V5#2.
The reference comes from note 13.0 (list of computer horror stories)
in NANDI::SWENG (q.v.).
				/AHM

    
    Don't look for SWENG on NANDI, try SIVA::