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

Question

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?

Answer 1

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.

Answer 2

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.