So when things don’t work so well with programs, sometimes you get an overflow. In the more traditional sense of the term, it refers to an attempt to store a large number in a piece of memory not capable of holding it, i.e. there isn;t enough memory. What you don’t want is this to happen during some critical operation. But that’s what happened on the Apollo XI mission during the landing on the moon phase. The recordings of the landing contain references to “1201 alarm” and “1202 alarm“. The 1201 referred to an “Executive overflow – no vacant areas” whilst the 1202 alarm was “Executive overflow – no core sets“. What did this mean? Well, firstly it had more to do with processor availability.
It turns out that the astronauts checklist required the rendezvous radar to be turned on before initiation of the descent. This caused the 1202 alarm, because the radar was stealing processor cycles, and the computer was required to do too many things. On landing approach, the CPU was suppose to have a load of 85%, however the radar reduced the available cycles to 13% of the processors time . When the command 1668 was issued by Buzz Aldrin to calculate the “difference between altitude sensed by the radar and the computed altitude”, the extra 10% overflowed the processor’s ability, prompting the 1202. Fortunately the system had “priority scheduling”, which allowed non-critical low priority tasks to be deleted, and allow critical tasks (such as the landing) to be completed.. A short while later the 1201 alarm appeared. Followed by more 1202 alarms. At 650 feet, Armstrong took the lander autopilot off AUTO, reducing some of the load on the system (which still controlled the rate of descent), and successfully landing the lunar lander.
The moral of the story? Not every error or warning will appear during the testing phase of a piece of software.
Check out the whole story of the landing on Don Eyles webpage.