When IPLs are a good idea.

I recently wrote about the Placebo effect on mainframe IPLs in emergency situations https://lnkd.in/gVkvAtkB. I am all for doing as a few IPLs in a calendar year as is necessary. There is not a driving need to do so or is there? The exception to the rule is changes requiring an IPL. While IPLs should hopefully be fully automated. Changes requiring an IPL can be disruptive to that process.

The first scenario would be changes that do not impact the IPL process but need an IPL to take effect. A lot of changes fall into this. These tend to be effects that are permanent upon IPL. These tend to be straightforward if validation is done. The human factor is the wild card. Was validation done? Did clean up get done correctly? Did something get transposed or accidentally deleted?

The second would be changes to the IPL process itself. If you have more than one LPAR this should be worked out on your test LPAR. As someone who has been around this is not necessarily true. Unfortunately, what I have seen is that is not how the systems align. Sometimes a test LPAR will be used to test a new region or an upgrade. I have not seen a general use of using test LPARs for IPLs.? I would love to see more of this or the use of zVDTs.

IPLs are not practiced as a standard and as such are the most stressful situations. Add to that a change and it can be very challenging. So why has it become common place to just go for it? Well change control was lacking for quite some time. IPLs are disruptive. However not practicing and not padding the calendar with extra IPLs around a major upgrade is a disservice. If you do not have a test LPAR or it is not set to mirror production, investing in zVDTs is key. Practice, practice, and more practice. With a lot of systems being set up 10+ years ago upgrades can be tricky with user exits, custom work, etc. Mainframes are like a custom car where you or a dedicated mechanic is going to know the ins and outs. The mainframe is just that and when your mechanic retires or leaves you get someone else who may not see the quirks. They may have a different approach. If your old mechanic did things their way and not as best practice nor standard it takes a lot to understand what is going on.

Upgrades specifically z/OS or to other foundational products are the highest risk and cause the most back outs. For all the reasons mentioned above. Without a mirrored test system there are so many variables its hard to catch all the issues.

So you have completed your change – maybe without issue and maybe with on the fly improvements. It does not necessarily mean your next IPL will be flawless. If you are like me and do not want to waste resources on IPLing every week. Then your next IPL will be in a month, in 3 months or even next year. By then your sys prog may have retired, be on vacation, etc. The big issue is no one will remember what was done, who did what and why. Without fail issues will lengthen your IPL and no one will have memory of what happened.

This is why I advocate after a major change to IPLing or at least putting 2-3 IPLs the next few weeks. Work out the issues soon after these changes. The stress level goes down. You can have the appropriate people on standby. This can save your company from a major incident.