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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Purdy Sent: Thursday, December 07, 2017 9:01 AM To: [email protected] 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 <[email protected]> wrote: > On Dec 7, 2017, at 9:37 AM, Allan Staller <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
