Robert L. Patrick: Operating Systems at Conception
(I am honoured to publish here a document made by Robert L. Patrick, the architect of the first operating system in the world, GM-NAA I/O. A few of my words around this text are here. General page about the earliest operating systems is here. Milos.)
Operating Systems at Conception
On 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 (1), 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 (2) 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 (3), 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 system contained a core map in memory which the programmer was obligated to maintain during execution. If a program failed to run to completion, the operator restarted the computer and manually transferred control to a standard fixed location that would use 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 et al. 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:
- It was simpler and less work to program.
- Professional operators ran the system.
- Programmers stayed at their desks and programmed.
- It gave better service for both test and production runs.
- The number of jobs per hour increased tenfold.
- There was no idle machine time if there was work to run.
- There was no custom hardware involved (except the time clock).
- There were no extra hardware rental dollars required.
Postscript 1: I spent most of my career either developing applications or improving machine room operations. However, I did participate in several other noteworthy software developments, namely: as team leader on a business compiler for the H-800 at Computer Sciences, as an architect on the Direct Couple operating system extension to IBSYS for the IBM 7040-7090 at Aerospace, as an architect on the IMS/360 data base management system at Space, and as an architect on a custom data base system to support a research project at RAND.
Postscript 2: It should be noted that early operating systems up through the SHARE Operating System (SOS) were designed and implemented by the user community to meet pressing needs as bulleted above. Starting with IBSYS the systems were designed and implemented by the manufacturer to make the augmented machines more appealing in the marketplace. Various features have crept into the designs until today’s systems are big and function rich.
Postscript 3: For further information about the GM-NAA I-O System see:
- Robert L. Patrick Oral History, Smithsonian Institution, 1973.
- Time-Life Books, “Understanding Computers Series – The Computerized Society”, 1987, Pg 14.
- RAND Paper: “General Motors/North American Monitor for the IBM 704 Computer”, January 1987 for the National Computer Conference (Chicago), Old-Timers Session, June 1987.
- Robert L. Patrick Oral History, Computer History Museum, 2006, Pg 56.
Robert L. Patrick
- Henry Lawrence Gantt, “Work, Wages and Profit”, The Engineering Magazine, NY, 1910.
- (original) GM I-O System Time Phasing Charts (architectural design), artifact collection, Computer History Museum.
- SHARE, Boston, November 1955
~ by millosh on December 16, 2008.
Comments are closed.