Editing DOS/360 and successors (section)

==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.<ref name=sysgen/>{{rp|p.297}}  Detailed charts listed memory requirements for each [[sysgen]] option, often as little as 100 bytes.  A minimum system would leave just over 10&nbsp;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#FORTRAN IV|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 [[The Mythical Man-Month|Mythical Man-Month]]'s discussion on design and the use of main memory.<ref>{{cite book
   |title=The Mythical Man-Month |year=1975 |page=101
   |author=F. P. Brooks |publisher=Addison-Wesley Publishing Company |isbn=0-201-00650-2}}</ref> 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 {{mono|$$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 {{mono|$$B}}.

The use of {{mono|$$A}} and {{mono|$$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 {{mono|$$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&nbsp;1'') and F2 (''foreground&nbsp;2'').  Multiprogramming was an optional feature of DOS/360, selectable at [[system generation]].<ref name=sysgen>{{cite book|last=IBM Corporation|title=IBM System/360 Disk Operating System: System Generation and Maintenance|year=1969|url=http://www.bitsavers.org/pdf/ibm/360/dos/C24-5033-7_Disk_Operating_System_System_Generation_and_Maintenance_Apr69.pdf}}</ref>{{rp|p.34}}  A later SYSGEN option allowed [[Batch processing|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 [[Initial Program Load#IBM Initial Program Load|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 program]]s, an [[Assembly language|Assembler]], and [[compiler]]s for [[FORTRAN]], [[COBOL]] and eventually [[PL/I]], and it supported a range of file organizations with [[access method]]s 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 ([[basic direct access method|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 system]]s such as [[ADABAS]], [[IDMS]] and IBM's [[DBOMP]] and [[Data Language Interface|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.