Misplaced Pages

TSS (operating system)

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
(Redirected from TSS/370) 1960s timesharing system for IBM mainframes
This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (August 2010) (Learn how and when to remove this message)
Operating system
TSS
DeveloperIBM
Working stateDiscontinued
Source modelSource available
Initial release1967; 57 years ago (1967)
Available inEnglish
PlatformsSystem/360 Model 67, System/370 models with DAT
Default
user interface		Command-line interface
LicenseTSS/360: free
TSS/370: Proprietary
History of IBM mainframe operating systems
Early mainframe computer OSes
Miscellaneous S/360 line OSes
DOS/360 and successors (1966)
OS/360 and successors (1966)
VM line
TPF line
UNIX and Unix-like
IBM System/360 Model 67-2. This is the computer model on which TSS/360 would have run

The IBM Time Sharing System TSS/360 is a discontinued early time-sharing operating system designed exclusively for a special model of the System/360 line of mainframes, the Model 67. Made available on a trial basis to a limited set of customers in 1967, it was never officially released as a supported product by IBM. TSS pioneered a number of novel features, some of which later appeared in more popular systems such as MVS. TSS was migrated to System/370 and 303x systems, but despite its many advances and novel capabilities, TSS failed to meet expectations and was eventually canceled. The Resident Supervisor of TSS/370 was used as the basis for a port of UNIX to the IBM mainframe. TSS/360 also inspired the development of the TSS/8 operating system.

Novel characteristics

TSS/360 was one of the first implementations of tightly coupled symmetric multiprocessing. A pair of Model 67 mainframes shared a common physical memory space, and ran a single copy of the kernel (and application) code. An I/O operation launched by one processor could end and cause an interrupt in the other. The Model 67 used a standard 360 instruction called Test and Set to implement locks on code critical sections.

It also implemented virtual memory and virtual machines using position-independent code.

TSS/360 included an early implementation of a "Table Driven Scheduler" – a user-configured table whose columns were parameters such as current priority, working set size, and number of timeslices used to date. The kernel would refer to this table when calculating the new priority of a thread. This later appeared in systems as diverse as Honeywell CP-V and IBM z/OS.

As was standard with operating system software at the time, TSS/360 customers (such as General Motors Research Laboratories) were given full access to the entire source of the operating system code and development tools. User-developed improvements and patches were frequently incorporated into the official source code.

User interface

TSS provides users a command-line interface. Users interact with the command system. The command format consists of Command_Name. The command name is one to eight characters without imbedded blanks. The operands are optional depending on the command, and must be separated from the command name by at least one blank. Multiple operands should be separated by TAB characters or commas. Command lines can be continued by typing a hyphen ("-") at the end of the line to be continued and typing the continuation at the beginning of the next line. Multiple commands can be written on a line by separating them with semicolons (";"). Comments are allowed in command lines, separated from the command with a semicolon and included in single quotes ("'"). Operands can be either positional or keyword, with the format "keyword=value".

System commands are divided into seven categories:

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

Position-independent code

TSS provided an early implementation of position-independent code, the ability to have different processes run a single copy of an executable possibly mapped to a different virtual addresses in each process.

Each procedure may have a read-only public CSECT, a writable private Prototype Section (PSECT) and a writable save area, typically located in the PSECT. Address constants of external procedures and entry points must be located in the PSECT, since the dynamic loader will not place a routine at the same virtual address in every process. A program that follows Type I linkage conventions is generally responsible at entry for saving its registers in the save area pointed to by register 13, retrieving the address of its PSECT from word 19 of the save area, chaining the save area to a new save area and putting the address of the new save area in register 13. A caller that follows Type I linkage conventions loads a V-constant for the routine into General Register 15 (GR15) and copies an R-constant for the routine's PSECT into the 19th word of the save area pointed to be GR13 prior to calling that routines.

When the dynamic loader loads a program, it makes a copy of the PSECT and relocates the adcons to reflect the virtual addresses assigned within the current process, therefore each user of the program has a unique copy of the PSECT.

The Dynamic Loader does not load program pages or resolve address constants until the first page fault.

Criticism

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2020) (Learn how and when to remove this message)

TSS/360 suffered from performance and reliability problems and lack of compatibility with OS/360, although those issues were eventually addressed. IBM attempted to develop TSS on a very aggressive schedule with a large staff of programmers to compete with Multics. By 1967, it had become evident that TSS/360 was suffering from the same kinds of delays as OS/360. In February 1968, at the time of SHARE 30, there were eighteen S/360-67 sites attempting to run TSS. During the conference, IBM announced via "blue letter" that TSS/360 was being decommitted – a great blow to the time-sharing community. This decision was temporarily reversed, and TSS/360 was not officially canceled until 1971. However, TSS/360 continued to be quietly available for a time to existing TSS/360 customers, as an interim measure.

After TSS/360 was canceled, IBM put its primary efforts into the Time Sharing Option (TSO), a time-sharing monitor for OS/360. Several other groups developed less ambitious, more successful time sharing systems for the S/360-67, notably CP-67 at IBM's Cambridge Scientific Center, an early virtual machine monitor which evolved into VM/370, MTS at the University of Michigan, and ORVYL at Stanford University. IBM also provided the TSS/370 PRPQ as a migration path for existing TSS/360 customers, which went through multiple releases.

See also

References

  1. Felton, W. A.; Miller, G. L.; Milner, J. M. (October 1984). "The UNIX System : A UNIX System Implementation for System/370". AT&T Bell Laboratories Technical Journal. 63 (8): 1751–1767. doi:10.1002/j.1538-7305.1984.tb00063.x. S2CID 7425099.
  2. C. Gordon Bell; J. Craig Mudge; John E. McNamara (12 May 2014). Computer Engineering: A DEC View of Hardware Systems Design. Elsevier Science. p. 180. ISBN 978-1-4832-2110-6. TSS/8 was designed at Carnegie-Mellon University with graduate student Adrian van de Goor, in reaction to the cost, performance, reliability, and complexity of IBM's TSS/360 (for their Model 67). Although the TSS/360 was not marketed, it eventually worked and contributed some ideas and trained thousands for IBM. At Carnegie-Mellon (CMU), a TSS/8 operated until 1974 when the special swapping disk expired. The cost per user or per job tended to be about 1/20 of the TSS/360 system CMU ran.
  3. Levine, John R. (2000) . "Chapter 8: Loading and overlays". Linkers and Loaders. The Morgan Kaufmann Series in Software Engineering and Programming (1 ed.). San Francisco, USA: Morgan Kaufmann. ISBN 1-55860-496-0. OCLC 42413382. ISBN 978-1-55860-496-4. Code: Errata:
  4. IBM Corporation (August 1976). Time Sharing System Command System User's Guide (GC28-2001-9) (PDF). Retrieved May 2, 2015.
  5. IBM System/360 Time Sharing System Dynamic Loader (PDF) (Fourth ed.). September 1971. GY28-2031-3.
  6. IBM Corporation (April 1976). IBM Time Sharing System Assembler Programmer's Guide (GC28-2032-6) (PDF). pp. 132–147. Retrieved December 25, 2021.
  7. IBM Corporation (1966). IBM System/360 Model 67 Time Sharing System Preliminary Technical Summary (C20-1647-0) (PDF). pp. 47–50. Retrieved December 25, 2021.

Further reading

External links

Operating systems by IBM
Supercomputer
Server, mainframe
Desktop, workstation
Point of sale
Projects
Related
Category
Time-sharing operating systems
Categories: