This ongoing discussion prompts a question: Are dynamic IODF changes actually so prevalent in most environments (especially in Production) that the condition warrants that much consideration ? I, for one, would tend to doubt it. If it is the case in a 'sandbox' or development type environment, it's likely a tolerable condition. The advantage of using established facilities like UCBSCAN is that you can exploit parameters, like IOCTOKEN, to indicate if there is something of this nature happening and allows you the option of whether or not to react to it. In the case of DASD, the recommendation for some time has been to PIN the UCB if exclusivity is required and subsequently UNPIN it when it is no longer needed. These operations, of course, require authorization.
Frank. GSG Systems. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Sam Golob Sent: Wednesday, November 14, 2012 2:34 AM To: [email protected] Subject: "New" way to do UCB lookups Hi Folks, Somebody please enlighten me. If you're trying to scratch a dataset on a pack, and somebody else is in the middle of doing an IODF change at the time, what is the difference if you are obtaining a copy of the UCB (to determine what's on the disk pack), or the real UCB itself? I'm not expecting a complete answer from somebody, but I'd at least like a reference to a manual or manuals where the perspective and advantages/disadvantages of copied, (and captured) UCB's is explained, as opposed to the real UCB's. I want to read about it. Please show me where. Thanks. All the best........ Sam ---------------------------------------------------------------------- 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
