yeah s
http://www.medmutual.com/ Visit http://www.medmutual.com/ CONFIDENTIALITY NOTICE: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message. Thank you, Medical Mutual. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, November 14, 2012 5:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "New" way to do UCB lookups Frank, In one environment it was at least a weekly occurrence. In others once a month and others every 6 months, In the "weekly" environment it was a lively change management adventure as we did have several outages (sometime entire sysplex) It was fraught with issues and maybe if we had been more aggressive with maintenance the outage might not have happened. But the boss bought off on the chances, so... We did not have the man power to stay current like we should have been in that type of environment, but the boss yelled a few times and chasing down the cause was not a witch hunt per se but we just tried to tell them about issues and that is all we could do. At times we would get DASD that had data on it from a previous installation. The DASD people just wiped it out without looking or caring. As for CPU's it was at times scary (at least for me) as we had so many issue with OEM vendors that We had so many serial numbers floating around it was a PITA. That was scarier (to me) that the upgrades. I won't even go into tape drives types. Ed Ed On Nov 14, 2012, at 1:39 PM, Bonaduce, Frank wrote: > 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:IBM- m...@listserv.ua.edu] > On Behalf Of Sam Golob > Sent: Wednesday, November 14, 2012 2:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
