Jump to content

TSS (operating system)

From Alfawiki
IBM Time Sharing System (TSS/360)
Company typeOperating system
IndustryComputer software
Founded1967
FounderIBM
Defunct1971
FateDiscontinued
ProductsTime-sharing operating system
ParentIBM

The IBM Time Sharing System, known as TSS/360, was an early time-sharing operating system specifically designed for the Model 67 mainframe. Although it was introduced in 1967 on a limited trial basis to select clients, IBM never provided official support for it. TSS incorporated several pioneering features that later influenced operating systems such as MVS. Despite being adapted for System/370 and 303x platforms, TSS did not achieve commercial success and was ultimately discontinued. The system’s Resident Supervisor served as a basis for porting UNIX onto IBM mainframes. Moreover, TSS/360 played a role in inspiring the creation of the TSS/8 operating system, which delivered enhanced cost-effectiveness and stability in educational environments.

Innovative Features

Among the earliest systems to support tightly integrated symmetric multiprocessing, TSS/360 enabled two Model 67 mainframes to share physical memory and operate under a single kernel and application instance. An I/O request on one processor could generate an interrupt on its counterpart. The Model 67 utilized the standard 360 Test and Set instruction to implement locks within critical code sections.

The system also provided support for virtual memory and virtual machine capabilities through the use of position-independent code.

TSS/360 introduced an early form of a "Table Driven Scheduler," where users configured a table containing parameters such as current priority, working set size, and the count of timeslices used. This table guided the recalculation of thread priorities and influenced subsequent operating systems like Honeywell CP-V and IBM’s z/OS.

Consistent with practices of the era, customers including General Motors Research Laboratories were granted complete access to the OS source code and development tools, allowing them to implement enhancements that were often incorporated into official updates.

User Interface

TSS provides a command-line interface, enabling user interaction through its command system. Commands follow the syntax Command_Name[ operands], where command names range from one to eight characters without spaces. Operands are optional and can be separated by spaces, tabs, or commas. Lines may be extended by ending with a hyphen ("-"). Multiple commands can appear on a single line separated by semicolons (";"). Comments are indicated by semicolons followed by single quotes ("'"). Operands may be specified either positionally or as keywords (e.g., "keyword=value").

System commands are organized into seven groups:

  • Task management – LOGON, LOGOFF, ABEND
  • Data management – CATALOG, DDEF, DELETE
  • Program management – LOAD, DUMP, DISPLAY, TRAP
  • Command creation – PROCDEF, BUILTIN
  • Message handling
  • User profile – SYNONYM, DEFAULT, PROFILE
  • Program product language interface – ASM (Assembler (F)), COBOL, HASM (Assembler (H)), PLI (PL/I (F)), PLIOPT (PL/I Optimizing Compiler), FTNH (FORTRAN (H)), among others.

Position-independent code

TSS pioneered an early form of position-independent code, allowing multiple processes to share a single executable instance mapped at distinct virtual addresses.

Each routine consists of a read-only public CSECT, a writable private Prototype Section (PSECT), and a writable save area usually located within the PSECT. Since the dynamic loader assigns routines to different virtual address spaces per process, address constants for external routines and entry points are stored in the PSECT. Programs adhering to Type I linkage conventions handle register preservation in the save area referenced by register 13, obtain the PSECT address from word 19, link save areas, and adjust register 13 accordingly. Before invoking a procedure, callers load a V-constant into General Register 15 (GR15) and transfer an R-constant corresponding to the routine's PSECT into the 19th word of the save area.

Upon program loading, the dynamic loader duplicates and relocates the PSECT to correspond with each process's virtual address space, ensuring that every user operates with a distinct PSECT copy. It postpones loading program pages and resolving address constants until triggered by the initial page fault.

Criticism

TSS/360 encountered challenges related to performance, stability, and compatibility with OS/360, which were addressed over time. IBM adopted an ambitious development timeline supported by a large team to rival Multics but experienced delays comparable to those faced by OS/360. By 1967, eighteen S/360-67 installations were running TSS; however, in February 1968, IBM announced the decommissioning of TSS/360—a major blow to time-sharing users. Although this decision was briefly reversed, it culminated in official cancellation in 1971. Despite this, TSS/360 continued to be offered as a temporary solution to existing clients.

Following cancellation, IBM redirected efforts toward the Time Sharing Option (TSO) for OS/360. Other notable time-sharing systems for S/360-67 included CP-67 developed at IBM's Cambridge Scientific Center (which later evolved into VM/370), Michigan Terminal System (MTS) at the University of Michigan, and ORVYL at Stanford University. IBM also provided TSS/370 as a migration pathway for former TSS/360 users, releasing several versions.

See also

Further reading

  • Explores TSS origins and its scheduling complexities.
  • Examines the "second system syndrome" effect on TSS development.

External links

Retrieved from "https://www.alfawiki.org/index.php?title=TSS_(operating_system)&oldid=28139"