NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

James E. Mager
Interviewed by Jennifer Ross-Nazzal
Las Cruces, New Mexico – 23 January 2003

Ross-Nazzal: Today is January 23rd, 2003. This oral history with Jim Mager is being conducted in Las Cruces, New Mexico, for the NASA Johnson Space Center Oral History Project. The interviewer is Jennifer Ross-Nazzal, and she is assisted by Sandra Johnson.

Thank you for joining us this morning. We really appreciate it.

Mager: My pleasure.

Ross-Nazzal: I’d like to first ask you about your interest in engineering. What sparked that interest in engineering while you were growing up?

Mager: It was probably at least three factors. One is environmental, from the standpoint of I was basically raised as an orphan. I wasn’t an orphan. I had a mother and a father, but I was raised by my grandparents till I was nine, and then I was put in a private school for orphans and wards of the court, and I stayed there till I was seventeen. When I was seventeen, my mother decided she wanted to take my brother out of school. My reaction to it wasn’t very positive. I generally had a reputation of being, basically I guess you could call it Mr. Goody Two-Shoes. It didn’t mean I didn’t pull little things, but I was sneaky, and never got caught. But I did some things, and the school decided, well, she’d better take me with him. [My brother] was a year younger than I was.

At that point in time, a couple entered my life, and that was my junior English teacher and her husband. They found out that I was going to be leaving Van Wert, Ohio, and going to California, and my junior English teacher felt like I ought to at least have the opportunity to complete my senior year at the high school. She probably had a couple good reasons for that. One was, I was a good student. I ended up third in my class. But also, I was one of the star football players, and she was a football fan, so I’m sure she was, in part, looking out for the football team.

So they came and visited me at the private school before I left for California and made a proposal that I consider coming back and live my senior year with them. I told them that I’d just at least like the opportunity to go out to California. I’d been there one other time. And then I’d make my decision. They said, “Fine.” But I’d already made up my mind I was going to come back.

So I went to California, got a job, earned enough money to buy a bus ticket back to Ohio, and went back to Ohio. Well, it turned out that the relationship with them went more than one year; it went five years, including four years of college, and they put out of their pocket over half of my college expense. They did a lot of encouraging.

The other factor was, as I said, I had a father, and I’d established for myself a goal of doing better than he did. At that time, he was making about 5,000 a year, which was not a bad salary back in the mid-fifties. So I set my goal at 10K, and I went from there. I got a late start on applying to college and scholarships, and ended up going to—at the time it was Case Institute of Technology [Cleveland, Ohio], which was probably one of the most expensive engineering schools in the United States—it’s now Case Western Reserve [University]—and ended up going into electrical engineering.

My aptitude was better in chemistry, and I worked the first year there in the chemistry department, but when it come time to choose, I had a roommate who was a chemical engineer. He was a senior. I [asked], “Well, what are you looking at from a job standpoint?”

“Oh, 325 a month.”

And I had the survey data which said electrical engineers were getting 525, so that helped make my decision, which did not make the chemistry department manager very happy. He worked on me, but it didn’t work. So I ended up in electrical engineering.

Ross-Nazzal: What did you do once you graduated and before you started working at the Manned Spacecraft Center [Houston, Texas]?

Mager: Well, first of all, you know, my family was basically farmers. The private school I was in is basically farm oriented. They had 5,000 continuous acres of some of the best farmland in the United States around the school, and as a school requirement, we had to take three years of vo-ag [vocational agriculture], and in FFA [Future Farmers of America] I had all kind of projects. Didn’t do very well with any of them. So I figured out I didn’t have a green thumb.

I had the educational aspect of electrical engineering, but I had absolutely no experience. So I made a decision that what I wanted to do was go into field services first, [to gain] hands-on [experience]. And I went to work for Singer-Link [Corporation] on flight simulators, and I was a field tech rep [representative] for approximately two years. I spent time at Air Force bases in Arizona, New York, Air National Guard in Indiana and Illinois, and the last assignment I was at the Naval Air Station at Pensacola, Florida.

In 1981 [sic], when I think I was fourteen, I made a trip to California to the Oxnard-Ventura area, and I fell in love with the area. So in the spring of ’61, I decided I wanted to move to California. I had an uncle and aunt that worked for the government, civil service, employed with the Department of Navy at Point Mugu, California. So I decided that I was going to go to California and look for a job, and specifically targeted the Point Mugu Naval Air Station [California].

I took another long bus ride from Pensacola, Florida, to California, interviewed. I put in my application, [went] back to Florida, and about two weeks later I got an offer. So I ended up working at the Point Mugu Naval Air Station as a civil service employee supporting the Pacific Missile Range [Point Mugu, California], and I spent three and a half years there. [I] started out doing radar system engineering to improve the radar system’s performance, and then I moved into the data systems arena from the standpoint of the data transmission systems that were required to get data from the instrumentation back to the central location in Point Mugu.

My first supervisor there, about a year after I got there, he moved to Houston and got a job with JSC, and continuously made requests that I make a decision to come to [Houston]. Well, I wasn’t quite ready for the move, but then in 1963, DOD [Department of Defense] made a decision to transfer the management of the Pacific Missile Range from the Navy to the Air Force at Vandenberg Air Force Base [California]. We had sites at Vandenberg on the Pacific Missile Range, [and] I’d spent a lot of time [at] Vandenberg. They offered me a good job. I was going to be on the staff in the Engineering Department, Directorate, but from a living-conditions standpoint, fog, coolness of California, I did not specifically like the Lompoc-Santa Maria-Vandenberg area. So that’s what drove my decision to venture out to JSC.

Ross-Nazzal: When you got to JSC, you actually started working for the Network Operations Branch and the Network Systems Branch.

Mager: Yes. I was in the Flight Support Division, which was a part of—I can’t even remember what the directorate name was, but Chris [Christopher C.] Kraft was the director of the organization. The Division Chief was an Air Force major who later become a NASA employee at [NASA] Headquarters [Washington, D.C.]. So I started out in the Network Operations Branch, who my first supervisor in California was the Branch Chief, as the engineer from an operational standpoint for the command system in the control center.

Ross-Nazzal: What were your basic duties?

Mager: Oversight of the operation of the command system, from the standpoint of its performance, getting it ready for each one of the flights, etc.

Ross-Nazzal: During the flights, you actually served as a support control coordinator. Can you tell us what that position entailed?

Mager: That position was instituted from the standpoint of—the Division I was in provided all the systems within the control center to support the flight control operation. And as such, if requirements came up during a flight where they needed something other than what had been planned, the support control coordinator position was created to be the focal point to where that person or individual had the responsibility of going out and doing whatever was necessary to make the service available to the flight control team.

Ross-Nazzal: According to our research and the Mission Control manning lists, you actually did serve on a few flights. Did you serve in one of the support rooms, or did you actually serve in the MOCR [Mission Operations Control Room]?

Mager: From a support coordinator function standpoint, we basically operated out of the VIP [Very Important Person] room behind the MOCR. We had a com [communications] position [in] a room that we set in and monitored the mission [so that] the flight director or the mission director [could] get [a hold] of us, to address new [or] any additional requirements they might have. [In addition,] if there were problems, system problems, then we would go get involved in the system problems from the standpoint of ensuring that the right people were involved in getting the problem resolved, etc.

Ross-Nazzal: Do you remember any serious network problems that occurred while you were working as support control coordinator?

Mager: Well, you always had radar systems or telemetry systems or command transmitters. They’d [have] a failure, they’d go red, so you’d have to figure out workarounds, or if there wasn’t a workaround, feed the input back into the mission support team so that they could replan the activities, etc.

I started the first—I’m trying to remember. I got there in December of ’64, and I believe that was GT [Gemini-Titan] II, was either right at that time or the next month after. The control center, at that point in time, was not the control center that supported the flights. They were just going through their final verification of all the systems and getting ready to support a flight. The first flight the control center supported was GT III, which I think was March of ’65, and that was supported in a flight-following mode, where the Mission Control Center at [Cape] Canaveral [Florida], at the Cape, it did the actual Mission Control. We flight-followed to make sure all of our systems provided the level of support that was required to support a manned flight. And then GT IV was the first flight where we would control the flight, and the Cape was backing us up.

Sometime in the GT IV-GT V time frame, we had an incident in the control center where the master digital command system—we had two in order to provide redundancy, and one of them burped its memory one night, and all the commands in that system hit an Agena vehicle who was in active mode at the Cape, and I think it was one of the Agena vehicles that was getting tested out for one of the later GT flights. To my amazement, my Division Chief decided that I should be the one that lead the team to figure out what happened and take corrective action. That ended up in me having to go to the Cape, to the flight readiness review, review the results, where we were, to all the senior NASA management people.

Just an interesting comment. In the investigation, we never did find the specific cause, so I had to develop, based on engineering knowledge, what was the most likely scenario. Well, about at the end of the Gemini Program, we were converting the control center to support Apollo, and the master digital command systems weren’t going to be used, so we were tearing them apart. And we did find what caused the problem, and it totally matched what the conclusion I came up with as the probable cause. So it made me feel a little bit good. But the thing that sort of caught me as a surprise, I’d only been at JSC six months at the time this occurred. The Engineering Directorate down there had all the engineers that had wrote the requirements for the system. They’d interfaced with Radiation, [I] think it was Corporation—who built the system. They hadn’t the knowledge of the system, yet they picked me. If there was one event that probably made my career, and it sort of set me up for later on, it was that one event. So that’s just a little background.

Ross-Nazzal: You mentioned the problem that you had with the Agena and the computer. Can you talk to us about how the network changed from the Mercury-tracking network into the Gemini network—

Mager: Of course, I wasn’t there on Mercury, but basically it started following the path of the way communications has evolved over the last sixty years. Basically, their data was received in the control center except for the direct interfaces from the Cape via teletype. When you evolved to Gemini, you started getting more, at the time, what we called a wideband. It wasn’t too wideband. And you got some high-speed interfaces, which was two kilobits per second, etc. If you look at the entire manned spaceflight, the ability of communications technology to support transmissions, and the amount of data, is continuously evolved. You’ll see that throughout the various NASA manned spaceflight. It applies to any space operation. It’s more data, and as each program come along, each program, the vehicle was more complex. There was a greater need for more data, so the systems were upgraded, designed to take advantage of what technology made available.

Ross-Nazzal: During the Gemini Program, NASA had planned to learn more about orbital rendezvous. What did that require from your Branch or your Division?

Mager: Primarily our role was to provide the data that the flight control team needed to have in order to perform their mission. So that data meant air-to-ground communication so they could talk to the crew; telemetry information so they could monitor the vehicle’s status; command capability so they could command certain things into the vehicle; and trajectory information, which at that point in time was totally radar systems that were located around the world. So because of the rendezvous, one of the things you’ve got to have is the position information, velocity information, so that you know the position relative to the vehicles you’re trying to rendezvous, and generate the trajectory information for the spacecraft that would target whichever one is active in the rendezvous, to the rendezvous with the other targets.

Basically, our job was just to make sure all that information in the data was there when it was needed to feed the generation of the solutions to be successful on the rendezvous.

Ross-Nazzal: Did any changes have to be made to the Mission Control Center for the Gemini ’76 mission?

Mager: That’s going back a little bit far. Some of that detail I don’t remember, but in general the control center had to go through a reconfiguration for every flight, because there was differences in the vehicles, differences in how they ID’d [identified] telemetry parameters or calibration information relative to once you got the data from that instrument on the ground, what did you have to apply to it so that on the display of the flight controller it represented temperature or pressure or whatever. So you always had to do some form of reconfiguration with the control center from flight to flight. Of course, like on a rendezvous mission, there had to be a lot of planning done up front relative to making sure that the required data, i.e., you’re now tracking and processing information from two vehicles, not one, all that had to be planned out.

Ross-Nazzal: What was the biggest challenge in terms of rendezvous during the Gemini Program?

Mager: If you’re talking about the flight operations, that’s not my arena. Okay? My arena was basically to provide the data that is required for them to be able to conduct their mission. So that required us to work with the flight control team, [and] understand what the requirements were.

And then at that time we worked, interfaced with Goddard Space Flight Center [Greenbelt, Maryland], because Goddard owned the network, okay, and they owned the communications that linked the network to the control center. During Gemini, in the control center, during a mission, we had a network support team which was totally staffed by Goddard, and we interfaced with them.

Ross-Nazzal: Let’s move on to the Apollo Program. Can you tell us how the network changed from the Gemini Program into the Apollo Program?

Mager: The first thing was, we made changes to take advantage of communication bandwidth capability. We went to 56 kilobit interface to the Cape, and other aspects, because the Apollo Program was a lot more complex, a lot more data requirements. So the first thing we did was to change the communications. And the NASA network went from basically a radar—they still use radar systems from the standpoint of trajectory information, but they went to the unified S-band system, which the unified S-band system [provided] one link [which] was used for all the air-to-ground telemetry command information versus separate instrumentation systems. We basically went to high-speed interfaces from all the sites to the control center.

Ross-Nazzal: How did these changes impact your job?

Mager: We basically ripped out, except for the consoles in the various areas, the whole system and replaced it, redesigned it. And that redesign was one driven by totally different requirements for Apollo than there was for Gemini, and also from the standpoint of the complexity of the operation, the complexity of the vehicle, the amount of data available off the vehicle. So you had to expand the capacity of the control center to process.

A general rule in providing support to an operations group, you can sit down and design a system that’s going to provide 100 percent more capability than the operation requires. Well, you can be rest assured that within a short period of time the operations is going to gobble up that additional capacity. Finding better ways to do things, better ways to let the systems help you generate information in a form that you can easier use without you having to doodle on a piece of paper, etc. And that type of evolution and change was even true for Skylab, and it’s true for Shuttle. We basically changed the whole system—new computers, new front-end processors. So it’s basically a redesign of the control center.

Ross-Nazzal: Were there any specific challenges that you faced during the Apollo Program in changing the system?

Mager: The main challenges was schedules and getting everything done that we need to get done to make sure that the system was capable of providing the support that it was intended to provide. One of the things that our Branch did is we took the requirements that had been defined for the various systems, and sat down and scripted out very detailed test procedures that would check—we started out first doing it internal to the building to make sure that if we put this input into this system, that we got the expected result. And then after we completed the control center, we extended that type and level of testing all the way out to every end instrument on the network to verify that the system, end-to-end, would meet the requirements that had been levied on the system by the operations team. We did the end-to-end stuff every flight as a part of the preparation in saying we were ready to support the flight.

Ross-Nazzal: Sounds like a lot of work.

Mager: Oh, it was fun.

Ross-Nazzal: In ’68 you actually headed the Telemetry Command Group. Do you remember what your duties were in that position?

Mager: Well, we had a data systems operations section—I can’t remember what the exact name was at the time—which included people who had expertise in telemetry systems, command systems, tracking systems, air-to-ground communications systems, and then we had the network controller. In my group was—and I can’t remember how many people was involved—was specifically just the telemetry and command part of that total section responsibility.

Ross-Nazzal: Then a few years later, you actually headed the Mission Operation Section.

Mager: And that was that whole group. It had the network controllers. The network controller was a person that sat in the MOCR, and he interfaced with the flight control team. If they needed something done or if there was network problems, he interfaced that to the flight control team, and then if they had specific requirements, they’d feed them to him, and then he would send it to the right person in our ops [operations] team, which was in a support area downstairs.

Ross-Nazzal: During the missions, did you stay in the MOCR or the support rooms?

Mager: There was a time, I guess it was probably when I was in the Telemetry Command Group, I supported the mission from the command console, but that was downstairs. By the time I took over the section, I basically—I would fill in occasionally, but most of the time I was free, I was roaming the building, I would talk to individual flight controllers. If we had problems, I’d interface with them, etc.

I sort of established a work habit that I was in by 3:00 a.m. every morning, and I left exactly at 4:30, because I had a philosophy. I had four kids at the time, and my philosophy was from 4:30 till the time my wife and the kids went to bed was their time. From that point on, it was my time. So I’d get by with three or four hours of sleep.

During the flights, I was out there continuously. I’d grab fifteen-minute power naps. Sometimes that was on my table in my office. Of course, at that time we also had a dormitory in the control center with bunks, shower facilities, etc., and [occasionally] I used those. I basically, when we was in flight, lived out there.

Ross-Nazzal: Sounds like a long schedule.

Mager: Do you know John [H.] Beall?

Ross-Nazzal: No, I don’t recognize that name.

Mager: He’s the CFO [Chief Financial Officer] at JSC now, and he’s tainted my customers’ knowledge of me out here by telling them that I lived in the control center. But that was just my way.

Ross-Nazzal: You also had a big schedule.

Mager: Yes, but by getting in by 3:00 a.m. every morning, from a paperwork standpoint, everything was done before anyone else got in, so I could spend most of the day walking and talking, which keeps you in contact with what’s going on and the people.

Ross-Nazzal: You mentioned, when we were talking about Gemini, that the Mission Control Center had to be reconfigured for each flight. Was that the case also for the Apollo Program?

Mager: Oh yes, in spades. And it’s in spades more when you get into the Shuttle Program. Because as I said, as manned spaceflight changed from program to program, one of the things that happened was—what you tried to do with each one of those vehicles was expand it. You were trying to expand your envelop relative to knowledge about manned spaceflight experiments, etc. So each one of those drove a greater data need, greater capacity on board the vehicle, and you had to be able to, on the ground, process that data by the fact—if you had a flight that had experiments on it, that in itself is different from the previous flight, so you had to do something to get the system on the ground ready to receive that information and present the information in a form or the data in a form that meant something to either the flight controller or the PI [principal investigator] or whatever.

So, mission-to-mission configuration, I cannot recall anytime that you didn’t have to change the configuration, whether the next flight was identically the same as the previous flight.

Ross-Nazzal: Why don’t you tell us about the Apollo 11 mission and your memories of that event.

Mager: I wasn’t on the console, but I was in the control center, as usual: I was just like everyone else; I was glued to the data and the information that we had coming in, and excited relative to the—were we going to encounter any problems in the actual landing, and was the LM [Lunar Module] going to perform right, etc. And I got just as excited as anybody else when you heard the words, “The Eagle has landed.”

Ross-Nazzal: That’s a nice memory.

Mager: Yes.

Ross-Nazzal: What about the Apollo 13 mission? We know that you received a Superior Achievement Award for your role.

Mager: Let me clear up one thing. It’s like a lot of awards, that award was because of the performance of my people. I contributed, but the award itself was the product of the effort of the section I had at that time.

From a data systems standpoint in providing information to the flight control team, what the Apollo 13 explosion did to us, it basically disrupted communications, because it damaged a high-gain antenna, etc. So we spent a lot of time reconfiguring the system to come up with a configuration that would allow us to continuously communicate with the Apollo 13, and they ended up migrating to the LM. So we had to reconfigure the whole system from a communications standpoint and the S-band system at the remote sites to reestablish that communication. So that really was my team’s primary [action], was to reestablish that communication so that the mission could go on and the crew could communicate to the ground, the ground could communicate to the crew, and the ground could monitor the LM systems, etc.

Ross-Nazzal: Were there any problems making that change?

Mager: No, it just took time. Yes. Some of the people I had had excellent knowledge of the unified S-band systems, etc. So it took that knowledge. I’m sure they tried some things that didn’t exactly work the way they thought it was going to work, so they had to follow another—can I take a break for a minute?

Ross-Nazzal: Certainly.

[Tape recorder turned off.]

Mager: As I said, the main contribution of myself and my team was mainly just to provide capability of the people in the Mission Control Center to communicate with the spacecraft with its problems.

Ross-Nazzal: Do you have any other memories of any Apollo missions that you’d like to talk about?

Mager: I guess my feeling was, every flight sort of had something new. It’s like—and I can’t remember which flight it was on, is when we established the capability to transmit video from the ground. I think one of the first things we did, we provided video from the Moon’s lunar surface of the LM taking off as it was going back to rendezvous with the CSM [Command and Service Module]. That was a new capability. You didn’t know what it was going to look like. You were hoping everything was going to work the way you built the system, etc. Then watching every launch, there’s always that excitement of the launch, seeing it go, hoping, crossing your fingers that nothing goes wrong, etc.

And as I said, for the entire Apollo Program, I spent the entire—every day I was there. I didn’t go home. Usually those flights were short enough that my physical body kept up with it. But I generally, when it was over, I’d crash. It’d take me at least twenty-four hours to recover. I couldn’t do it today.

Ross-Nazzal: Pretty fast recovery.

Mager: I couldn’t do it today. But it was just me. I wanted to be there.

Ross-Nazzal: It was an exciting time. In ’72, you became the technical assistant for the Ground Data Systems Division.

Mager: Yes.

Ross-Nazzal: What were your basic duties in that position?

Mager: Seventy-two, we were in the time period where we were starting to get ready and change things in the control center for Skylab. If my memory is good, we had to go through an ops readiness review, to say that the control center, all of its procedures and everything was in place to support that program. And one of my jobs was to manage getting everything we had to have, get together to go through that ops readiness review, and I think it was with Headquarters personnel that we had to conduct a review. We had to provide certification, proof of certification that everything had been done and checked out, okay, and that was my primary role. If I remember right, I was only in that position for a short period of time, because I think on January 1st of ’73, I became the Branch Chief for the Ops Support Branch.

Ross-Nazzal: How did the extended missions for Skylab affect Mission Control?

Mager: The Mission Control Center was built against a reliability requirement of triple 95, which, you know, basically it’s not perfect, which said you had a lot of redundant systems. When you’ve got short missions, the probability of you having a system problem that could impact the support to the mission was significantly less than if you were trying to support something that was up there for nine months or like with Space Station today, you know, years. So the probability of encountering problems that interrupted the flow of information to the team just increased with the long duration.

I think the biggest impact of the long-duration mission was on the people and their families from the standpoint of up to that point in time you got used and the families got used to maybe providing seven to ten days of support, maybe, two to three times a year. Well, you went nine months continuous support. That was breaking the routine that a family and even yourself was used to. I know it impacted me. But one of the reasons it impacted me more was from the standpoint of when we went to Skylab, we went to a new concept for data transmission, of we went to a data compression concept, which is, in general terms, instead of sending every bit of information from the remote site back to the control center, you only transmitted changes.

Right after we got into the flight, we started noticing in the data that we were providing to the principal investigators that there were spikes. And for an investigator or a scientist, spikes are just disaster. So me and one other individual in the control center took the action to figure out what was causing the spikes, and we had to look at what was causing the spikes. We had to look at from the end at the remote site, all the way through the control center systems. And data compression, you do that via use of algorithms to determine what data you need to send, etc. So it was a lot of software involved, etc.

Ended up spending, for that nine-month period, I ended up working basically seven days a week, fourteen hours a day, because we did not find the specific cause of that problem until about the last month, and it turned out to be a problem in the software at the remote sites.

So I couldn’t have supported the Skylab like I did Apollo flight, where I was there, and I planned to be. I would not have got into that routine. It ended up causing problems. I ended up in a divorce. So from a physical standpoint and mental standpoint, the length of the mission, to me, was probably the biggest. The other failures, standard, okay. But that’s my memory from Skylab.

Ross-Nazzal: Initially, after they launched Skylab 1, there were a number of problems they found when it got into orbit.

Mager: Yes, they had problems with the radiator.

Ross-Nazzal: Did that cause any problems for the network?

Mager: My recollection is no. As usual, when you get an event like that, it’s going to change requirements, and with requirements changes, that will require you to do something to the network, but I don’t recall any extensive problems with our ability to get data, etc., other than that caused, I think, caused Skylab cooling problems and that kind of stuff, which might have impacted their onboard systems, etc. But from a ground standpoint, it was doing routine.

Ross-Nazzal: Do you remember what you did the first few weeks after launch of Skylab 1?

Mager: No. It was about the time we were getting in trying to figure out why we were having data problems, and I’m losing a little bit relative to going back that far and remembering specifics. I’m not sure what the cooling and the changes they had to make to basically restore capabilities from a systems viewpoint, I’m not sure that that initial event didn’t curtail the initial plans relative to run the instruments and that kind of stuff with experiments, because I’m sure the crew was doing a lot of other things, trying to—but I can’t remember anything specifically about that.

Ross-Nazzal: What was happening in the Mission Control Center with the Skylab missions going and then the preparations for the Apollo-Soyuz Test Project?

Mager: Of course, you know, control center we had two floors. Either floor was capable of supporting a flight by itself. The data systems were built relative to the number of mainframe computers we had, etc., that we could support just like two simultask activities. We tended to—and again I’m a little bit foggy on this one—we tended to rotate which floor was used for—you know. And where you were supporting a mission on one floor or you were making changes to the other floor to get ready for the next mission, when that would include supporting simulations with the flight control team, and that was going to be supporting the next team, and you would also configure that other floor to support that next mission.

We had the capability in the control center. We were staffed to provide, basically, do operations, and we had enough isolation and separation, isolation between the systems, that you could work in one area without a great fear of doing something that interrupted mission support on the other flight. Now, we did have some general rules that if you were in a critical mission category like launch, or anything, we didn’t do that, okay. That was just to be absolutely sure that someone, someplace in the building didn’t do something not intentionally, but somehow it fed back in and interrupted service in the system was providing the mission support. We had some pretty strict rules relative to when we did things and making sure we interfaced with the mission team that was in operations that we were going to do this, etc., and get their go-ahead before we did things.

Ross-Nazzal: Talk to us about how you became involved with the Apollo-Soyuz Test Project.

Mager: After the project was basically agreed to between the U.S. and Russia, I got involved in the initial teams to set up the communications interfaces that were going to be required between the Russian Control Center and the MCC [Mission Control Center]. I can’t remember exactly how many team meetings that I initially participated in, but two of them were in Russia. One was in June of ’73, and the other was in October of ’73. What I had to do was—one of the first things we had to do was, what kind of interface agreements did we have to have between ourselves and the Russians in order to be able to establish communications between the two facilities, and we decided and agreed on using the international communication standards.

Just to back up a little bit, in addition to those two meetings over there, I participated in the initial stuff at least two where they came over here. And since we were getting into the international communication standards arena, I decided I needed the help of someone that had specific knowledge of those standards. So I asked the Division Chief for the NASCOM [NASA Communications] Communications Division at Goddard, Vern Stelter, to support me on those team meetings.

After we reached base agreement as to the protocols we were going to use, etc., I basically turned that working group operations over to my people, and they then continued the joint working groups, which were alternated between Russia and here. I could’ve taken a position “I’m the only one that can do it,” etc., but I also wanted to give my people a chance to get to Russia and see what Russia was like, etc.

Ross-Nazzal: How did the Russian Control Center differ from the Mission Control Center?

Mager: I never got—you know, the visits to Star City [U.S.S.R.] occurred after I stopped participating in the group meetings, so I never got out there, but I saw pictures, and it appeared to me they copied us, but I don’t know that to be a fact. But from the pictures it almost looked like they copy-catted us.

Ross-Nazzal: Why don’t you tell us a little bit about meeting with these other Soviet engineers. Did you study Russian before you went over there? Did they know English?

Mager: Well, I had had, when I was out at Point Mugu, I don’t know for what reason, I had enrolled in a Russian class at Ventura Junior College [Ventura, California], and because of operations, I guess I only got to go about four weeks or so, but I got an introduction to the Cyrillic alphabet. I’d done quite a bit relative to—I’d sat down and translated on paper the pronunciation of the Cyrillic alphabet to an equivalent English. So I had developed probably a vocabulary of forty, fifty words. In addition, in doing that and having built into, eventually built into my brain a correlation between English and Cyrillic, basically when I got to Russia, there was a lot of signs that I could read and interpret, just by having that translation. But that’s all I had, about three weeks of Russian.

We had pretty good—we had excellent support from a translation standpoint, and over there we had, I think it was—I don’t remember the first trip that much, but the second trip I had a twenty-five-year-old Russian engineer, aerospace engineer, who served as the translator, and he did an excellent job, and one of the reasons he did, he was very inquisitive about how life was in the United States. In fact, as I was getting ready to leave, he made a proposal to me. He wanted me to go to Glynn [S.] Lunney and make a request to Glynn Lunney that he and I exchange positions for two months; he’d come to the United States, do my job, etc. And he was serious. Of course, I didn’t entertain it. But he later came on over on one of the later teams that came over here, and he was supporting the testing of the docking mechanism in the Engineering Directorate there at JSC. When he came, he brought me a quart jar of black caviar. So we established a good relationship.

Ross-Nazzal: Sounds like it.

Mager: I found, generally in my group, there was, generally one to two people on the Russian side that interfaced with—they were very competent. That was my assessment. We established good working relationships, etc. The nice thing about going to Russia at that time was when we were over there, they basically treated us like royalty. They wined and dined us, took us places. We got together after hours, on weekends. I spent a total of four weeks over there, and it was a very enjoyable four weeks. Had a lot of work, but got around and toured Moscow [U.S.S.R.] and some of the countryside, because on the weekend they’d take us out of town to some historical aspect of Russia.

Ross-Nazzal: What difficulties were there for you and your group in linking these two control centers to provide constant communication with the spacecrafts?

Mager: One we agreed to protocols, etc., it was a matter of then sitting down and agreeing to what kind of support was going to be provided, what communications requirements were required. Of course, that required interfaces back to our side to see what they wanted to be able to do. And then once you understood that, it was a matter of submitting the requirements to the communications companies to meet, okay. We had to agree on operational procedures, and who had what responsibilities for what and all that kind of stuff, but that’s standard stuff that you have in any mission, manned spaceflight mission. There’s a lot of effort spent in just working out the details of procedures. Everything is written out in detail, specifically who’s going to do what, what you’re going to do next, etc. Discipline is very strong relative to making sure you follow what you agree to do and documenting your procedures step-by-step.

Ross-Nazzal: Our research also indicates that you were Chief of the Operations Integration Branch.

Mager: I became Branch Chief at the start of Skylab, January of ’73. I think the Branch then was Ops Support Branch. Then if your records say there was a different name, it was just a reorganization.

Ross-Nazzal: I wanted to ask you, your biographical sheet says you were responsible for the Goddard Spaceflight Center tracking network support requirements.

Mager: Yes.

Ross-Nazzal: What was Goddard’s role at the time in relation—?

Mager: They owned the network. They owned the remote sites. They owned the communications. If you remember, when I was talking about Gemini, I mentioned that, and they had people down supporting in the Mission Control Center and the Network Support Group.

As we got into Apollo, that could get to be very expensive, because that team probably had at least twenty people relative to those people coming from Goddard down to JSC and supporting the flight. So we basically agreed that their interface to the operation [would be] remotely done from Goddard, and as time went along, you started seeing JSC, my group, gaining more control over the direct interface to the remote sites, where we would interface directly with remotes—you started out going through Goddard, etc., but eventually, across time, [that] eroded to where we were communicating directly to the site, telling the site to reconfigure, to do this and etc., etc.

Between us and Goddard, we set up an interface group, and it was called the Network Control Group. It was co-chaired by myself and my counterpart at Goddard, and we used to meet as frequent as we needed to meet to work out requirements, or that’s where we also worked interface procedure problems, issues relative to support, etc. So we had that interface group going, and that’s the mechanism we used to sustain the operation, make decisions relative to changes we needed to make, etc.

Now, the requirements for the network got documented in the PRD, Program Requirements Document, which was a NASA documentation system. It may still exist. I don’t know. Haven’t kept up with it for about sixteen years. But we collected the requirements from the flight control team, and we documented it in the PRD, and that’s how Goddard received the requirements, and they would respond, etc. That was the format that we used to move requirements back and forth. But operational procedures, etc., most of that stuff got worked through the Network Control Group, and actions levied by the Network Control Group.

Ross-Nazzal: You’ve mentioned, in regard to several programs, that you were constantly changing out the system. Can you give us an example of how you changed the Mission Control system from the ASTP [Apollo-Soyuz Test Project] or the Apollo Program into the Shuttle Program?

Mager: I’ve got to think a little bit on that one. I know we changed out the computer systems, the host computer. Control center architecture for Gemini, Apollo, Skylab, ASTP, and even the initial Shuttle was basically what you’d call a host-driven architecture, i.e., that’s where you got a big IBM [International Business Machines Corporation] computer which is doing almost all the number crunching and data processing, driving that out through display devices to provide the information to the flight control team or the people that need it.

A lot of the things we did in [in parallel with] ASTP was redesign of the software to meet the Shuttle Program requirements, which were significantly different and bigger than Apollo or ASTP. We changed—and I may be getting a little bit out of sequence. The initial control center interface is from the point that generated the data to the console easily required a pair of wires. So you had cables with 104 pairs and all this kind of stuff.

We eventually evolved in them—it may have been—I can’t remember whether it was initially to support Shuttle or it was right after it. We evolved to where we were [sending] that over a network, copper path, and you had all the data multiplexed on that one copper path, so you could pull out all those 104, 26 pair, whatever, cables and just get rid of it.

In the control center, before we went to the network type of interface, the cable in the control center, there was probably enough cable to go from Earth to the Moon. So that’s how much cable we pulled out of there. But that was the evolution of how you move data from point A to point B, etc. And there’s further evolution that came along a little bit later, and I’ll talk about that a little bit later. But mainly, it was a change in the control center systems to, one, addressing additional requirements, expand the capability of the control center and, two, to take advantage of the changes in technology, because technology has played a big role in Mission Control today.

Ross-Nazzal: Were there any major difficulties or challenges that you faced?

Mager: Generally, initially, I think Shuttle was initially planned to launch in 1978. So our initial schedules for all this implementation was laid out to meet that initial schedule. So you get into schedule pressures. Anytime you’re building new systems, manufacturing, building new systems and installing them, you’re going to run into problems, and those problems would tend to, at times, create some schedule issues. But that’s typical of any system development, implementation, integration activity. That’s a fact of life. Anytime you’re trying to put a complex system together, you’re going to have problems, going to have to work around, adjust your schedules, etc.

By the fact that—the first Shuttle was, what, 1981?

Ross-Nazzal: Yes.

Mager: It turned out we had, what, five years, six years? Five years between ASTP and Shuttle, and that was the most boring time in my career. You know, we had time to—everything got spread out. I’ll say it again. It was the most boring time of my career.

Now, some of that time, for me, was pulled up—I mentioned back on Skylab we had that spiking data. By the fact we didn’t find it till the last month of that program, we ended up having to regenerate all of the PI data and redeliver it. So that was one of the tasks, but that didn’t take five years.

Ross-Nazzal: I would hope not.

[Tape recorder turned off.]

Mager: On the ASTP communications effort, I did receive the NASA Exceptional Service Medal, and again, to be honest, that was the result of a team, not me individually. I contributed, but by the fact that I was the top of the heap, I’m the one that got the medal.

One of the changes we did make in going from Apollo, ASTP, Skylab, to Shuttle was, we made a decision in the control center to change the way we did flight-to-flight reconfiguration. During those previous programs, flight-to-flight reconfiguration was extensive and manpower-intensive, because I mentioned we had cables with multiple pairs in it. Anytime someone wanted to make a communication change to what was on the key set, we basically had to hook the wires to different points. Telemetry, we had ground stations. You had to come up with a patch board that represented the differences in the telemetry system to make sure that if this console wanted this bit of information, it was this point into the telemetry downlink, the ground station pulled it out, put [it to] this point. You had to again make sure that it connected from one end to the next end. So it took quite a bit of time and quite a bit of manpower to do the flight-to-flight.

What we did when we went from those programs, went into Shuttle, we decided we wanted to go to a concept of table-driven configuration, where basically we built into the software tables that defined the configuration we wanted. Then we had the hardware equipment that would take that and route it to the right place. And that was a part of going to a network concept, because all you had to do is instruct the sender as to what address to send it to, and then the equipment along the network who had that address would pick it up and put it to the right display.

It ended up cutting considerably the amount of effort that was required to do the flight-to-flight. And we needed to do something like that because you’re talking into getting into Shuttle, which was [at] one time was eight, ten flights a year, versus up to that time, after Apollo 11, we basically was, what, two flights a year that we had to worry about. And my Branch, the Ops Integration Branch, had the responsibility for the development of that reconfiguration system. That’s the first time I had specifically picked up a development responsibility.

I’ll mention one other thing you missed. As a result of the effort in building that system, I got the Outstanding Leadership Medal in 1983 for that. Again, team, not me. Okay. I was a part of the team.

Ross-Nazzal: And this reconfiguration process took place between ASTP and Shuttle?

Mager: Yes. It was a part of the systems development that we did. Of course, we had to basically modify all the other software in order to just accommodate the changes that the Shuttle vehicle itself presented from a standpoint of Shuttle vehicles got a lot more systems, a lot more complex, and, of course, the ops requirements changed. So we had to basically rebuild the software to do that.

Ross-Nazzal: There was also another change with the Space Shuttle Program, and that was the use of the TDRS [Tracking and Data Relay Satellite]. Can you talk about the importance of that for Mission Control?

Mager: Well, yes. Up to the time we got TDRS online, we had to use the worldwide network. We had remote sites around the world, initially on Gemini, and I’m not sure about Apollo. But on Gemini we sent—the flight control people sent people out to those sites, and they actually interfaced with the spacecraft and executed the flight control functions from that remote site.

If my memory is right, we got away from that in Apollo, but then when Shuttle—and I guess it was, what, 1983 is when we launched the first TDRS. That enabled NASA to start closing down remote sites, because what TDRS does—well, with the remote site and using independent radar systems, telemetry systems, command systems at the remote site, you maybe have one or two contacts in orbit every hour and a half. The initial TDRS, when they got the two up, is, it allowed them to provide continuous coverage for the entire Earth, except for about a 15 degree span or area of exclusion that was basically in the Indian Ocean area. So basically it got you pretty close to full coverage.

Now, launch azimuth can impact the amount of coverage, because you’re relying on the [ability] of the Shuttle and the TDRS satellite to see each other. Of course, the TDRS is at geosynch [geosynchronous] in geosynch orbit, so it’s basically over the same spot on Earth at all times. And what’s that; 23,000 miles up. So it basically increased the amount of data.

Ross-Nazzal: Were there any challenges associated with using the TDRS for the Mission Control Center?

Mager: Well, we went through a period of—we still kept some of the remote sites like MILA [Merritt Island Launch Area, Kennedy Space Center, Florida] and Bermuda, because MILA was required from the standpoint of being able to support, provide data during pad tests, etc., versus tying up the TDRS vehicle. But we kept Bermuda because the initial use of TDRS to support launch and the degradation of you [receiving] communication signals with the plume that’s coming out of the engine, that tends to degrade the stuff. So we basically had to grow into—and we had sat down and said, “Okay. That is what this means to use TDRS,” etc., but when you sit down before you got something, you always learn something the first time you actually get it. So we had to go through some growing pains. But basically, it was moving in the right direction.

Ross-Nazzal: You worked under the Ground Data Systems Division for a number of years. What was that [Division] responsible for?

Mager: It was responsible for the development and sustaining of all of the systems in the control center. It was also responsible for the maintenance and operations of the control center, the flight-to-flight reconfiguration, and the control of the data systems when they were supporting a mission to get the data that was required by the mission to execute to plan. So the Ground Data Systems Division had total responsibility for the Mission Control Center, other than the actual flight control function.

Ross-Nazzal: Actually, right before you left NASA, you started working for the Systems Development Division. How did that change come about?

Mager: That came about as a result of a NASA reorganization to align JSC organization to the STSOC contract. That’s Space Transportation System Operations Contract. And in that, what happened was in the Mission Support Directorate we had—GDSD [Ground Data Systems Division] had Mission Control Center. We had a Flight Simulations Division. They had the same responsibilities for the flight simulators. In the reorganization, Mission Support Directorate was going to retain the development responsibility for all those facilities, and Mission Ops Directorate was going to pick up all of the operations [and] sustaining. So what happened was, my equivalent over in the Flight Simulations Division decided he wanted to stay on the ops side, and by the fact that my leaning was probably more towards development by that time, decided I was going to keep the development. So he took my Mission Control Center stuff, okay, the ops and sustaining engineering part of it, and I took his simulation system development responsibilities. So that’s what SDD became, Systems Development Division, for flight simulations and control center.

Ross-Nazzal: When did you actually begin working for the United Space Alliance [USA]?

Mager: That’s one correction. I’ve never worked for USA. I went to work for STSOC.

Ross-Nazzal: When did you officially leave NASA?

Mager: February of 1987, the 16th, in fact, a government holiday that year. I got questioned about my mental capacity.

Ross-Nazzal: What did you start doing as a contractor?

Mager: I basically ended up doing a lot of the same things I did in my old GDSD role, started out with maintenance and operations for all of the facilities that STSOC had responsibility for. I did that for probably six, seven months. They were having some problems in their engineering department organization for those same facilities relative to the sustaining activities. So I agreed to move over as a Deputy there. Plus, at the same time, they wanted to establish a capability for systems integration, and I took that over as a manager for systems integration for the STSOC. The things that today Honeywell [Corporation] was responsible for under the STSOC operations.

Let me drop back a little bit and talk about Shuttle. I’m going to go back to Shuttle. I ended up being the—eventually ended up being the Division Chief of the Systems Development Division, and probably one of the things I contributed most to is to the continuing evolution of the control center to where it is today.

All the other programs I mentioned was basically a host-based architecture, data system architecture, where everything focused around a big IBM computer. In 1983—and this came about because of the evolution of personal computers and workstations—I got interested in looking at could we use that capability. And I had some inputs from an individual, John [F.] Muratore, who was an Air Force officer working in the Flight Control Division who, at the same time, he got interested in workstations and their ability to allow the user to graphically display data, etc.

So I decided that what I wanted to do was implement a prototype system in the control center—I did this in conjunction with John—to provide a prototype capability to basically do the same thing that the typical Mission Control systems did, but basically operating off of the telemetry data, etc. It was prototype in a nature that we didn’t try to build into the system all the redundancy that you’d have to have to meet a triple 95 reliability requirement. And what we really wanted to get out of it was learn what we needed to know to apply that technology, i.e., get to a distributive data system architecture versus a host-based architecture.

Now, I had an alternative purpose. I was very much interested in the technology and what it could potentially do. The other aspect of my interest was, we basically still were in a tight NASA budget scenario, and one of the things in my experience was that the things they typically targeted for hits in reductions was those things that appeared as big mountains from a cost standpoint in the budget. One of the big costs in the control center—and the control center before it become SDD, the control center budget, we ran about 100 million dollars a year, and the software maintenance sustaining effort was a significant part of that cost.

So I said, well, you know, if you could make that software maintenance look like a bunch of molehills, then it no longer sticks out there like a sore thumb and becomes a prime target. So, software maintenance in the workstation environment on a distributive environment, from a standpoint of GDSD, would become—we would build the core capability, i.e., the capability, basically the operating system that allowed that system to tie together into the rest of the system. And that was a very small software package compared to the mission operation computer software. And the user would be responsible for all of the display software that interfaced with them. So that sustaining effort transferred to him. So, in effect, I was playing games with the system. We was trying to get the size of that mountain down to where it was a bunch of molehills.

Also, the control center always had a very strict configuration management system. You didn’t change anything without permission, without going through some formal process. From a software standpoint in a host-based architecture, that’s very easy. You’ve got one organization that owns the software, so you’ve basically got to focus effort from a configuration management standpoint. Well, when you get into an architecture where you’ve got that software distributed across thirty, forty, fifty workstations, then configuration management becomes an issue.

So, that’s build the prototype to one, understand what we need to know technically relative to fiber optics land, construction and implementation, what we needed to know relative to the workstation software, and what we needed to learn from a configuration management standpoint.

By the time they got to—and I had an agreement with the flight control or Mission Operations Directorate that I would install this system, and they would use that system as a secondary support to the standard Mission Control system. So that’s the way we implemented it, and we learned a lot of good things out of it. But I hear through the grapevine that as a result of mission ops’ own investigation as to their operation on STS-26 or STS-51, or whichever one you want to call it, that one of their findings was that the flight control team had migrated from that being their secondary system to being their primary, because they liked it.

Now, why did I go through all this? The current architecture in the control center fed off of that prototype. The current architecture uses the distributive system, and one of the last things I did was get established through NASA Headquarters, in the budgeting process, that the project initiation to convert the control center, and the simulator systems to [distributive system], to the architecture they’re in today. So that was my last gift to NASA.

Ross-Nazzal: That’s pretty impressive.

Mager: Now, where were we before I regressed?

Ross-Nazzal: I just have a few questions about this move from the host to the distributive environment. Was it a much more efficient system initially, or were there any challenges at first using the system as a secondary support system?

Mager: As I said, we had to learn a lot of things. One, we wanted to go to a fiber optic system from a copper network configuration because of the amount of bandwidth you can get across the fiber optics. And there’s a lot of things you’ve got to understand when you splice fiber optics. There’s a definite technique to make it work so that you don’t—you get the communications path you need. We had to address the issues of configuration management, because you spread the configuration management from one organization to basically every flight control position. So you had to learn how to control the configuration of the system through there.

And the second thing is—not the second thing—is that you had to understand the languages. The software languages that were using for the workstation are different than a host computer, etc.

Ross-Nazzal: You had mentioned that the software maintenance for the Mission Control Center was upwards of 100 million dollars a year.

Mager: No. The total budget.

Ross-Nazzal: Oh, okay.

Mager: The total budget for control center, and that was when it was—it was the GDSD Division, it was roughly 100 million. That included dollars for development. It included dollars for sustaining engineering on the systems, and the maintenance and operations of the control center. But a significant part of that, because there’s universal algorithms that says that if you’re providing sustaining engineering on a piece of software, depending on the language that the software’s coded in, one programmer can sustain X-thousand lines of code. Well, the control center, the Mission Control Center’s host computer had millions of lines of code, and most of the code was machine code. We used a standard number, 45,000 lines of code per [programmer], and our staff was built on that algorithm. So that led to not an insignificant staff just to support the software, and their role primarily was to, if you got a discrepancy, an error in the software, to go fix it. And the move to distributive—the software-sustaining costs didn’t go down.

Ross-Nazzal: Okay. That was my question.

Mager: You just made it appear from the standpoint of Code B, who’s the comptroller at Headquarters. He couldn’t see a big number of people just to support the mission computer software. He’d have to look deeper down to see a little bit of software support sustaining for this workstation, this, you know. So it was a sleight of hand or whatever you want to call it.

Ross-Nazzal: I understand.

Mager: Gaming the system a little bit.

Ross-Nazzal: I’d like ask you two general questions.

Mager: Okay.

Ross-Nazzal: What do you think has been your most challenging milestone in working for NASA or the space agency?

Mager: I have a difficult time coming up with—because to me it was all a challenge. I liked doing it. So it came with the job. I enjoyed what I did. There was one period of time I felt like I was underworked. I missed the continuous operations activities, because it got stretched out, etc. If you talk about what I consider to be the most significant thing I’ve contributed, to me it’s probably just driving the control center away from something, an architecture that had been a driving force in the control center for twenty-five years. You meet resistance. You get told you’re dumb. “The old host base is tried and proven. We know how to do it. Why change?”

I just felt like we needed to change just to take advantage of what technology was giving us the capability to do, and I think the flight control team is much happier today than they were back then. You get into a situation where if I make a decision, I’m going to—let’s say each of you had your own workstation, and I made the decision that it was more cost-effective that if I put all those computers, your PC [personal computer], in one group, and you had to interface with that group to get your work done, you would fight it like hell, because, one, I took control of your ability to do your work out of your hands; and, two, I certainly took your ability to define your priorities, because that organization that now owns it is going to define the priorities.

So that was sort of the analogy going to the workstations versus—and why the flight control teams are much happier in a distributive environment than they were, because they had to come to me when they had the central host architecture. They couldn’t do it—if they wanted a new capability, if I said no, they couldn’t go try. I had a hammer. I had a hard control on that thing, whereas going distributive they can go try it. And it was my job to make sure that the software that interfaced from what they did back into the system protected the rest of the system from anything they did.

I don’t know if I answered your question.

Ross-Nazzal: You did. What was your most significant accomplishment?

Mager: I’d say it’s that, yes. You could always say I did fairly well. The system took care of me. I started to work at JSC as a GS [General Schedule]-12; ended up as a GS-15. I was number one for senior executive, and I told them no, didn’t want it. They got ticked off at me, but that’s okay. But that was just before I left. Basically, I’d already decided I was going to go plow some new ground someplace, at least try.

Ross-Nazzal: How did you make it out here to New Mexico working for the White Sands Test Facility [Las Cruces, New Mexico], as a contractor?

Mager: As a contractor. I started out with STSOC, and then we bid—RSOC [Rockwell Space Operations Company] bid on the ops support contract and won that one, which was to provide the same thing that STSOC did for Shuttle for Station. And I was the Honeywell—of course, it was Allied Signal [Inc.] at the time—the Honeywell program manager on that.

In 1992, Honeywell, Allied Signal, decided they were going to try to go after the Eastern Range M&O [Maintenance and Operations] operation contract out of Patrick Air Force Base in Florida. So they asked me to go support that proposal activity. So it was going to be done out of Cocoa Beach [Florida]. So I think in the May time frame of ’92, I moved to Cocoa Beach, and I spent thirteen months in Cocoa Beach working on that proposal, and we didn’t win.

So in June of ’93, I moved back to Houston on the STSOC contract, and they asked me to support putting together the best and final on [the team] contract out here.

At the same time, they decided that they needed to make a change in the proposed program manager for this contract out here, because they were having problems with the guy they had selected. So they picked a person who was a Rockwell employee and working on the STSOC contract. He was one of their department managers in Rockwell, well respected, had at one time been the chief engineer for Shuttle when Rockwell was building it, and they wanted to propose him. But they had a problem with that, Honeywell did, and that’s the fact he had no experience with Honeywell. So they asked me to be the deputy in order to back him up and make sure he had the Allied Signal input into how things should be done from a corporate standpoint. So that’s how I ended up out here.

I first came out here in December of ’93. I also had the responsibility for transitioning the contract; since we weren’t the incumbent. And came out in December of ’93, and about two weeks after we started transition, Lockheed [Corporation] filed a protest and we got a stop-work order. It wasn’t till April 6th of 1994 that we actually got started again. So I’ve been here since April 6th, 1994.

Ross-Nazzal: What are your basic duties out here at the facility?

Mager: We’re into our second contract out here. The initial contract I was officially on the contract as Deputy Program Manager. As a part of our proposal strategy, we decided we wanted to eliminate the [Deputy] Program Manager, so I become the Business Manager. Officially, I am the Business Manager, but I still do the Deputy function. I’m the senior old man, you know. Been around the circle several times. But basically as Business Manager. And it’s basic focusing on the contract, the financials and all that kind of stuff. And I love numbers.

Ross-Nazzal: Quite a bit of a change, moving from working with Mission Control to moving into being a Business Manager.

Mager: Well, but it’s a lot of the same things. I miss the ops environment, but one of my—probably the things I got known for was my ability to troubleshoot things, and it’s just the approach I took. I thoroughly understand the system. I know what each component of the system contribute to the whole. So if you’ve got problems, you look for the changes in patterns, and you can do the same thing with finance and numbers.

We got huge amounts of financial data, and just looking at the data with the knowledge of what the system is, can allow you to pick up problems. There’s always hidden information in all the data you get. To me, it’s a mental challenge to go find that information. Sort of turns me on.

Ross-Nazzal: I’m glad you enjoy it. If you don’t mind, I’d like to ask Sandra if she has any questions for you.

Mager: No.

Johnson: I just have a couple. I want to go back to more the Apollo time. You mentioned simulations a couple of times, and I was just wondering if you could tell me what your role of you and your group were during the mission simulations, and specifically with Apollo 13, had you simulated the problems that you had to overcome after the explosion?

Mager: In that case, no. But the simulations, I don’t know what they do today, but back when I was still there, we probably supported at least a minimum of 150 hours of simulations for every mission. In general, during those simulations, they insert problems, but I don’t recall us ever inserting a problem where you had an explosion and you had to do a transfer from one vehicle to the other vehicle, etc. I’d [have] to say no, we didn’t.

Johnson: Did you ever get a chance to travel to any of the remote communication sites?

Mager: Yes. In 1972—you’ve probably run across the name of Ed [Edward I.] Fendell.

Ross-Nazzal: Yes.

Mager: Ed Fendell and I, [NASA] had a practice of before every new program, of doing a site tour to brief each one of the sites on what’s coming up, what were the changes, what was the purpose of the program, etc. We usually had three teams, split up three teams and sent them out. Ed and I teamed together to go to—we went to MILA, we hit the Vanguard, which was the ship. We hit Bermuda, Madrid, [Spain], and Canary Islands.

Now, in my days at Point Mugu, I was over on the [operations] side of Point Mugu relative to maintaining the current systems and coming up with mods [modifications] for them, etc., but I got loaned out to the Development Department, and as part of that, they sent me to Miami Beach to accept a bunch of equipment from a company, which was going to be installed downrange on the Pacific Missile Range to support one of the nuclear test ban programs that [President Lyndon B.] Johnson at the time wanted to have the capability if the Russians violated the nuclear test ban treaty. So I got to spend time in Hawaii at the PMR [Pacific Missile Range Facility Hawaiian Area, Kauai, Hawaii] station, which also happened to be at the same location as the NASA site.

Then I spent seven weeks at Johnson Island, which wasn’t—it’s not the best place in the world to go. At the time they’d just dredged up coral to expand the size of the atoll from a quarter mile by a mile to a half-mile by two miles. And had 4,500 men on that island. I spent seven weeks there. The food was good.

Johnson: Also, I was wondering, during the ASTP time and when you were dealing with Russian engineers, as you mentioned, did you notice any major differences in the actual engineering style or the way that they were trained compared to the way you were trained?

Mager: I mentioned technically I found them to be pretty danged knowledgeable. Now, if you looked at their systems—one of the things we were able to do, they have an exposé or exposition complex—I think it’s out on the north side of Moscow—where they have buildings where they have on display all the products they produced, and one of those buildings had the actual Soyuz vehicle. So one afternoon, me and my Russian counterpart went out there. My perception from that was—when I was out there, I went and looked at their computers and went and looked at their test equipment. It looked like the test equipment—like Hewlett Packard [Company], another example, that they just carbon-copied us. The computer they had on display, it looked like a Univac 1218 that we used in the early 1960s at the remote site. You know, it’s one of the naval data—I can’t remember. It was one of the computers that Univac developed for the Navy.

And then looking at the Soyuz, their approach to things, whereas we tend to go to micronization of component systems, etc., you know, brute force. A lot of metal, heavy, big, thick, whereas we tend to—but the people I worked with I found to be very competent, from an engineering discipline standpoint, etc. I don’t think there was—from a technology standpoint, I may be wrong, but I don’t believe they was anywhere close to us from a technology standpoint. But a good engineer, if you give him the technology, it ain’t going to take him long.

Johnson: Thank you.

Mager: Okay.

Ross-Nazzal: Before we close, do you have any last words or anything else you want to touch on that we didn’t touch on?

Mager: Well, I had a—you don’t have to record this. I had an interesting incident while I was in Moscow.

Johnson: Do you want me to stop it?

Mager: It’s up to you. I had an incident, interesting incident while I was in Moscow. One of the afternoons we finished early, so we decided we were going to go tour, and my Russian counterpart and my interpreter, who was Russian, went along with us. There was four of us. So we decided we wanted to go to [Vladimir] Lenin’s mausoleum. So we went to Red Square and went by the building, I think it was the library or something that’s at the end of Red Square where you’re supposed to turn in any briefcases and that kind of stuff, and they’ll hold them for you while you go through.

My Russian counterpart, he had a sun-dried fish that he turned in there because we were going to go to the Russian-Brazilian soccer match that night, and that was going to be part of our treat, was sun-dried fish. So he turned that in, and I didn’t think about it, but I had a sport jacket on, and I had a camera in my pocket. Didn’t turn it in. So they said, “Come on.”

And the line to get into the mausoleum was probably a mile, mile and a half long. He said, “We’re not going to wait that long. Come on.” So they went up, and my counterpart went up and talked to a Russian officer, Army officer, I assume what he says was, “These are Americans that are part of the space program,” etc.

So the Army officer stepped in, pushed the people back, put us in line. As I was getting up just to go into the mausoleum, you had to go through another two guards who was looking at the crowd to make sure that everything was proper, etc., he noticed that bulge in my pocket. He yanked me out of the line. Of course, my Russian counterpart and the interpreter rushed over and, I’m sure, explained who I was and what I was doing there, probably didn’t understand the rules. So the Army officer suggested I go to the exit side and that there would be a militia man sitting there at the exit, and that I ask the militia guy to hold my camera for me till I come through. So I went around there. My counterpart went with me. And the militia guy wouldn’t take it.

So after about ten minutes, that Russian army officer left his post, come around to check on me, and he said, “Well, your other two people are just going through. They ought to be coming out the exit in a minute. Why don’t you just wait and give it to them and let them do it, and then come back, and I’ll put you in line.”

That’s what I did. Man, he stepped in and pushed people back, stuck me in line. Just getting into that mausoleum, they have their honor guard with submachine guns about every six feet, both sides of the steps as you go down. I happened to have raised my hand to scratch my head, and I heard “click.” Saw a motion. “Get your hands down.”

But I enjoyed Russia. If Russia today was like it was then, I’d probably like to go back. I’m not so sure about today. That’s just an off-the-side.

Ross-Nazzal: That’s a great story.

Johnson: Good story.

Ross-Nazzal: Thank you for sharing it with us. Do you have any other information you’d like to share with us?

Mager: I can’t even think of any. I probably do. You’re doing me a favor. Back before I left the government, I sat down and wrote a history of the control center and had it down on paper to the point I gave it to my Branch Chiefs to review. I got their inputs back, and you’d have to understand me, I don’t like writing, and to me, that was too much effort, and I threw it away.

Ross-Nazzal: Oh, no. So this is your history of the control center.

Mager: Yes. Part of it. But what I went through was a lot more extensive from a systems standpoint, did a lot more detailed explanation of the evolution of the systems, etc. And after sixteen years, I’m too far away from it.

Ross-Nazzal: We certainly learned a lot about the control center today. We appreciate you taking the time to share it.

Mager: My pleasure.

Johnson: Thank you.

Mager: I enjoyed it.

Ross-Nazzal: Thank you so much.

[End of interview]

Return to JSC Oral History Website