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 <edgould1...@comcast.net> wrote: > On Dec 7, 2017, at 9:37 AM, Allan Staller <allan.stal...@hcl.com> 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
