DOS/360 and successors
| Company type | Operating system |
|---|---|
| Industry | Computer software |
| Founded | 1964 |
| Founder | IBM |
| Headquarters | Armonk , United States |
Area served | Worldwide |
| Products | DOS/360 and its variants (BOS/360, TOS/360, DOS/VS, DOS/VSE, VSE/AF, SSX/VSE, VSE/SP, VSE/ESA, z/VSE) |
| Owner | IBM |
| Website | www |
Disk Operating System/360, commonly known as DOS/360, was the inaugural operating system in a family designed for IBM System/360, System/370, and subsequent mainframe computers. Introduced by IBM at the close of 1964 and first released in June 1966, DOS/360 became the most extensively utilized operating system worldwide during its time.
BOS/360
The Basic Operating System (BOS) represented an early variant of DOS and TOS, capable of running on machines equipped with as little as 8 KB of main memory and a single 2311 disk drive.
TOS/360
TOS/360 (Tape Operating System/360) was an IBM operating system tailored for the System/360, primarily supporting the Model 30 around 1965. Focused on tape drive usage, TOS shared considerable portions of its code and documentation with DOS/360.
Before being phased out, TOS underwent fourteen releases. Its discontinuation coincided with the increased affordability of disk drives such as the IBM 2311 and IBM 2314 within the System/360 lineup, which gradually replaced the previously expensive tape-based storage systems used on earlier machines like the IBM 7090.
DOS/360
Serving as the main operating system for many small to medium-sized IBM System/360 installations, DOS/360 was widely adopted across various environments.
DOS/VS
Introduced in 1972 as an enhancement to DOS/360 under the label "Release 28," DOS/VS incorporated virtual memory capabilities tailored for the new System/370 architecture. It employed a fixed page table mechanism to manage a single address space up to 16 megabytes shared among all partitions.
DOS/VS increased concurrent partition support from three (Background, Foreground 1, Foreground 2) to five (Background plus Foreground 1 through Foreground 4), enabling up to fifteen subtasks simultaneously across the system. This version was eventually succeeded by DOS/VSE and later by z/VSE.
DOS/VSE
Launched in 1979, DOS/VSE built upon DOS/VS by extending support to IBM 4300 series processors. These processors featured ECPS:VSE technology, which allowed single-level storage integration for both CPUs and I/O channels. While DOS/VSE took advantage of ECPS:VSE when available, it also operated on System/370 systems lacking this feature. Notably, VSE marked the final freely distributed iteration of DOS.
VSE/AF
The VSE/Advanced Functions (VSE/AF) release in 1983 enhanced DOS/VSE by adding broader device compatibility and improved functionality. Many organizations implemented VSE/AF together with utilities such as VSE System Installation Productivity Option/Extended (VSE System IPO/E), which combined DOS/VSE, VSE/AF, and additional components to streamline system operations.
SSX/VSE
IBM's 1982 initiative, SSX/VSE ("Small System Executive"), aimed to simplify procurement and installation by packaging VSE with widely used products. This offering included a bundle of fourteen elements like Advanced Functions/VSE, VSE/POWER, ACF/VTAME, CICS/DOS/VS, among others. Initially available only through individual RPQ requests, these products were later added to IBM's price list following pressure from independent software vendors concerned about competitive fairness.
VSE/SP
In 1986, IBM introduced VSE/SP ("System Product") concurrently with the launch of 9370 processors. Replacing SSX/VSE, VSE/SP combined VSE with essential software such as VSE/AF, ACF/VTAM, CICS, and POWER/VS. Despite customer interest in XA (31-bit) addressing support, VSE/SP maintained compatibility only with 24-bit addressing.
VSE/ESA
Introduced in 1990, VSE/ESA brought forth a 31-bit DOS/VSE variant capable of handling up to 384 MB of real memory. It supported as many as twelve static partitions and enabled VSE/POWER along with ACF/VTAM to operate within private address spaces. Additionally, the introduction of dynamic partitions allowed for running up to 150 simultaneous jobs, each in its own distinct address space. The initial version functioned in ESA or 370 mode, offering limited support for XA hardware; the 1995 release of Version 2 operated exclusively in ESA mode on ESA-compatible hardware. Version 2 also incorporated multiprocessing through the Turbo Dispatcher, permitting partitions to execute concurrently across multiple processors. Although designed to accommodate up to ten processors theoretically, practical implementations generally limit this to four processors, with each partition assigned to a single processor at any given time—primarily facilitating multitasking. These multiprocessing constraints remain in place within the most recent z/VSE editions.
z/VSE
IBM launched z/VSE 3.1 in 2005, aligning the product with the "System z" mainframe branding while maintaining the architectural framework of VSE/ESA 2.7 without significant modifications. This version ran solely in 31-bit mode even on hardware capable of 64-bit processing. The 2007 release of z/VSE 4.1 introduced support for 64-bit real addressing, expanding physical memory capacity up to 8 GB; however, applications continued to utilize only 31-bit virtual address spaces. By 2011, it was estimated that approximately 4,000 installations worldwide were using z/VSE.
History
IBM originally intended to develop a unified operating system, OS/360, for its System/360 hardware family, but unforeseen delays necessitated the rapid creation of four separate alternatives:
- BPS/360 for machines with at least 8 KB of memory and a punched card reader,
- BOS/360 for systems equipped with at least 8 KB of memory and a disk drive,
- DOS/360 for configurations featuring at least 16 KB of memory and a disk drive,
- TOS/360 for systems having at least 16 KB of memory and tape drive support.
While OS/360 required a minimum of 64 KB memory at launch, DOS/360 could operate on as little as 16 KB, making it suitable for entry-level models such as the S/360 model 30. Initially designed as a single-tasking system without multitasking capabilities, DOS/360 later evolved to support multitasking with up to three memory partitions, each demanding at least 32 KB. Despite these constraints, DOS/360 became the most prevalent operating system for processors with less than 256 KB memory due to strong System/360 sales and its appropriateness for mid-sized enterprises.
DOS/360 served as an interim solution bridging the availability gap between System/360 hardware and OS/360 software readiness. Customers invested heavily in DOS environments and were reluctant to transition when OS/360 was finally released, compelling IBM to maintain support for DOS/360 alongside OS/360. Contrary to some assertions, GECOS was not derived from DOS/360; however, Xerox Operating System (XOS) was architected similarly to facilitate easier porting of programs.
Hardware requirements
DOS/360 mandated a System/360 CPU (model 25 or higher) with the standard instruction set; decimal and floating-point instruction sets were optional enhancements. The minimum required memory was 16 KB; storage protection features were necessary only when employing multiprogramming. Essential peripheral devices included an 1052 Model 7 printer-keyboard console, a selector or multiplexor channel, and at least one disk drive—initially an 2311 offering 7.25 MB capacity. Typically included were a card reader, card punch, and line printer; magnetic tape drives could be used as alternatives.
A representative configuration might consist of an S/360 model 30 equipped with 32 KB memory and decimal instruction set support; an IBM 2540 card reader/punch; an IBM 1403 printer; two or three IBM 2311 disk drives; two IBM 2415 magnetic tape drives; along with the standard 1052-7 console unit.
Technical details
Unless otherwise specified, the following information pertains to DOS/360; subsequent versions introduced additional capabilities.
Crafted for entry-level System/360 machines, DOS/360 emphasized conserving memory resources. The DOS supervisor, the core resident segment of the operating system, could be as compact as 5902 bytes. Memory allocation tables for system generation (sysgen) frequently indicated requirements as low as 100 bytes. A minimal configuration allocated slightly more than 10 KB for a single batch partition, adequate to run utilities and most compilers except for COBOL, PL/I, and the complete FORTRAN IV compiler. To achieve a reduced memory footprint, the entire DOS was implemented in assembly language.
Transients
As detailed in The Mythical Man-Month, DOS/360 utilized overlay modules known as transients, which were loaded into two dedicated transient regions to conserve memory usage:
- Physical transients resided in the 556-byte A-Transient area and were responsible for managing hardware error processing (ERPs), logging error information (OBR/MDR) onto IJSYSRC, and delivering messages. All modules in the A-Transient group started with .
- Logical transients occupied the 1200-byte B-Transient area and provided shared services such as OPEN and CLOSE functions for LIOCS. Every B-Transient module began with .
The prefixes and ensured these modules were positioned at the forefront of the directory to facilitate rapid loading.
With DOS/VS, Machine Check and Channel Check Handlers were introduced as additional transients prefixed with , executing within the Recovery Transient area. This development improved reliability, availability, and serviceability (RAS) for the System/370. Prior to this, machine checks would cause immediate program termination, while channel checks ended the execution of the program accessing the device when the error occurred.
Multiprogramming
Early versions of DOS, similar to OS/360, supported only single-task operation. Subsequent "real" DOS editions enabled running up to three simultaneous programs in distinct memory partitions—BG (background), F1 (foreground 1), and F2 (foreground 2)—utilizing OS/360's hardware memory protection features. Multiprogramming was an optional feature in DOS/360, selectable during system generation. An additional SYSGEN option allowed batch processing in either foreground partition; otherwise, foreground tasks had to be manually initiated by the computer operator.
DOS/VS further extended this capability to support up to seven concurrent programs, although practical limits often restricted this to five or six due to hardware constraints. Both DOS and DOS/VS permitted users to configure the number of partitions during IPL (boot).
Program libraries
Executable code was maintained within a Core Image Library (CIL). Since DOS lacked mechanisms to reclaim space after program deletion or updates, filling the CIL necessitated compression through utility programs—an operation that frequently interrupted development activities. Many organizations would suspend modifications for a day, perform offline compression of the CIL, and then IPL with the refreshed library at business commencement. Additionally, DOS supported relocatable libraries containing linkable object modules and source statement libraries holding assembler macros and include text. Sites could also define supplementary private relocatable and source libraries on separate disk volumes.
Utilities
DOS/360 offered a suite of utility programs alongside an Assembler and compilers for FORTRAN, COBOL, and later PL/I. It accommodated various file structures with distinct access methods:
- Sequential data sets processed records in a linear fashion, reading or writing one block after another from beginning to end.
- Indexed files (ISAM) utilized key fields embedded in records to enable targeted retrievals.
- Direct access files (BDAM) required specifying exact physical disk locations; despite its complexity, BDAM was the most rapid disk access approach and gained widespread adoption among software providers, particularly database management systems such as ADABAS, IDMS, IBM's DBOMP, and DL/I.
Both sequential and ISAM file types supported records of fixed or variable length and could extend across several disk volumes.
Telecommunications
Included with DOS/360 were the Basic Telecommunications Access Method (BTAM) and the Queued Telecommunications Access Method (QTAM). While BTAM was considered rudimentary by later measures, it allowed connectivity with virtually any terminal, a significant benefit during an era lacking standardized communication protocols. Its straightforward API also enabled integration with external communications processors, making DOS/360 systems effective nodes within extensive organizational networks. QTAM operated on a higher logical plane using OPEN/CLOSE/GET/PUT macros, minimizing the necessity for device-specific expertise.
Job control
Job control statements in DOS began with a blank space in columns one and two, except for special cases such as end-of-job ("/&"), end-of-data ("/*"), and comments ("//*"). (Note: "" represents a single space.)
- The statement indicates the commencement of job control directives. Its format is: <syntaxhighlight lang="jcl" inline>// JOB <jobname> <comments></syntaxhighlight>. The consists of 1 to 8 alphanumeric characters; any following text is disregarded.
- The statement defines the program executed as a job step. Format: <syntaxhighlight lang="jcl" inline>// EXEC <program></syntaxhighlight>.
- The statement permits operator interaction between job steps. Format: <syntaxhighlight lang="jcl" inline>// PAUSE <comment></syntaxhighlight>.
- The statement sends messages intended for the operator. Format: .
- The end of data statement signifies the conclusion of input data. Format: <syntaxhighlight lang="jcl" inline>/*</syntaxhighlight>.
- The end of job statement denotes job termination and can trigger data flushing in case of abnormal ends. Format: <syntaxhighlight lang="jcl" inline>/&</syntaxhighlight>.
- The statement configures system options applicable to the job. Format: <syntaxhighlight lang="jcl" inline>// OPTION <option1>[,<option2>...]</syntaxhighlight>.
- The statement maps logical I/O units to physical devices. Format: <syntaxhighlight lang="jcl" inline>// ASSGN SYSxxx,<device>[,<tape option>]</syntaxhighlight>. Devices may be specified as physical addresses ("X'cuu'"), ignored ("IGN"), or unassigned ("UA"). Tape options define mode settings or use "ALT" for alternate device selection.
- The statement resets I/O assignments back to default configurations. Format: <syntaxhighlight lang="jcl" inline>// RESET <option></syntaxhighlight>, where options include "SYS", "PROG", "ALL", or specific units such as "SYS002".
- The statement lists active I/O assignments. Format: <syntaxhighlight lang="jcl" inline>// LISTIO <option></syntaxhighlight>, supporting parameters like "SYS", "PROG", "ALL", individual units, or device status queries.
- The statement issues control commands to magnetic tape devices (e.g., forward space, rewind). Format: <syntaxhighlight lang="jcl" inline>// MTC <opcode>,SYSxxx[,<nn>]</syntaxhighlight>.
- The statement provides volume label details used in disk or tape label verification. Format: <syntaxhighlight lang="jcl" inline>// VOL SYSxxx,<volume></syntaxhighlight>.
- Tape and disk labeling directives evolved from earlier statements such as , , and to more advanced forms like and , offering precise positional parameters for label handling and extent management.
Job control language
The DOS JCL emphasized rapid parsing and straightforwardness, resulting in a positional syntax that was more obscure compared to the keyword-based job control used in OS/360.
Spooling
Initially, DOS did not include a spooling system to optimize punched card and line printer input/output operations. By the late 1960s, this limitation was addressed by IBM and other vendors. IBM introduced the optional Priority Output Writers, Execution processors, and input Readers (POWER) spooler, while Software Design, Inc. provided the GRASP spooler solution.
Program loading
DOS/360 lacked a relocating loader, which meant that programmers had to link edit distinct executable files for every partition or memory address space. Although assembler programs could be designed as self-relocating, this approach involved added complexity and slight increases in program size. In extensive DOS setups, custom relocating loaders were frequently developed to simplify this procedure.
Application programming interface
The DOS/360 application programming interface was not compatible with that of OS/360. Programs written in high-level languages required recompilation and relinking to operate on OS/360, sometimes necessitating code modifications due to differences in compilers. Transitioning software from OS/360 to DOS proved more challenging because OS/360 supported a broader range of API functions that needed to be removed for DOS compatibility. This issue was less severe for languages such as COBOL, but Assembler programs often demanded substantial revisions.