Previous topic |
Next topic |
Contents |
Glossary |
Contact z/OS |
PDF
How a load module is created Application programming on z/OS |
|
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. 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:
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:
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:
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:
|
Copyright IBM Corporation 1990, 2010
|