In IBM mainframe operating systems OS/360 and its successors, a Unit Control Block (UCB) is a memory structure, or a control block, that describes any single input/output peripheral device (unit), or an exposure (alias), to the operating system. Certain data within the UCB also instructs the Input/Output Supervisor (IOS) to use certain closed subroutines in addition to normal IOS processing for additional physical device control.
Some other operating systems have similar structures.
Overview
During initial program load (IPL) of current MVS systems, the Nucleus Initialization Program (NIP) reads necessary information from the I/O Definition File (IODF) and uses it to build the UCBs. The UCBs are stored in system-owned memory, in the Extended System Queue Area (ESQA). After IPL completes, UCBs are owned by Input/Output Support. Some of the data stored in the UCB are: device type (e.g. disk, tape, printer, terminal), address of the device (such as 1002), subchannel identifier and device number, channel path ID (CHPID) which defines the path to the device, for some devices the volume serial number (VOLSER), and a large amount of other information, including OS Job Management data.
While the contents of the UCB has changed as MVS evolved, the concept has not. It is a representation to the operating system of an external device. Inside every UCB are the UCBIOQ pointer to the current IOS Queue Element (IOQ), UCBIOQF and UCBIOQL pointers to a queue of IOQs (IOQs) and a subchannel number for the subchannel-identification word used in the start subchannel (SSCH) instruction to start a channel program (chain of channel command words (CCWs)).
The UCB evolved to be an anchor to hold information and states about the device. The UCB currently has five areas used for an external interface: Device Class Extension, UCB Common Extension, UCB Prefix Stub, UCB Common Segment and the UCB Device Dependent Segment. Other areas are internal use only. This information can be read and used to determine information about the device.
In the earliest implementations of OS/360, the UCBs (foundations and extensions) were assembled during SYSGEN, and were located within the first 64 KB of the system area, as the I/O device lookup table consisted of 16-bit addresses. Subsequent enhancements allowed the extensions to be above the 64-kilobyte (65,536 bytes) line, thereby saving space for additional UCB foundations below the 64-kilobyte line and also thereby preserving the architecture of the UCB lookup table (converting a CUu to a UCB foundation address). Eventually an installation could choose to place UCBs above the 16 MiB line line, although in a process called shadowing the UCB the OS creates a temporary local copy of the UCB when allocating a file without the XTIOT option.
Handling parallel I/O operations
UCBs were introduced in the 1960s with OS/360. Then a device addressed by UCB was typically a moving head hard disk drive or a tape drive, with no internal cache. Without it, the device was usually grossly outperformed by the mainframe's channel processor. Hence, there was no reason to execute multiple input/output operations to it at the same time, as these would be impossible for a device to physically handle. In 1968, IBM introduced the 2305-1 and 2305-2 fixed-head disks, which had rotational position sensing (RPS) and eight exposures (alias addresses) per disk; the OS/360 support provided a UCB per exposure in order to permit multiple concurrent channel programs. Similarly, later systems derived from OS/360 required an additional UCB for each allocated virtual volume in a IBM 3850 Mass Storage System (MSS), and for each exposure on a 3880-11 and its successors.
Parallel Access Volumes (PAVs)
Since only one set of channel commands or I/O could be run at one time. This was fine in the 1960s when CPUs were slow and I/O could only be processed as fast as CPUs could process it. As systems matured and CPU speed greatly surpassed I/O input capacity, access to the device that was serialized at the UCB level became a serious bottleneck.