Re: Interesting post-cume error

FWiW, if you are curious as to why and where the code ran...

PTF processing is either delayed or immediate. There is the option for a PTF to be created to enable only *DELAYED. There is no option for a PTF to be created to enable only *IMMED. Any PTF that allows for being applied immediately, must also be able to be applied delayed.
However some functions can not be performed during an IPL [within the current design], due to limits on available resources in the IPL path. There has never been a post-IPL portion of processing built into the PTF apply process, for those PTFs being applied at IPL. The goal being, to avoid the need to access any such resources, rather than forcing the requirement, to somehow ensure such resources are available.
Creative ways to attempt to ensure such functions are able to run may be employed. One option might be to submit to QSYSNOMAX during the IPL. But if the system comes up restricted, the job queue is held, or the system is ended before the back-end processing finishes, the expected PTF actions will not complete.
In order for some PTF exit processing to be performed, at least with the hope of its being performed more likely than with other methods, the QDBSRVXR2 system job may be hijacked /err... borrowed/ by at least one PTF [chain] to make its post-IPL processing complete.
As has already been noted and validated, the PTF chain originating the specific error seen, includes the QSQSYSIBM API which provides [the creation of] a set of objects. The PTF exit program calls the API to generate the objects to match the level of the PTFed code; thus the expectation that the PTF being applied, the objects beyond just the API itself, will have the PTFed level matching the PTF code level applied. Given that is the only thing that PTF was expected to do beyond applying the objects included in the PTF, then that failure would be resolved by calling the API interactively [or in batch; at least outside of the IPL path].
Calling the API as recovery could be problematic if a defect exists whereby the code failure in the QDBSRVXR2 job [ignoring that itself], had left locks on objects that can not be removed implicitly by a conflicting operation [such as with ALCOBJ RQSRLS(*CONFLICT)] -- with a consequence being, an IPL is required to recover, because QDBSRVXR2 is a system job which does not support end/restart. All known errors for locks being left, have long since been eliminated.

Regards, Chuck