the flight directors’ loop from their offices. We would cut the loops during the debriefings, so that we had some privacy for soul searching or a plain old-fashioned ass chewing. After the final busted training run, the telephone behind the console rang. Frustrated, I picked it up with my customary “Kranz here.” I heard the familiar voice of Kraft. “I listened to your runs today,” he said. “Sounds like you had a tough time. What’s going on?”
I think he really wanted to take a reading on my frame of mind by listening to the sound of my voice. He knew the business, and he knew the job, so my response was simple. “Chris, you’ve had these types of days. It is just a matter of time and training, we’ll work it out.” After Chris hung up, I switched off the ringer on the phone so I would no longer hear if he called.
SimSup was winning the battle and there was little we could do except hunker down, study some more, get more training under our belts, and come back and do it again and again and again. This was the time where
Sam Phillips set up a preliminary telephone conference the week before the Flight Readiness Review with George Low, flight surgeon Chuck Berry, and myself at the Houston end; Kennedy Space Center director Rocco Petrone and Deke Slayton were at the Cape. I was surprised at the turn of the meeting when Phillips asked if we each felt comfortable with the schedule. He indicated a willingness to push launch into August if we needed more training time.
We each carefully measured out the time we had remaining to train and figured the few extra days would not buy us that much. Then it came down to Chuck Berry. Chuck was concerned about the crew work load but after stammering a bit about the crew schedule, he also gave a Go. My team was coming up to its peak very smoothly, and I did not want to back off. This was a time when the pressure was good. I think that Phillips also talked to Neil that day, and he got a Go from the crew.
The Flight Readiness Review was conducted on June 17, and there were no major open items. The review went well until Kraft made a few comments about the landing data rules. A free-for-all started, and I was called on to write some specific rules on the communications and data requirements for landing. This issue continued to be debated until the week before flight, and it appeared that some of the folks at headquarters were getting damn nervous about the consequences of a crash, if one occurred. Chris, Cliff, and I agreed on the real rule: that “we must have enough data to reconstruct what went wrong.” This rule left me the maneuvering room to take it right down to the surface before I had to make a land or abort call. Once we were close, I intended to let the crew go if everything appeared okay to them. I considered a low-altitude fire-in-the hole abort more risky than landing without data. I always looked at a fire-in-the-hole abort the same way I looked at a parachute when I was flying jets. You use a parachute only when you have run out of options. The day before the launch, I processed a write-in mission rule change that legitimized this landing philosophy: “The flight director will determine if sufficient data exists to continue the landing.” No computer could make this call—it had to be a human decision.
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,
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
