Input/Output Supervisor

IOS has two purposes:

• To handle I/O requests, which are requests for the execution of channel programs
• To handle I/O interruptions, which result from the execution of channel programs and from operator intervention

To facilitate the handling of the I/O requests and interruptions, IOS is divided into two primary program sections (CSECTs):

• Execute channel program supervisor (EXCP in PCP, MFT/MFT-II and MVT; EXCP/EXCPVR, in SVS; STARTIO in MVS/370 and later instances of the OS)
• Input/output interruption supervisor

These primary sections are resident in main storage and provide control program support for the normal execution of channel programs.

The secondary program sections (also CSECTs), termed Error Recovery Procedures (ERPs), are, with but one exception, located on external storage, and are brought into main storage for recovery from the abnormal execution of channel programs. In the early instances of the OS, these sections were brought into the Input/Output Supervisor's "transient area", not unlike the OS/360 Control Program's Supervisor Call "transient areas". In post-MVT instances of the OS, these sections are located in the pageable linkpack area (PLPA) and are demand-paged.

The sole exception is, of course, the ERP for direct access storage devices, which must always remain resident in order to recover from possible I/O errors on the IPL volume and on other volumes which contain datasets which may be concatenated with certain system datasets.

IOS is designed around a multi-programming concept whereby operations on different I/O channels, control units and devices may be managed concurrently and apparently simultaneously. This concurrency and apparent simultaneity is present even in the most basic version of the OS, PCP, which otherwise supports only one user task, as the underlying hardware architecture has but one set of I/O instructions and but one I/O interruption, for accessing the devices and for accessing the resulting device status, respectively, available to support all attached I/O devices, hence all I/O device operations must be synchronously multiplexed in to the half-dozen privileged I/O instructions and asynchronously de-multiplexed out from the single I/O interruption by IOS[NB 1] yet this entire process, from start to finish, is made to appear to be synchronous to the application. Essentially, IOS is a hypervising operating system built on top of the OS itself, and entirely within it, not as a separable function. A very specialized hypervisor, to be sure, as the hypervisation is restricted to the several I/O instructions and the one I/O interruption.

In MVS/370 and later instances of the OS, IOS is also designed around a multi-processing concept whereby all available processors, as many as two in MVS/370 and as many as sixteen in later instances of the OS (twelve were supported by IBM; sixteen were supported by Amdahl), are effectively and efficiently utilized. And, to best utilize this multi-processing capability, IOS's multi-programming implementation was partitioned into smaller executable units, in particular those which may be executed under the control of an SRB.

IOS is not invoked directly by the programmer. Rather, IOS is invoked through "branch entries" to start I/O requests and through "interrupt handlers" to complete I/O requests.