z/OS MVS Initialization and Tuning Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Search order the system uses for programs

z/OS MVS Initialization and Tuning Guide
SA23-1379-02

When a program is requested through a system service (like LINK, LOAD, XCTL, or ATTACH) using default options, the system searches for it in the following sequence:

  1. Job pack area (JPA)

    A program in JPA has already been loaded in the requesting address space. If the copy in JPA can be used, it will be used. Otherwise, the system either searches for a new copy or defers the request until the copy in JPA becomes available. (For example, the system defers a request until a previous caller is finished before reusing a serially-reusable module that is already in JPA.)

  2. TASKLIB

    A program can allocate one or more data sets to a TASKLIB concatenation. Data sets concatenated to TASKLIB are searched for after JPA but before any specified STEPLIB or JOBLIB. Modules loaded by unauthorized tasks that are found in TASKLIB must be brought into private area virtual storage before they can run. Modules that have previously been loaded in common area virtual storage (LPA modules or those loaded by an authorized program into CSA) must be loaded into common area virtual storage before they can run. For more information about TASKLIB, see z/OS MVS Programming: Assembler Services Guide.

  3. STEPLIB or JOBLIB

    STEPLIB and JOBLIB are specific DD names that can be used to allocate data sets to be searched ahead of the default system search order for programs. Data sets can be allocated to both the STEPLIB and JOBLIB concatenations in JCL or by a program using dynamic allocation. However, only one or the other will be searched for modules. If both STEPLIB and JOBLIB are allocated for a particular jobstep, the system searches STEPLIB and ignores JOBLIB. Any data sets concatenated to STEPLIB or JOBLIB will be searched after any TASKLIB but before LPA. Modules found in STEPLIB or JOBLIB must be brought into private area virtual storage before they can run. Modules that have previously been loaded in common area virtual storage (LPA modules or those loaded by an authorized program into CSA) must be loaded into common area virtual storage before they can run. For more information about JOBLIB and STEPLIB, see z/OS MVS JCL Reference.

  4. LPA, which is searched in this order:
    1. Dynamic LPA modules, as specified in PROGxx members
    2. Fixed LPA (FLPA) modules, as specified in IEAFIXxx members
    3. Modified LPA (MLPA) modules, as specified in IEALPAxx members
    4. Pageable LPA (PLPA) modules, loaded from libraries specified in LPALSTxx or PROGxx

    LPA modules are loaded in common storage, shared by all address spaces in the system. Because these modules are reentrant and are not self-modifying, each can be used by any number of tasks in any number of address spaces at the same time. Modules found in LPA do not need to be brought into virtual storage, because they are already in virtual storage.

  5. Libraries in the linklist, as specified in PROGxx and LNKLSTxx.

    By default, the linklist begins with SYS1.LINKLIB, SYS1.MIGLIB, SYS1.CSSLIB, SYS1.SIEALNKE, and SYS1.SIEAMIGE. However, you can change this order using SYSLIB in PROGxx and add other libraries to the linklist concatenation. The system must bring modules found in the linklist into private area virtual storage before the programs can run.

Note:
  1. For more information about which system services load modules, see:
  2. The default search order can be changed by specifying certain options on the macros used to call programs. The parameters that affect the search order the system will use are EP, EPLOC, DE, DCB, and TASKLIB. For more information about these parameters, see the topic about the search for the load module in z/OS MVS Programming: Assembler Services Guide.
  3. Some IBM® subsystems (notably CICS® and IMS™) and applications (such as ISPF) use the facilities described in the above note to establish other search orders for programs.
  4. A copy of a module already loaded in virtual storage might not be accessible to another module that needs it. For example, the copy might reside in another address space, or might have been used or be in use and not be reusable or reentrant. Whenever an accessible copy is not available, any module to be used must be loaded. For more information about the system's search order for programs and when modules are usable or unusable, see the information on Program Management in z/OS MVS Programming: Assembler Services Guide.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014