OS 2200
OS 2200 is the operating system for the Unisys ClearPath Dorado family of mainframe systems. The operating system kernel of OS 2200 is a lineal descendant of Exec 8 for the UNIVAC 1108 and was previously known as OS 1100.
Documentation and other information on current and past Unisys systems can be found on the Unisys public support website.
See Unisys 2200 Series system architecture for a description of the machine architecture and its relationship to the OS 2200 operating system. Unisys stopped producing ClearPath Dorado hardware in the early 2010s, and the operating system is now run under emulation.
History
There were earlier 1100 systems going back to the 1101 in 1951, but the 1108 was the first 1100 Series computer designed for efficient support of multiprogramming and multiprocessing. Along with this new hardware came the operating system Exec 8.The UNIVAC 1108 computer was announced in 1964 and delivered in late 1965. The first 1108 computers used Exec I and Exec II, which had been developed for the UNIVAC 1107. However, UNIVAC planned to offer symmetric multiprocessor versions of the 1108 with up to 4 processors and the earlier operating systems weren't designed for that, even though they supported limited multiprogramming.
When the UNIVAC 1110 was introduced in 1972, the operating system name was changed to OS 1100 to reflect its support for the wider range of systems. The name OS 1100 was retained until 1988 with the introduction of the Sperry 2200 Series as a follow on to the 1100 Series when its name was changed to OS 2200. Since that time, the 2200 Series became the Unisys ClearPath IX Series and then the Unisys ClearPath Dorado Series, but the operating system retained the OS 2200 name.
The company name and its product names also changed over time. Engineering Research Associates of Saint Paul was acquired by Remington Rand Corporation. Remington Rand also acquired the Eckert–Mauchly Computer Corporation of Philadelphia which was then building the UNIVAC computer. The two were combined into the UNIVAC division of Remington Rand under the direction of William Norris. William Norris had been one of the founders of ERA and later left Remington Rand to start Control Data Corporation. The UNIVAC division of Remington Rand Corporation became the UNIVAC division of Sperry Rand Corporation after Remington Rand merged with Sperry Corporation. In the 1970s Sperry Rand began a corporate identity program that changed its name to Sperry Corporation and all the division names to begin with Sperry, so the computer systems division became Sperry UNIVAC. Later the division names were dropped and everything simply became Sperry.
The operating system kernel is still referred to as "the Exec" by most Unisys and customer personnel. However, when Unisys began releasing suites of products tested together as system base releases, later called "ClearPath OS 2200 Release n", the term OS 2200 changed to refer to the entire suite of products in the system release and others, such as BIS, released asynchronously for the Dorado hardware platforms.
In 1986 Burroughs and Sperry corporations merged to become Unisys. The major mainframe product lines of both companies have continued in development including the MCP Operating System from Burroughs and OS 2200 from Sperry.
In 2016 Unisys made a virtual Microsoft Windows version of OS2200 available at no cost for educational and leisure purposes.
Exec 8
EXEC 8 was UNIVAC's operating system developed for the UNIVAC 1108 in 1964. It combined the best features of the earlier operating systems, EXEC I and EXEC II, which were used on the UNIVAC 1107. EXEC 8 was one of the first commercially successful multiprocessing operating systems. It supported simultaneous mixed workloads comprising batch, time-sharing and real-time. Its one file system had a flat naming structure across many drums and spindles. It also supported a well-received transaction processing system.Previous systems were all real-mode systems with no hardware support for protection and separation of programs and the operating system. While there had been support for multiprogramming in previous systems, it was limited to running one user job concurrently with multiple supporting functions known to be well-behaved, such as the card reader, printer, and card punch spoolers.
The Exec 8 operating system was designed from the very beginning to be a multiprogramming and multiprocessing operating system because the 1108 was designed to have up to four CPUs. Memory and mass storage were the primary system constraints. While the 1100 Series was envisioned as targeting a more general market, extreme real time processing was a primary requirement.
The specifications for Exec 8 were drawn up by December 1964 as a preliminary Programmers Reference Manual and work began in May 1965.
Exec 8 began as a real time operating system with early use mostly in general scientific and engineering work, but it was also used in message switching, process control, simulation, and missile firing control. It was designed to run on systems that often had only 128K words, and was focused on real time and batch processing. While the earliest release levels did work in 128KW, increasing functionality in later releases made that untenable, since it didn't leave enough space for programs of useful size. The maximum memory capacity of an 1108 was 256KW so efficient use of memory was the most important constraint since core memory was the most expensive part of the system.
Mass storage consisted of 6-foot long rotating drums that held 256KW to 2MW. The highest capacity mass storage was the FASTRAND drum, which held 22 MW. File fragmentation was dealt with by a process called a "file save", which was generally done once per day, at night. It involved rolling all files out to tape, reinitializing the drum file system, then reading the files back in.
With severe memory constraints and real time use, keeping only a single copy of code loaded into core was a requirement. Since the 1108 was designed for multitasking, the system was fully "reentrant". Each reentrant module accessed program data through a single memory "base address", which was different for each instance of run data. Switching execution contexts could be done in a single instruction merely by setting a different base address in a single register. The system used fine-grained locking to protect shared data structures. The executive, compilers, utilities, and even sophisticated user applications that might have multiple copies running concurrently were written so that their code could be shared. This required loading only one copy into memory, saving both space and the time it took to load the code.
Another reason to separate code and data into different load entities was that memory was implemented as two independent banks called IBANK and DBANK. Each had its own access path, so the CPU could read both banks simultaneously. By loading executable code into one memory bank and data into the other, the run time of many programs could be almost halved.
Re-entrant code had to be thread safe ; self-modifying code was not allowed. For other programs, modifying executable code during runtime was still an acceptable programming technique in the time of 1100-series computers, but users were encouraged not to do it because of the performance hit. Security benefits were touted but not highly valued because hacking most 1100-series applications would provide no benefit to anyone, and because few hackers were malevolent then.
Exec 8 was primarily a batch processing system that gave applications very fine control of CPU scheduling priority for its threads. Processor switching was preemptive, with higher priority threads gaining control of the processor currently running the lowest priority thread of any program. Except in realtime systems, even the lowest priority tasks got some processor time. It was a multiprogramming and multiprocessing operating system with fully symmetric processor management. A test-and-set instruction built into the hardware allowed very efficient and fine-grained locking both within the OS and within multi-threaded applications.
In Exec 8, work is organized into jobs, called "runs," which are scheduled based on their priority and need for lockable resources such as Uniservo tape drives or Fastrand drum files. The control language syntax uses the "@" symbol as the control statement recognition symbol. It was immediately followed by the command or program name, then a comma and any option switches. After a space character, the remainder of the statement differed for particular commands. A command to compile a FORTRAN program would look like "@FOR sourcefile, objectfile". Input data for an application could be read from a file, or immediately follow the @ command in the run stream. All lines until the sentinel command "@END" were assumed to be input data, so forgetting to insert it led to the compiler interpreting subsequent commands as program data. For this reason, it was preferable to process data in files rather than inputting it in the run stream.
In 1968, work began on adding time-sharing capability to Exec 8. It was delivered with level 23 of the executive in 1969. Time sharing had the same capabilities as batch and real time processes. Everything that could be done in batch could be done from an ASCII terminal. In [|demand] mode, job stream I/O was attached to a terminal handler rather than card image and spool files. The same run control language was used for both. A few years later, more specific time sharing commands were added, and some control statements could be issued asynchronously for immediate processing, even when neither the executive or the running program were expecting data. Those commands, which could be entered only from a terminal, began with "@@". Because they could be performed without stopping other work in progress from the same terminal, they were called transparent commands. At first these were just statements to kill the current program or redirect terminal output to a file, but eventually, almost all control statements were allowed to be "immediate."
Both batch and demand runs terminate with an @FIN statement, and if a demand user terminates his session while his run is active, the Exec automatically terminates the run without requiring @FIN.