|
|
Operating Systems at Conception
Click here to get the file
Size
9.6 kB
-
File type
text/html
File contents
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Operating Systems at Conception</title>
</head>
<body>
<h1>Operating Systems at Conception</h1>
<p>Robert L. Patrick<br />
Atascadero, CA<br />
December 2008</p>
<h2>Abstract</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>Contents</h2>
<ul>
<li>Acknowledgements</li>
<li>Background</li>
<li>Concept</li>
<li>Features</li>
<li>Benefits</li>
<li>Notes</li>
<li>References</li>
</ul>
<h2>Acknowledgements</h2>
<ul>
<li>Bob Patrick, George Ryckman, Jim Fishman, Don Harroff, and (later) Floyd Livermore at GMR; and a team led by Owen Mock from NAA.<span style="text-decoration:none; "></li>
</ul>
<h2>Background</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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<span style="font-size:10.0pt; "> (5)</span>, 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<span style="font-size:10.0pt; "> (6)</span> 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.</p>
<p>My design was presented at SHARE <span style="font-size:10.0pt; ">(7),</span> 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.)</p>
<h2>Concept</h2>
<p>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.</p>
<h2>Features</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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. </p>
<h2>Benefits</h2>
<p>The system provided the following benefits:</p>
<ul>
<li>It was simpler to use and less work to program.</li>
<li>Professional operators ran the system.</li>
<li>Programmers stayed at their desks and programmed.</li>
<li>It gave better service for both test and production runs.</li>
<li>The number of jobs per hour increased tenfold.</li>
<li>There was no idle machine time if there was work to run.</li>
<li>There was no custom hardware involved (except the time clock).</li>
<li>There were no extra hardware rental dollars required.</li>
</ul>
<h2>Notes</h2>
<ol>
<li>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.</li>
<li>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 described 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.</li>
</ol>
<h2>References</h2>
<p>For further information about the GM-NAA I-O System see:</p>
<ol>
<li>Robert L. Patrick Oral History, Smithsonian Institution, 1973.</li>
<li>Time-Life Books, “Understanding Computers Series - The Computerized Society”, 1987, Pg 14.</li>
<li>Robert L. Patrick. “General Motors/North American Monitor for the IBM 704 Computer”, RAND Paper P7316, January 1987. Written for the National Computer Conference (Chicago), Old-Timers Session, June 1987. <a href="http://www.rand.org/pubs/papers/P7316/">Online at rand.org</a></li>
<li>Robert L. Patrick Oral History, Computer History Museum, 2006, Pg 56. <a href="http://www.computerhistory.org/collections/accession/102657941">Online at computerhistory.org</a></li>
<li>Henry Lawrence Gantt, “Work, Wages and Profit”, The Engineering Magazine, NY, 1910.</li>
<li>(original) GM I-O System Time Phasing Charts (architectural design), artifact collection, Computer History Museum.</li>
<li>SHARE, Boston, November 1955</li>
</ol>
</body>
</html>
|
|
«
|
July
2025
|
»
|
| Su |
Mo |
Tu |
We |
Th |
Fr |
Sa |
|
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
|
Forgot your password?
