Sam's code uses the official z/OS's UCB lookup table, so I don't think this code traverses any chain of control blocks. I would guess that it traverses the lookup table, whose location remains constant (unless an IODF change happens, perhaps) but possibly the contents of any given cell in the table might change. The contents of the cell would somehow be used to find the address of the UCB. To know exactly how the lookup table is used to look up the UCB address, see Sam's code (which I have not done).
The reIPL I referred to happened in the mid-1980s, and may well have been due to an operator's panicking rather than any APAR-able design defect in MVS/XA. My code used the system service LSPACE to query a device without first having done anything to ensure that the device did not lose its last available channel path. LSPACE back then did 3 or 4 EXCPs sequentially to the device (interrogating the VTOC, mostly, as I remember). Somewhere in between two of these EXCPs the last path went away, then the next EXCP happened and device allocation got "hung up" (I don't remember the details). I was told that the only way the data center could regain the use of the device involved was to reIPL, which they did since they felt they needed the device. That was the beginning of my education in doing I/O to an offline device. I don't remember now if my code was running authorized or not. Like John Gilmore, I believe that one should always follow all the guidelines in IBM's documentation about serialization, environmental requirements (cross-address space, protect key, addressing mode, etc.), etc., unless the code is being used for one's own learning experience. And most especially if the code is being distributed in a commercial product or even as an unsupported sample program in the public domain. However, PINning a UCB is an authorized function, Sam's code runs unauthorized, so Sam's code cannot serialize on each UCB. I personally would rather use UCBLOOK to run through all the UCBs in any code that I expected to be taken seriously. But finding the ULUT and how to use it would certainly be a fun project (see "learning experience" above). IBM's UCBLOOK service obviously has some way of serializing properly. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Gibney, Dave Sent: Friday, November 16, 2012 1:40 PM To: [email protected] Subject: Re: "New" way to do UCB lookups Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can be traversing one of these chains, encounter an element disappearing, and initiate an I/O or any other action which results in more than an abend of my SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as an IPL? Surely such a failure of system integrity would be APARable. Even if the interface is not GUPI. Integrity is not enforced by documentation :) Although a screwdriver is generally preferred to drive a screw, there are times when expedience or need indicates a hammer will do the job adequately for the specific situation. Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Bob Shannon > Sent: Friday, November 16, 2012 7:31 AM > To: [email protected] > Subject: Re: "New" way to do UCB lookups > > >A minimal requirement for their integrity is that two dispatchables > >not > access >one of them concurrently. > > Absolutely. > > > we are dealing here with well understood risks that are entirely > > avoidable > and that there is thus no excuse for incurring them > > At a higher level no one has mentioned the risk of using an > undocumented interface to do something for which documented services are > available. > > Bob Shannon > Rocket Software > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
