This is the sort of thing that I feel quite strongly about when I’m talking to customers, so there is a level of irony that rushing an RSU installation has proved to be so very instructive!
The background to this is that I am currently at IDUG (EMEA in Malta) and was chatting to a colleague about some new REST API maintenance that has enabled versioning and management enhancements (PI98649). I wanted to have a look at it, so I logged on to the zPDT (IBM mainframe emulator) to install it. Oh, and there was some RSU maintenance as well.
There was a reasonable number of ++HOLDs to run through, and I was in a bit of a rush to get it done. I read through the ACTIONs, and the BINDs and started on the DOC.
“Hmm. There really is quite a bit of this, I’ll just kick off the APPLY and finish reading.”
…
“That’s running, good.”
…
“What’s that? REASON(DEP)?”
Oops.
PI97037 (V12 = UI55836) provides support for z/OS Dataset Encryption in DB2 – the dependency referenced in the HOLD is for the z/OS enabling APAR – OA51064 (z/OS 2.2 = UA92616).
Have you ever wondered what happens if you skip one of these?
In this case, DB2 continues to operate quite happily, but issues quite a lot of DSNP012I messages – like this:
As these keep on appearing over time, covering all of the pagesets in the catalog and directory it seems to be a cause for concern. The last two bytes of the CTLGRC (x’006C’ = 108) give us the return code that maps onto (for diagnostics) the IDC3009I message.
From this we can see that DB2 is requesting a catalog locate using a field name that is not supported by our ICF catalog. Or put another way, our ICF catalog is back-level on our (actually DB2s) access method call. Or, in plain English: Install the DEP, stupid!
Having done the last of these and re-IPL’d with CLPA, normal service has been resumed, so I can go and have a look at that new REST functionality now.
If there is a lesson to be learned here, it is that rushing maintenance is a dangerous thing. Read all of the ++HOLD data before getting carried away with shiny new toys, and remember to manage all of the elements listed. IBM frequently ask us to BIND or REBIND packages to complete a fix and if this is not performed, we are still exposed to the problem.
Beware – a strong software maintenance approach can be derailed by a weak implementation strategy.