Unit Control Block

Last updated

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.

Contents

Some other operating systems have similar structures.

Overview

During initial program load (IPL) of current [lower-alpha 1] 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 [1] IOS Queue Element [2] (IOQ), UCBIOQF and UCBIOQL pointers [3] to a queue of IOQs [lower-alpha 2] (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)). [4]

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. [1] 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, 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. [5] Similarly, later systems derived from OS/360 required an additional UCB for each allocated virtual volume in a IBM 3850 Mass Storage System (MSS), [6] and for each exposure on a 3880-11 and its successors. [7] [8]

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.

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. To maintain backward compatibility, operations are still serialized below the 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, Workload Manager (WLM) reassigns a PAV to new UCBs from time to time. In the third version of PAV processing, with the IBM DS8000 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.

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 significantly 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. Thus, a smaller number of UCBs are required to service the same workload, compared to Dynamic PAVs. There is no delay waiting for WLM to react. [9]

In other operating systems

Digital's VMS operating system uses an identically named structure, the UCB, for similar purposes. A UCB is created for each I/O device. The data in the UCB includes the device's unit number (a part of the device name) and a listhead to which pending I/O requests may be queued. The UCB may have a device-driver defined extension in which the driver can keep driver-defined data that is instantiated for each device. [10]

See also

Notes

  1. ↑ In some older systems, the UCBs were part of the Nucleus and were assembled during the SYSGEN process.
  2. ↑ In OS/360, OS/VS1 and SVS, there was a field pointing to a queue of Request Queue Elements (RQEs).

Related Research Articles

IBM mainframes are large computer systems produced by IBM since 1952. During the 1960s and 1970s, IBM dominated the computer market with the 7000 series and the later System/360, followed by the System/370. Current mainframe computers in IBM's line of business computers are developments of the basic design of the System/360.

<span class="mw-page-title-main">MVS</span> Operating system for IBM mainframes

Multiple Virtual Storage, more commonly called MVS, is the most commonly used operating system on the System/370, System/390 and IBM Z IBM mainframe computers. IBM developed MVS, along with OS/VS1 and SVS, as a successor to OS/360. It is unrelated to IBM's other mainframe operating system lines, e.g., VSE, VM, TPF.

<span class="mw-page-title-main">Operating system</span> Software that manages computer hardware resources

An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs.

A direct-access storage device (DASD) is a secondary storage device in which "each physical record has a discrete location and a unique address". The term was coined by IBM to describe devices that allowed random access to data, the main examples being drum memory and hard disk drives. Later, optical disc drives and flash memory units are also classified as DASD.

Disk Operating System/360, also DOS/360, or simply DOS, is the discontinued first member of a sequence of operating systems for IBM System/360, System/370 and later mainframes. It was announced by IBM on the last day of 1964, and it was first delivered in June 1966. In its time, DOS/360 was the most widely used operating system in the world.

In computing, channel I/O is a high-performance input/output (I/O) architecture that is implemented in various forms on a number of computer architectures, especially on mainframe computers. In the past, channels were generally implemented with custom devices, variously named channel, I/O processor, I/O controller, I/O synchronizer, or DMA controller.

<span class="mw-page-title-main">SDSF</span> Component of the z/OS operating system

The System Display and Search Facility (SDSF) is a component of IBM's mainframe operating system, z/OS, is an interactive user interface that allows users and administrators to view and control various aspects of the mainframe's operation and system resources. Some of the information displayed in SDSF includes Batch job output, Unix processes, scheduling environments, and the status of external devices such as printers and network lines. SDSF is primarily used to access batch and system log files and dumps.

The IBM Basic assembly language and successors is a series of assembly languages and assemblers made for the IBM System/360 mainframe system and its successors through the IBM Z.

Count key data (CKD) is a direct-access storage device (DASD) data recording format introduced in 1964, by IBM with its IBM System/360 and still being emulated on IBM mainframes. It is a self-defining format with each data record represented by a Count Area that identifies the record and provides the number of bytes in an optional Key Area and an optional Data Area. This is in contrast to devices using fixed sector size or a separate format track.

An access method is a function of a mainframe operating system that enables access to data on disk, tape or other external devices. Access methods were present in several mainframe operating systems since the late 1950s, under a variety of names; the name access method was introduced in 1963 in the IBM OS/360 operating system. Access methods provide an application programming interface (API) for programmers to transfer data to or from device, and could be compared to device drivers in non-mainframe operating systems, but typically provide a greater level of functionality.

In IBM mainframe operating systems, Basic sequential access method (BSAM) is an access method to read and write datasets sequentially. BSAM is available on OS/360, OS/VS2, MVS, z/OS, and related operating systems.

In IBM mainframe operating systems, Execute Channel Program (EXCP) is a macro generating a system call, implemented as a Supervisor Call instruction, for low-level device access, where the programmer is responsible for providing a channel program—a list of device-specific commands (CCWs)—to be executed by I/O channels, control units and devices. EXCP for OS/360 and successors is more specifically described in the OS System Programmer's Guide.; EXCP for DOS/360 and successors is more specifically described in DOS Supervisor and I/O Macros. This article mostly reflects OS/360 through z/OS; some details are different for TOS/360 and DOS/360 through z/VSE.

The history of IBM mainframe operating systems is significant within the history of mainframe operating systems, because of IBM's long-standing position as the world's largest hardware supplier of mainframe computers. IBM mainframes run operating systems supplied by IBM and by third parties.

<span class="mw-page-title-main">OS/360 and successors</span> Operating system for IBM S/360 and later mainframes

OS/360, officially known as IBM System/360 Operating System, is a discontinued batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was influenced by the earlier IBSYS/IBJOB and Input/Output Control System (IOCS) packages for the IBM 7090/7094 and even more so by the PR155 Operating System for the IBM 1410/7010 processors. It was one of the earliest operating systems to require the computer hardware to include at least one direct access storage device.

Basic Direct Access Method, or BDAM is an access method for IBM's OS/360 and successors computer operating systems on System/360 and later mainframes. BDAM "consists of routines used in retrieving data from, and storing data onto, direct access devices." BDAM is available on OS/360, OS/VS2, MVS, z/OS, and related high-end operating systems.

The Input/Output Configuration Program is a program on IBM mainframes.

System Generation (SysGen) is a two-stage process for installing or updating OS/360, OS/VS1, OS/VS2 (SVS), OS/VS2 (MVS) and chargeable systems derived from them. There are similar processes for, e.g., DOS/360, which this article does not cover. Also, some of the details have changed between releases of OS/360 and many details do not carry over to later systems.

In MVS/370 and successor versions of IBM mainframe operating systems, Start Input/Output (STARTIO) 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 channels, control units and devices and a number of "exits", several of which may be immediate returns to the Input/Output Supervisor (IOS). Invokers of STARTIO must be in supervisor mode and key 0. STARTIO interfaces directly with the IOS component of MVS.

In IBM mainframe operating systems, Queued Sequential Access Method (QSAM) is an access method to read and write datasets sequentially. QSAM is available on OS/360, OS/VS2, MVS, z/OS, and related operating systems.

References

  1. 1 2 "UCB Mapping" (PDF). z/OS 2.5 MVS Data Areas MVS Data Areas Volume 4 (RRP - XTL) (PDF). IBM. September 30, 2021. p.  994. GA32-0938-500. Retrieved May 9, 2022.
  2. ↑ "IOQ Information" (PDF). z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG) (PDF). IBM. September 30, 2021. pp. 1033–1039. GA32-0936-50. Retrieved May 8, 2022.
  3. ↑ "IOSDUPFX mapping" (PDF). z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG) (PDF). IBM. September 30, 2021. p.  1181. GA32-0936-50. Retrieved May 9, 2022.
  4. ↑ z/Architecture Principles of Operation (PDF) (Fourteenth ed.). IBM. May 2022. p. 14-15. SA22-7832-13. Retrieved January 24, 2023.
  5. ↑ "IODEVICE" (PDF). OS System Generation – Release 21.8 (PDF) (Fourteenth ed.). IBM. August 1974. p. 339. GC28-6554-13. Retrieved January 24, 2023.
  6. ↑ "Virtual Drive Concept" (PDF). Introduction to the IBM 3850 Mass Storage System (MSS) (PDF) (Third ed.). IBM. July 1975. p. 22. GA32-0028-2. Retrieved January 24, 2023.
  7. ↑ "IBM 3880 Storage Control Model 21". IBM. September 18, 1984. 184-119. Retrieved January 24, 2023.
  8. ↑ IBM 3880 Storage Control Model 21 - Installation and Administration Guide (PDF) (First ed.). IBM. October 1984. p. 3. GA32-0084-0. Retrieved January 24, 2023.
  9. ↑ Rogers, Paul; Salla, Alvaro; Sousa, Livio (September 2008). "7.22 HyperPAV feature for DS8000 series" (PDF). ABCs of z/OS System Programming (PDF). Vol. 10 (Fourth ed.). IBM. p. 494. SG24-6990-03. Retrieved May 5, 2022.{{cite book}}: |work= ignored (help)
  10. ↑ Goldenberg, Ruth; Saravanan, Sara (1994). OpenVMS AXP Internals and Data Structures. Digital Press. p. 753. ISBN   978-1555581206. The executive creates a unit control block (UCB) for each I/O device attached to the system.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.