Location of the load module

Load modules and program objects can reside in the link library, the job or step library, the task library, or a private library.
  • The link library (defined by the LNKLSTxx or PROGxx member of SYS1.PARMLIB) is always present and is available to all job steps of all jobs. The control program provides the data control block for the library and logically connects the library to your program, making the members of the library available to your program. For more information, see z/OS MVS Initialization and Tuning Guide.
  • The job and step libraries are explicitly established by including //JOBLIB and //STEPLIB DD statements in the input stream. The //JOBLIB DD statement is placed immediately after the JOB statement, while the //STEPLIB DD statement is placed among the DD statements for a particular job step. The job library is available to all steps of your job, except those that have step libraries. A step library is available to a single job step; if there is a job library, the step library replaces the job library for the step. For either the job library or the step library, the control program provides the data control block and issues the OPEN macro to logically connect the library to your program.

    Authorization: To invoke a program, an authorized program (supervisor state, APF-authorized, PSW key 0 - 7, or PKM allowing key 0 - 7) must reside in an APF-authorized library or in the link pack area. The system treats any module in the link pack area (pageable LPA, modified LPA, fixed LPA, or dynamic LPA) as though it come from an APF-authorized library. Ensure that you properly protect SYS1.LPALIB and any other library that contributes modules to the link pack area to avoid system security and integrity exposures, just as you protect any APF-authorized library. See APF-authorized programs and libraries for more information about APF-authorized libraries.

  • Unique task libraries can be established by using the TASKLIB parameter of the ATTACH or ATTACHX macro. The issuer of the ATTACH or ATTACHX macro is responsible for providing the DD statement and opening the data set or sets. If the TASKLIB parameter is omitted, the task library of the attaching task is propagated to the attached task. In the following example, task A's job library is LIB1. Task A attaches task B, specifying TASKLIB=LIB2 in the ATTACH or ATTACHX macro. Task B's task library is therefore LIB2. When task B attaches task C, LIB2 is searched for task C before LIB1 or the link library. Because task B did not specify a unique task library for task C, its own task library (LIB2) is propagated to task C and is the first library searched when task C requests that a module be brought into virtual storage.
    Task A    ATTACH EP=B,TASKLIB=LIB2
    Task B    ATTACH EP=C
  • Including a DD statement in the input stream defines a private library that is available only to the job step in which it is defined. You must provide the data control block and issue the OPEN macro for each data set. You may use more than one private library by including more than one DD statement and an associated data control block.
A library can be a single partitioned data set, or a collection of such data sets. When it is a collection, you define each data set by a separate DD statement, but you assign a name only to the statement that defines the first data set. Thus, a job library consisting of three partitioned data sets would be defined as follows:
//JOBLIB   DD  DSNAME=PDS1,...
//         DD  DSNAME=PDS2,...
//         DD  DSNAME=PDS3...

The three data sets (PDS1, PDS2, PDS3) are processed as one, and are said to be concatenated. Concatenation and the use of partitioned data sets is discussed in more detail in z/OS DFSMS Using Data Sets.

Some of the load modules from the link library may already be in virtual storage in an area called the link pack area. The contents of these areas are determined during the nucleus initialization process and will vary depending on the requirements of your installation. The link pack area contains all reenterable load modules from the LPA library, along with installation selected modules. These load modules can be used by any job step in any job.

With the exception of those load modules contained in this area, copies of all of the reenterable load modules you request are brought into your area of virtual storage and are available to any task in your job step. The portion of your area containing the copies of the load modules is called the job pack area. Any program loaded by a particular task is also represented within that task's load list.