Lindy, If the control block is small enough to be wholly contained in a register, then you can serialize against the whole control block by the proper use of one of the Compare and Swap instructions. Typically, however, a control block is larger than that, so a convention is established that every possible user of the control block must follow. Here "user" means any code that will ever access any part of the control block for any purpose (read-only, update, create/delete the control block, etc.).
One possible convention is to have another control block (e.g., a full word) be used as the "lock" that governs access to the control block (or to any other resource). Any code process that needs to access the resource must first serialize against the lock, possibly by using one of the Compare and Swap instructions. When the lock has been successfully acquired (is locked), then the process does what it needs to do with the control block (or resource) and finally releases (unlocks) the lock. Read the description in the Authorized System Services book on the SETLOCK service. Read through the whole section and learn about all the various keywords. Sometimes a lock can be a single bit (see the system lock words in the PSA DSECT). Sometimes a full word is used (e.g., each UCB has its own unique lock full word so that any number of UCBs can be locked by different processes at the same time without impacting each other, such as when an I/O request is being put into the queue of requests for device X while an I/O interrupt for device Y is being processed at the same time by IOS on a different CPU sharing the same central storage). In the case of ENQ and DEQ, the lock can be a two-level character string in which the first level is from one to eight bytes long and the second level is another character string of from one to 256 bytes. The SETLOCK service is reserved for authorized programs, as it is used only with system locks, but you can certainly do the same kinds of things that SETLOCK does with locks that you create for your own unauthorized programs. The key to using locks (pun intended) is that ALL processes that will ever access the resource being controlled by the lock must use the same convention to acquire the lock some time before beginning to access the resource and must release the lock some time after they no longer need the resource. How can such control blocks be located? Sometimes there are a large number of control blocks in a chain (list, queue), and some part of the control block is used as a pointer to the next control block of the same type. TCBs within one address space are chained this way. There are many ways that tasks need to be managed by the system, so the TCB queue also has sideways pointers and an upward pointer (not the same as a previous pointer). A long time ago, each UCB had a full-word pointer within it to hold the address of the next UCB in the chain of all UCBs. All the UCBs in the system could be accessed in ascending device number sequence by running through this chain. That was before dynamic changes to the I/O hardware became possible. You can no longer run through the UCB chain by using this field, which is now used for other information. There is a UCB service called UCBLOOK, described in both the Authorized and the Unauthorized System Services books, to run through the chain of UCBs. But this new service uses an internal look-up table to find the address of each next UCB in the chain. This look-up table is not externally documented by IBM. It may be that the look-up table has a fullword for every possible I/O device number in the system, which means at least 2 times 65536 devices (two channel sets times 65536 possible 2-byte device numbers in each channel set). This is a lot of storage to use for a look-up table, and on many systems most of the entries would contain a zero, so there is probably some more storage-efficient scheme used for this look-up table. If you are building software that needs to use control blocks that you are going to design just for this software, you are free to manage your control blocks any way you way. Some of they might be chained together, or some of them might be managed through look-up tables. z/OS uses both techniques for system control blocks. Now to answer your question. How do you know that nobody else has updated your control block in such a way that will undo the updates you make to it? You don't, unless you control all the code that will ever update it, and you remember to serialize somehow with some type of lock before any such code updates the block and then unserializes when through with the update. IBM guarantees its system control blocks from being hosed by other parts of z/OS, and all authorized programs not written by IBM (mostly vendor products) that access or update these control structures (locks) and control blocks must follow all the externally documented conventions or system integrity can be compromised. If you write authorized code, you follow all the rules, and you get weird results, then there may be some other authorized code changing the control block structure incorrectly. But it most likely will be your own code that is not strictly following all the documented rules. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield Sent: Friday, November 16, 2012 10:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "New" way to do UCB lookups Are you saying, that you can put some sort of "lock" on a control block, so that when you update it, you know that nobody else has updated it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
