Use NOPURGE in the global zone options member to not delete the PTFs when they are accepted (if that's what is desired). A cross zone query can be done to see if a resolving PTF for an APAR has been applied. Just replace the first character of the APAR number with an 'A'. In your example PMxxxxx would become AMxxxxx. If a superseding PTF has been replied it will show SUP.
Bill Skeldum -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Hoelscher Sent: Tuesday, December 03, 2013 8:17 AM To: [email protected] Subject: Re: When should we ACCEPT DB2 PTFs? I NEVER accept PTFS - but for an entirely different reason I like to build meaningful reports as to what has been applied - when applied, the corresponding APAR#, a description, is it hiper? The RSU to which it belongs, and the owning product affected by the PTF To build this report - I run a LISTMCS to create a ptf/apar xref - BUT ACCEPTING the ptf removes entry from the MCS (when I ACCEPTED the FMIDs at instell time, I first captured the apar/ptf xref for the ptfs that were bundled with the install - otherwise - after our semi-annual RSU apply (we are limited in how often we can apply proactive maint) - I run my report - but ACCEPTING PTFS would limit the effectiveness of my report - I am amazed how often I get a call - do we have PMxxxxx installed? To save a trip the IBM website - the xref comes in handy Chris hoelscher Technology Architect | Database Infrastructure Services Technology Solution Services 123 East Main Street |Louisville, KY 40202 [email protected] Humana.com (502) 476-2538 - office (502) 714-8615 - blackberry Keeping CAS and Metavance safe for all HUMANAty -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Joel C. Ewing Sent: Saturday, November 23, 2013 10:29 AM To: [email protected] Subject: Re: [IBM-MAIN] When should we ACCEPT DB2 PTFs? I can't recall ever seeing such an ACCEPT recommendation from IBM, probably because your own installation maintenance practices play such a major role here. The only reason for not ACCEPTing PTFs (USERMODS and APAR fixes should typically never be accepted) is because you might need to RESTORE a PTF; but if you have been successfully running with a PTF installed for months, it is highly unlikely you would ever need to RESTORE it, and even if some subsequent error HOLD was placed on the PTF, if it is not an issue that has caused problems in your environment it is just as likely that a resolving PTF will become available allowing you to go forward in maintenance rather than having to back out the PTF. I have even had a few rare cases where I have bypassed an ERROR HOLD to force an ACCEPT of a PTF and "clean up" a zone when the nature of the error HOLD was such that it would clearly never be an issue for us. The most likely point at which you might actually need to do a RESTORE would be shortly after another mass APPLY of PTF's (not just any "next APPLY"). Failure to ACCEPT previous mass maintenance for PTFs already running in production sometime before doing the next mass APPLY means any RESTORE after that point is likely to also force a back out of PTFs with which you have been successfully running for months. I would expect this to add unnecessary risk by placing your system in configurations further at variance from those with which IBM and others (including your own installation) have done rigorous RSU-level testing. Joel C. Ewing On 11/22/2013 05:30 PM, Mike Schwab wrote: > How about not until IBM tells you to? As in "you must accept xxxx > before apply this PTF"? > > On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan <[email protected]> > wrote: >> IMO, the short answer is just before the next APPLY. >> >> HTH, >> -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
