Re: RSU maintenance strategy - Need expert suggestions
Hi All, Thanks very much for your timely and quick response. Yes have proposed a strategy to the customer and will be reviewed by early next year. I will have some follow-up questions regarding the same and will post to get some advise. Thanks again. On Tue, Dec 12, 2017 at 1:32 AM, Edward Gould wrote: > Mark, > > > On Dec 9, 2017, at 12:32 PM, Mark Zelden wrote: > > > > And then you just apply everything that turns up in MISSINGFIX for > > FIXCAT(*) along with the RSU maintenance? > > > > Why install a 100% of missing maintenance specific to some hardware or > hardware > > feature you don't have or for some function you aren't using or planning > to use > > ahead of the time it has been fully tested via CST and shows up with an > RSU sourceid? > > What's to gain? To me it just seems more likely you could install a PTF > that will end > > up PE'd. > > > > Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" > - but that's the > > point of putting on general preventive maintenance. However, it also > does > > include critical maintenance as well - PE fixes, HIPERs and security / > integrity. > > > > I guess we'll have to agree to disagree on this one. > > > > Regards, > > I will go along with you on this one. Once in a while you will find a > chain so long it makes you ill. A long time ago, I chased a chain that had > 3500 (thats right) 3500 ptfs waiting to go on because of one fix. I think > that is when my hair color started to turn gray. I can see chasing 3 or 4 > PTF’s but 3500 was out off the park for me. > To get to your other points, I do not lay back and wait, everyday I am > working I look for the hipers and the security/Integrity fixes on IBMLINK. > I like to be proactive in this area as one time we had an auditor that > thought he would get one over on me. He sent an email to the VP and asked > if we had this specific PTF on as he thought it was important. The VP > passes it on down the line to me. I looked it up and it didn’t even pertain > to our system, so I thought I would do him one better and found the PTF in > question and told him in English that the PTF did NOT involve our system > but this PTF did. I did a cut and paste into the email of the cover letter > and the pre’s and Co’s and that PTF had been on the system for 6 months. I > then said to him in the future please call or email me directly so we > didn’t tie up management in issues that we could handle quicker and more > completely via email/phone call as we were there to serve him. That stopped > the ambush’s. A few weeks later I get an email and didn’t reply to him the > same day but the next day I replied again that the fix was not for our > system but this one was and again I told him it had been on for 7 months. > He tried it once more and I told him the same story except this one had > been on a year. I smelled something fishy, I dropped by his desk when he > wasn’t there and asked his team mate what was going on with these requests > and he told me that VP of Auditing had become friends with another auditor > in another shop and the *other* auditor was trying for a promotion and that > he had some MVS sysprog feeding him these PTF numbers. > > Ed > > > -- > 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: RSU maintenance strategy - Need expert suggestions
Mark, > On Dec 9, 2017, at 12:32 PM, Mark Zelden wrote: > > And then you just apply everything that turns up in MISSINGFIX for > FIXCAT(*) along with the RSU maintenance? > > Why install a 100% of missing maintenance specific to some hardware or > hardware > feature you don't have or for some function you aren't using or planning to > use > ahead of the time it has been fully tested via CST and shows up with an RSU > sourceid? > What's to gain? To me it just seems more likely you could install a PTF that > will end > up PE'd. > > Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but > that's the > point of putting on general preventive maintenance. However, it also does > include critical maintenance as well - PE fixes, HIPERs and security / > integrity. > > I guess we'll have to agree to disagree on this one. > > Regards, I will go along with you on this one. Once in a while you will find a chain so long it makes you ill. A long time ago, I chased a chain that had 3500 (thats right) 3500 ptfs waiting to go on because of one fix. I think that is when my hair color started to turn gray. I can see chasing 3 or 4 PTF’s but 3500 was out off the park for me. To get to your other points, I do not lay back and wait, everyday I am working I look for the hipers and the security/Integrity fixes on IBMLINK. I like to be proactive in this area as one time we had an auditor that thought he would get one over on me. He sent an email to the VP and asked if we had this specific PTF on as he thought it was important. The VP passes it on down the line to me. I looked it up and it didn’t even pertain to our system, so I thought I would do him one better and found the PTF in question and told him in English that the PTF did NOT involve our system but this PTF did. I did a cut and paste into the email of the cover letter and the pre’s and Co’s and that PTF had been on the system for 6 months. I then said to him in the future please call or email me directly so we didn’t tie up management in issues that we could handle quicker and more completely via email/phone call as we were there to serve him. That stopped the ambush’s. A few weeks later I get an email and didn’t reply to him the same day but the next day I replied again that the fix was not for our system but this one was and again I told him it had been on for 7 months. He tried it once more and I told him the same story except this one had been on a year. I smelled something fishy, I dropped by his desk when he wasn’t there and asked his team mate what was going on with these requests and he told me that VP of Auditing had become friends with another auditor in another shop and the *other* auditor was trying for a promotion and that he had some MVS sysprog feeding him these PTF numbers. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
We install RSU four times a year. It definitely does not require 1 FTE. I would estimate it takes us about 16-32 man hours per quarter covering both z/OS and DB2. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ANIL KUMAR Sent: Wednesday, December 06, 2017 11:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU maintenance strategy - Need expert suggestions This email originated from outside of the organization. Hi All, I needed expert suggestions on following the RSU maintenance strategy for z/OS , associated ISV products , DB2 etc. Could you please let me know 1) How many times in a year do we need to apply the maintenance to z/os , ISV products , DB2 etc. 2) How to decide which ones to be applied. (latest RSU) 3) Whether the HIPERs included also be applied , even though we have not encountered the specific issues in out shop. So far in the account I was working for , it was not a strict rule to apply maintenance be it z/OS or DB2 or associated ISV product. Infact I do not remember any maintenance being applied to DB2 unless it was a major upgrade for which the pre-req was needed. Even for ISV's if they are running fine, then no action was taken. However for a different shop , we have been asked to come up with the best approach on whats needs to be done. If we keep updating the maintenance then 1 FTE job will be consumed for the work for a year. Hence needed some advise on what strategy is being used by different shops and what is the best practice. Please advise. If any documents etc are available please point me to them and I shall read. Sincerely hoping to get some advise. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
Our recommendations (for IBM products) are here: https://www-03.ibm.com/systems/resources/zOS_Preventive_Maintenance_Strategy.pdf ANIL KUMAR wrote: Hi All, I needed expert suggestions on following the RSU maintenance strategy for z/OS , associated ISV products , DB2 etc. Could you please let me know -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
Skip - I think you contradicted yourself too. When you were talking about RSU you wrote that it contains "new function that we can live without a little while longer". Well, if you run a REPORT MISSINGFIX FIXCAT(*) and apply all that maintenance, you are doing the exact opposite. You're putting on every single PTF related to some "function you can live without for a while longer" (because it will end up on RSU if not PE'd) or for a function / hardware you won't ever use. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Sat, 9 Dec 2017 12:32:11 -0600, Mark Zelden wrote: >And then you just apply everything that turns up in MISSINGFIX for >FIXCAT(*) along with the RSU maintenance? > >Why install a 100% of missing maintenance specific to some hardware or >hardware >feature you don't have or for some function you aren't using or planning to use >ahead of the time it has been fully tested via CST and shows up with an RSU >sourceid? >What's to gain? To me it just seems more likely you could install a PTF that >will end >up PE'd. > >Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but >that's the >point of putting on general preventive maintenance. However, it also does >include critical maintenance as well - PE fixes, HIPERs and security / >integrity. > >I guess we'll have to agree to disagree on this one. > >Regards, > >Mark >-- >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >ITIL v3 Foundation Certified >mailto:m...@mzelden.com >Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html >Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > >On Sat, 9 Dec 2017 03:55:24 +, Jesse 1 Robinson >wrote: > >>We do have specific FIXCAT runs for scheduled hardware or software upgrades, >>but this is the blanket report we run to cover all the bases in the ninth >>inning of a general maintenance upgrade. (Pardon the baseball metaphor.) >> >>REPORT MISSINGFIX >> FIXCAT(*) >> ZONES(MVST100) >> >>My view is that RSU incorporates a lot of PTFs that are not necessarily >>critical. Many range from cosmetic to new function that we can live without a >>little while longer. All are good to have at some point but do not >>necessarily bear on immediate operability. FIXCAT OTOH is more likely to >>focus HIPERs and really important stuff that should be swept in to the mix if >>feasible, especially if a -n RSU has been chosen. >> >>Once again, I imagine what I will tell the boss. ;-) >> >>. >>. >>J.O.Skip Robinson >>Southern California Edison Company >>Electric Dragon Team Paddler >>SHARE MVS Program Co-Manager >>323-715-0595 Mobile >>626-543-6132 Office ⇐=== NEW >>robin...@sce.com >> >> >>-Original Message- >>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>Behalf Of Mark Zelden >>Sent: Friday, December 08, 2017 3:27 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: (External):Re: RSU maintenance strategy - Need expert suggestions >> >>On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant >>wrote: >> >>>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote: >>> >>>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: >>>> >>>>>... As others have suggested, pay attention to HIPER and FIXCAT, and >>>>>ERRORSYSMOD reports. >>>> >>>>What Skip said! ... >>>> >>>>The part I wanted to stress the Skip wrote (and why I chimed in) was >>>>his advise to pull the HOLDDATA and run report errorsysmods when you decide >>>>to go forward. >>> >>>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX >>>report. >>>And receive the latest HOLDDATA before every APPLY and ACCEPT. >>> >> >>Of course that won't hurt, but the time to run MISSINGFIX is when you are >>implementing new hardware features, new software features, OS upgrades etc. >> >>What FIXCAT categories do you do it on for normal maintenance? I could see >>running it for >>IBM.TargetSystem-RequiredService.z/OS.* and >>IBM.TargetSystem-RequiredService.z/OSMF.*, >>but if a PTF was recommended for your current release it would have an RSU* >
Re: RSU maintenance strategy - Need expert suggestions
And then you just apply everything that turns up in MISSINGFIX for FIXCAT(*) along with the RSU maintenance? Why install a 100% of missing maintenance specific to some hardware or hardware feature you don't have or for some function you aren't using or planning to use ahead of the time it has been fully tested via CST and shows up with an RSU sourceid? What's to gain? To me it just seems more likely you could install a PTF that will end up PE'd. Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but that's the point of putting on general preventive maintenance. However, it also does include critical maintenance as well - PE fixes, HIPERs and security / integrity. I guess we'll have to agree to disagree on this one. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Sat, 9 Dec 2017 03:55:24 +, Jesse 1 Robinson wrote: >We do have specific FIXCAT runs for scheduled hardware or software upgrades, >but this is the blanket report we run to cover all the bases in the ninth >inning of a general maintenance upgrade. (Pardon the baseball metaphor.) > >REPORT MISSINGFIX > FIXCAT(*) > ZONES(MVST100) > >My view is that RSU incorporates a lot of PTFs that are not necessarily >critical. Many range from cosmetic to new function that we can live without a >little while longer. All are good to have at some point but do not necessarily >bear on immediate operability. FIXCAT OTOH is more likely to focus HIPERs and >really important stuff that should be swept in to the mix if feasible, >especially if a -n RSU has been chosen. > >Once again, I imagine what I will tell the boss. ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ⇐=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Mark Zelden >Sent: Friday, December 08, 2017 3:27 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: RSU maintenance strategy - Need expert suggestions > >On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant >wrote: > >>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote: >> >>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: >>> >>>>... As others have suggested, pay attention to HIPER and FIXCAT, and >>>>ERRORSYSMOD reports. >>> >>>What Skip said! ... >>> >>>The part I wanted to stress the Skip wrote (and why I chimed in) was >>>his advise to pull the HOLDDATA and run report errorsysmods when you decide >>>to go forward. >> >>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX >>report. >>And receive the latest HOLDDATA before every APPLY and ACCEPT. >> > >Of course that won't hurt, but the time to run MISSINGFIX is when you are >implementing new hardware features, new software features, OS upgrades etc. > >What FIXCAT categories do you do it on for normal maintenance? I could see >running it for >IBM.TargetSystem-RequiredService.z/OS.* and >IBM.TargetSystem-RequiredService.z/OSMF.*, >but if a PTF was recommended for your current release it would have an RSU* >sourceid also >so that seems like an extra step that doesn't add value. > >Regards, > >Mark >-- >Mark Zelden - Zdlden Consulting Services - z/OS, OS/390 and MVS ITIL v3 >Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: >http://www.mzelden.com/mvsutil.html >Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > >-- >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: RSU maintenance strategy - Need expert suggestions
We do have specific FIXCAT runs for scheduled hardware or software upgrades, but this is the blanket report we run to cover all the bases in the ninth inning of a general maintenance upgrade. (Pardon the baseball metaphor.) REPORT MISSINGFIX FIXCAT(*) ZONES(MVST100) My view is that RSU incorporates a lot of PTFs that are not necessarily critical. Many range from cosmetic to new function that we can live without a little while longer. All are good to have at some point but do not necessarily bear on immediate operability. FIXCAT OTOH is more likely to focus HIPERs and really important stuff that should be swept in to the mix if feasible, especially if a -n RSU has been chosen. Once again, I imagine what I will tell the boss. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Friday, December 08, 2017 3:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RSU maintenance strategy - Need expert suggestions On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant wrote: >On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote: > >>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: >> >>>... As others have suggested, pay attention to HIPER and FIXCAT, and >>>ERRORSYSMOD reports. >> >>What Skip said! ... >> >>The part I wanted to stress the Skip wrote (and why I chimed in) was >>his advise to pull the HOLDDATA and run report errorsysmods when you decide >>to go forward. > >I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX >report. >And receive the latest HOLDDATA before every APPLY and ACCEPT. > Of course that won't hurt, but the time to run MISSINGFIX is when you are implementing new hardware features, new software features, OS upgrades etc. What FIXCAT categories do you do it on for normal maintenance? I could see running it for IBM.TargetSystem-RequiredService.z/OS.* and IBM.TargetSystem-RequiredService.z/OSMF.*, but if a PTF was recommended for your current release it would have an RSU* sourceid also so that seems like an extra step that doesn't add value. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant wrote: >On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote: > >>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: >> >>>... As others have suggested, pay attention to HIPER and FIXCAT, and >>>ERRORSYSMOD reports. >> >>What Skip said! ... >> >>The part I wanted to stress the Skip wrote (and why I chimed in) was his >>advise to pull >>the HOLDDATA and run report errorsysmods when you decide to go forward. > >I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX >report. >And receive the latest HOLDDATA before every APPLY and ACCEPT. > Of course that won't hurt, but the time to run MISSINGFIX is when you are implementing new hardware features, new software features, OS upgrades etc. What FIXCAT categories do you do it on for normal maintenance? I could see running it for IBM.TargetSystem-RequiredService.z/OS.* and IBM.TargetSystem-RequiredService.z/OSMF.*, but if a PTF was recommended for your current release it would have an RSU* sourceid also so that seems like an extra step that doesn't add value. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
I usually try to implement maintenance twice a year, but each shop is somewhat different, depending upon ipl schedule, size of shop, workload, etc. If you're looking for a doc to justify your decision, there is this: https://www-03.ibm.com/systems/resources/zOS_Preventive_Maintenance_Strategy.pdf Bobbie Jo Justice Senior Systems Engineer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote: >On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: > >>... As others have suggested, pay attention to HIPER and FIXCAT, and >>ERRORSYSMOD reports. > >What Skip said! ... > >The part I wanted to stress the Skip wrote (and why I chimed in) was his >advise to pull >the HOLDDATA and run report errorsysmods when you decide to go forward. I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX report. And receive the latest HOLDDATA before every APPLY and ACCEPT. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote: >Each shop needs to craft its own policy on software maintenance. At one time >not that long ago, a new z/OS release came out every six months (!). Many >shops skipped releases because they didn't have time for each one. Now the >release interval is two years, which changes the scheduling dynamic a lot. As >others have suggested, pay attention to HIPER and FIXCAT, and ERRORSYSMOD >reports. > >I thi k the best practice is to install a recent RSU--maybe the latest, maybe >one back--with a few extra important fixes (as above) laid on top. The *day* >you decide to go forward, pull HOLDDATA one more time and revise your plan if >necessary. Do this as frequently as your enterprise can tolerate. If it takes >you months to roll out maintenance to all LPARs, that extends the update >interval. However, it also raises the importance of being as current as >possible when you leave the starting gate. > >Here is my guiding ROT. If something goes seriously south in my system, I >imagine having to explain it to my boss. If it turns out that the vendor >issued some kind of alert for this issue... > >1. I took the recommended action, which turneo out to cause yet a worse >problem. >2. I decided that we would not be impacted, so I chose to ignore the alert. > >I would not want to have to defend #2. > >. What Skip said! Hopefully at least quarterly RSU. If not that, twice a year. I know some shops have LPARs that can only be IPLed once a year. Obviously they are not getting quarterly RSU maintenance rolled out the easy way (via IPL). The part I wanted to stress the Skip wrote (and why I chimed in) was his advise to pull the HOLDDATA and run report errorsysmods when you decide to go forward. For me it isn't "the day of", but it will be on Friday of the weekend of the scheduled IPLs. Since it takes at least a couple of months to roll out to 30 LPARs, I run it again before the next set of IPLs (different sysplexes / environments can run into different problems). My client did get burned big time once with an LE PTF to support Enterprise COBOL 4 (IIRC) that broke COBOL behavior with Enterprise COBOL 3. I think it went PE on the Thursday or Friday before the IPLs and we didn't know. It caused days and weeks of re-runs of some applications because the problem with the data wasn't found immediately. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
As others have said, there is no one size fits all either for rollout strategy or for frequency. You need to analyze the history, policies and requirements of your shop. The one thing that I would urge is frequent downloading of HOLDDATA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ANIL KUMAR Sent: Wednesday, December 6, 2017 11:55 PM To: IBM-MAIN@listserv.ua.edu Subject: RSU maintenance strategy - Need expert suggestions Hi All, I needed expert suggestions on following the RSU maintenance strategy for z/OS , associated ISV products , DB2 etc. Could you please let me know 1) How many times in a year do we need to apply the maintenance to z/os , ISV products , DB2 etc. 2) How to decide which ones to be applied. (latest RSU) 3) Whether the HIPERs included also be applied , even though we have not encountered the specific issues in out shop. So far in the account I was working for , it was not a strict rule to apply maintenance be it z/OS or DB2 or associated ISV product. Infact I do not remember any maintenance being applied to DB2 unless it was a major upgrade for which the pre-req was needed. Even for ISV's if they are running fine, then no action was taken. However for a different shop , we have been asked to come up with the best approach on whats needs to be done. If we keep updating the maintenance then 1 FTE job will be consumed for the work for a year. Hence needed some advise on what strategy is being used by different shops and what is the best practice. Please advise. If any documents etc are available please point me to them and I shall read. Sincerely hoping to get some advise. Thanks. -- 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: RSU maintenance strategy - Need expert suggestions
My strategy was to weekly, via an automated process receive EHOLDATA, and monthly apply RSU maint, but only move the maint to prod twice a year. exceptions are to prepare for hardware upgrades, apply HIPERs, or PTF to fix an issue, and to apply toleration maint for z/OS upgrades. my 2.2 system was ordered at an RSU1701 level, I'm just now preparing to apply 1709 to production. my predecessor and his boss only wanted to apply MAINT in preparation for an upgrade, so once a year, I finally talked him into semi annually makes my job easier Carmen Vitullo - Original Message - From: "Dave Gibney" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, December 7, 2017 1:38:45 PM Subject: Re: RSU maintenance strategy - Need expert suggestions I do it on an irregular basis, usually in preparations for a z/OS upgrade, or because it seems like it's been too long. And yep, Sandbox, Sandbox, Development, Production. In sequence and with time at each stage. > > > > On Dec 7, 2017, at 9:37 AM, Allan Staller wrote: > > > > Hi All, > > > > I needed expert suggestions on following the RSU maintenance strategy > > for z/OS , associated ISV products , DB2 etc. Could you please let me > > know > > > > 1) How many times in a year do we need to apply the maintenance to z/os , > ISV products , DB2 etc. > > 2) How to decide which ones to be applied. (latest RSU) > > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major > upgrade for which the pre-req was needed. Even for ISV's if they are running > fine, then no action was taken. > > > > However for a different shop , we have been asked to come up with the > best approach on whats needs to be done. If we keep updating the > maintenance then 1 FTE job will be consumed for the work for a year. > > > > Hence needed some advise on what strategy is being used by different > shops and what is the best practice. Please advise. > > > > If any documents etc are available please point me to them and I shall > > read. > Sincerely hoping to get some advise. Thanks. -- 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: RSU maintenance strategy - Need expert suggestions
Each shop needs to craft its own policy on software maintenance. At one time not that long ago, a new z/OS release came out every six months (!). Many shops skipped releases because they didn't have time for each one. Now the release interval is two years, which changes the scheduling dynamic a lot. As others have suggested, pay attention to HIPER and FIXCAT, and ERRORSYSMOD reports. I think the best practice is to install a recent RSU--maybe the latest, maybe one back--with a few extra important fixes (as above) laid on top. The *day* you decide to go forward, pull HOLDDATA one more time and revise your plan if necessary. Do this as frequently as your enterprise can tolerate. If it takes you months to roll out maintenance to all LPARs, that extends the update interval. However, it also raises the importance of being as current as possible when you leave the starting gate. Here is my guiding ROT. If something goes seriously south in my system, I imagine having to explain it to my boss. If it turns out that the vendor issued some kind of alert for this issue... 1. I took the recommended action, which turned out to cause yet a worse problem. 2. I decided that we would not be impacted, so I chose to ignore the alert. I would not want to have to defend #2. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Purdy Sent: Thursday, December 07, 2017 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RSU maintenance strategy - Need expert suggestions Also consider maintenance timing and levels for a z/OS upgrade. We had a maintenance level gap between the running and new z/OS, and an IDCAMS return code changed in the maintenance gap. It could have been worse. I modified the maintenance strategy to update the old release at a higher or equal level than the new release. Lower risk/exposure, but not completely eliminated. We're doing an RSU + HIPER + assorted FIXCAT per year and just before a new z/OS, hardware, or major program product. I'm reviewing an automated weekly holddata download and reporting on applied PTFs now in PE status. Just don't have the manpower to do it more frequently. Sign up for red alerts as well. Possibly excessive paranoia. David On Thursday, December 7, 2017 Edward Gould wrote: > On Dec 7, 2017, at 9:37 AM, Allan Staller wrote: > > Hi All, > > I needed expert suggestions on following the RSU maintenance strategy > for z/OS , associated ISV products , DB2 etc. Could you please let me > know > > 1) How many times in a year do we need to apply the maintenance to z/os , ISV > products , DB2 etc. > 2) How to decide which ones to be applied. (latest RSU) > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major upgrade > for which the pre-req was needed. Even for ISV's if they are running fine, > then no action was taken. > > However for a different shop , we have been asked to come up with the best > approach on whats needs to be done. If we keep updating the maintenance then > 1 FTE job will be consumed for the work for a year. > > Hence needed some advise on what strategy is being used by different shops > and what is the best practice. Please advise. > > If any documents etc are available please point me to them and I shall read. > Sincerely hoping to get some advise. Thanks. Allan, As other have said each shop is different. The idea of putting RSU maintenance in test for 4 weeks, then pre production, then production and letting them cook as I call it, is for the installation I work is sufficient. In previous environments it was not practical as we didn’t have the hardware to have the luxury of doing the cooking process and we usually came in on Sundays at 3AM and did our testing ourselves. *IF* you got the resources by all means do it as others suggested. The only caveat I will throw in is to every day look at any hipers and *know* your system to see if they pertain to you, also look at logrec every morning to see what software hits you took the night before and see if there are many duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t schedule an IPL), KNOW your system and once you get the feel you will be able to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just order and receive them so if you ne
Re: RSU maintenance strategy - Need expert suggestions
I do it on an irregular basis, usually in preparations for a z/OS upgrade, or because it seems like it's been too long. And yep, Sandbox, Sandbox, Development, Production. In sequence and with time at each stage. > > > > On Dec 7, 2017, at 9:37 AM, Allan Staller wrote: > > > > Hi All, > > > > I needed expert suggestions on following the RSU maintenance strategy > > for z/OS , associated ISV products , DB2 etc. Could you please let me > > know > > > > 1) How many times in a year do we need to apply the maintenance to z/os , > ISV products , DB2 etc. > > 2) How to decide which ones to be applied. (latest RSU) > > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major > upgrade for which the pre-req was needed. Even for ISV's if they are running > fine, then no action was taken. > > > > However for a different shop , we have been asked to come up with the > best approach on whats needs to be done. If we keep updating the > maintenance then 1 FTE job will be consumed for the work for a year. > > > > Hence needed some advise on what strategy is being used by different > shops and what is the best practice. Please advise. > > > > If any documents etc are available please point me to them and I shall read. > Sincerely hoping to get some advise. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
Also consider maintenance timing and levels for a z/OS upgrade. We had a maintenance level gap between the running and new z/OS, and an IDCAMS return code changed in the maintenance gap. It could have been worse. I modified the maintenance strategy to update the old release at a higher or equal level than the new release. Lower risk/exposure, but not completely eliminated. We're doing an RSU + HIPER + assorted FIXCAT per year and just before a new z/OS, hardware, or major program product. I'm reviewing an automated weekly holddata download and reporting on applied PTFs now in PE status. Just don't have the manpower to do it more frequently. Sign up for red alerts as well. Possibly excessive paranoia. David On Thursday, December 7, 2017 Edward Gould wrote: > On Dec 7, 2017, at 9:37 AM, Allan Staller wrote: > > Hi All, > > I needed expert suggestions on following the RSU maintenance strategy for > z/OS , associated ISV products , DB2 etc. Could you please let me know > > 1) How many times in a year do we need to apply the maintenance to z/os , ISV > products , DB2 etc. > 2) How to decide which ones to be applied. (latest RSU) > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major upgrade > for which the pre-req was needed. Even for ISV's if they are running fine, > then no action was taken. > > However for a different shop , we have been asked to come up with the best > approach on whats needs to be done. If we keep updating the maintenance then > 1 FTE job will be consumed for the work for a year. > > Hence needed some advise on what strategy is being used by different shops > and what is the best practice. Please advise. > > If any documents etc are available please point me to them and I shall read. > Sincerely hoping to get some advise. Thanks. Allan, As other have said each shop is different. The idea of putting RSU maintenance in test for 4 weeks, then pre production, then production and letting them cook as I call it, is for the installation I work is sufficient. In previous environments it was not practical as we didn’t have the hardware to have the luxury of doing the cooking process and we usually came in on Sundays at 3AM and did our testing ourselves. *IF* you got the resources by all means do it as others suggested. The only caveat I will throw in is to every day look at any hipers and *know* your system to see if they pertain to you, also look at logrec every morning to see what software hits you took the night before and see if there are many duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t schedule an IPL), KNOW your system and once you get the feel you will be able to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just order and receive them so if you need to put them on its easy. I put maintenance on that and always tested it out, it was my own system. Before it affected anyone I wanted to know. Now, there are some components that lets say don’t always send out reliable fixes, those I keep careful track of and handle them gingerly as testing tends not to catch these PTFs , I will not say which components as they have changed from time to time, but you will know after you baby sit the systems for a couple of years. Ed -- 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: RSU maintenance strategy - Need expert suggestions
> On Dec 7, 2017, at 9:37 AM, Allan Staller wrote: > > Hi All, > > I needed expert suggestions on following the RSU maintenance strategy for > z/OS , associated ISV products , DB2 etc. Could you please let me know > > 1) How many times in a year do we need to apply the maintenance to z/os , ISV > products , DB2 etc. > 2) How to decide which ones to be applied. (latest RSU) > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major upgrade > for which the pre-req was needed. Even for ISV's if they are running fine, > then no action was taken. > > However for a different shop , we have been asked to come up with the best > approach on whats needs to be done. If we keep updating the maintenance then > 1 FTE job will be consumed for the work for a year. > > Hence needed some advise on what strategy is being used by different shops > and what is the best practice. Please advise. > > If any documents etc are available please point me to them and I shall read. > Sincerely hoping to get some advise. Thanks. Allan, As other have said each shop is different. The idea of putting RSU maintenance in test for 4 weeks, then pre production, then production and letting them cook as I call it, is for the installation I work is sufficient. In previous environments it was not practical as we didn’t have the hardware to have the luxury of doing the cooking process and we usually came in on Sundays at 3AM and did our testing ourselves. *IF* you got the resources by all means do it as others suggested. The only caveat I will throw in is to every day look at any hipers and *know* your system to see if they pertain to you, also look at logrec every morning to see what software hits you took the night before and see if there are many duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t schedule an IPL), KNOW your system and once you get the feel you will be able to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just order and receive them so if you need to put them on its easy. I put maintenance on that and always tested it out, it was my own system. Before it affected anyone I wanted to know. Now, there are some components that lets say don’t always send out reliable fixes, those I keep careful track of and handle them gingerly as testing tends not to catch these PTFs , I will not say which components as they have changed from time to time, but you will know after you baby sit the systems for a couple of years. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
YMMV. The answer is whatever works for your shop. There are as many choices as shops. I generally apply PUT (not RSU) maintenance twice annually to (current -2) for the major subsystems. The choice between PUT and RSU is up to your installation. IVS maintenance is applied "as needed" to support the above activities. Given IBMs recent conversion to 2 year release cycles, I have given some thought to moving to once annually for maintenance. No decision has yet been reached. I.E. if PUT1712 (or RSU1712) is current, I will apply bulk maintenance through PUT1710/RSU1710 Many moons ago, when PUTs (Program Update Tape) were shipped regularly from IBM (and the documentation was available), it was noted that virtually all PE's generated by a particular PUT tape were reported within 60 days. Thus, at N-2 by appropriate exclusion of PTFS, you could have a virtually trouble free installation for that particular tape. I have seen nothing to indicate the underlying ecosystem has changed and continue to use current-2. HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ANIL KUMAR Sent: Wednesday, December 6, 2017 10:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU maintenance strategy - Need expert suggestions Hi All, I needed expert suggestions on following the RSU maintenance strategy for z/OS , associated ISV products , DB2 etc. Could you please let me know 1) How many times in a year do we need to apply the maintenance to z/os , ISV products , DB2 etc. 2) How to decide which ones to be applied. (latest RSU) 3) Whether the HIPERs included also be applied , even though we have not encountered the specific issues in out shop. So far in the account I was working for , it was not a strict rule to apply maintenance be it z/OS or DB2 or associated ISV product. Infact I do not remember any maintenance being applied to DB2 unless it was a major upgrade for which the pre-req was needed. Even for ISV's if they are running fine, then no action was taken. However for a different shop , we have been asked to come up with the best approach on whats needs to be done. If we keep updating the maintenance then 1 FTE job will be consumed for the work for a year. Hence needed some advise on what strategy is being used by different shops and what is the best practice. Please advise. If any documents etc are available please point me to them and I shall read. Sincerely hoping to get some advise. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message w
Re: RSU maintenance strategy - Need expert suggestions
We do maintenance twice per year. The process to migrate from TECH->DEV->PROD takes us approx. 8-12 weeks allowing time for the maintenance to age in TECH for at least a month while testing, then moving to DEV for at least a month before moving to PROD. PROD is done over a period of 4 weeks. So, when we start maintenance process, we usually select maintenance a little bit greener than IBM suggests, knowing that it will age before going to prod, so I usually select current PUT-1, and current RSU to apply+select FIXCAT groups, followed by monitoring ERRORSYSMOD report, and applying HIPER, XSYSTEM, SECINT iteratively, until we are a couple weeks from going to PROD at which time things get locked down. I also tend to go look on ShopZ to see if any of the ancillary IBM products have upgrades, and order/install/maintenance those, which makes the next z/OS upgrade much easier, as it usually ends up being just the OS itself getting the upgrade, and not all the APP DEV tools, etc. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ANIL KUMAR Sent: Wednesday, December 06, 2017 11:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU maintenance strategy - Need expert suggestions **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi All, I needed expert suggestions on following the RSU maintenance strategy for z/OS , associated ISV products , DB2 etc. Could you please let me know 1) How many times in a year do we need to apply the maintenance to z/os , ISV products , DB2 etc. 2) How to decide which ones to be applied. (latest RSU) 3) Whether the HIPERs included also be applied , even though we have not encountered the specific issues in out shop. So far in the account I was working for , it was not a strict rule to apply maintenance be it z/OS or DB2 or associated ISV product. Infact I do not remember any maintenance being applied to DB2 unless it was a major upgrade for which the pre-req was needed. Even for ISV's if they are running fine, then no action was taken. However for a different shop , we have been asked to come up with the best approach on whats needs to be done. If we keep updating the maintenance then 1 FTE job will be consumed for the work for a year. Hence needed some advise on what strategy is being used by different shops and what is the best practice. Please advise. If any documents etc are available please point me to them and I shall read. Sincerely hoping to get some advise. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU maintenance strategy - Need expert suggestions
My shop did it once a quarter. Can you take the time to review each Hyper / RSU for PTFs that fix a problem your site is having and apply as soon as ready, or wait if you didn't find anything up to xx months? On Wed, Dec 6, 2017 at 10:55 PM, ANIL KUMAR wrote: > Hi All, > > I needed expert suggestions on following the RSU maintenance strategy for > z/OS , associated ISV products , DB2 etc. Could you please let me know > > 1) How many times in a year do we need to apply the maintenance to z/os , > ISV products , DB2 etc. > 2) How to decide which ones to be applied. (latest RSU) > 3) Whether the HIPERs included also be applied , even though we have not > encountered the specific issues in out shop. > > So far in the account I was working for , it was not a strict rule to apply > maintenance be it z/OS or DB2 or associated ISV product. Infact I do not > remember any maintenance being applied to DB2 unless it was a major upgrade > for which the pre-req was needed. Even for ISV's if they are running fine, > then no action was taken. > > However for a different shop , we have been asked to come up with the best > approach on whats needs to be done. If we keep updating the maintenance > then 1 FTE job will be consumed for the work for a year. > > Hence needed some advise on what strategy is being used by different shops > and what is the best practice. Please advise. > > If any documents etc are available please point me to them and I shall > read. Sincerely hoping to get some advise. Thanks. > > -- > 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
