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.