Unit Control Block

In IBM mainframe operating systems such as OS/360 and its successors, a Unit Control Block (UCB) is a data structure in memory, also known as a control block, that represents an individual input/output peripheral device (referred to as a unit) or an alias recognized by the operating system. Specific fields within the UCB guide the Input/Output Supervisor (IOS) to call specialized routines that provide enhanced control of devices beyond the standard IOS functions.

Overview

On modern MVS systems, the Nucleus Initialization Program (NIP) constructs UCBs during the initial program load (IPL) by extracting device information from the I/O Definition File (IODF). These UCBs are stored in system-managed memory located in the Extended System Queue Area (ESQA), where Input/Output Support maintains them after IPL completion. Essential data contained within each UCB includes the device category (such as disk, tape, or printer), device address, subchannel identifier and device number, channel path ID (CHPID), volume serial number (VOLSER) for certain devices, and Job Management details used by the OS.

While the internal format of UCBs has undergone changes throughout MVS development, their fundamental purpose—to represent external hardware devices to the operating system—has remained constant. Each UCB holds references like UCBIOQ pointing to the active IOS Queue Element (IOQ), as well as UCBIOQF and UCBIOQL which link to IOQ queues. Additionally, it stores a subchannel number utilized during the start subchannel (SSCH) instruction to trigger channel program execution.

The UCB functions as a repository for device-specific information and status, organized into five externally accessible segments: Device Class Extension, UCB Common Extension, UCB Prefix Stub, UCB Common Segment, and UCB Device Dependent Segment. Other segments are designated for internal system operations only. This design facilitates effective management and retrieval of device state information.

Originally implemented in OS/360, UCBs were created during SYSGEN and confined to the first 64 KB of system memory due to limitations imposed by 16-bit addressing. Subsequent improvements enabled extensions beyond this boundary, optimizing memory utilization while maintaining efficient lookup mechanisms. Eventually, system installations gained the capability to position UCBs above 16 MiB; nevertheless, when files are allocated without using the XTIOT option, the OS generates temporary local copies ("shadowing") of UCBs to ensure backward compatibility.

Handling parallel I/O operations

Introduced in the 1960s with OS/360, UCBs initially managed devices such as moving head hard disk drives or tape drives that lacked internal caching mechanisms. These devices operated slower than the mainframe's channel processor, making simultaneous I/O operations unnecessary at that time. In 1968, IBM released fixed-head disks (models 2305-1 and 2305-2) featuring rotational position sensing (RPS) and multiple exposures per disk surface. To support concurrent channel programs on these devices, OS/360 assigned a separate UCB for each exposure. Later generations of systems required additional UCB assignments for every allocated virtual volume within the IBM 3850 Mass Storage System (MSS) and for each exposure on hardware such as the 3880-11 model.

Parallel Access Volumes (PAVs)

As processor speeds surpassed input/output capabilities, the serialized access at the UCB level became a performance constraint. Parallel Access Volume (PAV) technology addresses this by enabling UCBs to replicate themselves, allowing multiple I/O operations to occur concurrently on a single device, supported by DASD hardware. Although operations remain serialized beneath the UCB layer to maintain backward compatibility, PAV introduces additional UCBs with alias addresses linked to the same logical device—for instance, a device with a base address of 1000 could have aliases such as 1001, 1002, and 1003, each possessing its own UCB. This configuration supports simultaneous I/O requests; while writes targeting the same disk extent are serialized, other read and write commands can execute in parallel.

The development of PAV went through three stages: initially, the disk controller allocated PAVs to UCBs; subsequently, the Workload Manager (WLM) dynamically redistributed PAVs; and eventually, with the introduction of the IBM DS8000 series, any available PAV with the necessary UCB can be utilized for each I/O operation. This advancement notably decreases IOSQ delay within overall disk response time, often removing it completely. As of 2007, PAV is constrained by a maximum of 255 alias addresses per base address and a total limit of 256 devices per logical control unit (including base and aliases).

HyperPAVs

The transfer of aliases between disk devices managed by WLM can require several seconds, which may be insufficiently responsive for certain workloads. HyperPAVs enhance this by assigning a UCB from a shared pool for each individual I/O transaction and promptly returning it afterward. This method demands fewer UCBs to support comparable workloads relative to Dynamic PAVs and eliminates delays caused by WLM's response time.

In other operating systems

Digital's VMS employs a similarly designated UCB structure for every I/O device. Each UCB holds the device's unit number along with a queue head for pending I/O requests. Device drivers have the capability to extend the UCB structure to include driver-specific information instantiated on a per-device basis.

References