How CA PMO Optimizes Directory Searches › Searches Initiated by a Program or Application

Searches Initiated by a Program or Application

To find nonload modules (that is, any modules that are not load modules), programs must initiate their own directory searches; they cannot use Program Management for these searches. Often, the program contains a FIND macro or a BLDL macro that initiates the search.

Programs also can initiate searches for load modules. By conducting its own search for a load module, a program avoids the S806 abend that can occur under Program Management. For instance, TSO, IMS, and DB2 commonly initiate searches for load modules because they cannot afford to abend. These programs almost always use a BLDL macro. After a program initiates a directory search for a load module, it verifies that the module actually exists. If the module does exist, a macro in the program invokes Program Management. Depending on the type of macro that invokes Program Management, it loads, links, attaches, or transfers control to the load module.

Programs that conduct their own searches for load modules conduct in-storage searches of the Job Pack Area (JPA) and Link Pack Area (LPA) in addition to initiating their own directory searches.

Whether a program needs a load module or a nonload module, it can initiate a directory search in one of two ways:

1. Search of Private Libraries only: The program issues a BLDL/FIND request. This request usually initiates a DASD I/O search of the directories of the private libraries in the concatenation specified in the JCL, as the following illustration shows. (The request may result in an in-storage search if LLA manages the libraries to be searched.)

   

   Private Libraries-Only Search

2. Search of Private and LNKLST Libraries: The program issues a BLDL request to initiate a directory search against a concatenation of JOB/STEP/TASK libraries allocated for the program. (The FIND macro cannot initiate this type of directory search.) The search is usually conducted on DASD. (There may be an in-storage search if LLA manages the libraries involved in the search.) If the load module is not found, z/OS attempts to find it in the LLA address space or the LNKLST libraries (see the following illustration).

   This search also may be conducted on DASD.

   

Private and LNKLST Libraries Search

Note: Programs seldom use this procedure to initiate a search for a nonload module. One possible exception is when you invoke a CLIST member from TSO. If you omit a percent sign (%) preceding the CLIST member name, the JOB/STEP/TASK libraries and the LNKLST libraries are searched unnecessarily.

If the directory search succeeds, the program saves the directory entry for the member. For a successful load module search, the program can later invoke Program Management to load, link, attach, or transfer control to the program load module. For a successful nonload module search, the program can later read the contents of the member into virtual storage.

Note: This is commonly done with the READ macro instruction. The FIND macro instruction used to initiate the directory search causes the system to use the address of the first block of a specified partitioned data set member as the starting point for the next READ macro instruction.

If the directory search fails, the program does not attempt to read the member into virtual storage. For searches of load modules where the module is not found, the program avoids the S806 abend that occurs when Program Management initiates the search.