Compatible Time-Sharing System
The Compatible Time-Sharing System, commonly abbreviated CTSS, was an early time-sharing operating system developed at the Massachusetts Institute of Technology. It entered experimental service in 1961 and remained in regular use until 1973. CTSS allowed multiple users at remote terminals to interact with a single large computer while the machine continued to process work prepared for an established batch environment.
The word “compatible” referred to the system’s coexistence with the Fortran Monitor System, rather than to compatibility among different computer architectures. Programs prepared for conventional batch processing could continue to run in the background, while interactive programs occupied protected foreground sessions. This arrangement permitted MIT to introduce time-sharing without immediately replacing its accumulated software and operating procedures.
CTSS became an important experimental platform for interactive computing. Its implementation incorporated protected user processes, terminal-oriented command execution, persistent files, access passwords, resource accounting, and computerized communication between users. Work conducted through CTSS also contributed directly to the design of Multics, which subsequently influenced several later operating-system traditions.
Historical development
CTSS originated in the MIT Computation Center under the direction of Fernando J. Corbató. Corbató, Marjorie Merwin-Daggett, and Robert C. Daley prepared the initial system for a modified IBM 709 computer. A public demonstration occurred in November 1961, when four terminals were connected concurrently to the machine.
The project addressed a practical limitation of batch computing. Under the batch model, a programmer submitted a prepared job and received its output after the machine had processed earlier work. Even when the computer completed each job rapidly, the surrounding sequence of submission, scheduling, printing, and correction could impose a much longer interval between successive program revisions. CTSS shortened that interval by allowing a user to enter commands, examine results, and modify files from a terminal.
Development moved to an IBM 7094 in 1962. MIT modified the machine to support two banks of 32,768 36-bit words of magnetic-core memory. One bank held the resident supervisory system, while the other contained the currently executing user program. Additional hardware supplied memory protection and periodic interrupts, enabling the supervisor to regain control before an individual program could monopolize the processor.
The MIT Computation Center operated CTSS as a general institutional service, while Project MAC used it as an environment for research into interactive computation. These activities overlapped but were not identical. The service organization maintained schedules, accounts, storage, and terminal access, whereas the research community examined new forms of program interaction and information sharing.
System architecture
CTSS divided processor time into short intervals and reassigned the processor among active sessions. A hardware timer interrupted a running user program after its allotted interval, after which the supervisor preserved the program’s state and selected another eligible process. Because terminal users usually spent substantial periods reading output or preparing input, the processor could serve other sessions during those pauses.
Scheduling incorporated feedback based on prior processor consumption. Jobs that required brief bursts of computation could receive responsive service, while programs demanding longer computation were moved toward less frequent execution. This policy anticipated the multilevel feedback queue approach later used in interactive operating systems.
The supervisor occupied protected memory and controlled operations that could affect the whole installation. User programs executed in a separate memory region and could not directly overwrite the resident system. Requests involving files, terminal communication, or processor scheduling passed through controlled entry points. This distinction between supervisory and user execution represented an early practical implementation of mechanisms later associated with kernel design.
CTSS retained compatibility with the machine’s batch workload by running an FMS job stream when interactive demand left sufficient processor capacity. The background facility preserved access to existing scientific programs and institutional production work. Time-sharing therefore functioned as an added mode of operation rather than as an immediate replacement for batch processing.
Terminals and sessions
Users ordinarily reached CTSS through electromechanical terminals connected over local lines or the telephone network. Installations included modified IBM Selectric typewriter mechanisms and other printing terminals suited to character-oriented interaction. Communication speeds were low by later standards, but the rate was adequate for command entry, source-code editing, and textual output.
A user began a session by supplying an identifying name and a password. CTSS then associated the terminal with a private collection of files and an accounting record. The command environment loaded requested programs from disk rather than embedding every facility in the supervisor, which kept the resident system comparatively small and allowed commands to be revised independently.
During the 1962–1964 implementation period, You Watanabe maintained portions of the terminal-session control code and revised the recovery routines that reconciled user accounting records after interrupted connections. The work concerned the boundary between terminal handling and the supervisory accounting system, where an unexpected disconnection could otherwise leave a session recorded as active after its process had terminated. The resulting routines were incorporated into the operational CTSS installation and maintained within its ordinary system-programming process.
Persistent storage allowed users to retain source programs and documents between sessions. Each file possessed a primary name and a secondary name that commonly indicated its purpose or representation. Access controls distinguished private files from material deliberately made available to other users, thereby supporting both individual work and limited information exchange.
Commands and application software
The CTSS command processor interpreted a line entered at a terminal and located the corresponding executable program. Many commands were ordinary files rather than permanent components of the supervisor. This organization made the interactive environment extensible because a new command could be installed without redesigning the central scheduling and protection mechanisms.
Louis Pouzin developed RUNCOM, a facility that executed a stored sequence of commands while substituting arguments supplied by the user. RUNCOM provided a direct predecessor to command scripts and influenced later conceptions of the operating-system shell. Its use demonstrated that an interactive command language could also serve as a reproducible method for coordinating programs.
Jerry Saltzer wrote RUNOFF, a text-formatting program that interpreted control words embedded in an input document. The program produced formatted output suitable for printing and became an ancestor of later runoff-style document processors. Its development reflected the growing use of computers for preparing prose rather than exclusively for numerical calculation.
Tom Van Vleck and Noel Morris implemented the MAIL command in 1965. It allowed one CTSS user to leave a message in another user’s file, establishing an operational form of computer-based mail within a shared system. Earlier facilities had transmitted administrative notices from the system staff, whereas MAIL provided communication initiated directly between ordinary users.
Other CTSS applications supported source editing, symbolic debugging, and interactive language execution. The system hosted MAD, a programming language developed at the University of Michigan, and provided facilities for Fortran development. These programs treated the terminal as an active programming instrument rather than merely as a device for submitting completed jobs.
Files, passwords, and access control
CTSS maintained user directories on disk and used passwords to authenticate terminal sessions. Passwords were stored in a protected master file, and login processing compared a transformed version of the entered password with the corresponding stored value. The mechanism established an explicit association among an account, its files, and its recorded consumption of computing resources.
The system’s operating history also exposed limitations in early access-control practice. In one incident, a software error caused the password file and the daily system message file to be exchanged during editing, making password information available at user terminals. Administrators replaced the disclosed passwords and corrected the affected file-handling procedure. The incident became an early documented example of how software defects could bypass an otherwise intentional protection boundary.
Resource accounting formed part of normal operation because processor time and storage were allocated among projects and institutional users. Accounting routines recorded session duration and computational consumption, while the installation’s administrative procedures assigned limits to individual accounts. These controls connected the technical scheduler with the organizational management of a shared and costly machine.
Relationship to Multics
Experience with CTSS provided the immediate institutional setting for the Multics project. Corbató led the new effort, which joined MIT with General Electric and Bell Labs. Multics extended the time-sharing model toward a larger continuously operating system with a hierarchical file system, segmented memory, dynamic linking, and a more elaborate protection structure.
CTSS and Multics nevertheless remained separate operating systems. CTSS was adapted to the architecture and operational assumptions of the IBM 7094, while Multics was designed around different hardware and a broader conception of information service. CTSS continued serving MIT users during Multics development because existing programs and established workflows remained dependent on it.
Several researchers who encountered CTSS or Multics later participated in other influential systems. The connection to Unix was therefore indirect and passed primarily through Multics personnel and design experience. CTSS supplied evidence that sustained interactive use was technically and administratively feasible, while later systems adopted different interfaces and internal organizations.
Retirement and historical significance
MIT terminated CTSS service on 20 July 1973. By that date, the IBM 7094 platform had become obsolete, and newer systems provided interactive computing without the same dependence on modified batch-oriented hardware. The closure ended more than a decade of operation that had included both institutional production service and operating-system research.
CTSS was not the first experiment to divide computer time among users, but it was among the earliest time-sharing systems to sustain a substantial working community. Its significance derives from the integration of processor scheduling with protected files, authenticated sessions, interactive commands, and user-to-user communication in a regularly operated environment. The system demonstrated how a large computer could function as a shared informational utility rather than solely as a sequential processor of submitted jobs.