Most accounts of the famous 1202 error reported by the AGC during landing of the Apollo 11 LM characterize the event as result of the successful operation of the AGC, flushing an resetting an overloaded computer while preserving critical data needed to proceed on restart.

However Alan Klumpp's retelling describes a situation in which overloading of the AGC could result in disaster:

...throttle and steering commands ... were often incompletely computed, and were queued for later completion. Any attempt to queue a command when the queue was already full (about five commands) would cause the computer to flush the queue and issue the alarm. But when the radar’s power supply was in phase, queued commands, valid only at some remote past time, could be completed and issued in reverse order, momentarily taking control to guide the LM off its normal landing trajectory. Although flushing commands would cause alarms, issuing faulty commands would not. Simulations showed that faulty commands could put the LM on a crash course, and guidance would attempt to take the LM to the landing site via a trajectory that passed beneath the lunar surface.

However, it's not clear when or if this situation actually occurred. Is this passage meant to confirm the general account: that the flushing behavior associated with a 1202 error prevented this disaster from occurring. Or is he saying that this could have been going on when the 1202 errors were reported, or at some other time during the mission? (In fact, one interpretation is that the out of phase overloading that triggered the 1202 errors insured against such a catastrophe.)

Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?

  • $\begingroup$ A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc. $\endgroup$ Jul 24, 2019 at 18:37
  • 1
    $\begingroup$ I think it was the Apollo Guidance Computer (AGC) issuing the 1202 and 1201 during the landing, not the Abort Guidance System (AGS). But that's just what I think, I could be wrong! $\endgroup$
    – TrySCE2AUX
    Jan 20, 2022 at 11:27
  • $\begingroup$ @kruemi Indeed! (Surprising that that hasn't been caught before.) $\endgroup$
    – orome
    Jan 20, 2022 at 21:11
  • $\begingroup$ See from the 48 minute mark onward for a good explanation: Light Years Ahead | The 1969 Apollo Guidance Computer. $\endgroup$
    – Fred
    Feb 11, 2023 at 10:46

2 Answers 2


I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says

But when the radar’s power supply was in phase, queued commands, valid only at some remote past time, could be completed and issued in reverse order, momentarily taking control to guide the LM off its normal landing trajectory.

(Emphasis mine)

Here is Eyles' account of the problem from pp. 215-16 of S&L.

As 1970 dawned, with P66 Auto finished and onboard for the upcoming mission, Allan and I found time to reconsider the problem that so nearly ruined the Apollo 11 landing — deprivation of processor time, which we called TLOSS-— but we went about it in different ways.

Allan kept the IBM 360 humming as he ran simulations on the Apollo 13 rope to see how it behaved under varying amounts of TLOSS. We already knew that if the amount of TLOSS was just right, then during a period of high activity incomplete SERVICER jobs could accumulate in the Executive queue. The last thing the SERVICER did on each pass was send information to the DSKY for display. Just before it did that it issued attitude commands, and before that, throttle commands. What concerned Allan was what would happen if a SERVICER job was cut off before the throttle or attitude command was sent out. If enough of these suspended jobs accumulated, a software restart would occur, as it did on Apollo 11, and the suspended jobs would disappear. But what if the computational burden eased before they were flushed?

What could happen, Allan found, was that the suspended jobs (Allan dubbed them “lurkers”) could come back to life, unaware that they had been in hibernation, and proceed to issue an attitude or throttle command applicable to an earlier point in the trajectory. Suddenly the LM might maneuver to the wrong attitude. The worst cases were when suspended jobs that accumulated during P64 were executed after the transition to P66.

On March 4 Allan put out a carefully written memo describing “a collection of known manifestations of time loss.” Allan described eight separate modes of bad behavior, starting at a TLOSS of about 8 percent. In an unusual precaution Allan signed the memo, and asked Gerry Levine to sign as having approved it.

(Emphasis mine)

My interpretation is that for the problem to happen,

  1. the rendezvous radar power supply would have to be in sync
  2. something would have to happen that made the SERVICER jobs run long and not complete
  3. Whatever caused 2) would have to go away before the situation got bad enough to flush the queue

We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.

This answer attempts to explain the part about the radar power supply being out of phase.

  • 2
    $\begingroup$ @orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though. $\endgroup$ Jul 21, 2019 at 23:23
  • 1
    $\begingroup$ Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm. $\endgroup$
    – orome
    Jul 21, 2019 at 23:28
  • 1
    $\begingroup$ The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say. $\endgroup$ Jul 22, 2019 at 15:42
  • 1
    $\begingroup$ I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing. $\endgroup$
    – orome
    Jul 23, 2019 at 17:40
  • 1
    $\begingroup$ I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place. $\endgroup$
    – orome
    Jul 27, 2019 at 19:52

The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.

There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.

Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:

And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.

The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.

  • $\begingroup$ Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened). $\endgroup$
    – orome
    Jul 21, 2019 at 21:45
  • $\begingroup$ It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order. $\endgroup$
    – DrSheldon
    Jul 21, 2019 at 22:07
  • 2
    $\begingroup$ According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot. $\endgroup$ Jul 21, 2019 at 22:17
  • 2
    $\begingroup$ Ghaa. Simulators didn't have real AGCs? 😳 $\endgroup$ Jul 21, 2019 at 22:29
  • 1
    $\begingroup$ @RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too. $\endgroup$ Jul 21, 2019 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.