I arrived at Livermore (the lab) from Berkeley in the middle of 1955. The lab was negotiating with Remington Rand Univac for the LARC at the time but I was not in on that. IBM had also bid on the job but the lab was proceeding with RemRand. IBM did a deal with Los Alamos for a similar machine about two years later than the LARC contract. IBM called their machine “Stretch” or more formally the “IBM 7030”. By about 1958 the lab ordered a Stretch as well; the LARC was late for delivery. The LARC was indeed delivered about two years late. The Stretch was also late but only by a few months. The two machines ran largely different applications. Both machines ran large applications coded in assembly language most of the time.

The Stretch comprised about 10 boxes each as big as a large refrigerator. These boxes abutted each other at their broad sides. If the row of boxes went East and West, then the works rolled out to the South for access, whereas the wiring connecting the units ran along the North side of the row. On the broad side of the last box was the engineer’s console which had about 3000 incandescent indicator lamps. They ran at low voltage and glowed a gorgeous orange with the room light turned out.

This was still the era when maintenance engineers came with the machine. With earlier machines engineers were on site 24 hours a day, but the transistor machines were enough more reliable that they could all sleep at home most nights. I recall that they would do preventative maintenance for a few hours about every two weeks. The core memories had ECC (error checking and correcting code). On a word fetch a single bit error was corrected and double bit errors were detected. Engineers could sample corrected errors and so tune the box during maintenance. It was clear that this saved much downtime. The 7090s, each with just one such memory box and without ECC, experienced more down time for memory problems than the Stretch which had six boxes. Aside from memory problems the machine failures were almost always in a part of the machine with which the engineer had no previous experience. They had to learn a new part of the machine with impatient programmers hovering about. The machine had about 250,000 discrete transistors.

Most of the machine was highly error checked. The index registers and general registers were parity checked. Much of the logic was checked. The fixed point variable field length arithmetic and boolean operations were serial by 8 bit byte and those operations were either checked by duplication or other means. The floating point arithmetic was checked using modulo three. In a floating add, for instance, the part of the fraction that was shifted out so as not to contribute to the sum was itself reduced modulo three so as to confirm the result. Exponent arithmetic was checked as well. I don’t know what fraction of the logic gates were protected against error. I think it was less than 100%. Detected logic errors caused the machine to stop. Here is how the Stretch multiplied and how it divided.

One of the boxes was the basic exchange which would maintain several concurrent streams of 8 bit bytes between core and various IO devices. This prefigured the channels of IBM’s subsequent 360 line. Attached to the basic exchange were a card reader, card punch, line printer, operator’s console and about eight mag tape units.

The high speed exchange was another big box that did the same for the large disk with about 16MB of storage. The transfer rate was about one word (8 bytes) per 4 microseconds.

Perhaps the machine feature most significant to those with problems to solve was the large memory. Previously the largest memory had about 106 bits. The Stretch had six times as much. On previous machines the working data for production jobs would not fit in core but required mag tape which would be read and written by explicit application logic, overlapped with the computation proper. Such applications were complex and difficult to debug. Since application data would all fit in the core memory of the Stretch, applications came into production months sooner than they had upon the introduction of previous machines.

This was still before timesharing and debugging consisted of reserving time slots on the machine and bringing card decks to the machine when it was your turn. The card reader would read the deck and the machine would assemble or compile your code. Some kept their sources on mag tape and bought tape and card decks that described updates to their programs. A new program listing would normally be produced on the attached line printer which was a 600 lines per minute chain printer. A rudimentary operating system would normally remain in place between jobs. Later we came to the point that the OS would request mag tapes enough in advance of a job that they might well be fetched and mounted by the time that they were required. A few jobs used tapes for working storage. The disks were not used heavily. Occasionally data would be left on disk from day to day. Space was informally allocated by coordination among the programmers whose jobs used the disk.

Livermore developed a Fortran compiler for the Stretch. Fortran was used for many smaller production jobs but the few bigger jobs remained in assembler.

IBM built about 10 Stretches; one was a component of the Harvest that went to NSA. The Stretch missed its original performance targets and was upstaged by the IBM 7090 which had aggressively adapted the Stretch transistor technology and 2 microsecond core memories. The more modest goals of the 7090 brought it to market before the Stretch itself. It met an immediate need to run deployed 709 code with which it was highly compatible. (The 709 was a tube machine and about seven times slower.) T.J.Watson severely criticized the Stretch effort for having missed the goals and terminated sales of the machine. Several years later he acknowledged that the machine had indeed been strategic for the circuit and core technology that it had developed for IBM. This had enabled the 7090—a highly profitable machine.


Planning a Computer System : Project Stretch
More on the design, and perhaps more.
Contrasting IO systems of LARC and Stretch. A good deal of Stretch history.
The LARC note includes some Stretch information.
An interview with Stephen Dunwell