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

Products

• Datacom
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware
• Datacom/AD
• Datacom/DB

Issue/Introduction

While this article is written for 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 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 in 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.

Likewise, having multiple base loadlibs in a Linklist could also cause the wrong module to be used.

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

Resolution

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 Datacom and many other 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 a JOBLIB/STEPLIB, if that loadlib is not APF-Authorized, that module may not be used as expected. The 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 a 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 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 Broadcom support for Datacom if you have further questions.