DOS/360 and successors

The Basic Operating System(BOS) was an early version of DOS and TOS which could provide usable functionality on a system with as little as 8 KB of main storage and one 2311 disk drive.[3]

TOS/360 (Tape Operating System/360, not a DOS as such and not so called) was an IBM operating system for the System/360, used in the early days around 1965 to support the System/360 Model 30 and similar platforms.

TOS, as per the "Tape" in the name, required a tape drive. It shared most of the code base[4] and some manuals[5][6] with IBM's DOS/360.

TOS went through 14 releases, and was discontinued[7] when disks such as the IBM 2311 and IBM 2314 became more affordable at the time of System/360,[8] whereas they had been an expensive luxury on the IBM 7090.

DOS/360 was the primary operating system for most small to midsize S/360 installations.

DOS/VS was released in 1972. The first DOS/VS release was numbered "Release 28" to signify an incremental upgrade from DOS/360.[9] It added virtual memory in support of the new System/370 series hardware. It used a fixed page table which mapped a single address space of up to 16 megabytes for all partitions combined.

DOS/VS increased the number of partitions (separate simultaneous programs) from three (named Background, Foreground 1 and Foreground 2) to five (BG and F1 through F4) and allowed a system wide total of fifteen subtasks.[10]^{: pp.24–28}

DOS/VS was succeeded by DOS/VSE through z/VSE.

DOS/VSE was introduced in 1979 as an "extended" version of DOS/VS to support the new 4300 processors.[11] The 4300 systems included a feature called ECPS:VSE that provided a single-level storage for both the processor and the I/O channels.[12] DOS/VSE provided support for ECPS:VSE, but could also run on a System/370 without that feature. VSE was the last free version of DOS.

VSE/Advanced Functions[13] (VSE/AF) is a product that adds new device support and functionality to DOS/VSE. Many installations installed VSE/AF using products such as VSE System Installation Productivity Option/Extended (VSE System IPO/E), which combines DOS/VSE, VSE/AF and various other products.

An IBM staffer installing a third-party application running on SSX/VSE, at the IBM Böblingen facility where SSX work was done

SSX/VSE ("Small System Executive") was an attempt by IBM to simplify purchase and installation of VSE by providing a pre-generated system containing the OS and the most popular products.[14] SSX was released in 1982,[15] and later replaced by VSE/SP. SSX was sold by IBM as a bundle of 14 component products (Advanced Functions/VSE, VSE/POWER, ACF/VTAME, VSE/VSAM, CICS/DOS/VS, DOS/VS, Sort/Merge, VSE/ICCF, VSE/OCCF, VSE/IPCS, DOS/COBOL, Back Up/Restore, Space Management, VSE/DITTO), and originally would only agree to offer the individual products separately via RPQ, although IBM later agreed to add those products individually to its price list under pressure from ISVs who claimed that the bundling violated antitrust laws.[16]

In 1986 IBM released VSE/SP ("System Product") in conjunction with the announcement of the 9370 processors. VSE/SP replaced SSX/VSE and bundled VSE with the most popular VSE program products such as VSE/AF, ACF/VTAM, CICS, and POWER/VS.[17] VSE/SP supported only 24-bit addresses, despite customer requests to provide an XA (31 bit) version.

VSE/ESA was a 31-bit DOS/VSE version, which was released in 1990 with support for up to 384 MB of real storage. It provided up to twelve static partitions and allowed VSE/POWER and ACF/VTAM to be run in private address spaces. It introduced a new feature called dynamic partitions which could allow up to 150 concurrent jobs, each in its own address space.[18] Version 1 could run in either ESA or 370 mode, with the ESA mode also supporting XA hardware with limitations. Version 2 (1995) only supported ESA mode with ESA hardware. Version 2 added support for multiprocessing, through the new Turbo Dispatcher, which permits different partitions to execute simultaneously on different processors. A partition can only run on one processor at a time, which mostly limits the multiprocessing to multitasking. Up to ten processors are theoretically supported ("tolerated"), but up to four are effectively utilized.[19][20] Those limits remain in the last z/VSE.[21]

IBM released z/VSE 3.1 in 2005. This change in naming reflected the new "System z" branding for IBM's mainframe product line, but did not represent a fundamental change in architecture from VSE/ESA 2.7 which preceded it. In particular, it did not support the new 64-bit z/Architecture, running only in 31-bit mode even on 64-bit capable machines. z/VSE 4.1 released in 2007 introduced support for 64-bit real addressing, with up to 8 GB of memory. However, while parts of the supervisor run in 64-bit mode, it only provides 31-bit virtual address spaces to problem state applications. As of 2011 one estimate placed the number of sites using z/VSE at around 4,000.[22]

The concept of transient area is part of Mythical Man-Month's discussion on design and the use of main memory.[24] To further reduce memory usage, the supervisor employed overlays called transients that were read into one of two reserved transient areas as required.

• Physical transients were loaded into the 556 byte A-Transient area to handle hardware errors (ERPs), record error-specific data (OBR/MDR) on IJSYSRC, and issue error messages. All A-Transient module names began with $A.
• Logical transients were loaded into the 1200 byte B-Transient area to provide common program services like OPEN and CLOSE for LIOCS. All B-Transient module names began with $B.

The use of $A and $B prefixes ensured rapid loading of transients because their names were stored first in the directory.

DOS/VS added Machine Check and Channel Check Handlers, which were another set of transients all starting with $RAST and executing in the Recovery Transient area. This was done as part of the reliability, availability, and serviceability (RAS) enhancements for the System/370. Before this addition, machine checks caused termination of the program running and channel checks caused termination of the program accessing the device, at the time of the error.

Like OS/360, initial releases of DOS could run only one program at a time. Later versions of "real" DOS were able to run up to three programs concurrently, in separate memory partitions, supported by the same hardware memory protection features of the more scalable OS/360 operating system. These were identified as BG (background), F1 (foreground 1) and F2 (foreground 2). Multiprogramming was an optional feature of DOS/360, selectable at system generation.[23]^: p.34 A later SYSGEN option allowed batch operation run in either FG partition. Otherwise foreground programs had to be manually started by the computer operator.

DOS/VS allowed up to seven concurrent programs, although five or six was a more common number due to the smaller scale of the hardware usually hosting DOS systems. Both DOS and DOS/VS allow the number of partitions to be set at IPL (Initial Program Load), the IBM term for Boot load.

Executable programs were stored in a Core Image Library. While running, DOS could not reclaim space as programs were deleted or replaced with newer versions. When the Core Image Library became full, it had to be compressed by a utility program, and this could halt development work until it was complete. Many shops simply froze changes for a day, compressed the CIL "off-line", and IPLed with the new Core Image Library at the beginning of a business day. A relocatable library for linkable object programs and a source statement library for assembler macros and include text were also supported. Installations could define additional private relocatable and source statement libraries on other disk volumes.

DOS/360 had a set of utility programs, an Assembler, and compilers for FORTRAN, COBOL and eventually PL/I, and it supported a range of file organizations with access methods to help in using them:

• Sequential data sets were only read or written, one record block at a time from beginning to end.
• In indexed (ISAM) files a specified section of each record was defined as a key which could be used to look up specific records.
• In direct access (BDAM) files, the application program had to specify the physical location on the disk of the data it wanted to access. BDAM programming was not easy and most customers never used it themselves; but it was the fastest way to access data on disks and many software companies used it in their products, especially database management systems such as ADABAS, IDMS and IBM's DBOMP and DL/I.

Sequential and ISAM files could store either fixed-length or variable-length records, and all types could occupy more than one disk volume.

DOS/360 offered Basic Telecommunications Access Method (BTAM) and Queued Telecommunications Access Method (QTAM). BTAM was primitive and hard to use by later standards, but it allowed communication with almost any type of terminal, which was a big advantage at a time when there was little standardization of communications protocols. The simplicity of its API also allowed the relatively easy interface of external communications processors, which facilitated DOS/360 machines becoming nodes in the multi-tier networks of large organizations. Conversely, QTAM users did not need as much knowledge about individual devices because QTAM operated at the logical level using the OPEN/CLOSE/GET/PUT macros.

DOS JCL was designed for parsing speed and simplicity; the resulting positional syntax was significantly more cryptic than OS/360 keyword-driven job control.

Early DOS included no spooling sub-system to improve the efficiency of punched card and line printer I/O. By the late 1960s both IBM and aftermarket vendors began filling this void. IBM's spooler was an option called POWER, and Software Design, Inc., an independent software company, sold a spooler called GRASP.

DOS/360 had no relocating loader, so programmers had to link edit a separate executable version of each program for each partition, or address space, in which the program was likely to be run. Alternatively assembler-language programs could be written as self-relocating, but that imposed additional complexity and a size penalty, albeit a small one. Large DOS shops with multiple machines and multiple partition layouts often wrote their own relocating loader to circumvent this issue.

The DOS/360 application programming interface was incompatible with OS/360. High level language programs written for DOS needed to be compiled and linked before they could be used with OS/360. Minor differences between compilers of DOS as opposed to OS sometimes required modifications to programs. The port in the other direction however was more challenging. Since OS/360 had significantly more features supported in its API, any use of those features would have to be removed from programs being ported to DOS. This was less of a problem for programmers working in high level languages such as COBOL. Assembler programs, on the other hand, tended to utilize those very features more often and usually needed greater modification to run on DOS.