How a load module is created

In processing object decks and load modules, the linkage editor assigns consecutive relative virtual storage addresses to control sections, and resolves references between control sections. Object decks produced by several different language translators can be used to form one load module.

An output load module is composed of all input object decks and input load modules processed by the linkage editor. The control dictionaries of an output module are, therefore, a composite of all the control dictionaries in the linkage editor input. The control dictionaries of a load module are called the composite external symbol dictionary (CESD) and the relocation dictionary (RLD). The load module also contains the text from each input module, and an end-of-module indicator.

Figure 1 shows the process of compiling two source programs: PROGA and PROGB. PROGA is a COBOL program and PROGB is an Assembler language program. PROGA calls PROGB. In this figure we see that after compilation, the reference to PROGB in PROGA is an unresolved reference. The process of link-editing the two object decks resolves the reference so that when PROGA is executed, the call to PROGB will work correctly. PROGB will be transferred to, it will execute, and control will return to PROGA, after the point where PROGB was called.

Figure 1. Resolving references during load module creation

The binder

The binder provided with z/OS® performs all of the functions of the linkage editor. The binder link-edits (combines and edits) the individual object decks, load modules, and program objects that comprise an application and produces a single program object or load module that you can load for execution. When a member of a program library is needed, the loader brings it into virtual storage and prepares it for execution.

You can use the binder to:

Convert an object deck or load module into a program object and store it in a partitioned data set extended (PDSE) program library, or in a z/OS UNIX® file.
Convert an object deck or program object into a load module and store it in a partitioned data set (PDS) program library. This is equivalent to what the linkage editor does with object decks and load modules.
Convert object decks or load modules, or program objects, into an executable program in virtual storage and execute the program. This is equivalent to what the batch loader does with object decks and load modules.

The binder processes object decks, load modules and program objects, link-editing or binding multiple modules into a single load module or program object. Control statements specify how to combine the input into one or more load modules or program objects with contiguous virtual storage addresses. Each object deck can be processed separately by the binder, so that only the modules that have been modified need to be recompiled or reassembled. The binder can create programs in 24-bit, 31-bit and 64-bit addressing modes.

You assign an addressing mode (AMODE) to indicate which hardware addressing mode is active when the program executes. Addressing modes are:

24, which indicates that 24-bit addressing must be in effect
31, which indicates that 31-bit addressing must be in effect
64, which indicates that 64-bit addressing must be in effect
ANY, which indicates that 24-bit, 31-bit, or 64-bit addressing can be in effect
MIN, which requests that the binder assign an AMODE value to the program module.

The binder selects the most restrictive AMODE of all control sections in the input to the program module. An AMODE value of 24 is the input to the program module. An AMODE value of 24 is the most restrictive; an AMODE value of ANY is the least restrictive.

All of the services of the linkage editor can be performed by the binder.

Binder and linkage editor

The binder relaxes or eliminates many restrictions of the linkage editor. The binder removes the linkage editor's limit of 64 aliases, allowing a load module or program object to have as many aliases as desired. The binder accepts any system-supported block size for the primary (SYSLIN) input data set, eliminating the linkage editor's maximum block size limit of 3200 bytes. The binder also does not restrict the number of external names, whereas the linkage editor sets a limit of 32767 names.

By the way, the prelinker provided with z/OS Language Environment® is another facility for combining object decks into a single object deck. Following a pre-link, you can link-edit the object deck into a load module (which is stored in a PDS), or bind it into a load module or a program object (which is stored in a PDS, PDSE, or zFS file). With the binder, however, z/OS application programmers no longer need to pre-link, because the binder handles all of the functionality of the pre-linker. Whether you use the binder or linkage editor is a matter of preference. The binder is the latest way to create your load module.

The primary input, required for every binder job step, is defined on a DD statement with the ddname SYSLIN. Primary input can be:

A sequential data set
A member of a partitioned data set (PDS)
A member of a partitioned data set extended (PDSE)
Concatenated sequential data sets, or members of partitioned data sets or PDSEs, or a combination
A z/OS UNIX file.

The primary data set can contain object decks, control statements, load modules and program objects. All modules and control statements are processed sequentially, and their order determines the order of binder processing. The order of the sections after processing, however, might not match the input sequence. Figure 2 shows a job that can be used to link-edit an object deck. The output from the LKED step will be placed in a private library identified by the SYSLMOD DD. The input is passed from a previous job step to a binder job step in the same job (for example, the output from the compiler is direct input to the binder).

Figure 2. Binder JCL example

//LKED   EXEC PGM=IEWL,PARM='XREF,LIST', IEWL is IEWBLINK alias 
//           REGION=2M,COND=(5,LT,prior-step) 
//* 
//*        Define secondary input 
//* 
//SYSLIB   DD  DSN=language.library,DISP=SHR         optional 
//PRIVLIB  DD  DSN=private.include.library,DISP=SHR  optional 
//SYSUT1   DD  UNIT=SYSDA,SPACE=(CYL,(1,1))          ignored 
//* 
//*        Define output module library 
//* 
//SYSLMOD  DD  DSN=program.library,DISP=SHR          required 
//SYSPRINT DD  SYSOUT=*                              required 
//SYSTERM  DD  SYSOUT=*                              optional 
//* 
//*        Define primary input 
//SYSLIN   DD  DSN=&&OBJECT,DISP=(MOD,PASS)          required
//* 
//         DD  * inline control statements 
                        INCLUDE  PRIVLIB(membername) 
                        NAME     modname(R)
/*

An explanation of the JCL statements follows:

EXEC: Binds a program module and stores it in a program library. Alternative names for IEWBLINK are IEWL, LINKEDIT, EWL, and HEWLH096. The PARM field option requests a cross-reference table and a module map to be produced on the diagnostic output data set.
SYSUT1: Defines a temporary direct access data set to be used as the intermediate data set.
SYSLMOD: Defines a temporary data set to be used as the output module library.
SYSPRINT: Defines the diagnostic output data set, which is assigned to output class A.
SYSLIN: Defines the primary input data set, &&OBJECT, which contains the input object deck; this data set was passed from a previous job step and is to be passed at the end of this job step.
INCLUDE: Specifies sequential data sets, library members, or z/OS UNIX files that are to be sources of additional input for the binder (in this case, a member of the private library PRIVLIB).
NAME: Specifies the name of the program module created from the preceding input modules, and serves as a delimiter for input to the program module. (R) indicates that this program module replaces an identically named module in the output module library.