Robert L. Patrick Richard K. Van Vranken
Atascadero, CA El Segundo, CA
February 2009
The Direct Couple was an important step in the evolution of large mainframe operating systems which led to OS/360. The series started with the GM-NAA Operating System in 1956, and progressed through SOS, IBSYS, the Direct Couple, and then to the vast OS/360 in 1965.
IBSYS was an operating system for the 7090 that evolved from SOS (SHARE Operating System) for the 709 which evolved from the GM-NAA I-O System (General Motors - North American Input-Output System) for the IBM 704. These were all tape-oriented batch systems for engineering/scientific computation. The Direct Couple extension to IBSYS was an intermediate step in the evolution of “big iron” operating systems leading to OS/360.
The workload on an engineering/scientific computer system, then as now, consisted of a mix of short checkout jobs (typified by compile and go) across the spectrum to heavy compute jobs typified by double precision matrix inversions or a set of partial differential equations that predicted the performance of a space system. In the early 1960s, computer center managers used a metric to discuss their workloads. It consisted of the ratio of the sum of Input and Output cycles to Computing cycles for a single job. With this metric, you would find program development had a ratio in the middle of the spectrum; commercial jobs used a lot of I-O and little Compute; and engineering production would involve a little I-O and lots of Computing cycles. These were intuitive measures, glibly used in conversation, but seldom measured.
IBM built the 709 with channels that buffered the I-O so the arithmetic and logical unit of the mainframe could be occupied with useful work while I-O was taking place in parallel. If you had enough compute work, you used all of the available cycles efficiently. The 7090 was a faster mainframe of the same architecture with some added features and solid state circuitry to make it much more reliable. The 7090 (and its enhancements) became the workhorse of the engineering and scientific community.
While the operating systems of the day used computer resources efficiently, the nature of batch systems homogenized priorities within each batch. The innovations related to Time-Sharing successfully gave better service to individuals but at a high dollar cost. The Direct Couple was an attempt to give better service in the industrial environment without excessive cost.
The corporate purpose of the Aerospace Corporation was to support the country’s national security needs. A private, nonprofit company, it accomplished that objective by providing architectural and engineering services to military space systems and their related technologies. In particular, Aerospace supported the Air Force Systems Command’s Space Division, which planned and managed acquisition of U. S. military space systems and their related equipment, launch sites, and facilities.
Aerospace had a 7090 with a tape configuration installed and was giving efficient batch service, but had some high-priority customers who could not get acceptable service without destroying the production schedule when they usurped the whole machine to support a space launch. At about this time IBM announced the 7040 computer.
The 7040 was architecturally almost compatible with the 7090 (a cousin, so to speak), was physically smaller, slower, and less expensive. A person in the computer center at Aerospace, (the Director, Jack C. Van Paddenburg, as we recollect) was reviewing IBM’s latest offering and discovered a pricing anomaly. The I-O channels/control units for the 7090 were so expensive that a whole 32K 7040 with integral channels could be rented for the same price.
About the same time, the IBM Price Book offered a channel accessory that would allow external devices to be connected to a 7090 computer channel without Special Engineering. The accessory also allowed the channels of two IBM computers to communicate. This led to discussions by Dr. Robert R. Brown, Van Paddenburg, Richard K. Van Vranken, (all Aerospace employees) and Robert L. Patrick (a consultant); about what functions could be easily moved from the 7090 to the 7040 to get more throughput without spending more rental dollars. The discussions led to the development of the Direct Couple extension to IBSYS, and eventually HASP (Houston Attached Support Processor) and ASP (Attached Support Processor) for the S/360.
To estimate the throughput improvements we could get on our 7090, running our workload, if all buffers and device drivers were moved from the mainframe to the support computer, we measured our workload at the macro level. Van Paddenburg had long had excellent statistical and service reports that characterized his workload, the originating customer set, and the service levels attained. In case of breakdowns, he knew which customers were discomfited before they began to call. He also knew how much excess capacity his installation possessed.
Van Vranken was lead systems programmer. When we needed I-O/C statistics on each job, he and his systems programming team quickly modified IBSYS to produce overlap and interlock data. We analyzed the data, issued an engineering performance report (1), and decided an attached processor to handle the I-O would increase the number of jobs/day without increased rental, plus improving our service levels. Further, we freed up high-performance core when we offloaded routine I-O processing onto the slower system.
Based on our analysis, and the similarity of the two workloads, NASA-Houston participated in the development of the needed software. Floyd Goostree, a senior programmer from Aerospace, was assigned to work in Houston for the duration of the project.
The system we ended up with had the following attributes:
The scheduler was an important innovation. Early operating systems scheduled mechanically, by taking the next job in line, executing it, and reporting usage to the customer and center management. In contrast, the scheduler in the Direct Couple at Aerospace extracted information from the control cards (JCL) as the job was entered and built a list of work to do. First, if the job had an ultra high priority and the customer was waiting, it placed the job on top of the queue, did not start any more compute or print jobs, and ran that job next. Fortunately that did not happen often because it disrupted the rhythm of the shop and introduced great inefficiencies. However, if numbers were needed to support an immediate space launch, the system would honor such requests.
The scheduler’s work list contained the following information from the job cards: customer name, organization, priority, job state (checkout or production), estimated run time, estimated print volume, number and names of any tape files required. When a job terminated on the mainframe the next ready job was dispatched in priority order. In parallel, tapes were requested on a library console printer and assigned to drives. When the tapes were hung, the job was added to the ready queue. Thus, short, no-tape jobs of lower priority, could be run to maintain machine room efficiency while tapes were being extracted from the library. (If a long no-tape job was at the top of the list, it waited for the higher priority job, tape ready or not.)
There was a tape assignment table in the jr. processor so tapes could be hung wherever drives were available, not necessarily on the physical drives the program expected. This was an early version of “You hang it, I’ll find it”.
Output for printing was queued on disk. When a printer was available, the top priority print job was assigned. Short unclassified printout could be printed remotely, on request from a console next to the remote printer. Long print jobs and classified jobs were always printed at the center.
When the day shift went home, the operator at the master computer console informed the system and the system scheduled differently during nights, holidays, and weekends. During the off-shift, the system essentially ignored external priorities and scheduled for maximum efficiency. The goal was to have all queues go empty at the same time, so the system could be shut down or be turned over to IBM for maintenance or used by systems programmers for further development. Thus long print jobs were run first, and short jobs with little print were run last.
After our new system was complete, we measured what we had achieved (3). Then we looked for other inefficiencies we needed to attack. One was at the line printers themselves. There were three 1100 line/minute printers attached. Sometimes the operators let the output stacks build up with completed jobs and then burst that batch of output offline. This occurred even though there was an end-of job sheet with 3” letters that identified the place to break the web of paper between customers. We sought ways to eliminate this ad hoc batching and make the task of minding a printer less arduous.
When the Direct Couple system was installed for production, a room rearrangement was necessary. Since we ran classified work, no visitors were allowed in the machine room. To accommodate official visitors and the merely curious, sealed windows were installed in a hall adjacent to the center. The tape drives were placed close to the tape vault door and a remote printer told the tape crew what tapes to pull and where to hang them.
The two CPUs were adjacent and cabled channel to channel. The two master operator’s control panels (one for each CPU) were placed adjacent so one operator could control the shop. A console printer logged everything he did.
The three high-speed chain printers were located near the supply of boxed paper so the source was near the point of need. The study of printer operations showed that printed jobs tended to pile up when the operators got physically tired. So the print team and the tape team exchanged places every two hours. Each printer was fitted with a slide so finished jobs could be placed on the slide without the operator walking a step.
Each slide led to a rubber conveyor belt (similar to a supermarket checkout belt, only longer). This belt ran behind all three printers and deposited the output at a workstation, where the classified jobs were held for pickup by the submitter or his cleared representative, and the unclassified output was placed in pigeon holes for pickup by friends or the submitter himself.
Later the 7090 was replaced by a 7094 (faster and completely compatible) and the 7040 was replaced by a 7044 (ditto). The computers at Aerospace ran this way until replaced by System/360 Model 65s, several years later.
The Direct Couple software package traveled around the aerospace industry and was frequently modified to match its performance to the workload of each individual company. One 7044-7094 was so efficient that when it was replaced by a System/360 Model 40-65 combination, the new 360 configuration could not run 24 hours of work in a day. (After OS/360 was tuned to the workload, the 7000 system could be retired.)
IBM made the direct couple software into a product and offered it to 7090 customers (4). Later, on the 360s, the same package was called ASP (Attached Support Processor).
*******************************
Every manager of a big center considers the following whenever his workload changes:
At Aerospace we had enough acreage to accommodate a pair of machines; we had a large growing workload; we had a broad spectrum of legitimate customer priorities; and we had moderate budget constraints. We chose to use the senior machine for massive calculations and move the I-O services to a smaller machine (both machines could handle the I-O load, but the smaller computer was cheaper when it was waiting); in addition more sophisticated software allowed priority service without unduly impacting the rest of our customers; and best of all we had a talented software team who could do the job in-house.