Why a module is loaded from LINKLIST when it is in STEPLIB


Article ID: 15457


Updated On:


CA Datacom CA DATACOM - AD CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware


Although this article is written for CA Datacom, the principle applies to software practices in general.

A common situation is for a customer to place loadlibs for a product in Linklist. In the case of CA Datacom, this could involve both the base loadlib and the customized modules, called the CUSLIB.

Because the CUSLIB is specific to an individual database system, it cannot be used from Linklist effectively when there are multiple database systems in a single LPAR. As an alternative, some clients will leave one CUSLIB n the Linklist and try to use STEPLIB for all the other systems' CUSLIBs. This is not a good practice and could lead to processing errors if the wrong loadlib modules are loaded into a job.

Why would a module that is known to be in a STEPLIB loadlib not be used in my job, but instead, a module is loaded from the Linklist from a different loadlib?


Component: CAIVPE


The issue of an unexpected load module being loaded seems to be related to load module search order, and, in particular, when dealing with APF authorization. Another way of asking the question is, "What would cause IBM's LOAD macro to bypass modules in the JOBLIB or STEPLIB when these are not APF-authorized in favor of the same module in a Linklisted, APF-authorized library?"

Within CA Datacom, like many products, certain functionality must be handled through APF authorized code. Consequently, we require APF authorization for the base loadlib, and since the CUSLIB, is also normally part of a JOBLIB or STEPLIB concatenation with the base loadlib, it, too, needs to be authorized. This leads to a standard disclaimer - "If one JOBLIB or STEPLIB library is APF-authorized, then all must be authorized. Libraries lose their APF authorization when they are mixed with non-authorized libraries in JOBLIB/STEPLIB."

The key here is in the above statement. Even though the desired load module is in your JOBLIB/STEPLIB, if that loadlib is not APF-Authorized, that module may not be used as expected. The 2.1 IBM z/OS MVS Programming: Assembler Services Guide, under Program Management / APF-authorized programs and libraries, says, "APF also prevents authorized programs (supervisor state, APF-authorized, PSW key 0-7, or PKM 0-7) from accessing a load module that is not in an APF-authorized library." 

Therefore, even though the module is in a JOBLIB/STEPLIB loadlib, and that library should be chosen first in the search order, if the loadlib is not authorized and the calling module needs it to be, this loadlib will be skipped and the search will continue through other loadlibs or to the Linklist until an authorized version of the module is found.

The best course of action is to ensure that the load libraries are APF-authorized as directed by each product, and that recommendations from each product for using or not using Linklist are followed. For CA Datacom, we identify that the base loadlib and CUSLIB should be APF-authorized, and do not recommend the use of Linklist for these loadlibs.

Additional Information

As always, please contact CA Technologies support for CA Datacom if you have further questions.