(Repost from October 5, 2020)
Let's understand coexistence a little more in the world of Continuous Delivery.
I recently received two questions about z/OS coexistence, and I thought that others might also have the same questions. So, let's talk about software coexistence...
Question 1: I did coexistence verification for my z/OS V2.2 system for an upgrade to z/OS V2.4 back in January 2020. Now, I recently verified it again, and found that there were 8 PTFs missing. What is the "best practice" for doing coexistence verification for the new release of z/OS?
My answer 1: The "best practice" is that we issue coexistence PTFs when we need to maintain sysplex availability and identify them with FIXCATs. Sorry to say, not every release coexistence PTF can be hardened at a release GA date to make your coexistence a "one and done" activity. Especially for new functions added via PTFs ("Continuous Delivery" functions) that need coexistence. In the CD PTF case, coexistence has to be added post-GA. Sometimes, we call those new function PTFs that need coexistence "pre-conditioning PTFs" - but at the end of the day, they are still coexistence PTFs and should still have the coexistence SMP/E FIXCAT.
All this means, that SMP/E REPORT MISSINGFIX is more important to run occassionally to ensure that you put on an newly identified coexistence PTFs - hopefully before you install the applicable CD PTFs - as coexistence installation might be desirable to add earlier than a normal RSU installation. Depending on how many CD functions were added, and if those CD functions needed "pre-conditioning/coexistence" means the reports you get may vary from nothing to something. It all depends on what was closed, and what you've already installed.
We know that these "pre-conditioning" PTFs can be disruptive, as they often mean that the rolling IPLs they cause have to planned before you can put on the real PTF you want installed. We do try to reduce that as much as we can (and align on the release boundary), but sometimes it cannot be avoided.
How often would I check? I'd probably run an SMP/E REPORT MISSINGFIX weekly (with my HIPER/PRP reports), just for knowing. Usually, I won't find a lot of 'differences' in a week for coexistence, but at least I can find out quickly what I've got as soon as it happens. Monthly is a perfectly fine timeframe too, but I'd tend to automate weekly - which lots of people do. Armed with the reports, I can then decide if I want to install those coexistence PTFs "earlier" than a normal RSU installation or with the RSU installation.
Question 2. What is the best way to find out about these new coexistence PTFs? Do an SMP/E RECEIVE ORDER and REPORT MISSINGFIX periodically?
My answer 2: Yes. You got it, as I mentioned in the prior question! Do a RECEIVE ORDER (at least with CONTENT HOLDDATA, maybe more) nightly. Nightly is my recommendation, as I hate when the server is down and if it is down one night, I've only lost one day's worth of info which I can easily catch up on the next night. Then, in the next step, do your REPORT MISSINGFIX - nightly if you feel like it, as automation is cheap - or weekly/monthly.
Play around with the time of day you want to do your RECEIVE ORDER. For me in New York timezone, I found that 3pm was best. If I did it in the middle of the night, I found the server to be down more often. 3pm was my sweet spot for server availability at the very beginning, although I have noticed that it is better now than it had been back in the early days.
btw - if you see a "pre-conditioning" PTF (from reading HOLDDATA in a CD PTF), and that "pre-conditioning" PTF does NOT have a coexistence FIXCAT...well, that is a defect that should be immediately identified to the component with a Case to be fixed! I haven't seen this happen in a while, but it is a human activity to mark it with a FIXCAT. We can always mark an existing PTF with a new FIXCAT, and it will be picked up the next day.
Comments
Post a Comment