Writing JCL for the bind process

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 binding
ddname	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 binding
ddname	Type	Function
SYSLIB¹	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-specified²	Input	You can use ddnames to get additional executable programs and object modules.
Notes: ¹ Required for library runtime routines ² 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.