Gene Kranz - Failure Is Not an Option

During the last two weeks of training, the individual and team confidence were restored, thanks to the superb efforts of the simulation supervisor and his team. We were approaching readiness—so we took the day off on July 4, 1969.

The MCC final training day always had been a confidence builder, with most of the training runs focused on achieving the mission objectives. However, this wasn’t the case when we returned on July 5, and by midday I was doing a slow burn. Since Armstrong and Aldrin had deployed to the Cape, Koos was running us through the paces with the Apollo 12 crew. We were in top form, having aced six tough landing aborts in a row. As we continued to work through the final training exercises, the Apollo 12 backup crew moved into the simulator. SimSup often did this in the last day of training, giving us a less experienced crew in the simulator that forced us to do more prompting and work harder. This way we would not take anything for granted. We had started the day with Pete Conrad and Alan Bean. By midday, however, their backups, Dave Scott and Jim Irwin, joined the simulation.

The final simulation before a mission was much like a graduation ceremony, except that instead of going out into the world to get a job, we had the task of landing an American on the Moon. Sitting at the console, late in the afternoon on July 5, my mind had closed the books on training and was racing ahead to the thousand items to be closed out in the final two weeks before launch. Mentally I had made a fatal misjudgment.

Dick Koos had been monitoring my team and was not about to give us our diploma. He made up his mind that we would have to earn it. Dick quickly scanned the simulation scripts, then called out to his team, “Hey guys, open your books to Case No. 26 and have them load it in the simulators.” The technicians coordinating the simulator setup responded, “Case 26 is loaded.” Dick smiled and turned to his team. “Okay everyone, on your toes. We have never run this case, so it is going to take a helluva lot of precise timing on our part. This one must go by the numbers, so stand by for my call-outs. If we screw it up I hope you got a bunch of change ’cause we’ll end up buying the beer!”

The simulation picked up with the crew performing the final systems checks before starting the descent. I polled my controllers for the start engine Go NoGo, and Charlie Duke called to the LM crew, “Eagle, you are Go for powered descent.” Five minutes later, the descent engine started and we were on our way to the surface. I thought, “This is going to be a good one to wrap it up.”

Three minutes into the landing sequence Koos nodded to his team. “Okay gang, let’s sock it to them and see what they know about computer program alarms.” The LM computer provides a series of five-digit alarm codes. The computer alarms signal crew or ground procedural errors, computer hardware or software problems, or out-of-limits conditions. An ominous note states “30000 series alarms indicate a computer abort code that results in a software restart. 20000 series alarms are more serious and will result in the computer going to idle.”

In the Trench, Steve Bales, the GUIDO, was busier than hell. He had done well so far today in training and was damn glad it was all about to end. Steve was responsible for the LM computer. He had to make sure it got the right data from Earth and then had to be certain that guidance, navigation, and control functions during the landing were being executed properly.

Within seconds of Koos’s malfunction entry, Steve was peering intently at his television display. He was seeing a 1201 alarm code indicating a computer restart. This was the first time he had seen this code except during computer ground testing. An equally perplexed LM pilot in the simulator called up data on the LM computer display. The code was meaningless and he decided to wait for a Mission Control call to enlighten him.

At Bales’s fingertips was a small one-quarter-inch-thick blue handbook containing a glossary of the LM software. Quickly paging through the index he read “1201—Executive overflow—no vacant areas.” This meant that the computer was overloaded. The LM computer was unable to complete all its jobs in the course of a major computer cycle. Bales had no mission rules on program alarms. Everything still seemed to be working; the alarm did not make sense. As he watched, another series of alarms was displayed. Punching up his backroom loop, he called Jack Garman, his software expert. “Jack, what the hell is going on with those program alarms? Do you see anything wrong?” Steve was counting the seconds, waiting for Garman’s response, happy that the crew had not yet called for an answer.

Garman’s response did not help. “It’s a BAILOUT alarm. The computer is busier than hell for some reason, it has run out of time to get all the work done.” Bales did not need to consult the rules; he had written every computer rule. But there were no rules on computer program alarms. Where in the hell had the alarm come from? He felt naked, vulnerable, rapidly moving into uncharted territory. The computer on the LM was designed to operate within certain well-defined limits—it could only do so much, and bad things could happen if it were pushed to do things it didn’t have the time or capacity to do.

Staring at the displays and plot boards, Steve desperately sought a way out of the dilemma. The computer was telling him something was not getting done and he wondered what in the hell it was. After another burst of alarms Steve called, “Jack, I’m getting behind the power curve, whatever is happening ain’t any good. I can’t find a damn thing wrong but the computer keeps going through software restarts and sending alarms. I think it’s time to abort!”

Seconds later, oblivious to the problem, I was startled by Bales’s call, “Flight, Guidance… something is wrong in the computer. I’ve got a bunch of computer alarms. Abort the landing… ABORT!”

Charlie Duke picked up the call. “We gonna call an abort, Flight?” My response was curt: “Abort, CapCom, abort!”

If there was one word guaranteed to get your attention in Mission Control it is the word “abort.” This word is never used casually and literally rings across the voice loops as the word is passed to the crew, computer controllers, and support personnel. An abort is an intensely time-critical effort where every action must be perfect and perfectly synchronized. In an abort, your chances of getting out alive are good if the abort is done at the right time. If you are off the timeline, your chances are not good 200,000 miles away from home. An abort is the last option, one that must be perfectly executed with perfect timing if you’re going to pull it off.

The crew confirmed the abort call as they throttled up the descent engine, then staged. The ascent engine ignited and moments later they set up a rendezvous with the command module. I felt that we had made the right, necessary call, but I was really unhappy with Koos. Dammit, we should have finished our training with a landing on the surface.

The flight controller debriefing was extensive. After listening to the confession of the team members, Koos gave his evaluation of our performance. Slowly, methodically, Dick took us through the problem, then plunged in the dagger: “THIS WAS NOT AN ABORT. YOU SHOULD HAVE CONTINUED THE LANDING.”

Koos had grabbed me by the throat; I wondered where the hell he was going. Half dazed, I was anchored to my chair as he continued: “The 1201 computer alarm said the computer was operating to an internal priority scheme. If the guidance was working, the control jets firing, and the crew displays updating, all the mission-critical tasks were getting done.” Koos’s voice then became almost fatherly as he continued, “Hell, Steve, I was listening to you talk to your back room and I thought you had it nailed. I thought you were going to keep going, but then for some reason you went off on a tangent and decided to abort. You sure shocked the hell out of me!”