The Real Time Computer Complex (RTCC)

Picture #01

Picture #02

Picture #03

Picture #04

Picture #05

Picture #06

Picture #07

Picture #08

Picture #09

Picture #10

Picture #11

Picture #12

The eleven camera viewpoints on the RTCC layout.

The Mission Control Center with its RTCC became operational in January 1965 during the uncrewed Gemini 2 mission. Back then the RTCC was equipped with five IBM 7094-II mainframes to support the missions. It became clear that the IBM 7094s were insufficient for the required data processing tasks for the Apollo missions. It was decided that the IBM 7094s had to be replaced by the more powerful IBM 360/75s. These IBM 360/75s became operational in 1968. System upgrades were made continuously. For example, the disk drives IBM 2311 were gradually replaced by the IBM 2314 to reduce access times and increase storage capacity.

Note to the reader:
Since I have not been able to find any layout of the arrangement of the five IBM 360s in the RTCC, I have decided to draw the layout myself. I went through numerous iterations in which I tried to validate the drawn plan against photos or film footage. I have tried to collect all kinds of visual information as much as possible to have this iteration process converge towards a reasonably accurate depiction of the layout. I have also tried to familiarize myself with the spatial aspects of the room itself, with the used peripheral equipment, with its dimensions, and with the various IBM manuals, to discern the logic behind the arrangement of the equipment. There are still white spots, though. I have not been able to identify some of the equipment cabinets. So I am still looking for a more elaborate drawing of the RTCC systems configuration. Also the location of the System Select Unit has still not been identified. My guess would be somewhere near cluster E in front of the control room. But I have not been able to verify my conjecture.
The camera viewpoints as denoted on the layout in picture 12 are a reflection of this iteration effort in which a version of the drawing was validated against photo's. It took me some time first to identify the various camera locations in the RTCC room using visual clues like support columns, adjacent (control) rooms, windows, doors, ceiling, ceiling curtains, walls, and the equipment itself.

Further, there were two smaller mainframe systems which were used for data preparation (ref.10, section 2.3.3). These mainframes form the Auxiliary Data Processing Subsystem. My conjecture is that both systems were located in the room for tape and auxiliary storage and that these mainframes might have been IBM 360/65 models. However, I still have found no information about their location or about the mainframes.

The RTCC was part of the Mission Control Center (MCC) and in conjunction with the Communication, Command and Telemetry System (CCATS) and the Display & Control System it provided and presented data on demand to flight controllers and their support groups.

The Real Time Computer Complex (RTCC) was used for processing incoming data to provide data to be displayed on the various flight controller console screens and to compile program instructions and data to be uploaded to the guidance computer of the Apollo spacecraft. The RTCC could also provide the necessary computer power to provide in depth analysis and to provide recommendations on spacecraft trajectories for the on going mission.

The RTCC consisted of five mainframes computers. One mainframe was active, a second mainframe was in dynamic standby and did the same work in parallel with the primary mainframe. A switch to the standby mainframe could be done swiftly in the case the primary would fail. A third mainframe was kept in reserve. The two other mainframes were used for simulations, to make preparations for the next upcoming Apollo mission or to process data from the scientific packages of the current mission which were deployed on the lunar surface by the astronauts.

The overall MCC system configuration is depicted on this page about the MCC.

1. The system context of RTCC to illustrates its role and its purpose.
2. The layout of the RTCC.
3. The layout of the RTCC Control Room.
4. The voice loops between RTCC and MOCR.
   These voice loops were used to discuss and request computer support by the RTCC to the MOCR controllers.
   However, controlling spacecraft systems remotely in which commands and data needed to be uplinked to the spacecraft often required support from the RTCC to prepare the command/data package and the CCATS to have these packages formatted, managed and dispatch them to remote stations to have them stored awaiting the request from a MOCR controller to have the package uplinked to the spacecraft.
   Controlling and commanding a spacecraft remotely was facilitated by "The Command Subsystem".
5. The typical system configuration of an IBM 360/75J as used at the RTCC.
   This section also pays attention to the IBM 360/75 system architecture.
   The architecture of its IBM 2075 CPU is briefly discussed on a separate page.
6. The iconic appearance of the IBM 360/75 is discussed briefly.

Diagram based on ref.10, figure 3-1.

The MCC comprised three systems:

1. The Communications, Command and Telemetry System (CCATS)
   1. Communications Facility Control Subsystem
   2. Voice Communications Subsystem
   3. Telemetry Subsystem
   4. Central Processor Subsystem
   5. Teletype and Fascimile Subsystem
   6. Pneumatic Tube Subsystem
2. The Real Time Computer Complex (RTCC) System
   1. RealTime Computer Complex (RTCC)
   2. RTCC Control
   3. Auxiliary Data Processing Subsystem
3. The Display/Control System
   1. Computer Display/Control Interface Subsystem
   2. Timing Subsystem
   3. Television Subsystem
   4. Group Displays Subsystem

The television Subsystem and the Group Display Subsystem were used to present all the mission-related information to the mission controllers in MOCR, the staff in the SSRs and the RCR.

CCATS and RTCC
The three systems, CCATS, RTCC and the Display/Control System, are depicted in a functional block diagram shown above.
The diagram shows the mutual relationships between the three systems. CCATS had a prominent role in managing and processing communication and data traffic. The RTCC provided support to the CCATS by processing data.
The RTCC, with its five IBM 360/75J mainframes, had much computer power and was considered the top of the high-end computers in the late sixties / early seventies. The RTCC was also used to do all kinds of analysis on data for the mission controllers with regard to spacecraft systems, tracking and trajectory control. Programs were frequently running to provide data for the required spacecraft attitude, thrust vectors, burn times and time to enable the spacecraft to change its trajectory to correct its trajectory or change it into a contingency trajectory in case of emergencies. Several programs could be running on a single mainframe virtually simultaneously thanks to its job management capability to use its CPU efficiently. It enabled the mission controllers to maintain optimal situational awareness and anticipate various events in this dynamic mission environment.

Display/Control System
The funny blue L-shaped and U-shaped bars in the block diagram above depict the supporting role of the Display/Control System in providing and presenting data to the controllers in the RCR, the SSRs, the MOCRs, the RTCC Control Room and the CCATS Command Room.
Some of the MOCR controllers could also submit computer requests via the Computer Display/Control Interface Subsystem to the RTCC and submit command initiation requests to CCATS. These command initiation requests were basically instructions for a remote site computer and were formatted and sent by CCATS through a network of remote site computers. The RTCC, CCATS and this network of remote site computers were the backbone of the Command Subsystem. This system enabled the mission controllers to control the spacecrafts.
The U-shaped bars illustrate that the RTCC Control Room was part of the RTCC Computer Control Subsystem and was supported by the Display/Control System. Also the control equipment of the CCATS subsystems was supported by the Display/Control System.

Diagram based on ref.10, figure 3-2, section II and III.

1. The Communications, Command and Telemetry System (CCATS)
2. The Real Time Computer Complex (RTCC) System
   1. the Real Time Computer Subsystem,
      This subsystem consisted of five IBM 360-J75 mainframes with peripheral systems as depicted in section 5.
   2. the Computer Control Subsystem,
      to monitor computer performance, manual control of mission programs and data
   3. the Auxiliary Data Processing Subsystem,
      For input data preparation, the data were put on tape and made available for the Real Time Computer Subsystem. This subsystem consisted of two groups of equipment. Each group was set up around a central processor equipped with a core storage unit, disk and tape units.
      Note to the reader:
      I think that an IBM 360-50 was used as the central processor. The processing unit of this model was the IBM 2050 CPU. This CPU contained a multiplier channel and an optional one, two or three selector channels. But I am still looking for information to check my conjecture.
3. The Display / Control System

Five systems can be distinguished (A, B, D, E and F) (the letter C was not used).
The core of each system was formed by an IBM 360 model J75 mainframe. To this mainframe peripheral systems were connected: additional magnetic core memory units, disk drive units, tape units, line printers, card readers, teletype units, data adapters, etc. In the 1960s this mainframe IBM 360 was one of the most sophisticated computers of its time.

One of those five systems was sufficient to support an Apollo mission. Two of the remaining 4 systems were used as backup.
One mainframe was active, and a second mainframe was in dynamic standby and did the same work in parallel with the primary mainframe. A switch to the standby mainframe could be done swiftly in case the primary would fail. A third mainframe was kept in reserve. The two other mainframes were used for simulations, to make preparations for the next upcoming Apollo mission or to process data from the scientific packages of the current mission which were deployed on the lunar surface by the astronauts.

The RTCC was located on the first floor of the Operations Wing of the Mission Control Center (MCC) in Houston. (This MCC building had 3 wings: the Administrative Wing, the Lobby Wing and the Operations Wing.) The Operations Wing had 3 floors. In the 1960s and 1970s there were two Mission Operations and Control Rooms, one MOCR on the second floor and the other MOCR on the third floor.

IBM 360 model 50
The two IBM 360/50s of the Auxiliary Data Processing System were probably located in the room for tape and auxiliary storage.

DYNAMICS - Flight Dynamics Processing Controller
Was responsible for RTCC processing related to trajectory control.

COMPUTER COMMAND - Computer Command Controller
The responsibility of this controller pertained to:
- RTCC Digital Command System processing;
- retrofire and reentry planning;
- and recovery support.

COMPUTER TM - Telemetry Processing Controller
Was responsible for all RTCC processing of telemetry data.

SUPPORT - RTCC Select Support Controller
The select support controller provided advise on trajectory and orbit determination. In that role it also provided assistance to the Tracking Data Select Controller.

RTCC CMCC - RTCC Computer Monitoring & Computer Control

COMPUTER SUPERVISOR - RTCC Complex Supervisor
Was responsible for the overall RTCC operation.

COMPUTER M & O - Computer Maintenance & Operations Support
This name must be considered as a station designation.
Behind this station the RTCC director and the M&O supervisor were residing. They were responsible for all of the RTCC computer related hardware configurations and their functioning.

ALSEP - ALSEP Computer Controller

In the computer area each of the five IBM 360/75J mainframes was controlled by an operator who was named the Printer Controller. Printer Controllers who became responsible for an MOC and a DSC were given the call signs MOC and DSC.

Diagram based on descriptions in ref.9

AFLIGHT - Assistant Flight Director
Duplicating the flight director's duties, monitoring the mission and supplementing the flight director's control.

CAPCOM - Capsule Communicator
Was usually a colleague astronaut and was in his role as flight controller the only one in the room who was allowed to talk directly to the spacecraft's crew.

INCO - Instrumentation and Communication Officer
INCO monitored the communications systems for both the Command Module and the Lunar Module, taking these tasks from EECOM and TELMU respectively.

O & P - Operations and Procedures
Making sure that flight controllers followed all of the procedures when asking for data or communicating with people, all according to flight control operations handbook.

FAO - Flight Activities Officer
FAO, was the timeline manager for the mission and ensured that the preplanned activities for each mission were occurring on schedule.

NETWORK - Network Controller
NETWORK functioned as the interface with the global network of MSFN data collection and transmission stations which served NASA.
(MSFN: The Manned Space Flight Network was a set of tracking stations built to support the American Mercury, Gemini, Apollo, and Skylab space programs)

EECOM - Electrical, Environmental and Communications
Watching over the Command and Service Module's electrical and environmental systems.
The "communications" part was moved over to INCO after the Apollo 10 mission to ease the elaborate task of EECOM.

TELMU - Telemetry, Electrical and EVA Mobility Unit
Watching over electrical and environmental systems of the Lunar Module and the Lunar suits.

CONTROL - LM Guidance, Navigation and Control
The CONTROL operator monitored the state of the reaction-control systems, the descent and the ascent engines of the Lunar Module, as well as the hardware components of the spacecraft's guidance systems.

BOOSTER - Booster System Engineers
Monitoring the performance of all three stages of the Saturn V

FDO - Flight Dynamics Officer
Monitoring the flight trajectory of the launch vehicle and the spacecraft. FDO was also responsible for producing the data to compensate for flight path deviations.

GUIDO - Guidance Officer
Ensure that the Apollo Primary Guidance, Navigation and Control Systems (PGNCS) on both the Command Module and the Lunar Module operate correctly.

RETRO - Retrofire Officer
Is reponsible for getting the spacecraft back in case of mission abort and during the return phase of a mission. During the mission RETRO always kept a list of abort options to take swiftly adequate actions in case of emergencies.

SURGEON - Life Systems Officer / Flight Surgeon
Medical doctor who monitored the health of the crew.

A voice loop could be used in two different modes:

1. A monitor mode in which the controller was constantly listening in on the loop.
   
2. A listen/talk mode in which the controller could make a call to another controller on that loop or participate in an ongoing conversation.

For those voice loops for which it would only be required to listen/talk but not to monitor, only the listen/talk key could be found on the Keyset Unit. If the loop was used by somebody, the key would light up white, but audio was not reproduced. By pressing the lit key, the controller could listen and talk; the lit key went from steady white to flashing white.

All the voice loops depicted above were monitored constantly by at least one controller, meaning all the controllers involved were supposed to listen in continuously. By pressing an appropriate button on the Intercom Keyset Unit, a controller was enabled to speak on that particular voice loop. Since controllers had to listen in on many channels simultaneously to maintain a mission situational awareness, there was a way to manage the stream of audio information by controlling the volume of the individual voice loop channels.

Usage modes of the voice loops
Voice loop "MOCR DYN" was monitored by the RTCC controllers SUPERVISOR, DYNAMICS and COMPUTER TM and by the MOCR controllers GNC, CONTROL, FIDO, GUIDO and RETRO.
This voice loop was primarily used to discuss matters or exchange information on trajectory control.
The remaining MOCR controllers also had access to this voice loop, but they were not able to monitor this loop. They were only able to initiate a call or participate in an ongoing conversation, as denoted by the one-direction arrows.

Voice loop "RTCC TLM" was only monitored by RTCC controller COMPUTER TM to be alert to any request or any question from an MOCR controller. This voice loop was not monitored by the MOCR controllers.

The voice loop "FD" was used by the flight director to manage the MOCR controllers and the RTCC supervisor. Via this voice loop the supervisor kept FLIGHT informed about the status and the conditions of the MOC and the DSC. It underlines the importance of the RTCC providing support to MOCR. Without the RTCC, the MOCR controllers would be virtually blind.

The voice loop "RTCC CA/CB" was monitored by all the RTCC controllers and the MOCR controller NETWORK. The RTCC supervisor was the point of contact for NETWORK.

The voice loop "RTCC DYN" illustrates the required intensity of communication between FIDO, RETRO and the Computer Command Controller during a mission. The RTCC mainframes provided computational support during the mission. To make optimum use of the mainframes, the mission was divided into phases. For each phase a computer program subroutine was written to provide the support. Each phase and the transition between phases were meticulously monitored jointly by the RTCC supervisor, the Computer Command Controller, FIDO and RETRO. An emergency during launch, for example, would have triggered an abort for which it was required to force the computer to go into mission phase "Abort (Mode I, II, III)" and immediately start running the appropriate program subroutine to produce the required trajectory data for a safe return.

The tasks of FIDO and RETRO also encompassed submitting computational requests to the Computer Command Controller via "RTCC DYN" on a regular basis to anticipate eventualities or to have trajectory options available on request.

The "re-entry" phase apparently did require intensive consultation between the RETRO and the Computer Command Controller to have a decicated voice loop "REENTRY SUPPORT" justified for those two controllers. The RTCC Supervisor was monitoring this voice loop.

Command load messages and real-time commands
The data packages and the software updates were called command load messages and were used to update the navigation and guidance systems.
The commands to operate the spacecraft systems were called real-time commands (RTCs).
RTCs were prepared for the start of each Apollo mission and were dispatched to remote tracking stations and stored, ready to be uplinked to a spacecraft when required.
During the Apollo 11 mission, about 106 command loads were generated; 15 of them were "premission", prepared prior to the mission. The majority of the command loads had to be prepared during the mission because their content depended on the most recent telemetry and trajectory data.

Interplay between MOCR, RTCC and CCATS to generate and to send command load messages
According to ref.11 on page 9-6, the controllers BOOSTER, RETRO, FIDO and GUIDO were able to request the generation of command loads.
According to the voice loop configuration as depicted above, the voice loops "RTCC DYN", "REENTRY SUPPORT" and "RTCC CMD NET" were used by these four MOCR controllers to request a so-called command load generation. These three voice loops were monitored by the RTCC Computer Command Controller, who was responsible for generating the command loads.
Requests could also be submitted by sending request forms via the pneumatic tube system containing the most recent telemetry and trajectory data, which needed to be incorporated into the generation process.
The RTCC assigns unique 4-digit load numbers to each generated command load message. Each command load message was reviewed by a MOCR controller before it was transferred from the RTCC to CCATS for approval and formatting of the message to have it transferred to one or more remote tracking stations.

Command panels for mission controllers
The consoles of MOCR controllers BOOSTER, GUIDO, INCO and CONTROL were equipped with command panels to request an uplink of a specific command load to a spacecraft. These command panels also enabled the controllers to uplink so-called Real Time Commands (RTCs) to flip a valve or switch on equipment remotely. These command panels can be considered as the MOCR user interface with the Command Subsystem.

More information about the use of the command system can be found on these pages:

• "The Command Subsystem"
• "User procedures for the Command Subsystem"
  Note:
  This page contains message sequence diagrams which depict the interaction between MOCR, RTCC, CCATS, the Goddard Space Flight Center, the remote tracking station and the spacecraft to uplink command load messages and real-time commands.
  Furthermore, command panels used by the MOCR controllers are depicted on this page. However, the page itself functions as a tool to gather information about how the panels have been actually used.

Voice loops and the Command Subsystem
Since consultation between the MOCR, RTCC and CCATS was pivotal to operate the command subsystem properly, the voice loops had an important function.
The voice loops were organized to optimize the communication between the officers in MOCR, RTCC and CCATS for particular tasks or mission phases. For example:
The voice loop "RTCC CMD NET" provided the possibility for quick and efficient consultation between BOOSTER, GUIDO, the RTCC Computer Command Controller, the CCATS Computer Command Controller and the CCATS Command Load Transfer Controller during the generation of a command load, its CCATS validity check, during the formatting of the command load message and the transfer of the message to the remote station.
The voice loop "REENTRY SUPPORT" was dedicated to the critical reentry phase of a mission. Unlike the officers BOOSTER, GUIDO, INCO AND CONTROL, the RETRO console was not equipped with command panels. However, via voice loop "REENTRY SUPPORT", RETRO could request a data update to be uploaded by the COMPUTER COMMAND CONTROLLER via the Command Subsystem system.

Based on ref.4 figure 2 and ref.5 figure 50.

Backup arrangement
Configuration of an IBM 360/75 computer as selected by NASA for the Apollo mission support.
In this diagram is also shown how the Mission Operational Computer (MOC) was connected to a Dynamic Standby Computer (DSC). In this configuration the DSC was running the same jobs as the MOC but would not send data to the CCATS and to the Display & Control System. In case the MOC would fail, the DSC could take over swiftly.

The connection between the MOC and the DSC via the Channel-to-Channel Adapter (CCA) was used to establish an MOC-DSC pair out of the five available mainframes. It was used for transferring all the allocated storage from MOC to DSC to enable the DSC to duplicate MOC's work.

In case the DSC became the MOC, then the MOC became the DSC. If the problem with the previous MOC could be fixed quickly, the computer pair was maintained as well as the switching of roles. There was, however, always a third computer kept in reserve. In the case the original MOC had to be put out of commission for some time, the DSC, which had become the MOC, had to be paired up with the reserve computer, which then became the new DSC.

Note to the reader:
I am not sure whether the DSC obtained the data from the System Select Unit (SSU) via the MOC's Selector Channel or from the SSU directly. My guess would be from the SSU directly; it would make sense to duplicate the operational environment of the MOC as much as possible and have the peripheral equipment of the DSC doing the same jobs as that of the MOC as much as possible.

IBM 2075 CPU
The CPU was divided into three units:
1. the Bus Control Unit (BCU);
2. the Instruction Preparation Unit (I-Unit);
3. the Instruction Execution Unit (E-Unit).
The categories of functional units for each CPU unit are represented in the diagram.
In the diagram the Program Status Word Register (PSW register) of the I-Unit has been mentioned separately from the category "Registers". The 8 byte long PSW contains the 3 bytes long Instruction Counter and a total of 40 bits of data fields containing all kinds of status and control information which were instrumental for operating the CPU.

To a large extent the three units were operating independently and simultaneously. These units reflected the three distinct tasks which could be executed simultaneously to enhance the efficiency of the CPU. The units were logically interlocked to prevent them from overrunning each other.
The actual execution of an instruction which resulted in the requested end product was done by the E-unit.
The I-unit was responsible for fetching the instructions and fetching the operands, in fact collecting all the information the E-unit needed to just execute an instruction.
The BCU was taking care of all the required traffic between the CPU and the external devices.
The various decoders in the I-Unit and the E-Unit were translating the various operation codes (the instructions) into control signals which were sent to the appropriate functional units and to gates to set up the required data paths for actual execution of the instructions.

The instructions and the data were fetched from the Main Memory, where they were kept in storage as machine code. The machine codes were produced by a compiler or assembler program which had converted the user program, which was written in a high-level programming language, into machine code. This conversion process also included the breakdown of the high-level language instructions into a sequence of instructions (in machine code) which could be understood and executed by the CPU.
Compilers and assemblers were residing in the Main Memory or/and in the LCS.

A set of instructions which can be processed by a CPU is an integral part of its design. An instruction set is in fact laid out in the CPU decoders, which translate the instructions into control signals. Compilers and assemblers are provided with a library of all the available CPU instructions, which are used to convert the user program into machine code instructions. Since compilers or assemblers have to use a CPU to do their job, it is the CPU which is actually doing the conversion and is in fact used to generate its own input to execute the user program.
The instruction set of the CPU 2075 contained about 170 instructions.

The CPU 2075 was hardwired and not microcoded to maximize its processing speed.
The IBM 2075 CPU and its system context are briefly discussed in more detail on a separate page.

CPU memory
The CPU had access to up to four IBM 2365 units of 256 kbyte Processor Storage, a total of 1 MByte of storage. Data were stored in eight-byte words. So a total of 128 000 words could be stored in the main memory.
Two IBM 2361 Large Capacity Storage (LCS), with a capacity of 2 MByte each, could be added as a 4 MByte (512 000 words) extension of the Processor Storage.
The LCS also acted as a buffering device for exchanging data and programs with the IBM 2314 disk drives.

OS/360 and RTOS/360
The Operating System of an IBM 360 was residing on disks or tapes.
The mainframes needed to produce real-time data for the MCC to operate properly. For that purpose the OS/360 had to be adapted. OS/360 was an operating system for batch processing. For real-time applications a more sophisticated approach was required with regard to handling interrupts and tasks. IBM had developed an extension of the OS/360, the RTOS/360, the Real Time Operating System/360, to meet NASA's demands. Many features had been incorporated into this RTOS/360 to enhance the performance of the CPU and core memory, to introduce a Real-Time I/O Control System, to increase system reliability, to enhance task and data management and to improve the operator's monitoring and management utilities.

I/O Channels
The CPU 2075 had seven I/O channels. At least one of these seven must be used as a multiplexer channel and the other ones as a so-called selector channel. The multiplexer channel was suitable to be shared by various low-speed devices like printers, card readers and teletypes. A selector channel was suitable for high-speed devices like disk drives. It operated in the burst mode, meaning that it served one I/O device at a time. A selector channel could be subdivided into a maximum of eight subchannels; a total of 256 I/O devices could be addressed.
In this diagram tape drives are connected to the selector subchannels of the IBM 2870, which also contained the multiplexer subchannels.

In the diagram it is shown that for Channel 1 one subchannel was used to send data to other MCC systems and one subchannel was used to exchange data with disk drives.
The IBM 2701 data adapter unit provided a rapid demand response interface to the digital display (D.TV) in the MOCR and the RTCC.

The bidirectional exchange of data between the CPU and other MCC systems was provided through the Multiplexer Channel at apparently a lower data rate. Nevertheless, real-time acceptance and transmission of large amounts of data and control information could be accomplished through the use of the IBM 2902 Multiplex Line Adapter (MLA).

The IBM Storage Channel was an attachment to the IBM 2860-2 Selector Channel. It provided the capability of high-speed data transfer between storage locations in the main memory and the LCS. This storage channel enabled swapping of data and programs from low-speed storage to high-speed main processor storage and vice versa to use the high-speed CPU as efficiently as possible.
Using the storage channel was part of an usual strategy to organize storage types according to their performance. It was important that the operating system was able to anticipate the CPU's data and program routine demands; these data were often kept in storage in low-performance storage devices. Data traffic was well choreographed by the operating system to have data retrieved and transferred all the way up in the hierarchy of storage types right on time for processing according to a scheme as shown in the picture below. The CPU output was then transferred down in the hierarchy of storage types.

A selector channel could also be used to exchange data with another CPU.

Large Core Storage Support
One of the features of RTOS/360 was the improved management of the Large Capacity Storage (LCS). The LCS could be operated in three modes of operation to increase the performance of the IBM 360/75:

1. Using the LCS for job shop operation management, which comprised various tasks:
   1. Using the LCS as an assembler work space instead of disks or tapes to improve assembler execution time;
   2. Using the LCS instead of main memory as work storage for compilers to allow larger compilations to be performed in main memory;
   3. Placing job control information on the LCS to increase job throughput;
   4. Using the LCS as a system residence device for nonresident (resident on disk or tape) operating system programs.
2. Using the LCS as an addressable extension of main memory to be able to run larger application packages
3. Using the LCS as a data funnelling device as depicted in the picture above. The RTOS/360 played a pivotal role in managing data swapping in the memory hierarchy chain to keep up with the CPU's information demand and to keep it busy to use the CPU as efficiently as possible.

1. as an extention of the CPU main memory in which data flows between the BCU and the LCS;
2. as a data swapping device in the memory hierarchy. In that case the storage channel is used to enable the LCS to operate as an intermediate storage device between main memory and other storage devices via the selector channels.

------

Drawing based on ref.8 figure 6 and various photos. Group names of indicators: ref.8 page 26.

Control panels, like the one shown above, with a bank of lights and toggle switches, were very common in the nineteen-fifties, -sixties and -seventies. For an outsider it gave the illusion that we could look into the mind or the soul of the computer, into the inner workings of a man-made living entity, to put it poetically. However, this actually is not far from the truth.

The CPU of the IBM 360/75, containing all kinds of registers, circuitry for arithmetic and logic operations, control circuitry and gates, was made up of several circuit boards. All those lights on the control panel were directly connected to various circuitry. Those lights gave a trained engineer instant information about the health of the circuitry. In case of a CPU failure, an engineer could run a diagnostic program to help identify the problem. The control panel was, however, very helpful to identify which circuit board was responsible for the failure and needed to be replaced. The various toggle switches enabled the engineer to intervene, to insert data or instructions as (binary) machine code into various CPU registers and go through a sequence of computer cycles step by step to exercise diagnostics.

The various lights or indicators on the control panel, reflecting the content of registers and the status of controls, gates and checks, were grouped. Some indicators were vacant.
The IBM 360/75 was a 64-bit computer; it had a 64-bit main memory. For its operations it used 32-bit words or 64-bit double words. Units of 8-bit bytes or 4-bit nibbles were used for short words.

A little bit more about diagnostics
The CPU was equipped with special hardware (Fault Location Testing (FLT) hardware) to help the engineer to check CPU circuits. The FLT hardware had a 45-bit FLT Control Word register to display the test result on the system control panel. When the mainframe was put in the FLT mode, test words could be read from tape to run checks on the CPU circuits. When a failing circuit was detected, the ID number of the present test which had failed was shown in the last 18 bits of the FLT Control Word. This ID number could be looked up in a listing where information could be found about which circuit and which test points were associated with the failure.

Impressive fast developments of large scale integration of circuitry on single silicon chips took off in the mid 1970s and is ongoing. These developments have resulted in highly reliable computer circuits and have rendered this kind of diagnostics obsolete. Control panels like the one shown above are nowhere to be found in computer systems for nearly four decades.

1. Introduction to IBM System/360 Architecture
   (For students)
   International Business Machines Corporation, 1967
   White Plains, New York

2. IBM System/360 Model 75
   Functional characteristics
   IBM Systems Reference Library 1964, 1967, 1968, 1969, 1974
   International Business Machines Corporation, Data Processing Division
   White Plains, New York

3. IBM System 360 System Summary
   IBM Systems Reference Library 1964, 1967, 1968, 1969, 1974
   International Business Machines Corporation, Data Processing Division
   White Plains, New York

4. RTOS - Extending OS /360 for real time spaceflight control
   by J. L. Johnston
   International Business Machines Corporation
   Houston, Texas, May 1969

5. IBM Field Engineering Manual of Instruction
   2075 Processing Unit - Volume 1
   Comprehensive Introduction
   Functional Units
   IBM Systems Development Division, Product Publications
   Kingston, New York, December 1965

6. IBM Field Engineering Manual of Instruction
   2075 Processing Unit - Volume 2
   Storage Bus Control
   Instruction Preparation
   FLT, Logout, MCW
   Interrupts
   IBM Systems Development Division, Product Publications
   Kingston, New York, December 1965

7. IBM Field Engineering Manual of Instruction
   2075 Processing Unit - Volume 3
   Fixed Point
   I Execute
   Branch
   Floating Point
   Variable Field Length
   IBM Systems Development Division, Product Publications
   Kingston, New York, January 1966

8. IBM Field Engineering Manual of Instruction
   2075 Processing Unit - Volume 4
   Special features
   Power Supply and Control
   Appendix
   IBM Systems Development Division, Product Publications
   Kingston, New York, March 1966

9. Project Apollo 500 RTCC Operations Support Plan For Mission G
   MSC Internal Note No. 69-FS-2
   Flight Support Division, Flight Software Branch
   Manned Spacecraft Center, Houston, April 1969

10. Familiarization Manual
    Mission Control Center Houston
    PHO-FAM001, 30 June 1965
    by Western Development Laboratories, Houston Operations

11. Saturn V Flight Manual SA-506 (Apollo 11)
    George C. Marshall Space Flight Center
    MSFC-MAN-506, 25 February 1969
    page 9-5 and 9-6

12. Apollo 13 mission, EECOM console layout
    https://history.nasa.gov/afj/ap13fj/pdf-hr/a13-eecom-console.pdf
    Prepared by Andy Anderson
    From the Apollo 13 Mission Documents section of

    The Apollo 13 Flight Journal
    by David Woods, Johannes Kemppanen, Alexander Turhanov and Lennox J. Waugh
    NASA History Division