Hubbry Logo
search
logo
Compatible Time-Sharing System avatar
Compatible Time-Sharing System
Compatible Time-Sharing System
current hub
2238411

Compatible Time-Sharing System

logo
Community Hub0 Subscribers
Read side by side
Compatible Time-Sharing System
View on Wikipedia
from Wikipedia
Compatible Time-Sharing System (CTSS)
Preamble of two versions of the CTSS scheduler, one in MAD and one in FAP
DeveloperMIT Computation Center, Project MAC
Written inFAP assembly, MAD
Working stateDiscontinued, simulator available
Source modelOpen source
Initial release1961; 65 years ago (1961)
Marketing targetColleges and universities[1]
Available inEnglish
Supported platformsIBM 7090, IBM 7094
Kernel typeMonolithic, protected
Default
user interface		Command-line interface
License[data missing]
Succeeded byMultics
Official websitewww.cozx.com/dpitts/ibm7090.html

The Compatible Time-Sharing System (CTSS) was the first general purpose time-sharing operating system.[2][3] Compatible Time Sharing is time sharing which is compatible with batch processing, in that they operate concurrently.

CTSS was developed at the MIT Computation Center ("Comp Center"). CTSS was first demonstrated on MIT's modified IBM 709 in November 1961. The hardware was replaced with a modified IBM 7090 in 1962 and later a modified IBM 7094 called the "blue machine" to distinguish it from the Project MAC CTSS IBM 7094. Routine service to MIT Comp Center users began in the summer of 1963 and was operated there until 1968.

A second deployment of CTSS on a separate IBM 7094 that was received in October 1963 (the "red machine") was used early on in Project MAC until 1969 when the red machine was moved to the Information Processing Center[4] and operated until July 20, 1973. CTSS ran on only those two machines; however, there were remote CTSS users outside of MIT including ones in California, South America, the University of Edinburgh and the University of Oxford.[1][5]

History

[edit]

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".[6] Computers at that time, like IBM 704, were not powerful enough to implement such system, but at the end of 1958, MIT's Computation Center nevertheless added a typewriter input to its 704 with the intent that a programmer or operator could "obtain additional answers from the machine on a time-sharing basis with other programs using the machine simultaneously".[7]

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.[8][9] 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[clarification needed] at MIT, after which a preliminary study committee and then 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.

Experimental Time Sharing System

[edit]

By July 1961[10] a few time sharing commands had become operational on the Computation Center's IBM 709, and 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.[11] "[M]ajor portions of [the CTSS system were largely prepared by]: Mrs. Marjorie M. Daggett, Mr. Robert Daley, Mr. Robert Creasy, Mrs. Jessica Hellwig, Mr. Richard Orenstein, and Professor F. J. Corbató".[8][12]

The system used an IBM 7090, modified by Herbert 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, which swapped out 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.[11]

This became the initial version of the Compatible Time-Sharing System. This was apparently the first ever public demonstration of time-sharing; there are other claims, but they refer to special-purpose systems, or with no known papers published. The "compatibility" of CTSS was with background jobs running on the same computer, which generally used more of the compute resources than the time-sharing functions.[citation needed]

Applications

[edit]

DOTSYS and BRAILLEMBOSS

[edit]

The first version of the DOTSYS braille translation software ran on CTSS and could output to a BRAILLEMBOSS braille page printer.[13][14] DOTSYS on CTSS was first demonstrated on August 18, 1966, as part of a feasibility study where teletypesetter tape, in the form of news, was converted to Grade 2 Braille. The following month the feasibility of converting textbook information on teletypesetter tape to error-free Grade 2 Braille was successfully demonstrated.[15]

As MIT CTSS was an academic system, a research vehicle and not a system for commercial computing, two years later a version of DOTSYS stripped of CTSS dependencies for software portability was used on an IBM 709 at the American Printing House for the Blind to print the first braille edition of a book produced from teletypesetter input, only a few weeks after the ink-print version.[16] The following year, on CTSS, a demonstration of printing mathematical tables in braille was shown. A short FORTRAN II program was written to produce a conversion table from inches to millimeters in braille via the BRAILLEMBOSS braille page printer.[17]

Intrex

[edit]
Diagram of the Intrex running on CTSS

The Intrex Retrieval System ran on CTSS. Intrex was an experimental, pilot-model machine-oriented bibliographic storage and retrieval system with a database that stored a catalog of roughly 15,000 journal articles. It was used to develop and test concepts for library automation.[18][19][20] A deployment of three BRISC CRT consoles for testing at the MIT Engineering Library showed that it was preferred over two other systems, ARDS and DATEL.[21]

Features

[edit]

Implementation

[edit]

Kernel

[edit]

CTSS used a modified IBM 7090 mainframe computer[28] that had two 32,768 (32K) 36-bit-word banks of core memory instead of the default configuration which provides only one.[29][30] 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 be called only by software interrupts, as in modern operating systems. Causing memory-protection interrupts were used for software interrupts.[8] Processor allocation scheduling with a quantum time unit 200 ms, was controlled by a multilevel feedback queue.[29] It also had some special memory-management hardware,[31] a clock interrupt,[32] and the ability to trap certain instructions.[31]

Supervisor subroutines

[edit]
  • 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

[edit]

CTSS at first had only an assembler (FAP) and a compiler for the MAD language. Also, FORTRAN II code could be translated into MAD code by using MADTRN. Later,[when?] half of the system was written in MAD. Other programming languages were added, including COMIT II, LISP 1.5, and a version of ALGOL.[when?]

File system

[edit]

Each user had their own directory to store their data, and there were also shared directories for groups of people with the same "problem number". Each file had two-part names, the second indicating its type, as did the filename extension in later systems. At first, each file could have one of four modes: temporary, permanent, read-only class 1, and read-only class 2. Read-only class 1 allowed the user to change the mode of the file. Files could also be symbolically linked between directories. An example 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

Peripherals

[edit]

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[33]
  • An IBM 7750 transmission control unit capable of supporting up to 112 teleprinter terminals, including IBM 1050 Selectrics and Model 35s. Some of the terminals were located remotely, and the system could be accessed using the public Telex and TWX networks.

Influences

[edit]

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.

Maurice Wilkes witnessed CTSS and the design of the Titan Supervisor was inspired by that.[34][35]

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. Dennis Ritchie wrote in 1977 that Unix could be seen as a "modern implementation" of CTSS.[36] One of the technical terms inherited from CTSS by these successor systems is daemon.

Incompatible Timesharing System (ITS), 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 "Unix" was a parody of "Multics".[37] CTSS and ITS file systems have a number of design elements in common. Both have an MFD (master file directory) and one or more UFD (user file directories). Neither of them support nested directories (sub-directories). Both have file names consisting of two parts which are a maximum of six-characters long. Both support linked files.[5]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Compatible Time-Sharing System

View on Grokipedia
from Grokipedia
The Compatible Time-Sharing System (CTSS) was a pioneering time-sharing operating system developed at the Massachusetts Institute of Technology (MIT) Computation Center, enabling multiple users to interactively access computing resources simultaneously via remote terminals on shared hardware.[1][2][3] First demonstrated in November 1961 on an IBM 709 mainframe, CTSS represented one of the earliest practical implementations of time-sharing, allowing efficient resource allocation among users without the delays of batch processing.[4][1] Development of CTSS began in spring 1961 under the leadership of Fernando J. Corbató, with key contributions from Robert Daley and Marjorie Daggett, building on earlier concepts like those explored by Herb Teager in 1960.[1][4] The system evolved from an experimental setup on the IBM 709 to a more stable version by 1963, running on upgraded IBM 7090 and 7094 hardware with modifications such as expanded 32K-word memory, an IBM 1301 disk for storage, and the IBM 7750 terminal controller supporting up to 30 simultaneous users.[4][2] Key innovations included a per-user disk-based file system, password authentication for security, hardware-based protection via dual-core isolation (supervisor in one core, user programs in another), and the ability to run batch jobs in the background alongside interactive sessions.[1][4] These features addressed the limitations of single-user batch systems prevalent in the early 1960s, providing real-time interaction and resource multiplexing through rapid context switching.[3][2] CTSS entered full service for MIT users in 1963 and supported critical research under Project MAC, including early applications like the ELIZA chatbot, text formatting with RUNOFF, and precursors to email via inter-user messaging.[4][2] It operated continuously until its retirement in May 1973, when maintenance costs and migration to newer systems like Multics rendered it obsolete.[1][4] The system's legacy profoundly influenced subsequent operating systems, including Multics (developed jointly by MIT, Bell Labs, and GE), which in turn shaped Unix, as well as IBM's CP/CMS and DEC's TOPS-10, establishing foundational principles for modern multi-user computing, virtual memory, and file protection. Recent efforts include the 2024 emulation of CTSS on modern hardware, enabling the resurrection of original programs like ELIZA.[1][4][5]

History

Origins and Early Development

The conceptual foundations of the Compatible Time-Sharing System (CTSS) trace back to early ideas on multiprogramming and interactive computing, notably John Backus's 1954 proposal during an MIT summer session on advanced coding techniques for digital computers. Backus envisioned time-sharing as a method to divide a large computer's resources among multiple users, allowing simultaneous access without the inefficiencies of batch processing, where he argued that "by time sharing, a big computer could be used as several small ones."[6] This idea addressed the growing demand for more responsive computing environments amid the limitations of sequential job submission on early mainframes like the IBM 704.[7] In the late 1950s, the MIT Computation Center, established in 1957 under Philip Morse to manage shared access to an IBM 704, became a hub for addressing batch processing's drawbacks, such as long turnaround times of up to 24 hours for job submissions.[1] The center's team, formed to optimize resource utilization for science and engineering research, focused on enabling interactive use to reduce delays and foster collaborative development. Key personnel included Fernando J. Corbató, who joined as a research associate in 1956 and became deputy director in 1958, leading efforts to conceptualize time-sharing; Robert C. Daley, a programmer hired around 1959 who contributed to early system design; J. H. Saltzer, involved in programming and documentation from the late 1950s; and M. M. Daggett (later Merwin), who joined in 1957 and worked on initial command structures and interrupt handling.[1] Their motivations stemmed from hands-on experience with interactive machines like the Whirlwind and TX-0, highlighting the need for a "computing utility" accessible in real-time.[8] By 1960, the team conducted first conceptual tests in simulated environments, with Herb Teager experimenting on modified Flexowriter terminals connected to the IBM 709 to prototype user interactions.[1] Initial funding and broader motivations crystallized in 1963 through Project MAC, sponsored by the Advanced Research Projects Agency (ARPA), which emphasized interactive computing to advance research in artificial intelligence and multiprogramming across MIT departments.[1] This support built on the late-1950s groundwork, paving the way for the Experimental Time-Sharing System as the first prototype.

Experimental Time-Sharing System

The experimental phase of the Compatible Time-Sharing System (CTSS) began in 1961 with modifications to MIT's IBM 709 computer to enable time-sharing capabilities. Key hardware alterations included the addition of a fourth channel for direct data connection, a real-time buffer and control rack, and three Flexowriter typewriter terminals for user input and output. These Flexowriters served as the primary interfaces, allowing interactive access similar to teletypewriters. Further modifications encompassed a 60-cycle interrupt clock for timing, memory protection mechanisms, dynamic relocation features, and input/output trapping to support multitasking.[9] In November 1961, Fernando J. Corbató and his team conducted the first public demonstration of the prototype CTSS at MIT, successfully supporting three simultaneous users through the Flexowriter terminals. This landmark event showcased the system's ability to provide responsive, multi-user computing, marking a significant advancement in interactive processing. The demonstration highlighted the feasibility of time-sharing on existing hardware, drawing from earlier conceptual ideas on efficient resource allocation.[10] At its core, the prototype introduced program swapping as the primary multitasking mechanism, where inactive user programs were transferred to auxiliary storage using two-channel overlapped magnetic tape drives, allowing the system to cycle between up to four users (three foreground and one background). Each user received a time slice of approximately 200 milliseconds in a round-robin scheduling approach, enabling brief but interactive sessions. Core memory was limited to 32,000 words, with 27,000 words allocated for user programs and 5,000 words reserved for the supervisor, which constrained operations to short computational tasks.[9] The system faced notable challenges, including high overhead from the swapping process due to the relatively slow tape transfer rates—about 3.3% of the main multiplexor channel speed—which led to delays in program loading and context switching. Input/output operations further exacerbated response times, often resulting in sessions limited to simple calculations or editing to avoid excessive wait times. Despite these limitations, the prototype's success validated the time-sharing concept and prompted a decision to upgrade to the more capable IBM 7090 in early 1962, followed by the IBM 7094, to develop the full CTSS implementation.[10]

Deployment and Evolution at MIT

The Compatible Time-Sharing System (CTSS) achieved full production deployment on a modified IBM 7094 at the MIT Computation Center in March 1963, marking the transition from its experimental phase to routine operational use.[1] This installation initially supported a growing number of users, reaching capacity for up to 30 simultaneous terminals by 1964 through enhancements to the IBM 7750 communications controller.[4] The system's design allowed for evolutionary improvements while maintaining compatibility with batch processing, enabling it to serve the Computation Center's diverse computing needs. Over its primary operational period from 1963 to 1968, CTSS underwent key upgrades to enhance performance and accessibility. In 1963, an IBM 1301 disk storage unit was added, replacing slower magnetic tape drives for user file storage and improving data persistence and access speeds.[1] Memory capacity was expanded with additional high-speed core storage banks, and remote access was facilitated via Bell 103A modems connected through MIT's private telephone exchange, allowing dial-up connections from off-site locations.[4] A secondary CTSS instance on a separate IBM 7094, dedicated to Project MAC and the Artificial Intelligence Group, extended operations until its final shutdown in May 1973.[1] By the mid-1960s, CTSS supported hundreds of registered users from MIT and nearby institutions, providing daily interactive sessions to up to 30 simultaneous users and handling a high volume of computational tasks central to Project MAC research.[11] This level of utilization demonstrated the system's scalability for multi-user environments, fostering advancements in areas like programming languages and collaborative computing. The primary installation at the Computation Center was decommissioned in late 1968, primarily due to the impending rollout of Multics on new GE-645 hardware in 1969, escalating resource constraints from aging IBM equipment leases, and the demand for more powerful systems to meet evolving research requirements.[1]

System Architecture

Hardware Platform

The Compatible Time-Sharing System (CTSS) originated on a modified IBM 709 computer, which served as the prototype platform for its initial demonstration in November 1961. This system was upgraded to an IBM 7090 in spring 1962, providing improved performance while maintaining compatibility with the original implementation. By 1963, the platform transitioned to the IBM 7094 as the main production system, supporting expanded operations at MIT's Project MAC. Each of these machines utilized ferrite-core memory with a standard capacity of 32,768 36-bit words, but CTSS required specific enhancements to enable time-sharing, including the addition of a second 32K-word memory bank to separate supervisor and user spaces.[10] Key hardware modifications for CTSS included an interval timer (IBM feature B/M 570220) to facilitate time-slicing, along with memory boundary and relocation registers (RPQ E007291) that enforced protection between the supervisor-resident A-core and user programs in B-core. These changes enabled a two-mode operation where restricted instructions in user mode trapped to the supervisor, preventing interference. Additionally, I/O channels were augmented to handle multiple peripherals without disrupting core operations, allowing the system to support concurrent batch processing via the Fortran Monitor System (FMS) in the background alongside time-shared foreground tasks. This design ensured backward compatibility with non-time-sharing workloads on the same hardware.[4][1] The storage hierarchy for CTSS began with IBM 729 magnetic tape drives for backups and data exchange, initially comprising six units—three dedicated to swapping and three to user files—connected across I/O channels. In 1963, this evolved to include an IBM 1301 disk storage unit for random-access file storage, offering approximately 28 million 6-bit characters of capacity per module, later upgraded to an IBM 1302 with enhanced density reaching about 36 megabytes total. Swapping operations relied on an IBM 7320 drum memory, introduced in 1962, which provided around 174,000 36-bit words (roughly equivalent to six core loads) for paging user programs in and out of memory, later upgraded to 7320A drums with 192,000 words each.[10][4][12] Terminal support was handled through direct connections initially, with up to four Friden Flexowriter terminals attached to I/O channels for local interaction at 10 characters per second. The system later incorporated the IBM 7750 transmission control unit, enabling remote access for up to 112 lines via telephone modems, including IBM Model 35 Teletypes at 110 baud, IBM 1050 data communication terminals, and IBM 2741 communications systems at 134.5 baud. These peripherals, supported by additional RPQs for reverse-break functionality and modem compatibility, allowed distributed users to interact without interfering with the central CPU's time-shared execution.[13][4]

Core Operating Principles

The Compatible Time-Sharing System (CTSS) implemented a time-sharing model that allowed multiple users to interact concurrently with the IBM 7094 computer while maintaining compatibility with traditional batch processing jobs, enabling the system to allocate resources between interactive foreground tasks and background batch operations without requiring separate hardware.[10] This design utilized a multi-level priority queue scheduling algorithm, where interactive users were assigned to higher-priority queues (typically levels 2 or 3 for programs under 4K words), employing a time quantum of 0.5 seconds to ensure fair CPU allocation and prevent any single user from monopolizing resources.[14] The scheduler operated via clock interrupts occurring in bursts of 200 milliseconds, facilitating round-robin-like dispatching among ready users in the active queue while dynamically adjusting priorities based on program size and behavior to balance responsiveness and throughput.[14] Batch jobs, in contrast, ran in lower-priority queues with longer execution limits, up to 10 minutes per foreground batch invocation, ensuring the system could handle both paradigms seamlessly.[14] To address the limitations of the 7094's 32K-word core memory (divided into A-bank for the supervisor and B-bank for users), CTSS employed a precursor to virtual memory through program swapping, which transferred entire user programs between core and secondary storage to simulate a larger addressable space.[4] Swapping utilized high-speed IBM 7320A drums (each holding 192K words, organized into logical 32K-word units) or disks (up to 76 million words) for storage, with transfer times of approximately 0.25 seconds to drum or 1 second to disk for a full 32K-word block, allowing the system to support programs exceeding physical memory by paging them out during idle periods.[14] This mechanism, often termed "onion skin" swapping due to its layered approach via a memory bound register, kept active user text segments in core when possible while relocating data beyond the bound to secondary storage, thereby enabling efficient multitasking without true paging but establishing key concepts for later virtual memory systems.[10] User isolation in CTSS was enforced through hardware modifications (RPQs) to the 7094, creating a two-mode architecture with a privileged supervisor mode in A-bank (32K words) and unprivileged user mode in B-bank, preventing direct user access to system resources or other users' memory.[4] The supervisor trapped all unauthorized I/O attempts, memory violations, or privileged instructions via a Protection Mode Trap Interpreter (PMTI), simulating safe operations while isolating up to 30 virtual machines and ensuring that a malfunctioning user program could not compromise the system or peers.[10] This hardware-software boundary, including relocation and boundary registers, confined each user's address space to a subset of B-bank, with the supervisor mediating all inter-user interactions to maintain integrity and security.[4] The command-line interface in CTSS provided a straightforward interactive environment centered on a simple line-oriented editor and basic job control commands, allowing users to edit, compile, and execute programs directly from terminals.[14] The QED editor supported essential operations like APPEND, CHANGE, DELETE, PRINT, READ, SUBSTITUTE, and WRITE for text manipulation, enabling rapid iteration on source code within sessions.[14] Program execution was initiated via the RUN command, which loaded and invoked compiled programs (e.g., RUN COMMAND or RUN FAP), often generating temporary files for output; job management included LINK to create cross-directory file references (e.g., LINK NAME1 NAME2) and DELETE to remove files (e.g., DELETE FILNAM), with safeguards like confirmation prompts for linked items to prevent accidental data loss.[14] Basic security in CTSS revolved around per-user directories and file protection mechanisms, with each registered user allocated a private User File Directory (UFD) within the Master File Directory (MFD), restricting access to personal files by default.[4] File protections were managed via the PERMIT command, which granted specific access modes (e.g., read, write) to other users or groups (e.g., PERMIT U.F.D. (FILE) 0 probn progn), while commands like ATTACH allowed temporary directory switching with authorization checks.[14] The system introduced the concept of daemons as background processes for automated tasks, such as the backup daemon, which performed incremental or full file system dumps without interrupting user sessions, running as a non-preemptible console-less foreground process to ensure reliability.[15] Early authentication relied on usernames and plain-text passwords stored in files like UACCNT, with a notable security incident in 1966 exposing passwords due to a swapping error.[10]

Implementation

Kernel and Supervisor

The Compatible Time-Sharing System (CTSS) featured a monolithic kernel design, with the entire supervisor resident in the 32,768-word A-bank of core memory, implemented in FAP assembly language for the IBM 7090/7094. This structure centralized all low-level operations, including interrupt processing, input/output management, and process scheduling, ensuring tight control over system resources without modular separation. The kernel's placement in A-bank provided inherent protection, as user programs executed exclusively in the adjacent B-bank, preventing direct access to supervisory code.[14] Key supervisor subroutines handled essential system tasks, such as I/O operations through RDFLXA and WRFLX, which facilitated reading from consoles or files and writing output without carriage returns, respectively, by trapping to the PMTI module via instructions like TSX ADDR,4. Deadlock detection and process termination were managed by the DEAD subroutine, which set a program to dormant status, exited it upon errors, and reset the memory bound register to zero for cleanup. Job prioritization and completion were overseen by PPJOB, which ended user jobs, returned control to the supervisor, and processed priority queues to maintain fair scheduling among active processes. These subroutines formed the backbone of system management, invoked through software traps to enforce isolation and resource allocation.[14][10] Memory management in CTSS relied on a dual-bank architecture, with the A-bank dedicated to the supervisor and the B-bank allocated dynamically to user programs in 256-word blocks, bounded by hardware registers to prevent overflows. Non-resident pages were swapped to secondary storage—a high-speed drum holding 186,400 words (with ~0.25-second transfer times) or a disk with 76 million words (~1-second transfers)—using an "onion skin" strategy that prioritized inner, frequently accessed layers to minimize latency. This setup supported time-slicing by rapidly swapping user contexts, aligning with the system's core principle of multiplexing access via short execution bursts.[14] Interrupt handling was priority-based, allowing nesting up to three levels, with hardware mechanisms like the B/M 570220 interval timer generating traps every 200 milliseconds or simulating 1/60-second increments to enforce time quanta. Timer interrupts preempted user programs, transferring control to a trusted supervisor location in A-bank for rescheduling, while other interrupts (e.g., from I/O devices) were queued to maintain system stability. The base quantum was 0.5 seconds, with execution limits scaled as 2P⋅L2^{P \cdot L} quanta, where P=2P=2 and LL ranged from 0 to 8 for priority levels, excluding time spent on swaps or disk I/O to fairly account for overhead.[14] Error recovery mechanisms emphasized resilience without full system crashes, trapping protection violations or illegal instructions directly to the supervisor for diagnosis and response. Programs could be aborted via DEAD or a quit signal (e.g., two break button presses), resetting buffers like RSSRB and returning error codes in the accumulator, while restarts were initiated through commands such as RESUME, RESTART, or START to reload from saved states. In severe cases, core dumps were analyzed post-freeze (e.g., via XEC *), enabling targeted restarts and minimizing downtime for ongoing user sessions.[14][10]

Programming Languages and Tools

The Compatible Time-Sharing System (CTSS) initially supported a core set of programming languages designed for compatibility with existing IBM 709/7090/7094 batch systems, including the assembler FAP and the algebraic compiler MAD. FAP, an IBM 7094 assembler with macro capabilities, allowed for symbolic debugging and pseudo-operations like BCORE for input/output handling. MAD, based on ALGOL 58 with extensions for list processing and simplified I/O via the MADIO package, served as the primary high-level language. Fortran II was also available, though it required translation into MAD code using the MADTRN utility to enable execution, supporting features like floating-point trap handling and on-line I/O through library subroutines such as READ FMT.[14] Later additions expanded CTSS's capabilities for specialized tasks, including SNOBOL in 1962 for advanced string processing, COMIT II in 1962 for pattern matching and substitution, LISP 1.5 in 1962 for list processing and artificial intelligence applications with recursive functions and console interaction, and ALGOL 60 for structured programming, often implemented via MAD or as an extended variant. These languages were integrated through compilers and interpreters that facilitated direct execution from source code using the RUN command, which allowed users to compile and run programs in languages like EDIT, FAP, or MAD without intermediate batch steps. For instance, SNOBOL's compiler included options for online output, while COMIT II featured an interpreter with debugging support via BREAK status.[14] Development tools in CTSS emphasized efficiency in a multi-user environment, featuring the QED text editor—a line-oriented tool for ASCII files that supported buffers, macros, regular expressions, and context-based editing, serving as a predecessor to the Unix ed editor. Debugging was handled by simple yet effective utilities, including FAPDBG for symbolic assembly debugging, MADBUG for MAD programs, STRACE for trace analysis, and the general DEBUG tool (occupying about 15,000 octal words) with breakpoints, memory inspection, and error tracing via the ERROR subroutine. Macro assemblers were enhanced in variants like BEFAP, enabling code generation and symbol table management during assembly.[14][16] A key innovation was the system-wide integration of SNOBOL, marking one of the earliest environments for robust string manipulation that enabled pioneering natural language processing experiments through its pattern-matching primitives. However, CTSS lacked modern integrated development environments, relying instead on line editors like QED and batch-style compilation processes for complex programs, which limited rapid iteration compared to later systems.[14]

File System

The file system of the Compatible Time-Sharing System (CTSS) employed a hierarchical structure with per-user home directories, called User File Directories (UFDs), and shared system directories organized under a Master File Directory (MFD) at the root level.[14] Each registered user maintained a private UFD for their files, while shared access was facilitated through linked common directories associated with project problem numbers, such as COMFIL or TSSFIL areas limited to five slots.[14] Files were named using a two-part convention, with each component limited to six alphanumeric characters (e.g., PROG1.MAD), supporting both BCD and binary formats.[14] This organization evolved from an initial flat namespace of user-specific file lists to a tree-like hierarchy, enhancing scalability for multi-user environments while aligning with the system's user isolation principles.[1][14] CTSS files operated in distinct modes to control lifecycle and access: temporary files were automatically deleted after reading or upon user logout, permanent files remained stored indefinitely, and read-only modes (Class 1 or 2) prohibited writes.[14] Additional protections included private mode, restricting access to the owner and supervisor, and protected mode for broader safeguards; these were set via commands like PERMIT or LINK with octal mode values (e.g., 1 for read-only, 100 for private) and enforced through owner/group permissions.[14] Storage resided on IBM 1301 and 1302 disk units, providing approximately 36 MB of shared capacity, with files allocated in 432-word records that could be chained across tracks for larger sizes.[1][12] Later configurations incorporated IBM 2302 disks and 7320 drums for auxiliary storage, maintaining the block-based layout without formal subdirectories in early versions.[14][12] Core operations encompassed CREATE (typically via the ED editor or .ASIGN), DELETE (.DELETE), RENAME (.RENAM), and LINK (for non-duplicative sharing across directories), all mediated by supervisor calls to ensure atomicity.[14] The supervisor also managed quotas, allocating limits such as 200 tracks per user to avert disk overflow, with commands like ALLOT for adjustments.[14] CTSS pioneered per-user disk quotas and private files in a time-sharing context, resolving multi-user resource contention and privacy concerns by isolating personal storage while enabling selective sharing.[1][14]

Peripherals and Input/Output

The terminal subsystem of CTSS relied on a combination of local and remote devices to facilitate user interaction. Locally, early implementations supported up to four Friden Flexowriter terminals, which were typewriter-like devices directly connected to the computer's I/O channels for input and output operations.[1] For remote access, the IBM 7750 transmission control unit served as the primary interface, capable of supporting 30 to 112 terminal lines depending on configuration and load, connected via asynchronous serial lines.[14] These lines utilized Bell System 103A modems for full-duplex communication at 300 bits per second over dial-up phone lines.[4] Storage peripherals in CTSS included IBM 729 magnetic tape drives for archival and backup purposes, typically configured with six units—three for user swapping in early versions and three for data storage—each handling 7-track tapes at speeds up to 200 characters per inch.[1] The IBM 7320 drum provided fast-access secondary storage for swapping user programs and data, offering 186,400 words of capacity with transfer rates enabling 32,000 words per second, which minimized latency during context switches.[14] Output to printers was managed through the IBM 1403 line printer, a high-speed chain printer capable of 600 to 1,400 lines per minute, used for bulk job results and system logs.[4] I/O operations in CTSS were buffered and controlled through supervisor calls, such as READ and PRINT routines, which transferred data between user programs and device buffers in core memory to prevent blocking during time-sharing cycles.[14] Print jobs were spooled to prevent interference with interactive sessions, routing output to pseudo-tape files on disk or directly to offline processors like the IBM 1401, which handled queuing and execution without tying up the main CPU.[1] This buffering mechanism supported formats like 6-bit ASCII or 12-bit BCD, with double buffering options to overlap I/O and computation for efficiency. Remote capabilities were introduced in 1963, marking one of the earliest implementations of dial-up access in a time-sharing system, allowing off-site users to connect via phone lines to the IBM 7750 and modems for interactive sessions from locations beyond MIT's campus.[1] Users initiated connections by dialing a dedicated exchange, after which the system assigned a console ID for tracking and management. CTSS lacked graphical interfaces, relying entirely on text-based interactions through terminals, where user input was echoed back for verification and editing was performed via control sequences like line deletion or character insertion supported by the terminal hardware.[14] I/O operations integrated with the file system through supervisor-mediated reads and writes, enabling seamless access to disk-stored files during terminal sessions.[4]

Applications

DOTSYS and BRAILLEMBOSS

The DOTSYS project, initiated in 1964 and reaching key milestones in 1966, was a pioneering effort by the MIT Sensory Aids Evaluation and Development Center (SAEDC) in collaboration with the American Printing House for the Blind (APH) to create the first real-time Braille translation system integrated with the Compatible Time-Sharing System (CTSS).[17][18] This initiative aimed to automate the conversion of printed materials into accessible formats for blind individuals, leveraging CTSS's time-sharing capabilities on the IBM 7094 to enable efficient, on-demand production.[19] The collaboration with APH facilitated practical testing and distribution, including the production of physical Braille copies for educational use.[17] Functionally, DOTSYS processed input from teletypesetter (TTS) tapes—representing printed text and mathematical content—and translated it into Grade II contracted Braille using a modular program structure divided into "boxes" for input preprocessing, translation rules, and output formatting.[18] Running on CTSS, the system handled the complexities of English text contraction and basic mathematical notation, producing error-free output suitable for immediate embossing.[17] The translated Braille codes were then routed to output devices, marking a significant step toward automating what had previously been a labor-intensive manual process.[19] Key achievements included two major demonstrations in 1966: the first on August 18, which converted United Press International (UPI) news service TTS tapes into Braille via a high-speed embosser, proving feasibility for real-time news dissemination; and the second on November 18, which translated textbook materials into Braille, resulting in 200 interpointed Grade II copies forwarded to APH for distribution to blind students.[17][18] These demos showcased DOTSYS's ability to manage structured content like tables and simple equations through customizable translation rules, though full handling of advanced mathematics required later enhancements.[20] Hardware integration centered on connecting DOTSYS output from CTSS to the BRAILLEMBOSS, an early MIT-developed Braille page printer that converted electrical signals into embossed pages at speeds comparable to teletypes.[19] The BRAILLEMBOSS, prototyped around 1963 and operational by 1966, interfaced directly with CTSS terminals like the Model 35 Teletype, allowing blind programmers and users to receive real-time Braille feedback during interactive sessions.[19] This setup bypassed slower manual methods, with the system achieving embossing rates of approximately 20 Braille pages per hour under optimal conditions.[20] The impact of DOTSYS and BRAILLEMBOSS was profound in enabling on-demand Braille production for educational materials, significantly reducing turnaround times from weeks to hours and making textbooks accessible to blind students without reliance on centralized transcription services.[17] By 1968, the system had supported the creation of full Braille editions, such as "The East Indiaman," and demonstrated potential for broader adoption in schools like Perkins, where over half of surveyed faculty expressed interest in monthly use.[19] This application of CTSS not only advanced accessibility technology but also highlighted time-sharing's role in specialized, user-focused computing.[18]

Intrex Experiment

The Intrex Experiment was a key component of MIT's Project INTREX (Information Transfer Experiments), an initiative launched in the mid-1960s to explore interactive bibliographic search for enhancing library services in research environments. Directed by Carl F. J. Overhage, the project focused on developing computer-based systems for efficient information retrieval, with initial planning conferences held in 1965 and active experimentation beginning in 1966. Funded primarily by the National Science Foundation (NSF) through grants like NSF-C472, along with support from the Carnegie Corporation and the Council on Library Resources, it aimed to test concepts for user-centered library automation targeting scientists and engineers.[21][22][23] Built on the Compatible Time-Sharing System (CTSS) running on a modified IBM 7094, the Intrex system featured a dedicated configuration for multi-user access, indexing approximately 15,000 journal articles and technical documents in fields like materials science and engineering. Users accessed the system via remote terminals to perform queries, retrieving abstracts, citations, tables of contents, and bibliographic details from an augmented catalog database. The catalog structure included about 115 data elements organized into 50 flexible fields, accommodating diverse document types and supporting dynamic updates through interactive editing. Data input combined off-line punched paper tape preparation with on-line terminal corrections, though the former proved more cost-effective at around $23.46 per file compared to $41.07 for direct terminal entry in 1968.[21][23][22] Key features emphasized user-driven retrieval, including subject searches via unconstrained noun-phrase indexing with weights from 0 to 4, phrase decomposition, and word stemming to handle variations without a controlled thesaurus. The system supported partial and full term matching using inverted files for authors, titles, and subjects, along with Boolean combinations of result sets and man-machine dialogs for query refinement and feedback. Precursors to relevance ranking appeared in the form of weighted terms and user comments fields that allowed iterative adjustments, enabling display-oriented outputs tailored to individual needs. Indexing averaged 16.4 terms per record, with student indexers achieving efficiency after initial training, stabilizing at 6-8 minutes per page of text. Programs were primarily implemented in Fortran, with provisions for handling full-text access via associated microfiche storage.[21][23][22] The hardware setup utilized CTSS's core IBM 7094 processor, augmented by a PDP-7 for auxiliary processing and dedicated drum storage for high-speed index and catalog retrieval, ensuring low-latency responses during searches. Terminals included IBM 2741 teletypewriters, Friden Flexowriters for input, and custom CRT displays with integrated microfiche readers for viewing full texts, supporting multiple simultaneous users—typically 8 to 12 during experiments. This configuration leveraged CTSS's time-sharing capabilities for concurrent sessions, with drum-based caching critical for the inverted file operations.[21][24][23] User testing from 1968 onward, including summer trials at MIT's Barker Engineering Library, demonstrated the feasibility of online catalogs, with participants reporting high satisfaction in interactive search efficiency over traditional card systems. Deep indexing improved precision but raised costs, prompting refinements in descriptor selection. The project, active through 1969 with follow-on work into the early 1970s, validated core concepts like relevance feedback and distributed access, influencing later information retrieval systems and laying groundwork for modern search engines by proving scalable bibliographic querying. It concluded amid hardware scaling limits of the IBM 7094 era and CTSS's phase-out by 1973, shifting focus to broader library automation efforts.[21][23][25]

Broader Educational and Research Uses

The Compatible Time-Sharing System (CTSS) played a significant role in MIT's educational initiatives, particularly in enabling interactive programming experiences for students. In the Department of Civil Engineering, CTSS was integrated into a freshman programming course in 1964, where 16 students accessed the system via a single remote console to practice real-time coding on an IBM 7094. This setup allowed learners to iteratively develop and test programs, fostering hands-on engagement with computing concepts compared to traditional batch methods on systems like the IBM 1620. Although evaluations showed no definitive superiority in student performance metrics such as grades, the experiment underscored CTSS's potential for enhancing instructional efficiency in technical courses by providing immediate feedback and reducing setup overhead.[26] Beyond structured coursework, CTSS supported student access to computational simulations and data analysis tasks across MIT departments. Users could run models for engineering problems, process datasets interactively, and debug simulations in real time, which was particularly valuable for exploratory learning in fields like electrical engineering and education research. This capability extended to broader academic exploration, where students from various disciplines utilized CTSS for ad-hoc computations without the delays of batch scheduling.[27] In research contexts, CTSS facilitated collaborative efforts in artificial intelligence through implementations like CTSS LISP, which enabled early projects in symbolic processing and list manipulation at MIT's AI Laboratory. Researchers employed LISP on CTSS for developing AI prototypes, leveraging its interactive environment to experiment with algorithms iteratively. Similarly, in linguistics, the COMIT language on CTSS supported string manipulation and pattern-matching tasks, aiding studies in natural language processing and computational philology. Physics modeling also benefited, with users running simulations for scientific computations, such as dynamic systems analysis, in an environment that promoted rapid prototyping and data visualization. These applications highlighted CTSS's versatility for interdisciplinary research, often involving shared directories for team-based file access.[28][14][29] By 1965, CTSS had attracted hundreds of registered users, including MIT faculty, students, and external academics from New England institutions, with daily service supporting up to 30 simultaneous sessions via dial-up terminals. This user base enabled pre-ARPANET remote collaboration, as researchers exchanged data and results asynchronously through features like early email. Languages such as LISP and COMIT were commonly referenced in these efforts for specialized analyses.[11] Daily operations on CTSS centered on interactive sessions for tasks like program debugging, data processing, and generating computational reports, which dominated usage over batch processing. An experimental study confirmed that time-sharing via CTSS accelerated program development cycles compared to batch systems, emphasizing its focus on user-driven interactions. Typical workflows involved logging in to edit files, execute code, and analyze outputs in short, iterative bursts, making it ideal for both educational drills and research iterations.[30] High demand for CTSS resources often resulted in queuing for CPU time and storage, as the system supported only a limited number of concurrent users and relied on tape for overflow. Such constraints, including manual file retrieval delays, highlighted scalability issues and spurred the development of more robust systems like Multics to accommodate growing academic needs.[4][31]

Legacy

Technical Influences

The Compatible Time-Sharing System (CTSS) exerted a profound influence on subsequent operating systems, particularly through the direct transfer of concepts and personnel from its development team at MIT. Led by Fernando Corbató, the core CTSS group transitioned their expertise in time-sharing, hierarchical file systems, and early security mechanisms—such as password-protected user directories—to the Multics project, initiated in 1965 on the GE-645 computer in collaboration with Bell Labs and General Electric.[32][8] Multics extended CTSS's innovations by integrating a more robust segmented memory model and access controls, establishing foundational principles for secure multi-user environments that prioritized user isolation to prevent interference between processes.[4] This lineage from CTSS directly informed Multics's design as a utility-like system, where computing resources were allocated dynamically among users without compromising data integrity.[33] CTSS's impact extended to Unix through Multics alumni, including Ken Thompson and Dennis Ritchie, who adapted its elements after leaving the Multics effort at Bell Labs. Unix incorporated CTSS- and Multics-inspired hierarchical file structures, enabling organized directories for user data management, and interprocess communication via pipes, which evolved from CTSS's linking mechanisms for chaining program I/O operations.[34][35] Additionally, Unix adopted the concept of daemons—background processes for system maintenance—originating in CTSS, where the term was first applied to autonomous programs handling tasks like automatic tape backups of the file system.[36] These borrowings facilitated Unix's lightweight, modular architecture, emphasizing process isolation inherited from CTSS's time-slicing and protection rings, which influenced modern operating systems' user-mode/kernel-mode separations and privilege levels.[37] Beyond these major systems, CTSS shaped several contemporaries, including IBM's VM/370, where its swapping techniques for memory management inspired virtual machine isolation, allowing multiple independent environments on a single mainframe.[38] At the University of Cambridge, Maurice Wilkes's 1965 exposure to CTSS prompted a redesign of the Titan operating system, incorporating time-sharing and user-level file access to support multi-user computing on the Atlas 2 hardware.[39] Similarly, the Incompatible Timesharing System (ITS) developed at MIT's Artificial Intelligence Laboratory drew from CTSS's legacy through shared institutional knowledge, emphasizing hacker-friendly extensibility and process autonomy in its PDP-10 implementation.[1] Lacking a formal licensing model, CTSS's innovations disseminated rapidly via seminal publications, such as Corbató's 1962 AFIPS paper on experimental time-sharing, fostering widespread adoption without proprietary restrictions.[8]

Preservation and Modern Interest

Efforts to preserve the Compatible Time-Sharing System (CTSS) have focused on archiving documentation, source code fragments, and related artifacts from its operational era. Bitsavers.org maintains an extensive digital collection of CTSS manuals, including the 1969 Programmer's Guide and earlier system notes, making these resources accessible for historical research.[40] The MIT Computation Center records, held in the MIT Institute Archives and Special Collections, include research materials on CTSS development from its 1961 demonstration onward.[41] In 2011, the Multics community, through the IEEE Annals of the History of Computing, commemorated the system's 50th anniversary with a detailed retrospective, compiling essays and bibliographies that highlight its evolution and user experiences. Emulation projects have revived interest by enabling CTSS to run on contemporary hardware. The SIMH simulator, particularly its IBM 7094 module developed by Dave Pitts, supports CTSS execution, including privileged instructions and peripherals like the Chronolog clock, allowing researchers to simulate the original environment.[42] These efforts stem from ongoing work to reconstruct the IBM 7094 setup, with Pitts' emulator providing a functional baseline since 2010.[43] In June 2025, a team led by Jeff Shrager and others published details of a major restoration project in the IEEE Annals of the History of Computing, reanimating the original ELIZA chatbot—developed by Joseph Weizenbaum on CTSS in 1964–1966—on a restored and emulated CTSS environment using the SIMH IBM 7094 simulator. This open-source effort reconstructed necessary components from preserved source fragments and documentation, enabling interactive execution of the historical ELIZA program and demonstrating CTSS's capabilities for modern study.[44] CTSS retains modern relevance as a foundational example in operating systems education, illustrating the origins of time-sharing and multiprogramming concepts taught in computer science curricula.[45] Its principles of multi-user access and resource allocation prefigure cloud computing's multi-tenancy and virtualization, where shared infrastructure serves multiple isolated users efficiently, as noted in historical analyses of computing evolution.[46] Oral histories, such as Fernando Corbató's 2006 interview at the Computer History Museum, provide firsthand accounts of CTSS design decisions, emphasizing its role in shifting from batch processing to interactive computing.[37] Despite these advances, preservation faces gaps, including incomplete recovery of the full source code; while fragments exist in archives, the complete kernel and supervisor routines are not fully documented or emulatable.[10] This has spurred continued interest in reconstructing the 7094 environment, with emulator updates addressing hardware specifics to bridge these voids.[47]

References

  1. [PDF] Compatible Time-Sharing System (1961-1973) Fiftieth Anniversary ...
  2. 1961 | Timeline of Computer History
  3. Time-sharing | IBM
  4. The IBM 7094 and CTSS - Multics
  5. http://bitsavers.org/pdf/mit/whirlwind/summer_session_1954/Digital_Computers_Advanced_Coding_Techniques_Summer_1954.pdf
  6. History - Multics
  7. Fernando Corbato - A.M. Turing Award Laureate
  8. An Experimental Time-Sharing System - MIT
  9. [PDF] Compatible Time-Sharing System (1961-1973) Fiftieth Anniversary ...
  10. The History of Electronic Mail
  11. [PDF] CTSS Hardware - SIMH
  12. [PDF] CTSS Programmer's Guide - People | MIT CSAIL
  13. [PDF] The Compatible Time-Sharing System - People | MIT CSAIL
  14. Multics Failure Recovery
  15. An incomplete history of the QED Text Editor - Nokia
  16. [PDF] ED 015 609 - ERIC
  17. DOTSYS: A Braille Translation Program, SAEDC Technical ...
  18. [PDF] Development and Demonstration of Communication Systems ... - ERIC
  19. [PDF] and characteristics), sources of braille (producers and braille ... - ERIC
  20. [PDF] DOCUMENT RESUME L: 003 277 Overhage, Carl F. J. Project Intrex
  21. [PDF] generation and encoding of the project intrex augmented catalog ...
  22. [PDF] ESL-R-360 - DSpace@MIT
  23. [PDF] DOCUMENT RESUME ED 047 739 LI 002 619 Project Intrex ... - ERIC
  24. Information Retrieval in Digital Libraries: Bringing Search to the Net
  25. Use of CTSS in a Teaching Environment - DSpace@MIT
  26. CTSS Creators and Users - Multics
  27. A New Version of CTSS LISP - DSpace@MIT
  28. [PDF] The two sides of time sharing - DSpace@MIT
  29. An experimental comparison of time sharing and batch processing
  30. https://www.multicians.org/f7y.html
  31. Multics--The first seven years
  32. Fernando Corbató - IEEE Computer Society
  33. Unix and Multics
  34. Unix: An Oral History - GitHub Pages
  35. The Origin of the Word Daemon - OSnews
  36. [PDF] Oral History of Fernando Corbató
  37. [PDF] The Origin of the VM/370 Time-sharing System - cs.wisc.edu
  38. The Cambridge Multiple-Access System | BCS
  39. None
  40. Massachusetts Institute of Technology, Computation Center records
  41. [PDF] IBM 7090/7094 Simulator Usage 01-Dec-2008 - SIMH
  42. http://www.piercefuller.com/library/ctss.html
  43. http://www.cozx.com/~dpitts/ibm7090.html
  44. [PDF] CSC 553 Operating Systems - Lecture 2
  45. Someone Else's Computer: The Prehistory of Cloud Computing - CHM
  46. Compatible Time-sharing System - Time Reshared
User Avatar
No comments yet.