Talk:Unit Control Block/Archive 1

Archive 1

Parallel Access Volumes, and UCBs in general

I'm torn between keeping the PAV stuff in this article and moving it to the PAV article proper. My inclination at this point is to keep it here because it reinforces the "importance" of understanding what a UCB is. Martin Packer 11:28, 17 October 2007 (UTC)

Yes, let's keep it here. In fact, Wikipedia allows redirecting Parallel Access Volumes link to a subsection of UCB page (behavior like e.g. Secondary storage link). I think this is very appropriate solution here, per WP:NOT#DICTIONARY.

I'm not a mainframe man at all, and I know the subject only theoretically. Could you explain access to UCB from program side? Is UCB kept permanently in operating system's internal tables or in a program's memory? How is it connected with a device (unit) identifier? Is UCB accessed from access method level or below, from the CCWs level? --Kubanczyk 18:03, 17 October 2007 (UTC)

Hi! Generally user application programs don't access a UCB directly... They use an "Access Method" to perform the I/O. So, for example two Access Methods for processing Sequential data are QSAM and BSAM (Queued Sequential and Basic Sequential, respectively). The Access Method is the thing that drives I/O and hence gets closer to accessing the UCB. Database subsystems, such as IBM's DB2 and IMS, and Software AG's Adabas, also access the data on behalf of the application program and hence are closer to the UCB. A component of z/OS, called IOS, is probably the thing that has the actual access to the UCB. I'll ask for some help here from the community in firming this up. But you raise a VERY good question. Most of my reply can probably go into the article itself. Martin Packer 19:46, 17 October 2007 (UTC)

Actually, the UCB represents the physical device (logical or otherwise) that will be allocated (assigned) to the unit of work. There are typically multiple data sets or files on any given device, so sharing is a routine function. The "assignment" of the UCB occurs when a unit of work begins and requires the operating system to "allocate" the device where the data, in which the work is interested, resides. In the final analysis, this is ultimately no different than defining the path to get to an application on the PC. In this case, the equivalent of the UCB would be the device letter. (Gerhard Adam, 17, Oct. 2007) —Preceding unsigned comment added by 65.242.184.131 (talk) 22:56, 17 October 2007 (UTC)

Although I am not a z/OS programmer, I have done systems programming on other architectures (VAX/VMS, RSX-11M) and worked on embedded code that went into S/370 systems and talked to channel programs over a block multiplexer channel. I find the statement that "an applications program must acquire the UCB" somewhat contrary to my understanding of how the IBM I/O architecture works. The actual I/O at the hardware level is performed by an SIO instruction kicking off a channel program. Since the SIO instructions are privileged, this is represented in user space by an EXCP SVC (supervisor call: execute channel program). On as shared disk structure, protection between users requires that users are prevented from doing this, so the user calls a set of runtime library routines generally referred to as "access methods". The UCB is part of the bottom half of the access method complex. Back when I was involved in those projects, I think the access method lived almost completely in user space; these days, I would think that most of the I/O system would live in kernel space (i.e. not in the user address space). Lpoulsen 23:10, 17 October 2007 (UTC)

We're getting closer here.

The UCB is actually a representation of a single logical device (physical or otherwise) and is meant to serialize access to the device. The UCB is built during IPL (Initial Program Load) and the information to build a UCB is read from the IODF (I/O Definition File) by the IPL program; NIP (Nucleus Initialization Program). The UCB is stored in ESQA (Extended System Queue Area). Some of the information stored in the UCB is device type (disk, tape, printer, terminal, etc...), address of the device, the Volume Serial number (if appropriate), subchannel and device number, CHPD (Channel Path ID) which defines the path to the device, and a ton of other information.

No one task "owns" a UCB, even during an I/O. UCB's are owned by the IOS (I/O Subsystem). IOS performs work on behalf of other tasks running in the operating system. The requests to the IOS to perform this work are made when any task opens, closes, reads, writes, gets, puts, etc... a file residing on the device associated with the UCB in question. In the past, distant past, some applications may have performed their own I/O. Today, a program/application issues a read or write for data and is, usually, put to sleep by the operating system while the I/O is processed. When the I/O completes, the task is woken up and continues on its merry way until the next time, oblivious that it was ever asleep.

IOS handles all the serialization, issuing the actual I/O's to a device and waiting for the results.

While an I/O is active to a device, there is a flag in the UCB to indicate that the device is busy. While a device busy with an I/O, no other I/O's will be issued to the device. When this happens, a device is flagged/marked busy, the I/O request is placed in a queue (IOSQ) to wait its turn. When the UCB/device is no longer busy, the IOS will look in the queue of I/O's waiting for the device and select the next I/O in line (top of the queue) and then starts the I/O down the path to the device. This activity will continue until there are no more I/O's waiting in line for that particular device.

In days gone by, there was no real way for the operating system to determine if a waiting I/O was more, or less, important than any other waiting I/O's. I/O's to a device were handled FIFO (First In, First Out). Sometime during the life of OS/390 (the predecessor to z/OS), WLM (WorkLoad Manager) was introduced, and WLM added "smart" I/O queuing. This smart queuing allowed the operating system, using information provided to WLM by the systems programmer, to determine which waiting I/O's were more, or less, important than other waiting I/O's. WLM would then, in a sense, move a waiting I/O further up, or down, in the queue so when the device in question 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.

Step in PAV (Parallel Access Volume). With appropriate support by the DASD hardware, PAV provided support for more than one I/O to a single device at a time. PAV allowed the definition of additional UCB's to the same logical device address using alias addresses. For example, a DASD device at address 1000, the base address, could have alias addresses of 1001, 1002 and 1003. Each of these alias addresses would have their own UCB. Since there are now four, in this example, UCB's to a single device, four I/O's could be active to the same logical device at the same time. Writes to the same domain (extents of an I/O, kind of like an area of the device) on a device are serialized, all other reads and writes occur simultaneously. This parallel I/O activity to a single logical device significantly reduces, if not eliminates, the queuing of I/O requests.

The only restrictions to PAV are the number of alias addresses, 255 per base address, devices per logical control unit, 256 (base plus aliases) and only the base UCB address is known to the outside world; you and me.

There are two types of PAV alias addresses, static and dynamic. Static means, like the name implies, that there are a static, fixed, number of alias addresses defined to a specific base address. Dynamic, as the name implies, 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, but only if WLM is in goal mode. On most systems that implement PAV, there is usually a mixture of the two 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 is high contention for a specific PAV enabled UCB (all UCB's, base and alias, are busy and work is piling up in the queue) or certain performance goals (specific WLM service classes) are not being met. If there is high contention for a UCB, WLM will try to move aliases from UCB's with lower contention to the UCB's with higher contention. If the problem is performance goals are not being met, WLM will look for device aliases on PAV enabled UCB's that are processing work for less important tasks (service class), and if appropriate, WLM will move aliases to the UCB's associated with the more important work.

I'll add more as time permits... -- GJGreen 03:51, 18 October 2007 (UTC)

Hi Gerhard, hi Lpoulsen, hi GJGreen, glad to have you here. Per Wikipedia adivces, please do not hesitate to edit any article. 99% of readers will not look here at the talk page. Right now I'm copying most of the content straight to article.

Btw, could you comment on Multiple Allegiance? I think initially I saw PAV/MA acronym to describe the feature of a disk controller (implying that from disk side PAV=MA??). I marked some other unclear places in the article's text itself. --Kubanczyk 18:32, 18 October 2007 (UTC)

Clarifications and corrections

There was an old question about Multiple Allegiance; it's related to a DASD channel command called RESERVE.

The I/O Supervisor in the operating system is distinct from the channel subsystem in the processor.

EXCP and STARTIO are very different facilities. EXCP is an access method that manages application channel programs, translates them and eventually issues STARTIO. Only privileged code can use STARTIO directly, and the bookkeeping is much more complicated than that required by EXCP or EXCPVR.

The material on EXCP and STARTIO belongs in a separate article. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:56, 22 July 2010 (UTC)

Similar structures in other operating systems (some with the same name)

VMS, and RSX-11M before that (and RSX-11M+, and other variants) have UCBs, and they are very similar in concept and function. They even have "device busy" bits (although drivers of devices that don't want everything serialized through one funnel) are free to ignore them.

The Windows NT family has device objects - which are very much the same thing under another name.

Should sections for these "related concepts" be added here? Or different articles created? Jeh (talk) 19:28, 22 July 2010 (UTC)

The article is mostly not about unit control blocks

Most of the material in the article has nothing to do with unit control blocks, except in the sense that an article descrbing retail stores is about bar codes. The bulk of the text, while notable, belongs in a separate article. The remaining text should be expanded to include OS/360, OS/VS1, SVS and versions of MVS prior to HCD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:42, 27 August 2010 (UTC)

User programs do share devices

Not only do user programs share devices, but it is the norm for DASD. The operating systems keeps track of data sets on DASD and allows programs to selectively share them or to allocate them for exclusive use. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:57, 27 August 2010 (UTC)

MVS I/O is nonblocking

Programs are not put to sleep when they request I/O. The queued access methods only issue waits if the program has requested an action that currently lacks resources, e.g., no data available for a GET, no buffer available for a PUT. A program using a basic access method is responsible for issuing its own waits, either explicitly or via the CHECK macro. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:02, 27 August 2010 (UTC)

Role of access method

The user does not directly provide device addresses or UCB addresses to an access methods, and, in fact, there may be multiple UCB addresses for a given data set. The application program creates an Access Control Block (ACB) or a Data Control Block (DCB) that typically contains an 8 character ddname. The OPEN SVC routine creates another control block called the Data Extent Block (DEB), and puts UCB addresses there. I/O requests to an access method always involve the address of an ACB or DCB, never an explicit DEB or UCB address. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:25, 27 August 2010 (UTC)