imported>Voidxor: Rm old uncited.

2023-12-09T00:38:50Z

Rm old uncited.

New page

{{Short description|Component of IBM mainframe operating systems}}
{{Use American English|date=December 2023}}
{{Use mdy dates|date=December 2023}}
{{More citations needed|date=January 2017}}

In [[IBM mainframe]] [[operating system]]s [[OS/360 and successors|OS/360 and its successors]], a '''Unit Control Block''' ('''UCB''') is a [[Object composition|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{{Efn|In some older systems, the UCBs were part of the Nucleus and were assembled during the SYSGEN process.}} [[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<ref name="ucb-mapping">{{cite book
| title = z/OS 2.5 MVS Data Areas MVS Data Areas Volume 4 (RRP - XTL)
| id = GA32-0938-500
| date = September 30, 2021
| url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320938/$file/iead400_v2r5.pdf
| section = UCB Mapping
| section-url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320938/$file/iead400_v2r5.pdf#page=1039
| page = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320938/$file/iead400_v2r5.pdf#page=1040 994]
| publisher = IBM
| access-date = May 9, 2022
}}</ref> IOS Queue Element<ref>{{cite book
| title = z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG)
| id = GA32-0936-50
| date = September 30, 2021
| section = IOQ Information
| section-url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320936/$file/iead200_v2r5.pdf#page=1097
| pages = 1033–1039
| url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320936/$file/iead200_v2r5.pdf
| publisher = IBM
| access-date = May 8, 2022
}}</ref> (IOQ), UCBIOQF and UCBIOQL pointers<ref>{{cite book
| title = z/OS 2.5 MVS Data Areas Volume 2 (IAX - ISG)
| id = GA32-0936-50
| date = September 30, 2021
| url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320936/$file/iead200_v2r5.pdf
| section = IOSDUPFX mapping
| section-url = https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320936/$file/iead200_v2r5.pdf#page=1244
| page = [https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5ga320936/$file/iead200_v2r5.pdf#page=1245 1181]
| publisher = IBM
| access-date = May 9, 2022
}}</ref> to a queue of IOQs{{efn|In OS/360, [[OS/VS1]] and [[OS/VS2 (SVS)|SVS]], there was a field pointing to a queue of Request Queue Elements (RQEs).}} (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)).<ref>{{cite book |title=z/Architecture Principles of Operation |edition=Fourteenth |id=SA22-7832-13 |page=14{{hyp}}15 |url=https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf |publisher=IBM |date=May 2022 |access-date=January 24, 2023 }}</ref>

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.<ref name="ucb-mapping" /> 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 [[Disk buffer|cache]]. Without it, the device was usually grossly outperformed by the mainframe's [[Channel I/O|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.<ref>{{cite book |title=OS System Generation – Release 21.8 |id=GC28-6554-13 |date=August 1974 |edition=Fourteenth |section=IODEVICE |section-url=http://bitsavers.org/pdf/ibm/360/os/R21.8_Aug74/GC28-6554-13_OS_System_Generation_Release_21.8_Aug74.pdf#page=359 |page=339 |url=http://bitsavers.org/pdf/ibm/360/os/R21.8_Aug74/GC28-6554-13_OS_System_Generation_Release_21.8_Aug74.pdf |publisher=IBM |access-date=January 24, 2023 }}</ref> Similarly, later systems derived from OS/360 required an additional UCB for each allocated virtual volume in a [[IBM 3850|IBM 3850 Mass Storage System]] (MSS),<ref>{{cite book |title=Introduction to the IBM 3850 Mass Storage System (MSS) |id= GA32-0028-2 |date=July 1975 |edition=Third |section=Virtual Drive Concept |section-url=http://bitsavers.org/pdf/ibm/3850/GA32-0028-7_Introduction_to_the_IBM_3850_Mass_Storage_System_Jul75.pdf#page=23 |page=22 |url=http://bitsavers.org/pdf/ibm/3850/GA32-0028-7_Introduction_to_the_IBM_3850_Mass_Storage_System_Jul75.pdf |publisher=IBM |access-date=January 24, 2023 }}</ref> and for each exposure on a 3880-11 and its successors.<ref>{{cite web |title=IBM 3880 Storage Control Model 21 |id=184-119 |date=September 18, 1984 |url=https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/897/ENUS184-119/index.html |publisher=IBM |access-date=January 24, 2023 }}</ref><ref>{{cite book |title= IBM 3880 Storage Control Model 21 - Installation and Administration Guide |id=GA32-0084-0 |date=October 1984 |edition=First |url=http://vtda.org/docs/computing/IBM/Mainframe/Hardware/DataStor/GA32-0084-0_IBM3380SCM21InstallationAdministration.pdf#page=14 |publisher=IBM |page=3 |access-date=January 24, 2023 }}</ref>

=== 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|post=,}} 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.<ref>{{cite book |first1=Paul |last1=Rogers |first2=Alvaro |last2=Salla |first3=Livio |last3=Sousa |date=September 2008 |title=ABCs of z/OS System Programming |volume=10 |id=SG24-6990-03 |edition=Fourth |section=7.22 HyperPAV feature for DS8000 series |section-url=https://s3p.manualzz.com/store/data/029464005.pdf?key=16282d34a07d49405e04fd1acc6a24b6&r=1&fn=29464005.pdf&t=1651800442156&p=86400#page=512 |page=494 |url=https://s3p.manualzz.com/store/data/029464005.pdf?key=16282d34a07d49405e04fd1acc6a24b6&r=1&fn=29464005.pdf&t=1651800442156&p=86400 |work=Redbooks |publisher=IBM |access-date=May 5, 2022 }}</ref>

== In other operating systems ==
Digital's [[OpenVMS|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.<ref>{{cite book |last1=Goldenberg |first1=Ruth |last2=Saravanan |first2=Sara |date=1994 |title=OpenVMS AXP Internals and Data Structures |publisher=Digital Press |page=753 |isbn=978-1555581206 |quote=The executive creates a unit control block (UCB) for each I/O device attached to the system. }}</ref>

== See also ==
* {{Annotated link|z/OS}}

== Notes ==
{{Notelist}}

== References ==
{{Reflist}}

{{Mainframe I/O access methods}}

[[Category:IBM mainframe operating systems]]

Unit Control Block - Revision history

imported>Voidxor: Rm old uncited.