An IDMS batch job that has worked in the past is suddenly abending with a S0C4.
Release: All supported releases
Typically, an IDMS batch program is normally linked NONREENTRANT as there is no real reason for it to be linked REENTRANT. However, if it is linked REENTRANT, the batch job's STEPLIB must not be APF-authorized. If it is, the program will abend with a S0C4. This has always been so with IDMS batch jobs and is the case today and indefinitely going forward.
What has changed that may make this more of an issue as of z/OS 2.4 is that IBM have made AllowUserKeyCSA(NO) non-optional. This means that IDMS users may have to APF-authorize their IDMS load libraries (see Storage Key Considerations for z/OS CSA Subpools). As a result, more load libraries that are in the STEPLIB of an IDMS batch program step are becoming APF-authorized.
Most often this is not a problem for batch jobs because normally there will be at least one load library in STEPLIB containing user programs and such a load library is most likely not APF-authorized. This will have the effect of making the entire STEPLIB non-authorized (all load libraries in a STEPLIB have to be authorized for the STEPLIB as a whole to be authorized).
However, if for some reason a job step's STEPLIB has only APF-authorized load libraries in it (e.g. code from a third party provider), then the STEPLIB becomes APF-authorized, and if the program is linked REENTRANT it will abend with a S0C4.
The solution is to put any unauthorized load library in the STEPLIB (even an empty one), or re-link the program NONREENTRANT.
IDMS: AllowUserKeyCSA(NO) Frequently Asked Questions
The technical reason for the S0C4 is that most IDMS batch programs include IDMSBALI in the link edit or #BALI in the assembly. These contain a constant IDCSACON which is updated with the address of the IDMS CSA. This will cause a S0C4 if the load-module is REENTRANT and STEPLIB is APF-authorized. See Using IDMSBALI or #BALI.