Robert L. Patrick
Atascadero, CA
December 2008
In the early 1950s, the engineering/scientific community in the U.S. quickly embraced the electronic computer because they had a large backlog of applications awaiting digital solution. However, there were two problems: The programming problem and the operations problem.
Solutions to reduce the programming effort and increase its quality are well documented: FORTRAN, COBOL, ALGOL, and more recently C, C++, and Java. Less well known are the efforts to push more jobs per day through each installed computer system so programs could be developed quicker and more production application programs could be run to produce numbers for analysis, design, and manufacture.
To get more jobs per shift through an installed computer, Operating System Software was developed. The first such system was designed at General Motors Research Labs and implemented by personnel from GMR and NAA (North American Aviation) for the IBM 704. It first ran production in 1956 and greatly increased the number of jobs per day a 704 could process. The following short note describes how it came about.
In the early 1950s computers were delivered as kits: hardware and a set of manuals. This was a tradition from the punched card days carried over into early mainframe computing. Programmers, both manufacturing and customer, immediately started informally exchanging tested subroutines for popular functions, in punched card form.
In 1954, the mode of operation was: programmer present and (personally) operating the control console. Some programmers were good operators, and some were barely competent. Programmers were in short supply and when they were operating, they were not programming.
Computer sessions were scheduled as blocks of time, were seldom used efficiently, and there was always unused idle time between scheduled sessions. There were backlogs of work to be programmed and tested, competing with backlogs of production runs to be made. There was a shortage of computer time. There were only about two-dozen commercial mainframes in the entire country.
Convair, in Ft. Worth, Texas, installed IBM 701 #7 (out of the 17 that were built). While there, I studied the industrial engineering work of pioneer Henry L. Gantt (5), ran some throughput experiments, and had some ideas about more efficient computer operations. After I moved to General Motors Research (they installed 701 #17), I produced the conceptual design (6) for a non-stop multi-user operating system as part of GMR’s plan for the installation of an IBM 704 supported by standalone card-to-tape and tape-to-print peripheral subsystems to handle basic input-output.
My design was presented at SHARE (7), and resulted in a joint operating system development project between GMR and North American Aviation. The planned system was tape based and had three phases: Input Translation, Compute, and Output Translation. George Ryckman led the GM effort. Jim Fishman, Don Harroff, and Floyd Livermore did the programming. The NAA effort was led by Owen Mock who had participated in the Los Angeles PACT effort for the 701. (I do not remember the names of the other talented NAA programmers.)
There were two versions of the original OS package because Mock and I could not agree on how debugging during the Compute phase was to be handled. The GM version had a run-time monitor which used a core map in memory which the programmer was obligated to maintain during execution. If a program failed to run to completion, the monitor used the core map to selectively dump memory in a meaningful format for return to the programmer. (Online traces were so inefficient they were seldom used and there was no attached terminal hardware available.) After a memory dump, the OS proceeded to the next job in the queue without stopping.
Card decks through the peripheral card reader contained job ID, accounting information, control cards (nee JCL), programs, and data. The form of the programs could be binary cards (from a previous run) or new programs ready for assembly. The initial system processed a sequence of decks from various programmers as a single non-stop batch.
The Input translator converted the whole batch to binary and then called in the Compute phase monitor. As each job in the entire batch was executed, accounting numbers were generated, and all output was recorded in binary. The Output phase then converted all output to decimal and the resulting tape was hand-carried to the peripheral machines in an adjacent room.
George Ryckman, an electrical engineer by training, designed and built a time-of-day clock which the system sampled to provide accounting data. We billed for time used and lines printed. A machine produced accounting sheet accompanied each job back to the submitter. The computer center had a courier who made his rounds every hour to give desk-to-desk pickup and delivery service to each programmer.
Later when Fortran-I was available, the compiler was added as just another input translator. Programs in the input stream could be intermixed binary, SAP assembly language, or Fortran in a single run.
After I laid down the preliminary design (we’d call it architecture today), I was reassigned to lead the development of a high priority military application and became a user of the system Ryckman and his team produced. When programmers were present and operating, we scheduled six-minute blocks for checkout. With the GM I-O system in full operation, 60 test jobs an hour were possible (depending on the length of the tests). Twenty copies were distributed to other 704 installations.
The input tape allowed intermixed test and production jobs in one batch. On one occasion, late in the development cycle of our military trajectory program, I made up eight copies of our program deck and loaded a different set of case data behind each one on a single input tape.
The system provided the following benefits:
For further information about the GM-NAA I-O System see: