|
You can use cataloged procedures rather than supply all the JCL
required for a job step. You can use JCL statements to override the
statements of the cataloged procedure to tailor the information provided
by the bind process.
For a description of the IBM-supplied cataloged procedures that
include a bind step, see z/OS XL C/C++ User's Guide. - Invoking with the EXEC Statement
Use the EXEC job control
statement in your JCL to invoke the binder. The EXEC statement is:
//LKED EXEC PGM=IEWL
- Using the PARM Parameter
Use the PARM parameter of the EXEC
job control statement to select one or more of the optional facilities
provided by the binder. For example, if you want a mapping of the
AMODE 64 executable program produced by the bind process, specify:
//LKED EXEC PGM=IEWL,PARM='MAP'
For
a description of bind options, see Bind options.
- Required DD Statements
The bind process requires
three standard data sets. You must define these data sets in DD statements
with the ddnames SYSLIN, SYSLMOD, and SYSPRINT. The required data
sets and their characteristics are shown in Table 1.
Table 1. Required data
sets used for bindingddname |
Type |
Function |
---|
SYSLIN |
Input |
Primary input to the bind process consists of a sequential
data set, members from a PDS or PDSE, or an in-stream data set. The
primary input must be composed of one or more separately compiled
object modules or bind control statements. An executable program cannot
be part of the primary input, although it can be introduced by the
INCLUDE control statement (see Using the INCLUDE statement). |
SYSLMOD |
Output |
The data set where output (executable program) from the bind
process is stored. It must be a PDSE or a file in the HFS (using PATH=). |
SYSPRINT |
Output |
SYSPRINT defines the location for the listing that includes
reference tables for the executable program. Output from the bind
process: - Diagnostic messages
- Informational messages
- Module map
- Cross-reference list
|
- Optional DD Statements
If you want to use the automatic call
library, you must define a data set using a DD statement with the
name SYSLIB. You can also specify additional data sets containing
object modules and AMODE 64 executable programs as additional input
to the bind process. These data set names and their characteristics
are shown in Table 2. Table 2. Optional data sets used for bindingddname |
Type |
Function |
---|
SYSLIB1 |
Library |
Secondary input to the binder consists of object modules or
load modules that are included in the executable program from the
automatic call library. The automatic call library contains load modules
or object modules that are used as secondary input to the binder to
resolve external symbols left undefined after all the primary input
has been processed. The automatic call library can include: - Libraries that contain object modules, with or without binder
control statements
- Libraries that contain executable programs
- The libraries that contain the Language Environment resident
routines. For a description of this data set see Planning to bind and run).
SYSLIB is input to the binder only if the CALL=NO bind
option is not in effect (see Table 1,
in z/OS MVS Program Management: User's Guide and Reference,
or z/OS TSO/E Command Reference for
more information). You can also identify secondary input to the binder
with the INCLUDE statement.
A routine compiled with a Language Environment-conforming
compiler cannot be executed until the appropriate Language Environment resident
routines have been linked into the executable program. The Language Environment resident
routines are contained in the SCEEBND2 library; the data set name
could be CEE.SCEEBND2. If you are unsure where SCEEBND2 has been installed
at your location, contact your system administrator. This data set
must be specified in the SYSLIB statement in your JCL.
In
the following example, the SYSLIB DD statement is written so that Language Environment resident
library routines are included as secondary input into your executable
program: //SYSLIB DD DSNAME=CEE.SCEEBND2,DISP=SHR
|
User-specified2 |
Input |
You can use ddnames to get additional executable programs and
object modules. |
Notes: - 1
- Required for library runtime routines
- 2
- Optional data set
|
- Examples of bind JCL
A typical sequence of job control statements
for binding an object module (compiled with LP64)
into an AMODE 64 executable program is shown in Figure 1. The ENTRY binder control statement
in the figure identifies CELQSTRT as the entry point for the AMODE
64 executable program. The NAME binder control statement in the figure
puts PROGRAM1 in USER.LOADLIB with the member name PROGRAM1.
Figure 1. Creating an AMODE
64 executable program under batch//LKED64X EXEC PGM=IEWL,REGION=20M,
// PARM='AMODE=64,RENT,DYNAM=DLL,CASE=MIXED,MAP,LIST=NOIMP'
//SYSPRINT DD SYSOUT=*
//SYSLMOD DD DSNAME=USER.PDSELIB,UNIT=SYSALLDA,
// DISP=(NEW,KEEP),SPACE=(TRK,(7,7,1)),DSNTYPE=LIBRARY
//SYSLIB DD DSNAME=CEE.SCEEBND2,DISP=SHR
//SYSLIN DD DSNAME=USER.OBJLIB(PROGRAM1),DISP=SHR
// DD DSNAME=CEE.SCEELIB(CELQS003),DISP=SHR
//SYSDEFSD DD DUMMY
//SYSIN DD *
ENTRY CELQSTRT
NAME PROGRAM1(R)
/*
- Adding Members to a Library
The output from the binder is
usually placed in a private program library.
The automatic
call library that is used as input to the binder can be a Language Environment library
(SCEEBND2 for AMODE 64 applications), a compiler library,
a private program library, or a subroutine library.
When you
are adding a member to a library, you must specify the member name
as follows: - When a single module is produced as output from the binder, the
member name can be specified as part of the data set name in the SYSLMOD.
- When more than one module is produced as output from the binder,
the member name for each module must be specified in the NAME option
or the NAME control statement. The member name cannot be specified
as part of the data set name.
|