Standard Files
Chapter 6: Linkage Editor and Loader
Introdu(~tion
An object module produced by the compiler requires further processing before i t is sui tablE~ for execution. I t must be
converted into a load module which can be loaded into main storage and executed.
Conversion and execution is performed, in either one or two job steps, by one of two operating system programs, the linkage editor <:md the linkage loader. This chapter describes these programs and the circumst:ances in which each can be used to the best, advantage. Both programs are fully dE~scribed in IBMSystem/360 Operating system: .Linkage.Editor and Loader.
Thet:wo linkage programs require the same kind of input, perform the same basic process (the resolution of external
references within the object module), and produce the same result, that is, a load module for execution. They differ in the way they are used and in what they do with the load modules they create.
Linkage loader: Execution by the linkage loader l:'equires one job step, in which a load module is created, loaded into main storage., and executed.
Linkage .editor: The linkage editor does no·t cause the load modules i t creates to be loaded and executed. Instead, each load module is placed in a program library; a further job step is required for the loading and execution of such a load module.
CHOICE OF LINKAGE PROGRAM
The two programs are compatible in the following respects:
1. Al1 object modules acceptable as input to a linkage editor are acceptable as input to a linkage loader.
2. All load modules produced by a linkage editor, except those produced with the NE (not editable) attribute are
acceptable as input to a linkage loader. (When the NE attribute is produced, the resulting load module has no external symbol dictionary and cannot be reprocessed; the external symbol dictionary is discussed below in the linkage-editor section.)
If you want to keep the load module, or use facilities that are not available to the linkage loader, such as providing an overlay structure, you must use the linkage editor. The linkage loader is essentially a one-shot program checkout facility with limited application.
The differences between the two programs can be summarized as:
Linkage editor:
1. Does not cause the load module to be executed.
2. Can produce more than one load module from a batched compilation.
3. Always places load modules in a
library, from which they can be loaded for execution in a later job or job step.
4. Can accept input from other sources as well as the primary input source.
5. Can provide an overlay structure for a program.
6. Can be used to modify existing load modules.
Linkage.loader:
1. Requires only one job step for processing, loading, and execution.
2. Can only produce one load module from a batched compilation.
3. Always loads this module into main storage and executes it.
4. The load module exists only for the duration of the job step.
5. Can accept input only from the primary source.
6. Cannot provide an overlay structure for a program, or modify existing load modules.
Performance Considerations
The execution time of a load module is the same whether i t is created by the linkage editor or the linkage loader. However, the
Chapter 6: Linkage Editor and Loader 63
editing and loading time for a module is greatly reduced when the linkage loader is used. This is achieved by reductions in:
1. Scheduling time: The object program is processed, loaded, and executed in one job step.
2. Processing time: The linkage loader can process a module in approximately half the time required by the linkage editor, because:
a. Linkage editor intermediate and I/O operations are eliminated.
b. The I/O time for reading modules can be reduced by the use of improved buffering techniques and chained scheduling.
3. Amount of . auxiliary sto:rage: If the linkage loader input is the object module in a compile~load-and-go job, the auxiliary storage that would be required by the linkage editor
intermediate and output data sets is not needed. If the linkage loader input is taken from modules
link-edited into a library, the
auxiliary storage requirements for the library can be reduced by storing the modules with unresolved library references; these references can be resolved at load time.
Linkage Editor
The linkage editor is an operating system service program that creates load modules.
It always places the load modules in a library, from which the job scheduler can call them for execution~
The input to the linkage editor can include object modules, load modules, and control statements that specify how the input should be processed. The ou1:put from the linkage editor comprises one or more load modules.
In addition to its primary function of converting object modules into loaci
modules, the linkage editor can also be used to:
• Combine previously link-edi·ted load modules
• Modify existing load modules
• Construct an overlay program A module constructed as an overlay program can be execut.ed in an area of main
storage that is not large enough to contain the entire module at one time. The linkage editor subdivides the module so that i t can be loaded and executed segment by segment.
MODULE STRUCTURE
Object and load modules have identical structures. They differ only in that a load module has been processed by the
linkage editor and stored in a library wi·th certain descriptive information required by the job schedule:r; in particular, the
module is marked as 'executable' or 'not executable.' A module comprises three typ1es of information:
• Text (TXT)
• External symbol dictionary (ESD)
• Relocation dictionary (RLD)
The text of an object or load module comprises the machine instructions that represent the program to be executed.
These instructions are grouped in blocks termed control sections; a control section is the smallest separately executable uni1:.
within a program.. An object module creatE~d
by the PL/I (F) compiler includes the following control sections:
• Control section for the shared library transfer vector.. (This is an area uSE~d
for communication between library modules in the PL/I shared library and those in the partition or region.)
• Program control section: contains the executable part of the program.
• Static internal control section:
contains storage for all variables declared STATIC INTERNAL and for constants and static system blocks.
• Control sections termed common areas:
one common area is created for each EXTERNAL file name and for each non-string element variable declared STATIC EXTERNAL without the INITIAL attribute •
• IHENTRY: execution of a PL/I program always starts with this control section, which passes control to the appropriate initialization routine;
when initialization is complete,
control passes to the address stored in the control section IHEMAIN.
• IH~mIN: for a procedure with the MAIN option, contains the starting address for execution of the PL/I program.
• cont:rol sections for PL/I library modules link-edited with the program.
External. Symbol Dictionary
The external symbol dictionary (ESD)
contains a list of all the external symbols
References to external symbols defined
elsewhel~e are also considered to be external symbols; they are known as external·references. Such external
references in a PL/I object module always
At execution time, the machine instructions in a IOcLd module (including the
The I:elocation dictionary (RLD) contains
informat~ion that enables the absolute addressE!s to be established when a module is loadE!d into main storage for execution.
These addresses cannot be determined
earlier because the starting address is not known until the module is loaded. The linkage editor consolidates the RLD entries in the input modules into a single
relocation dictionary when i t creates a load module.
LINKAGE EDITOR PROCESSING
A PL/I compiled program cannot: be executed until the appropriate PL/I subroutine library modules have been incorporated.
The library modules are included in two ways:
1. By incorporation in the load module during linkage editing.
2. By dynamic call during execution.
The first method is used for most of the PL/I subroutine library modules; the
following paragraphs describe how the linkage editor locates the modules. The modules, indicating which are loaded
dynamically.
corresponding external symbols in the module: i t attempts to resolve such references by a method termed automatic library call.
External symbol resolution by automatic library call involves a search of the library defined by a DD statement named SYSLIB; for a PL/I program this will be the PL/I subroutine library (SYS1.PL1LIB). The linkage editor locates the modules in which
Any linkage editor processing additional to the basic mode described above must be requested by linkage editor control
statements placed in the primary input.
These control statements are described at the end of this chapter under 'Additional Processing. '
Chapter 6: Linkage Editor and Loader 65
(prima:ry input)
r---,
I I
I PL/I I
I object
1----,
I module I II I I SYSLMOD
l _____________ J I l ________ >
r---,
I Ir---,
II I I Output I
I Linkage ~---> I module I I edi tor I load module I library I
r--->I I I I
r---,
I L _____________ J L _____________ JI I I
I PL/I I I
I library
r---
JI (SYS1.PL1LIB)I
I I
l _____________ J SYSLIB (call library)
Figure 6-1. Basic Linkage Editor Processing
Main Storage Requirements
Two levels of the linkage editor are currently available; each has a number of different versions. The E-level is
available in 15K, 18K, and 20K versions;
the F-Ievel is available in 44K, aSK, and 128K versions. The capabilities and
capacities of each version are described in system/36 0 Operating.System: LinkaqeEditor and Loader.
Job Control Language for Link-Editing
Al though you will probably use catcLloged procedures rather than supply all the job control statements required for a job s·tep that invokes the linkage editor, i t is necessary to be familiar with these statements so that you can make the bes·t use of the linkage editor and, if
necessary, modify the statements of the cataloged procedures.
The IBM-supplied PL/I cataloged
procedures that refer to the linkage editor are:
PLILFCL PLILFCLG PLILFLG
Compile and link-edit
Compile, link-edit, execute Link-edit and execute
Chapter 8 discusses these cataloged procedures and describes how to modify or override the statements they contain.
The following paragraphs describe the essential job control statements for
link-editing; they use statements from the PL/I cataloged procedures as typical
examples. Appendix B contains a
description of the parameters of the DD statements that are referred to.
EXEC STATEMENT
The name IEWL is an alias for the
linkage-editor program. If you use the name IEWL in the EXEC statement that invokes the linkage editor, the job scheduler will load the version to which this name corresponds. Normally this would be either the one which is the largest available within your operating system, Ol~
the one which is the most suitable for your job. You should consult your systems
programmer if you need to know what versions of the linkage editor are
available at your installation, and how to invoke them. The basic EXEC statement is:
/ / EXEC PGM=IEWL
By using the PARM parameter of the EXEC statement, you can select one or more of the optional facilities offered by the linkage editor; these facilities are discussed under 'Optional Facilities,' below. The use of the other parameters of the EXEC statement is as described in Chapter 7, 'Executing the Load Module.'
r---·---T---~---T---,
I ddname I Function I Possible device classes1. I
~---.---+---+---~
I SYSLIN I Primary input data, normally the I SYSSQ or the input job I I I output from the compiler I stream (specified by DD *) I
~---.---+---+---~
I SYSL~~OD I Output for load module I SYSDA I
~---.---+---.---+---~---~
I SYSU'l'l I Additional workspace I SYSDA I
~---
..
---+---+---~I SYSPRINT I Listing, including diagnostic I SYSSQ or SYSOUT device I
I I messages I I
~---"---+---+---~---~
I SYSLIB I Automatic call library (usually I SYSDA I
I I the PL/I subroutine library) I I
~---,----~---~---~
11SYSSQI Magnetic-tape or direct-access device I
I SYSDA, Direct-access device I
L ______ . ______________________________________________________________________ J
Figure 6-2. Linkage-Editor Data Sets DO STATEMENTS
The linkage editor always requires four standard data sets. You must define these data sets in DD statements with the
standard names SYSLIN, SYSLMOD, SYSUT1" and SYSPRINT.
A fifth data set, defined by a DO statement with the name SYSLIB, is
necessar.y if you want to use the automatic library call facility. The five standard data se'ts are summarized in Figure 6- 2.
Primary.Input (SYSLIN)
The primary input source must be a
CONSEcurIVE data set containing one or more object lDodules and/or linkage-editor
control statements; a load module cannot be part of the primary input, although i t can be introduced by the control statement INCLUDE.. For a PL/I program, the primary input source is usually a data set
containing an object module created by the compiler. The data set may be on
magnetic-tape or on a direct-access device, or you can include i t in the input job stream. In all cases, the input must be in the form of aO-byte F-format records.
'.rhe cataloged procedure PL1LFLG includes the DD statement:
//SYSLIN DD DDNAME=SYSIN
This statement specifies that the
primary input data set must be defined in, a DD statE~ment named SYSIN. If you use this catalogue procedure, you must supply this DD statE~ment, specifying the qualified ddname I~KED.SYSIN. For example, to
link-edit and execute a PL/I object module placed in the input stream, you can use the following statements:
//LEGO JOB / / EXEC PL1LFLG //LKED.SYSIN DO
*
Insert here the object module to be link edited and executed
/*
Note:
1. If modules with identical names appear in the primary input, the linkage editor processes only the first of them.
2. You can include load modules or object modules from one or more libraries in the primary input by using a linkage editor INCLUDE statement; refer to 'Additional Processing,' below.
Output (SYSLMOD)
The linkage editor always places the load modules that i t creates in a library defined by a DO statement with the name SYSLMOD. (A library is a type of
direct-access data set that can be used for the storage of other consecutive data sets, frequently load modules); the data sets stored in a library are termed members. To store a member in a library, include the parameter DSNAME=dsname(membername) in the DD statement that defines the library;
replace 'dsname' with the name of the library, and 'membername' with the name of the member.)
Chapter 6: Linkage Editor and Loader 67
The PL/I cataloged procedures include
This statement defines a temporary library named &&GOSET and assigns the name permanent library. For example, assume that you have a library called USLIB on 2311 disk pack serial number 371; to name the load module MOD1 and place it in this library, code:
//LKED.SYSLMOD DD DSNAME=USLIB(MOD1),
// UNIT=2311,
procedures allows for an initial allocation of 50K bytes and, if necessary, 15 further SYSUT1. The following statement contains the essential parameters:
//SYSUTl DD UNIT=SYSDA,
// SPACE=(1024,(200,20»
You should never need to modify the DD statement SYSUT1 in a cataloged procedu:re.
If your installation supports dedica·ted workfiles, these.can be used to provide workspace for the link-edit job step. For details of these workfiles and their use, see 'Workspace (SYSUT1,SYSUT3)' in Chapter 5, 'Compilation.'
Listing. (SYSPRINT)
The linkage edi to:r generates a listing that includes reference tables relating to the load modules that i t produces and also, when necessary, diagnostic messages. The information that may appear is described organization. Although the listing is usually printed, it can be written on any type of magnetic-tape or direct-access device. For printed output, the following statement will suffice:
//SYSPRINT DD SYSOUT=A
Automatic Call Library (SYSLIB)
If you want the linkage editor to resolve external references by automatic library call, you must use aDD statement with the name SYSLIB to define the library which the linkage editor must search. You can cause the linkage editor to search more than one library by concatenating the DD statements that define the libraries: include the
subroutine library (SYS1.PL1LIB).
The automatic call library can contain load modules or object modules, but not both.
EXAMPLE
The following example is a typical sequence of job control statements for link-editinsr a PL/I object module. The DD statement
stateme!:nt requests the creation of a new library.
//LINK JOB //. EXEC PGM=IEWL
//SYSLMOD DD UNIT=2311, / / VOLUME=SER=D186, / / DSNAME=MODLIB(LKEX), / / DISP=(NEW,KEEP), / / SPACE=(CYL,(10,10,1»
//SYSUTl DD UNIT=2311,
/ / SPACE=(1024,(200,20»
//SYSPRINT DD SYSOUT=A
//SYSLIB DD DSNAME=SYS1.PL1LIB, / / DISP=OLD
//SYSLIN DD
*
Insert here the object module to be link-edt ted
Optiona~l Facilities
The linkage editor provides a number of optional facilities that you can select by including the appropriate keywords from the following list in the PARM parameter of the EXEC statement that invokes it:
LIs~r
MAP or XREF LET or XCAL NCAl.
SIZg
The PARM parameter is a keyword
parametE2lr. Code PARM= followed by the list of options, separating the names of the options with commas and enclosing the list within single quotation marks. For
example::
/ / EXEC PGM=IEWL,PARM=ILIST,MAP'
If you are using a cataloged procedure, you must. include the PARM parameter in the EXEC statement that invokes the procedure.
and qualify the keyword PARM with the name of the procedure step that invokes the linkage editor. For example:
/ / EXEC PL1LFCLG,PARM.LKED='LIST,XREF' ':l"he j:ollowing paragraphs describe the optional facilities. The listing produced by the options LIST, MAP, and XREF are described under 'Listing,' below.
LIST
The LIST option specifies that all linkage editor control statements processed should be listed in the data set defined by the DD statement SYSPRINT.
MAP
The MAP option requests the linkage editor to produce a map of the load module; this map indicates the relative locations and lengths of the control sections in the module.
XREF
The XREF option requests the linkage editor to produce a map of the load module and a cross-reference list of all the external references in each control section. XREF includes MAP.
LET
The LET option requests the linkage editor to mark the load module 'executable,' even if slight errors or abnormal conditions are found during link-editing.
XCAL
The XCAL option requests the linkage editor to mark the load module as executable even i f errors or abnormal conditions, including improper branches between control sections, are found during link-editing. XCAL, which includes LET, applies only to an overlay module.
NCAL
The NCAL option specifies that no external references should be resolved by automatic library call. However, the load module is marked 'executable' (providing there are no errors).
You can use the NCAL option to conserve storage space in private libraries since, by preventing the resolution of external references during link-editing, you can
Chapter 6: Linkage Editor and Loader 69
store PL/I load modules without the relevant PL/I library subroutines; the DD statement SYSLIB is not required. Before executing such load modules, you must link-edit them again to resolve the external references, but the load module thus created need exist only while i t is being executed. You can use this technique to combine separately compiled PL/I
routines in a single load module.
SIZE
The SIZE option specifies the amount of main storage, in bytes, to be allocated to the linkage editor; i t applies only to the F-Ievel linkage editor. Code the SIZE option as a keyword parameter with the following format:
SIZE=(valuel,value2)
For 'valuel' substitute a decimal integer number representing the number of bytes of main storage to be allocated to the linkage editor, including the
allocation for the load module buff:er
allocation for the load module buff:er