Compatible Time-Sharing System

The Compatible Time-Sharing System (CTSS), was one of the first time-sharing operating systems; it was developed at Massachusetts Institute of Technology's Computation Center. CTSS was first demonstrated in 1961, and was operated at MIT until 1973. During part of this time, MIT's influential Project MAC also ran CTSS, but the system did not spread beyond these two sites.

CTSS was described in a paper presented at the 1962 Spring Joint Computer Conference, and greatly influenced the design of other early time-sharing systems.

Overview

The "Compatible" in the name refers to backwards compatibility with the standard batch processing OS for the IBM 7094, the FORTRAN Monitor System (FMS). CTSS ran an unaltered copy of FMS, processing a standard batch stream, in a pseudo-virtual 7094 provided by its background facility. (The hardware was partly but not fully virtualized; see History of CP/CMS for further details.) Background FMS jobs could access tapes normally, but could not interfere with foreground time-sharing processes or the resources used to support them.

CTSS was very influential. It showed that time-sharing was viable; it fostered important new applications for computers; it had a significant influence on the next generation of time-sharing systems, notably CP/CMS. CTSS and its direct successor, Multics, pioneered many core concepts of current operating systems.

Experimental Time-Sharing System

John Backus said in the 1954 summer session at MIT that "By time-sharing, a big computer could be used as several small ones; there would need to be a reading station for each user".^[1] But computers at that time, like IBM 704, were not powerful enough to implement such system. In June 1959, Christopher Strachey published a paper "Time Sharing in Large Fast Computers" at the UNESCO Information Processing Conference in Paris, where he envisaged a programmer debugging a program at a console (like a teletype) connected to the computer, while another program was running in the computer at the same time.^[2][3] Debugging programs was an important problem at that time, because with batch processing, it then often took a day from submitting a changed code, to getting the results. John McCarthy wrote a memo about that at MIT, after which a preliminary study committee and a working committee were established at MIT, to develop time-sharing. The committees envisaged many users using the computer at the same time, decided the details of implementing such system at MIT, and started the development of the system.

In November 1961, Fernando J. Corbató demonstrated at MIT what was called the "Experimental Time-Sharing System". On May 3, 1962, F. J. Corbató, M. M. Daggett and R. C. Daley published a paper about that system at the Spring Joint Computer Conference.^[4] Robert C. Daley, Peter R. Bos and at least 6 other programmers implemented the operating system, partly based on the Fortran Monitor System. The system used an IBM 709, modified by H. M. Teager, with added 3 Flexowriters for user consoles, and maybe a timer. Each of the 3 users had two tape units, one for the user's file directory, and one for dumping the core (program in memory). There was also one tape unit for the system commands, there were no disk drives. The memory was 27 k words (36 bit words) for users, and 5 k words for the supervisor (operating system). The input from the consoles was written to the buffers in the supervisor, by interrupts, and when a return character was received, the control was given to the supervisor, that dumped the running code to the tape and decided what to run next. The console commands implemented at the time were login, logout, input, edit, fap, mad, madtrn, load, use, start, skippm, listf, printf, xdump and xundump. This became the initial version of the Compatible Time-Sharing System. This was evidently the first ever demonstration of time-sharing, there are other claims but about special purpose systems or with no known papers published.

Features

• CTSS had one of the first computerized text formatting utilities, called RUNOFF (the successor of DITTO).
• CTSS had one of the first inter-user messaging implementations, possibly inventing email.^[5]
• MIT Computation Center staff member Louis Pouzin created for CTSS a command called RUNCOM, which executed a list of commands contained in a file. (He later created a design for the Multics shell, which in turn inspired Unix shell scripts.) RUNCOM also allowed parameter substitution.
• CTSS had the text editor QED, the predecessor of ed and vim, with regular expressions added by Ken Thompson.

Implementation

Kernel

CTSS used a modified IBM 7094 mainframe computer that had two 32,768 (32K) 36-bit-word banks of core memory instead of the normal one.^[6] One bank was reserved for the time-sharing supervisory program, the other for user programs. CTSS had a protected mode kernel, the supervisor's functions in the A-core (memory bank A) could only be called by software interrupts, like in the modern operating systems. Causing memory protection interrupts were used for software interrupts.^[2] Processor allocation scheduling with a quantum time unit 200 ms, was controlled by a multilevel feedback queue.^[6] It also had some special memory management hardware, a clock interrupt and the ability to trap certain instructions.

Supervisor subroutines

• RDFLXA—Read an input line from console
• WRFLX—Write an output line to console
• DEAD—Put the user into dead status, with no program in memory
• DORMNT—Put the user into dormant status, with program in memory
• GETMEM—Get the size of the memory allocation
• SETMEM—Set the size of the memory allocation
• TSSFIL—Get access to the CTSS system files on the disk
• USRFIL—Change back to user's own directory
• GETBRK—Get the instruction location counter at quit

Programming languages

CTSS at first had only an assembler FAP, and a compiler MAD, also Fortran II code could be translated into a MAD code. Later half of the system was written in MAD. Later there were other programming languages like LISP and a version of ALGOL.

File system

Every user had one's own directory, and there were also directories for groups of people, who had the same "problem number". Each file had two names, the second name was similar to extension today. At first each file could have one of four modes, temporary, permanent, read only class 1, and read only class 2. Read only class 2 differed in that the user couldn't change the mode of these files. Files could also be linked from other directories than the user's directory. A directory listing by listf:

	10 FILES	20 TRACKS USED
DATE		NAME		MODE	NO. TRACKS
5/20/63		MAIN	MAD	P	15
5/17/63 	DPFA	SYMTB	P	1
5/17/63 	DPFA	BSS	P	1
5/17/63 	DPFA	FAP	P	2

Disk control subroutines

• .DUMP—Dump a continuous block onto file
• .LOAD—Load a continuous block from file
• .ASIGN—Prepares file for writing
• .APEND—Prepares file for appending
• .SEEK—Prepares file for reading
• .RELRW—Prepares file for reading and writing
• .WRITE—Write data to a relative location in file
• .READK—Read data from a relative location in file
• .FILE—Terminate writing of file
• .ENDRD—Terminate reading of file
• .DLETE—Delete a file
• .RENAM—Rename a file and change its mode
• .FILDR—Obtain a copy of the user file directory
• .FSTAT—Get information about a file

Console commands

• login—Log into system
• logout—Log out of system
• listf—List files in the directory
• input—Input source code, fixed size lines
• edit—Edit source code in a BASIC style with line numbers
• printf—Print file starting from a line number
• fap—FAP assembler
• mad—MAD compiler
• madtrn—Fortran II to MAD translator
• load—Load binaries (linking in memory)
• use—Load missing binaries
• start—Run program loaded into memory
• save—Save program in the memory to file
• resume—Load saved program and resume running it
• pm—Get post-mortem information of the program in memory
• patch—Edit memory
• tra—Create transfer to a relative location in a program
• stopat—Create transfer to stop the program at a location
• rename—Rename file
• chmode—Change the mode of the file
• delete—Delete file, had * wildcards
• split—Split file
• combin—Join files, also binary files, making libraries
• cpu—Get the current machine conditions
• octlk—Print memory
• memo—Input text files, variable size lines
• modify—Edit text files, similar to edit
• ditto—Print text files with formatting (footnotes, pages)

Peripherals

Input-output hardware was mostly standard IBM peripherals. These included six data channels connecting to:

• Printers, punched card readers and punches
• IBM 729 tape drives, an IBM 1301 disk storage, later upgraded to an IBM 1302, with 38 million word capacity
• An IBM 7320 drum memory with 186K words that could load a 32K-word memory bank in one second (later upgraded to 0.25 seconds)
• Two custom high speed vector graphics displays
• An IBM 7750 transmission control unit capable of supporting up to 112 teleprinter terminals, including IBM 1050 Selectrics and Teletype Model 35s. Some of the terminals were located remotely and the system could be accessed using the public Telex and TWX networks.

Influences

Multics, which was also developed by Project MAC, was started in the 1960s as a successor to CTSS – and in turn inspired the development of Unix in 1969. One of technical terms inherited by these systems from CTSS is daemon.

ITS, the Incompatible Timesharing System, another early, revolutionary, and influential MIT time-sharing system, was produced by people who disagreed with the direction taken by CTSS and later, Multics; the name was a parody of CTSS, as later the name of Unix was a parody of Multics.^[7]

See also

• Fernando J. Corbató, project leader
• Timeline of operating systems

References

External links

• Compatible Time-Sharing System (1961-1973): Fiftieth Anniversary Commemorative Overview
• Oral history interview with John McCarthy, Charles Babbage Institute, University of Minnesota. Discusses computer developments at MIT including time sharing.
• The IBM 7094 and CTSS: personal memoir of Tom Van Vleck, a system programmer on CTSS
• The Origin of the Shell describes the evolution of RUNCOM into the modern shell
• CTSS Source in Paul Pierce's collection.
• CIO: 40 years of Multics, 1969-2009: Interview with CTSS and Multics developer Fernando J. Corbato.
• Oral history interview with Fernando J. Corbató, Charles Babbage Institute, University of Minnesota. Discusses many computer developments at MIT including CTSS.
• Oral history interview with Robert M. Fano, Charles Babbage Institute, University of Minnesota. Discusses computer developments at MIT including CTSS.
• Dave Pitts' IBM 7094 support – Includes a simulator, cross assembler and linker that can be used to build and run CTSS. Site also contains CTSS source. The CTSS fully works on the simulator.