An IDMS batch job that has worked in the past is suddenly abending with a S0C4
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.
Release : All supported releases
Component : CA IDMS
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 loadlibraries (see Storage Key Considerations for z/OS CSA Subpools.)
As a result, more loadlibraries 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 loadlibrary in STEPLIB containing user programs and such a loadlibrary is most likely not APF-authorized.
This will have the effect of making the entire STEPLIB non-authorized (all loadlibrarues 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 loadlibraries 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 loadlibrary in the STEPLIB (even an empty one), or re-link the program NONREENTRANT.