The IBM 7094 and CTSS

Tom Van Vleck

In the mid-1960s, IBM's 7094 was one of the biggest, fastest computers available, able to add floating numbers at a speed of about 0.35 MIPS.  A standard 7094 had 32K 36-bit words of memory. Its data channels could access memory and run simple channel programs to do I/O once started by the CPU, and the channels could cause a CPU interrupt when the I/O finished. They cost about $3.5 million.  Paul Pierce's collection includes a real 709 and 7094.

MIT got an IBM 7090, replacing the 709, in the spring of 1962, when I was a freshman, and had upgraded the 7090 to a 7094 by 1963. The 7090 and 7094 were operated in batch mode, controlled by the Fortran Monitor System (FMS). Batch jobs on cards were transferred to tape on an auxiliary 1401, and the monitor took one job at a time off the input tape, ran it, and captured the output on another tape for printing and punching by the 1401. Each user job was loaded into core by the BSS loader along with a small monitor routine that terminated jobs that ran over their time estimates. Library routines for arithmetic and I/O were also loaded and linked with the user's program. Thus, each user's job had complete control of the whole 7094, all 32K words of memory, all the data channels, everything.

IBM had been very generous to MIT in the fifties and sixties, donating its biggest scientific computers. When a new top of the line 36-bit scientific machine came out, MIT expected to get one. In the early sixties, the deal was that MIT got one 8-hour shift, all the other New England colleges and universities got a shift, and the third shift was available to IBM for its own use. One use IBM made of it was yacht handicapping: the president of IBM raced big yachts on Long Island Sound, and these boats were assigned handicap points by a complicated formula. There was a special job deck kept at the MIT Computation Center, and if a request came in to run it, operators were to stop whatever was running on the machine and do the yacht handicapping job immediately.

Early Time-Sharing

MIT professors, such as Herb Teager and Marvin Minsky, wanted more access to the machine, like they had had on Whirlwind in the fifties, and quicker return of their results from their FMS jobs. John McCarthy wrote an influential memo titled "A Time Sharing Operator Program for Our Projected IBM 709" dated January 1, 1959, that proposed interactive time-shared debugging. These desires led to time-sharing experiments, such as Teager's "time-stealing system" and "sequence break mode," which allowed an important professor's job to interrupt a running job, roll its core image out to tape, make a quick run, and restore the interrupted job. McCarthy's  Reminiscences on the History of Time Sharing describes his and Teager's role in the beginnings of time-sharing. Teager and McCarthy presented a paper titled "Time-Shared Program Testing" at the ACM meeting in August 1959.

FMS and Batch Processing

MIT and the University of Michigan were both 7094 owners, and the computation center people were colleagues who traded code back and forth. When I was a freshman in 1961, we used FORTRAN in the elementary course (FORTRAN II was brand new then), but by the time I was a sophomore, MIT had installed Michigan's MAD language, written by Graham, Arden, and Galler, and was using that in most places that a compiler language was needed, especially computer courses. MAD was descended from ALGOL 58: it had block structure and a fast compiler, and if your compilation failed, the compiler used to print out a line printer portrait of Alfred E. Neumann. (MIT took that out to save paper.) Mike Alexander says, "MAD was first developed about 1959 or 1960 on a 704, a machine which makes the 7094 look very powerful indeed." MAD ran under UMES, the University of Michigan Executive System, derived from a 1959 GM Research Center executive for the IBM 701 that was one of the first operating systems.

Part of the Michigan/MAD code was a replacement for the standard FORTRAN output formatter routine, (IOH). (Programs written in FAP (FORTRAN Assembly Program, the 7094 assembler) could use special characters, such as parentheses, in external names. I/O library routines were often given names that FORTRAN and MAD programs could not generate, to avoid name conflicts.) The MIT/Michigan version of (IOH) supported additional format codes used by the MAD language, and had other internal improvements over the IBM version. One change was to use the extra index registers that the 7094 had and the 7090 didn't. And buried deep in the code, there was the line of code

       SXA  VR16,1   'SOMEBODY HAS TO SAVE IT' SAYS BOB CRABTREE

Noel Morris and I created the Bob Crabtree Society, open to people who knew where that comment was and what it did.

I took Corby's MIT course 6.251, Introduction to System Programming, as soon as I could. When I took the course, there were a few exercises in MAD, and then we were presented with CAP (Classroom Assembly Program), a simple assembler for the 7094, and assigned a series of problems to improve it. The assembler itself was written in FAP, and we submitted batch jobs in the form of update runs that applied alters to the CAP source, reassembled and linked it, and ran a standard test suite. You got so many points for adding the * meaning "the current instruction counter," so many more for putting in a simple expression evaluator, and so on. The  textbook was by Corbató, Poduska, and Saltzer.

CTSS

After taking 6.251, I looked for a part-time programming job, and got one in 1963 at Project MAC, using the Compatible Time-Sharing System (CTSS). This was just after the famous 1963 Project MAC Summer Study, where many of the big names in computers spent time at Project MAC using the brand new idea of a time-shared computer.CTSS was written by a team of MIT Computation Center programmers led by Prof. Fernando J. Corbató, known to everybody as Corby. Corby's title was Deputy Director of the Computation Center. The Director was Prof. Philip M. Morse, who didn't seem to be involved in the day-to-day operations of the Center; Corby ran the whole thing. When you submitted FMS jobs, you specified your problem number and programmer number. The lower your number, the longer you had been associated with the Comp Center. Corby's was 3. Much of the CTSS research was funded by US National Science Foundation grants to the Computation Center.

A version of CTSS that swapped four users to tape was demonstrated on MIT's IBM 709 in November of 1961. CTSS was described in a paper at the 1962 Spring Joint Computer Conference, even though the software wasn't quite working on the IBM 7090. By the time of the 1963 Summer Study, CTSS worked and was supported by hardware RPQs on the 7090, and computer researchers from all over the country used the Comp Center CTSS to try interactive computing. Project MAC got its own 7094 in October 1963 (paid for by ARPA) in the new Tech Square building behind MIT. The Computation Center machine continued to run FMS; it had the standard blue side panels. The Project MAC machine had red side panels, and staff often referred to "the red machine" or "the blue machine."

CTSS was "compatible" in the sense that FMS could be run in B-core as a "background" user, nearly as efficiently as on a bare machine. Background could access some tape units and had a full 32K core image. This feature allowed the Computation Center to make the transition from batch to timesharing gradually, and to retain the ability to run "dusty decks" and software from other institutions. The Comp Center got the CTSS RPQs added to the blue machine and began running CTSS in 1965. The configuration for both machines included about a dozen tape drives, a swapping drum, and a 1302 disk file with a capacity of about 36 megabytes, shared among all users of the machine.

In 1965, most of the CTSS development group had moved over to Project MAC and was beginning the design of Multics. The plan was to use CTSS to support Multics development, and the last big CTSS project was a new, much better, file system, as a kind of parting shot, to ensure that the system would be adequate to support Multics development.

Documentation

• The first paper on CTSS:  "An Experimental Time-Sharing System," by Fernando J. Corbató, Marjorie Merwin Daggett, and Robert C. Daley.
•  MAC-TR-12, "The MAC system: a progress report," by Prof. Fano describes the usage of CTSS with examples.
• The  first edition of the CTSS manual (the so-called "candy stripe" book published by MIT Press) describes the system and its commands as of about 1963. (104 pages, 3.7MB PDF)
•  MAC-TR-16, "CTSS TECHNICAL NOTES," by Jerry Saltzer describes the internals of CTSS as of 1965. (3.5MB PDF)
• The  second edition of the CTSS manual describes the system and its commands as of 1969. (587 pages, 25MB PDF) new

Listings for the source of CTSS as of about 1972 are online in  Paul Pierce's Collection. You can download a 5MB ZIP file that contains the compilation listings for the supervisor, salvager, daemon, and commands (including RUNOFF).

7094 console

CPU Modifications

The hardware RPQs that made CTSS run on MIT's 7094s added an interval timer (B/M 570220) and memory boundary and relocation registers (RPQ E007291) to the 7094 processor. In addition, the MIT machines had two 32K core memory banks instead of one (RPQ E02120). Core bank A held the CTSS supervisor, and B Core was used for user programs. (RPQ stood for Request Price Quotation. IBM, in those days, would engineer and sell features not part of the standard product, for a price.) More importantly, the RPQ made the 7094 a two-mode machine. When the machine was running a program in B-core, many instructions were forbidden: executing them caused the machine to trap and take its next instruction from A-core. In particular, I/O instructions were forbidden, as well as attempts to switch core banks.

By convention, user programs called on supervisor services, such as the file system, by executing a TSX ADDR,4 where ADDR held TIA =HWRFLXA. (Where WRFLXA was the name of the entrypoint called) The TIA instruction was illegal in B-core mode, so the CPU trapped into the A-core supervisor module named PMTI (Protection Mode Trap Interpreter), which looked up the BCD name of the supervisor entrypoint, found its location, and made the transfer.

Terminal Access

The original CTSS provided remote access to Flexowriters directly connected to a data channel. By 1963, CTSS provided remote terminal service to dial-up terminals connected by modem to a specialized telecommunications computer, the IBM 7750.

Memory Boundaries and Swapping

CTSS used the modified 7094's memory boundary register to limit user jobs' access to only part of B-core, so that the supervisor didn't have to swap 32K to drum for every job. An algorithm called the "onion skin" left parts of a big job's core image in memory if a little job ran next, and handled all the complicated space accounting and reassembly of images. If the drums filled up, swapping spilled to disk.

(I remember visiting SDC in 1967 or so and seeing the Q-32 timesharing system there, which lacked these features. If you issued a command the swap space was statically allocated, and there wasn't enough to go around, so you might have to keep trying.. "LOAD OK ON 9" mean you'd claimed enough drum to run. The Q-32 system was first demonstrated in 1963.)

Indirect Addressing

The 7094 didn't recognize the indirect flag in an indirect word, but it had the XEC opcode, which executed an instruction out of line, and if you did XEC * the CPU would sit there taking I-cycles, uninterruptible, until manual reset. People were warned not to do this, and of course if they did it while CTSS was running we took a dump, and identified & fussed at the user. (One such crash was caused in 1965 or so by Joel Moses, who was running a big symbolic integration program written in LISP. When we complained, he said it was an honest mistake, caused by using RPLACD. I have been reluctant to use RPLACA and RPLACD ever since.)

The one time XEC * was used in a good way was the day in 1966 that a Computation Center administrator's mistake caused the CTSS password file and the message of the day to be swapped. (The editor in those days created a temporary file with a fixed name.) This was before (and was the source of) the idea of one-way encrypting passwords, so everybody's password was displayed to each user that logged in. Bill Mathews of Project TIP noticed the passwords coming out, and quickly entered the debugger and crashed the machine by entering an XEC * instruction. Naturally this happened at 5 PM on a Friday, and I had to spend several unplanned hours changing people's passwords. (The problem is described and analyzed in Corby's  Turing Award Lecture.) (The GE 645 let you chain indirections, and had several varieties of execute opcodes; if your program hung the CPU for some small number of milliseconds, a timer generated a "lockup" fault.)

Notable Applications

There were a few other significant improvements about that same time, some contributed by the user community. Noel Morris and I created a replacement command processor, . SAVED, which supported user-defined abbreviations, multiple commands on a line, and inter-user instant messaging. Noel and I also wrote a command, suggested by Glenda Schroeder and Louis Pouzin, called MAIL, which allowed users to send text messages to each other; this was one of the earliest electronic mail facilities (I am told that the Q-32 system had it earlier).

Louis Pouzin also invented RUNCOM for CTSS. This facility, the direct ancestor of the Unix shell script, allowed users to create a file-system file of commands to be executed, with parameter substitution. Louis also produced a design for the Multics shell, ancestor of the Unix shell.

Jerry Saltzer wrote one of the very first computer word processing programs, RUNOFF, for CTSS in 1963 and 1964. This program is the ancestor of Unix roff, nroff, and many subsequent programs. Jerry has placed the original CTSS documentation for RUNOFF online as  Manuscript Typing and Editing (from Patricia Crisman, editor. The Compatible Time-Sharing System, A Programmers Guide. Second edition. M. I. T. Press, 1965, section AH.9.01, December 1966 revision) and  TYPSET and RUNOFF, memorandum editor and type-out commands, M.I.T. Computation Center Memorandum CC-244 and M.I.T. Project MAC Memorandum MAC-M-193. November 6, 1964.

The ESL Display, familarly known as The Kludge, was an interesting device attached to the 7094. It consisted of a PDP-5 computer with a vector display scope and a controller that interfaced directly with channel D. This device could be used for interactive graphics with light pen and mouse input. It is described in  Dan Thornhill's thesis.

Corby's Hardware Transient and the Blackout

During the fall of 1965, the Computation Center was trying to bring up CTSS on the blue machine, and requesting help from the former CTSS developers at Project MAC when they ran into problems they couldn't handle. The blue machine kept crashing in the disk backup software, in a way we'd never seen, and the dumps didn't make sense. Hardware diagnostics showed no problem; the IBM CEs insisted the machine was fine. Bob Daley and Stan Dunten, in particular, were called on repeatedly to try to figure out what was going on. Corby involved himself too, and hypothesized a "hardware transient" that zapped some registers. Finally Mike Padlipsky and Charlie Garman took the blue machine in the middle of the day, and loaded a one-card program with a simple test loop, and left it running. After about ten minutes of execution, the failure count in an index register suddenly began counting up: they had caught the bug! (The bug was something like: the TXL/TXH opcodes sometimes reversed roles, in only one of the two core banks, if a big enough truck went by on Vassar Street.) The programmers heaved a sigh of relief, turned the machine over to the IBM CEs, and headed over to Tech Square House to celebrate. Quite a few people came down to the bar for a drink, when suddenly the lights went out. I remember I ran up nine flights of stairs to help crank the tape out of the tape drives by hand, because the tapes could be damaged if they were in the drive when power came back on. I needn't have run: it was November 9, 1965, and the lights were out over the entire East Coast, and stayed out until the next morning.

Other Timesharing Systems

I have written elsewhere about how Project MAC chose the GE 645 as the platform for its next generation system, instead of IBM's proposal of a System/360 machine. The Computation Center, however, did choose a 360 for its next generation batch environment, and installed and ran a large 65/40 shop running OS/360 and ASP during the time that Multics was being developed at Project MAC. And the MIT Urban Systems Laboratory obtained funding that supported the installation of an IBM 360/67, running CP/CMS.

Old Age

In late 1968, the Comp Center returned the blue machine to IBM. The red 7094 was moved from Tech Square to the new computation center in building 39, and Multics developers shared CTSS resources with general MIT time-sharing users until Multics was self-supporting in early 1969.

CTSS continued in use for several more years, with gradually declining usage, as MIT computer users switched to OS/360 batch, CP/CMS timesharing on the 360/67, or Multics. One project, called the Overlap Project, was funded to support 7094 usage until equivalents for some CTSS social-science tools were found on other machines. There was one kind of funny problem with this long decline of CTSS: every year, there was a fire drill as we tried to remember what you had to do to create a system for the next year. The Chronolog clock attached to tape channel E of the machine provided a date and time in BCD, but without the year; that came from a constant in the supervisor, and each year we had to recompile one small module, and relink the supervisor, the salvager, and a few other standalone utilities. As the original CTSS crew gradually moved on to other jobs, fewer and fewer people knew how to carry out this task, but we always managed to figure out how. And each year, we considered making the constant a configuration item somehow and decided not to bother, because the system wouldn't last another year.

The 7094 was a fine machine, but by the time it was over ten years old, it had become expensive to maintain, hard to find expert programmers for, and had been deserted by most users in favor of faster and more modern machines. A group of students proposed that they'd take over the machine and run it for student computing; the floor space, air conditioning, and maintenance costs made this impractical, but some of these students went on to found MIT's Student Information Processing Board, which supported student computing at MIT in many ways, and still exists today.

There was a ceremony held the following year, 1974, to honor those who worked on the system and those who supported it. A list of people involved was compiled.

Also see the nice June, 1999  Computerworld story by Mary Brandel.

Updated 06/22/95. Thanks to Mike Padlipsky, Frank Belvin, Olin Sibert, and Joe Morris for corrections, and to Mike Alexander for info about MAD and UMES.

More updates 12/18/97.

Updated 03/30/03 with information about RUNOFF and TYPSET, thanks to Jerry Saltzer.

Updated 09/10/04 with pointer to the source.

Copyright (c) 1995-2008 by Tom Van Vleck