DOS/360 and successors

History

When developing a new hardware generation of unified System/360 (or S/360) computers, IBM had originally committed to delivering a single operating system, OS/360, also compatible with low-end machines; but hardware was already available and the OS/360 project fell further and further behind schedule, as described at length by Fred Brooks in The Mythical Man-Month. IBM was forced to quickly develop four additional, closely-related, systems:

• BPS/360 for machines with at least 8 KB of core memory and a punched card reader,
• BOS/360 for machines with at least 8 KB memory and a disk drive,
• DOS/360 for machines with at least 16 KB memory and a disk drive,
• TOS/360 for machines with at least 16 KB memory and a tape drive.

When OS/360 was finally released, a year late, it required at least 64 KB of memory. DOS was designed to use little memory, and could run on 16 KB machines, a configuration available on the low-end S/360 model 30. Unlike OS/360, DOS/360 was initially a single-job system which did not support multitasking. A version with multitasking, supporting up to three memory partitions, requiring 32 KB of memory was later released. Despite its limitations, DOS/360 became the most widely used operating system for processors with less than 256 KB of memory because: System/360 hardware sold very well; DOS/360 ran well on System/360 processors which medium-sized organizations could afford; and it was better than the "operating systems" these customers had before.

DOS/360 was the operating system which filled the time gap between the announcement of the System/360 and the availability of the intended operating system, OS/360. As a result of the delay, a number of customers implemented DOS systems and committed significant investments to run them. IBM expected that DOS/360 users would soon upgrade to OS/360, but as a result of those investments, they were reluctant to commit to such conversion. IBM then needed to continue to offer DOS/360 as an additional operating system. The Hacker's Jargon File incorrectly states that GECOS (also known as GCOS) was copied from DOS/360, which was not the case, however the Xerox Data Systems Xerox Operating System (XOS) was intentionally similar to DOS to simplify program porting.

Hardware requirements

DOS/360 required a System/360 CPU (model 25 and above) with the standard instruction set (decimal and floating-point instruction sets optional). The minimum memory requirement was 16 KB; storage protection was required only if multiprogramming was used. A 1052 Model 7 printer-keyboard, either a selector or multiplexor channel, and at least one disk drive was required — initially a 2311 holding 7.25 MB. A card reader, card punch and line printer were usually included, but magnetic tape drives could be substituted.

A typical configuration might consist of a S/360 model 30 with 32KB memory and the decimal instruction set, an IBM 2540 card reader/card punch, an IBM 1403 printer, two or three IBM 2311 disks, two IBM 2415 magnetic tape drives, and the 1052-7 console.

Technical details

The following description applies to DOS/360 except as otherwise noted. Later versions offer additional functionality.

Because DOS/360 was designed to run on low-end models of System/360 memory usage was a concern. It was possible to generate a DOS supervisor, the resident portion of the operating system, as small as 5902 bytes. Detailed charts listed memory requirements for each sysgen option, often as little as 100 bytes. A minimum system would leave just over 10 KB of storage available for a single batch partition which was enough to run utilities and all compilers except COBOL, PL/I, and full FORTRAN IV. To keep memory usage as small as possible, DOS was coded entirely in assembly language.

Transients

The concept of transient area is part of Mythical Man-Month's discussion on design and the use of main memory. 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.

Multiprogramming

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. 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.

Program libraries

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.

Utilities

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.

Telecommunications

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.

Job control

All DOS job control statements began with "//" in card columns one and two except end-of-job which was "/&␢", end-of-data, "/*␢", and comments, "*␢". (In the description that follows the character "␢" represents a single blank.)

• The JOB statement indicates "the beginning of control information for a job." The format is // JOB <jobname> <comments>. <jobname> must be one to eight alphanumeric characters to identify the job. <comments> are ignored.
• The EXEC statement identifies a program to be executed as a job step. "All control statements necessary for execution must be processed" before the EXEC statement is read. The format is // EXEC <program>
• The PAUSE statement "can be used to allow for operator action between job steps." The format is // PAUSE <comment>. The comment is used to provide a message to the operator.
• The comments statement may be used to display a message to the operator. The format is * <comment>.
• The end of data statement marks the end of data in the input stream. The format is /*. Any data on the statement following the blank is ignored.
• The end of job statement marks the end of a job, and may indicate the end of data to be flushed if the job terminates abnormally. The format is /&. Any data on the statement following the blank is ignored.
• The OPTION statement specifies values of system options that apply to this job. The format is // OPTION <option1>[,<option2>...].
• The ASSGN statement "is used to assign a logical I/O unit to a physical device." The format is // ASSGN SYSxxx,<device>[,<tape option>]. SYSxxx indicates a logical unit such as SYS001 or SYSIPT. <device> is either "X'cuu'" to indicate a physical device (channel and unit), "IGN" for ignore, or "UA" for unassigned. <tape option> specifies either tape mode settings such as density, parity, etc., or "ALT" to indicate an alternate device.
• The RESET statement resets specified I/O unit assignments to their permanent values. The format is // RESET <option>. <option> may be "SYS" to reset all system logical unit assignments, "PROG" to reset all programmer assignments, "ALL" to reset all assignments, or "SYSxxx" to reset the assignment for the logical unit "SYSxxx", for example SYS002.
• The LISTIO statement instructs the system to print a listing of all specified I/O assignments currently in effect. The format is // LISTIO <option>. <option> is "SYS" to list all system assignments, "PROG", "F1", or "F2" to list all assignments for the background or specified foreground partition, "ALL", "SYSxxx", "X'cuu'", "UNITS" to list all assigned units, 'UA" to list all unassigned units, or "DOWN" to list all units marked as inoperative.
• The MTC statement issues command to a magnetic tape unit. The format is // MTC <opcode>,SYSxxx[,<nn>]. <opcode> is a function such as "FSF" to forward space one file or "REW" to rewind the tape. <nn> is a number that can specify the number of times the operation is to be performed, such as forward space two files.
• The VOL statement provides disk or tape volume label information for standard label checking. The format is // VOL SYSxxx,<volume>.
• DOS originally provided the TPLAB statement for tape label information and the DLAB and XTENT statements for disk label and extent information. At least as early as 1968 the TPLAB statement had been replaced by TLBL and the DLAB statement by DLBL . These statements used numerous positional parameters and had fairly high information densities.

Differences from OS/360

Job control language

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

Spooling

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 Priority Output Writers, Execution processors and input Readers (POWER), and Software Design, Inc., an independent software company, sold a spooler called GRASP.

Program loading

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.

Application programming interface

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.