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 PMx 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 choelsc...@humana.com 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Saturday, November 23, 2013 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 before apply this PTF? On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com wrote: IMO, the short answer is just before the next APPLY. HTH, -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
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 PMx would become AMx. If a superseding PTF has been replied it will show SUP. Bill Skeldum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Hoelscher Sent: Tuesday, December 03, 2013 8:17 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 PMx 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 choelsc...@humana.com 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Saturday, November 23, 2013 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 before apply this PTF? On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com wrote: IMO, the short answer is just before the next APPLY. HTH, -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu 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
Re: 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 before apply this PTF? On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com wrote: IMO, the short answer is just before the next APPLY. HTH, -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
IMO, the short answer is just before the next APPLY. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
How about not until IBM tells you to? As in you must accept before apply this PTF? On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com wrote: IMO, the short answer is just before the next APPLY. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
On Wed, 20 Nov 2013 20:36:15 -0500, Robert A. Rosenberg wrote: One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. That's the hard way. It is much easier to receive current hold data and run REPORT ERRORSYSMODS against the target zone. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
At 07:30 -0600 on 11/21/2013, Tom Marchant wrote about Re: When should we ACCEPT DB2 PTFs?: On Wed, 20 Nov 2013 20:36:15 -0500, Robert A. Rosenberg wrote: One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. That's the hard way. It is much easier to receive current hold data and run REPORT ERRORSYSMODS against the target zone. It has been a while since I was responsible for day to day SMP work. If as you say, REPORT ERRORSYSMODS will indicate that an APPLY'ed SYSMOD is now PE that that would look like a more efficient method than my ACCEPT CHECK one. The important thing is to find (and correct) the ticking timebomb that an APPLY'ed but now PE SYSMOD represents. No matter what method is used, the locating of PE'ed SYSMODs which were already APPLY'ed is IMO a good preventive practice. Hopefully this will not be something that occurs often and the longer you wait between the release of the SYSMODs and when you APPLY them, the more time there will be for the PE indication to occur before you do the APPLY. -- Tom Marchant -- 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
Re: When should we ACCEPT DB2 PTFs?
Cavet: I Know very little about DB2 However the let me say this about SMPE. The author did not go into detail about how their USERMOD's are designed. When I do a usermod it is for a stated level of a mod ie ++pre (). If I go to apply and find out there is conflict I just restore the usermod. I then apply as normal and after the the last PTF is applied I then go in and redo the usermod (with the correct pre's). Having said this I was quite surprised to hear that anyone one would have 20+ usermod's on DB2. When I do anything mass to a system I expect to have to rewrite 20+ usermods and would not find this abnormal. I just can't believe that DB2 was so messed up that it would require that many usermods. Maybe someone can speak up and say whether a typical DB2 site has that many usermods. Ed On Nov 19, 2013, at 9:47 PM, Robert A. Rosenberg wrote: At 03:11 -0600 on 11/19/2013, Alex wrote about When should we ACCEPT DB2 PTFs?: As you know, each DB2 RSU PTF package contains hundreds of PTFs. When we apply those PTFs, we may need to restore some USERMOD and related PTFs first and then proceed with applying task. If your problem is that to restore the USERMOD you must also restore PTFs, there is a solution that may work. If the USERMOD must be restored along with PTFs, you are going to need to rework it to have newer PREs to the new set of PTFs. Why not just create a new USERMOD that SUPs the old one and reapplies its contents. Since the USERMOD is going against a member that being replaced by a the new PTFs there would otherwise be no need to do the RESTORE to override the fact that the USERMOD is not listed as a PRE/SUP in the new PTF. Another solution is to just use UCLIN to delete the USERMOD entry on the module and then APPLY the USERMOD with the updated PRE info. -- 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
Re: When should we ACCEPT DB2 PTFs?
In 4562813219550940.wa.mathwstittbellsouth@listserv.ua.edu, on 11/19/2013 at 04:52 PM, Matthew Stitt mathwst...@bellsouth.net said: DB2 does not release PTFs on a Level Set basis. Who said anything about level sets? What should be a standard operating procedure is to order and receive PTFs on a daily basis. Why? You can download them when you want to do an APPLY, and automatically get the most recent hold data. When an Apply is done, any PTFs which are marked as being in error will not be Applied. So? That doesn't help if the error is not discovered until after you do the APPLY. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
At 00:28 -0500 on 11/20/2013, Shmuel Metz (Seymour J.) wrote about Re: When should we ACCEPT DB2 PTFs?: When an Apply is done, any PTFs which are marked as being in error will not be Applied. So? That doesn't help if the error is not discovered until after you do the APPLY. I agree. It bites you when it is time to do the ACCEPT. One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. You can then pull the designated fix PTFs (or APARs) if they exist and APPLY them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
When should we ACCEPT DB2 PTFs?
Dear friends, I have been confusing that when should we accept DB2 PTFs by SMP/E? As you know, each DB2 RSU PTF package contains hundreds of PTFs. When we apply those PTFs, we may need to restore some USERMOD and related PTFs first and then proceed with applying task. Let's say we need to apply 100 PTFs this time. Before that we restore 2 USERMODs and 50 related PTFs. Then we can apply those new 100 PTFs together with the 50 PTFs and 2 USERMODs we just restored. But if we don't accept the previous applied DB2 PTFs, we will probably get a huge PTFs chain (50 PTFs) during USERMODs restore operation. So my question is that when we should accept applied PTFs? Is there a criteria to make this decision? P.S. Accepting a PTF will take a risk that this PTE may go PE some day later. Looking forward to hearing your voice. Thank you! Alex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
W dniu 2013-11-19 10:11, Alex pisze: Dear friends, I have been confusing that when should we accept DB2 PTFs by SMP/E? As you know, each DB2 RSU PTF package contains hundreds of PTFs. When we apply those PTFs, we may need to restore some USERMOD and related PTFs first and then proceed with applying task. Let's say we need to apply 100 PTFs this time. Before that we restore 2 USERMODs and 50 related PTFs. Then we can apply those new 100 PTFs together with the 50 PTFs and 2 USERMODs we just restored. But if we don't accept the previous applied DB2 PTFs, we will probably get a huge PTFs chain (50 PTFs) during USERMODs restore operation. So my question is that when we should accept applied PTFs? Is there a criteria to make this decision? P.S. Accepting a PTF will take a risk that this PTE may go PE some day later. Looking forward to hearing your voice. Thank you! Some thoughts: 1. There are no clear straight criteria. It depends on many conditions. 2. Generally, the older PTF the smaller risk to ACCEPT it. 3. Beware: unaccepted PTFs may or may not be restorable. Good example is PTF with DELETE, but there are other cases, sometimes the ACTION need to be reverted, etc. IMHO the safe and convenient way to move back is to clone whole SMP/E environment (SMPE datasets, DLIBs, Targets LIBs). It costs some DASD (or just a tape) but it's quick and easy. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
Dear Radoslaw, Thank you very much for your sharing! Indeed, BACKUP is always helpful/important and should be keep in mind for our IT people. :-) Again, thanks and good luck to you! Alex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
My approach is to perform a backup and document of every major DB2 maintenance cycle. If I have relatively stable code I will accept what I have in production before starting a new cycle knowing full well I could revert to someting even earlier if need be. I am curious what usermod would have a PTF chain 50 sysmods long. DSNXGRDS and/or DSNUTILA for Hourglass - or something similar? IMO I would like to see IBM more closely couple those products and relieve the customer of that burden. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
In 4137735368258915.wa.szwangxdgmail@listserv.ua.edu, on 11/19/2013 at 03:11 AM, Alex szwan...@gmail.com said: I have been confusing that when should we accept DB2 PTFs by SMP/E? It's the same issue as for any other component or product. pick an aging interval that you're comfortable with and exclude service wqith an unresolved PE. I like 90 days, but YMMV. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
DB2 does not release PTFs on a Level Set basis. Believing there is a Level Set implies your company orders PTFs on a non-scheduled basis, say, every few months. What should be a standard operating procedure is to order and receive PTFs on a daily basis. If any PTFs you have not applied are found to have problems, the error hold will be received with the daily processing. Likewise with PTFs which have been accepted. When an Apply is done, any PTFs which are marked as being in error will not be Applied. Unless you choose to bypass the error hold. The same holds true for an Accept of the Applied PTFs. On Tue, 19 Nov 2013 12:39:34 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4137735368258915.wa.szwangxdgmail@listserv.ua.edu, on 11/19/2013 at 03:11 AM, Alex szwan...@gmail.com said: I have been confusing that when should we accept DB2 PTFs by SMP/E? It's the same issue as for any other component or product. pick an aging interval that you're comfortable with and exclude service wqith an unresolved PE. I like 90 days, but YMMV. -- Shmuel (Seymour J.) Metz, SysProg and JOAT \ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
At 03:11 -0600 on 11/19/2013, Alex wrote about When should we ACCEPT DB2 PTFs?: As you know, each DB2 RSU PTF package contains hundreds of PTFs. When we apply those PTFs, we may need to restore some USERMOD and related PTFs first and then proceed with applying task. If your problem is that to restore the USERMOD you must also restore PTFs, there is a solution that may work. If the USERMOD must be restored along with PTFs, you are going to need to rework it to have newer PREs to the new set of PTFs. Why not just create a new USERMOD that SUPs the old one and reapplies its contents. Since the USERMOD is going against a member that being replaced by a the new PTFs there would otherwise be no need to do the RESTORE to override the fact that the USERMOD is not listed as a PRE/SUP in the new PTF. Another solution is to just use UCLIN to delete the USERMOD entry on the module and then APPLY the USERMOD with the updated PRE info. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
