Unit Control Block
Encyclopedia
In IBM mainframe
operating system
s from the OS/360 and successors
line, 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.
A similar concept in Unix-like
systems is a kernel's
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 information stored in the UCB are: device type (disk, tape, printer, terminal, etc.), 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 channel command processor
of an external device. Inside every UCB is a representation of a subchannel information block, that is used in the SSCH assembler instruction (put in the IRB, for input, or put in the ORB, for output), to start a chain of channel commands, known as CCWs. CCWs are queued onto the UCB with the STARTIO macro interface, although that reference does NOT discuss the STARTIO macro as that macro instruction is NOT an IBM-supported interface, not withstanding the fact that that interface has remained the same for at least the past three decades. The STARTIO
interface will either start the operation immediately, should the Channel Queue be empty, or it will queue the request on the Channel Queue for deferred execution. Such deferred execution will be initiated immediately when the request is at the head of the queue and the device becomes available, even if another program is in control at that instant. Such is the basic design of IOS
.
The UCB evolved to be an anchor to hold information and states about the device. The UCB currently has 5 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 this OS, the UCBs (foundations and extensions) were assembled during SYSGEN, and were located within the first 64 kbytes of the system area, as the I/O device lookup table consisted of 16-bit Q-type (i.e., relocatable) addresses. Subsequent enhancements allowed the extensions to be above the 64 kbyte line, thereby saving space for additional UCB foundations below the 64 kbyte line and also thereby preserving the architecture of the UCB lookup table (converting a CUu to a UCB foundation address).
, 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 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 8 exposures (alias addresses) per disk, and the OS/360 support provided a UCB per exposure in order to permit multiple concurrent channel programs.
(WLM) was introduced in MVS/ESA 5.1. OS/390
added "smart" I/O queuing. It allowed the operating system, using information provided to WLM by the systems programmer, to determine which waiting I/Os were more, or less, important than other waiting I/Os. WLM would then, in a sense, move a waiting I/O further up, or down, in the queue so when the device was no longer busy, the most important waiting I/O would get the device next. WLM improved the I/O response to a device for the more important work being processed. However, there was still the limit of a single I/O to a single UCB/device at any one time.
Parallel Access Volume (PAV) allow UCBs to clone themselves to allow multiple I/O to run simultaneously. With appropriate support by the DASD hardware, PAV provides support for more than one I/O to a single device at a time. For backwards compatibility reasons, operations are still serialized below UCB level. But PAV allows the definition of additional UCBs to the same logical device, each using an additional alias address. For example, a DASD device at base address 1000, could have alias addresses of 1001, 1002 and 1003. Each of these alias addresses would have their own UCB. Since there are now four UCBs to a single device, four concurrent I/Os are possible. Writes to the same extent, an area of the disk assigned to one contiguous area of a file, are still serialized, but other reads and writes occur simultaneously. The first version of PAV the disk controller assigns a PAV to a UCB. In the second version of PAV processing, WLM (Work Load Manager) re-assigns a PAV to new UCBs from time to time. In the third version of PAV processing, with the DS8000 controller series, each I/O uses any available PAV with the UCB it needs.
The net effect of PAVs is to decrease the IOSQ time component of disk response time, often to zero. As of 2007, the only restrictions to PAV are the number of alias addresses, 255 per base address, and overall number of devices per logical control unit, 256 counting base plus aliases.
.) On most systems that implement PAV, there is usually a mixture of both PAV types. One, perhaps two, static aliases are defined for each base UCB and a bunch of dynamic aliases are defined for WLM to manage as it sees fit.
As WLM watches over the I/O activity in the system, WLM determines if there a high-importance workload is delayed due to high contention for a specific PAV-enabled device. Specifically, for a disk device, base and alias UCBs must be insufficient to eliminate IOS Queue time. If there is high contention, WLM will try to move aliases from another base address to this device - if WLM estimates doing so would help the workload achieve its goals more readily.
Another problem may be certain performance goals are not being met, as specified by WLM service classes. WLM will then look for alias UCBs that are processing work for less important tasks (service class), and if appropriate, WLM will re-associate aliases to the base addresses associated with the more important work.
Further, because with HyperPAV the UCB is acquired for only the duration of a single I/O, a smaller number of UCBs are required to service the same workload, compared to Dynamic PAVs. For large z/OS
images UCBs can be a scarce resource. So HyperPAVs can provide some relief in this regard.
IBM mainframe
IBM mainframes are large computer systems produced by IBM from 1952 to the present. During the 1960s and 1970s, the term mainframe computer was almost synonymous with IBM products due to their marketshare...
operating system
Operating system
An operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system...
s from the OS/360 and successors
OS/360 and successors
OS/360, officially known as IBM System/360 Operating System, was a batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was heavily influenced by the earlier IBSYS/IBJOB and Input/Output Control System packages...
line, a Unit Control Block (UCB) is a memory structure
Object composition
In computer science, object composition is a way to combine simple objects or data types into more complex ones...
, or a control block, that describes any single input/output
Input/output
In computing, input/output, or I/O, refers to the communication between an information processing system , and the outside world, possibly a human, or another information processing system. Inputs are the signals or data received by the system, and outputs are the signals or data sent from it...
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.
A similar concept in Unix-like
Unix-like
A Unix-like operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification....
systems is a kernel's
devinfo structure, addressed by a combination of major and minor number through a device node.Overview
During initial program load (IPL) of current MVSMVS
Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers...
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 information stored in the UCB are: device type (disk, tape, printer, terminal, etc.), 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
Volume serial number
A volume serial number is a serial number assigned to a disk volume or tape volume. It originated in 1950s in mainframe computer operating systems. In OS/360 line it is human-configurable, has a maximum length of six characters, is in uppercase, must start with a letter, and identifies a volume to...
(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 channel command processor
Channel I/O
In computer science, channel I/O is a generic term that refers to a high-performance input/output architecture that is implemented in various forms on a number of computer architectures, especially on mainframe computers...
of an external device. Inside every UCB is a representation of a subchannel information block, that is used in the SSCH assembler instruction (put in the IRB, for input, or put in the ORB, for output), to start a chain of channel commands, known as CCWs. CCWs are queued onto the UCB with the STARTIO macro interface, although that reference does NOT discuss the STARTIO macro as that macro instruction is NOT an IBM-supported interface, not withstanding the fact that that interface has remained the same for at least the past three decades. The STARTIO
Start Input/Output
In MVS/370 and successor versions of IBM mainframe operating systems, Start Input/Output is a macro instruction and a "branch entry" for low-level device access, where the programmer is responsible for providing a list of device-specific CCWs, that is, a Channel Program, to be executed by I/O...
interface will either start the operation immediately, should the Channel Queue be empty, or it will queue the request on the Channel Queue for deferred execution. Such deferred execution will be initiated immediately when the request is at the head of the queue and the device becomes available, even if another program is in control at that instant. Such is the basic design of IOS
Input/Output Supervisor
The Input/Output Supervisor is that portion of the IBM mainframe operating system control program which issues the privileged I/O instructions and supervises the resulting I/O interruptions for any program which requests I/O device operations until the normal or abnormal conclusion of those...
.
The UCB evolved to be an anchor to hold information and states about the device. The UCB currently has 5 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 this OS, the UCBs (foundations and extensions) were assembled during SYSGEN, and were located within the first 64 kbytes of the system area, as the I/O device lookup table consisted of 16-bit Q-type (i.e., relocatable) addresses. Subsequent enhancements allowed the extensions to be above the 64 kbyte line, thereby saving space for additional UCB foundations below the 64 kbyte line and also thereby preserving the architecture of the UCB lookup table (converting a CUu to a UCB foundation address).
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 driveTape drive
A tape drive is a data storage device that reads and performs digital recording, writes data on a magnetic tape. Magnetic tape data storage is typically used for offline, archival data storage. Tape media generally has a favorable unit cost and long archival stability.A tape drive provides...
, with no internal cache
Cache
In computer engineering, a cache is a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere...
. Without it, the device was usually grossly outperformed by the mainframe's channel processor
Channel I/O
In computer science, channel I/O is a generic term that refers to a high-performance input/output architecture that is implemented in various forms on a number of computer architectures, especially on mainframe computers...
. Hence, there was no reason to execute multiple input/output operations 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 8 exposures (alias addresses) per disk, and the OS/360 support provided a UCB per exposure in order to permit multiple concurrent channel programs.
Workload Manager and UCBs
When originally implemented, operating system had no real way to determine if a waiting I/O was more or less important than any other waiting I/Os. I/Os to a device were handled first in, first out. Workload ManagerWorkload Manager
In IBM mainframes, Workload Manager is a base component of MVS/ESA mainframe operating system, and its successors up to and including z/OS. It controls the access to system resources for the work executing on z/OS based on administrator-defined goals. Workload Manager components also exist for...
(WLM) was introduced in MVS/ESA 5.1. OS/390
OS/390
OS/390 is an IBM operating system for the System/390 IBM mainframe computers.OS/390 was introduced in late 1995 in an effort, led by the late Randy Stelman, to simplify the packaging and ordering for the key, entitled elements needed to complete a fully functional MVS operating system package...
added "smart" I/O queuing. It allowed the operating system, using information provided to WLM by the systems programmer, to determine which waiting I/Os were more, or less, important than other waiting I/Os. WLM would then, in a sense, move a waiting I/O further up, or down, in the queue so when the device was no longer busy, the most important waiting I/O would get the device next. WLM improved the I/O response to a device for the more important work being processed. However, there was still the limit of a single I/O to a single UCB/device at any one time.
Parallel Access Volumes (PAVs)
As mentioned before 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.Parallel Access Volume (PAV) allow UCBs to clone themselves to allow multiple I/O to run simultaneously. With appropriate support by the DASD hardware, PAV provides support for more than one I/O to a single device at a time. For backwards compatibility reasons, operations are still serialized below UCB level. But PAV allows the definition of additional UCBs to the same logical device, each using an additional alias address. For example, a DASD device at base address 1000, could have alias addresses of 1001, 1002 and 1003. Each of these alias addresses would have their own UCB. Since there are now four UCBs to a single device, four concurrent I/Os are possible. Writes to the same extent, an area of the disk assigned to one contiguous area of a file, are still serialized, but other reads and writes occur simultaneously. The first version of PAV the disk controller assigns a PAV to a UCB. In the second version of PAV processing, WLM (Work Load Manager) re-assigns a PAV to new UCBs from time to time. In the third version of PAV processing, with the DS8000 controller series, each I/O uses any available PAV with the UCB it needs.
The net effect of PAVs is to decrease the IOSQ time component of disk response time, often to zero. As of 2007, the only restrictions to PAV are the number of alias addresses, 255 per base address, and overall number of devices per logical control unit, 256 counting base plus aliases.
Static versus dynamic PAVs
There are two types of PAV alias addresses, static and dynamic. A static alias address is defined, in both DASD hardware and z/OS, to refer to a specific single base address. Dynamic means that the number of alias addresses assigned to a specific base address fluctuates based on need. The management of these dynamic aliases is left to WLM, running in goal mode. (Which is always the case with supported levels of z/OSZ/OS
z/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390, which in turn followed a string of MVS versions.Starting with earliest:*OS/VS2 Release 2 through Release 3.8...
.) On most systems that implement PAV, there is usually a mixture of both PAV types. One, perhaps two, static aliases are defined for each base UCB and a bunch of dynamic aliases are defined for WLM to manage as it sees fit.
As WLM watches over the I/O activity in the system, WLM determines if there a high-importance workload is delayed due to high contention for a specific PAV-enabled device. Specifically, for a disk device, base and alias UCBs must be insufficient to eliminate IOS Queue time. If there is high contention, WLM will try to move aliases from another base address to this device - if WLM estimates doing so would help the workload achieve its goals more readily.
Another problem may be certain performance goals are not being met, as specified by WLM service classes. WLM will then look for alias UCBs that are processing work for less important tasks (service class), and if appropriate, WLM will re-associate aliases to the base addresses associated with the more important work.
HyperPAVs
WLM's actions in moving aliases from one disk device to another take a few seconds for the effects to be seen. For many situations this is not fast enough. HyperPAVs are much more responsive because they acquire a UCB from a pool for the duration of a single I/O operation, before returning it to the pool. There is no delay waiting for WLM to react.Further, because with HyperPAV the UCB is acquired for only the duration of a single I/O, a smaller number of UCBs are required to service the same workload, compared to Dynamic PAVs. For large z/OS
Z/OS
z/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390, which in turn followed a string of MVS versions.Starting with earliest:*OS/VS2 Release 2 through Release 3.8...
images UCBs can be a scarce resource. So HyperPAVs can provide some relief in this regard.