DBL tries to resolve all unresolved external references in the modules of a load unit, For this, it first searches the modules which are already linked for CSECTs or ENTRYs with the same name. If no matching symbols can be found, it searches for further modules containing such CSECTs or ENTRYs and includes these modules in the load unit. This loading operation is referred to as the autolink function of DBL. The autolink function handles only CSECTs and ENTRYs that are not masked (see the manual “BINDER” [1]).
Search strategy
DBL searches for the modules that resolve the external references in various “repositories”. If a module containing matching CSECTs or ENTRYs is found in one of the repositories, it is included in the load unit and the search operation is terminated.
By default, searching involves the following steps, and the sequence in which steps 1 to 4 take place can be changed by the user (see the note entitled "User defined searching order"):
Searching in the link context (see "Context as a linking and loading environment").
Searching in the user shared code which was loaded with the ASHARE macro.
Searching in the user shared code is executed only in RUN-MODE=*ADVANCED.
The common memory pools are searched only if the user specified SHARE-SCOPE= *MEMORY-POOL(...)/*ALL, since the default is SHARE-
SCOPE=*SYSTEM-MEMORY. The search can be restricted to common memory pools with a defined scope or can be suppressed entirely (SHARE-
SCOPE=*NONE).
Searching in the system shared code, which consists of the nonprivileged subsystems in class 3/4/5 memory (see the manual “Subsystem Management” [10]). If an external reference is resolved by a symbol of the subsystem, DBL establishes a connection to this subsystem. The user can prevent searches in a nonprivileged subsystem by specifying the appropriate operand in the load call (SHARE[-SCOPE]=*NONE).
Searching in reference contexts (see "Context as a linking and loading environment") which the user has defined. If several reference contexts exist, these are searched in their existing order. If no reference contexts exist, this step is skipped. This step is also possible only for the BIND macro.
Searching in libraries specified by the user in the load call (LIBRARY or LIBNAM@/LIBNAM/LIBLINK operand). If no such library was specified by the user (in RUN-MODE=*ADVANCED), but a library was assigned the link name BLSLIB, then this default library with the link name BLSLIB will be used by DBL. If the specified library is corrupt or does not exist, processing is aborted with an error message.
Searching in
alternate libraries.
There are two groups of alternate libraries:
Alternate libraries that are declared using file link names.
In this case, it is necessary to distinguish between:
alternate user libraries with the file link names BLSLIBnn
andalternate system libraries with the file link names $BLSLBnn
Alternate system libraries are required for components of the runtime system supplied by Fujitsu. They are assigned independently by the respective runtime component by means of the file link name $BLSLBnn (00<=nn<=99) and cannot be influenced by the user. The file link names of alternate system libraries are managed by the Software Development of the Fujitsu Technology Solutions GmbH and are exclusively reserved for their software products.
System and user Tasklibs
These are libraries with the name TASKLIB or a library that is assigned using the SET-TASKLIB command.
Alternate libraries declared by means of the file link name are searched in the following order:
Alternate system libraries with the file link name $BLSLB00 .. 49
Alternate libraries that were assigned by the user via the file link name BLSLIBnn (00
<=nn<=99).Alternate system libraries with the file link name $BLSLB50 .. 99 .
In a group of libraries these are searched in ascending numerical order (by “nn”).
System and user tasklibs are searched in the following sequence:
the library assigned by the user with the SET-TASKLIB command.
the “$userid.TASKLIB” library
or, if this is not present,
the “$defluid.TASKLIB” library
Here, “defluid” is the name of the system default ID (value of the class 2 system parameter DEFLUID, see the “Introductory Guide to Systems Support” [9]).
Which of the alternate libraries is searched depends on the way in which the loadoperation is performed:
Loading performed with START/LOAD-EXECUTABLE-PROGRAM
or with the BIND macro (with INTVERS=SRVxxx, where xxx>=002)Users can define which of the specified libraries are to be searched and in whatorder in the ALTERNATE-LIBRARIES or ALTLIB operand.
Loading performed with START/LOAD-PROGRAM and RUN-MODE=*ADVANCEDor with the BIND macro (INTVERS=BLSP2/SRV001)
Only the alternate libraries declared with the file link name BLSLIBnn or $BLSLBnn are searched if ALTERNATE-LIBRARIES=*YES has been specified.
Loading performed with START/LOAD-PROGRAM and RUN-MODE=*STD
Only the system and user Tasklibs are searched.
Steps 5 and 6 above can be suppressed in the load call with START/LOAD-EXECUTABLE-PROGRAM or the BIND macro by specifying the operand AUTOLINK=*NO. If this is done, DBL will search only the already loaded private and shared code. This eliminates thepossibility of runtime modules being inadvertently loaded. Unresolved external references, if any, are handled by DBL as described in "Resolving external references".
If name conflicts are detected, DBL handles them as described in "Handling name conflicts".
The autolink function does not refer to the temporary EAM object module file. If modules are to be loaded from the EAM object module file (*OMF operand in the load call), the user must make sure that the first module in the file contains the start address of the load unit. In the load call, the user must specify that all modules are to be fetched from the EAM object module file (operand FROM-FILE=*MODULE(LIBRARY=*OMF,ELEMENT=*ALL,...)).
No overlay loading is initiated as a result of weak external references (WXTRNs). These are resolved only:
in a nonprivileged subsystem or in the shared code
by modules fetched, for example, using the INCLUDE statement
by the autolink function called by other EXTRNs or V-type constants.
A COMMON section is not linked by the autolink function. This means that if an external reference refers to a COMMON section, the module containing this COMMON section cannot be loaded automatically. The external references are not resolved.
User defined searching order
Users can change the search sequence of steps 1 to 4 to suit their requirements. The following operands are available for this:
For the MODIFY-DBL-DEFAULTS command:
RESOL-TYPE=*USER(ORDER=...) and
PUBLIC-RESOL-TYPE=*USER(ORDER=...)For the BIND macro:
RESORD (with RESTYP=USER) and PURESOR (with PURESTY=USER)
Handling unresolved external references
The user can control how external references not resolved by searching the alternate libraries (see step 6 in "Resolving external references") are to be handled by including the UNRESOLVED-EXTRNS operand in the load call.
The following options are available:
unresolved external references are not allowed
(operand UNRESOLVED-EXTRNS=*ABORT)
This causes loading of the current load unit to be aborted.unresolved external references are assigned a user-defined address(operand UNRESOLVED-EXTRNS=*STD)
The address is specified by the user in the ERROR-EXIT operand in the load call. The default value for the address is X’FFFFFFFF’.unresolved external references are resolved at a later time
(operand UNRESOLVED-EXTRNS=*DELAY)
DBL stores the unresolved external references in the link context (see "Context as a linking and loading environment"). If a new load unit is loaded in the context, DBL tries to resolve the stored external references at the end of the loading operation using CSECTs and ENTRYs of the new load unit. This process is repeated when further load units are loaded, for as long as the context remains in existence. This option does not apply to external dummy sections (XDSEC-Rs). When stored in the context, external references that are to be resolved at a later time are given a temporary address, specified by the user in the load call by means of the ERROR-EXIT operand. The default value is *NONE, which internally corresponds to the address X’FFFFFFFF’.the specification UNRES=DELAYWARN in the BIND macro basicaly has the same effect as UNRES=DELAY. The two specifications differ only in the return code. If external references exist which must be resolved later, a corresponding return code is issued with DELAYWARN, while the return code with DELAY is null. In addition, the specification UNRES=DELAYWARN is a prerequisite for outputting external references from earlier load operations which remained unresolved to the user-defined data area.
When RUN-MODE=*STD is set, processing is performed according to the operand UNRESOLVED-EXTRNS=*STD, and all unresolved external references are given the address X’FFFFFFFF’.
DBL logs all unresolved external references in the SYSOUT system file. In interactive mode, with UNRESOLVED-EXTERNS=*STD set, the user can then decide whether processing is to continue or terminate when unresolved external references are detected.In batch mode, processing is always continued.
Unresolved dummy sections (XDSEC-Rs) are listed separately from the other external references. XDSEC-Rs are only resolved with XDSEC-Ds in the same context.
The USNUNR@ operand of the BIND macro (only in conjunction with INTVER=SRVxxx, where xxx >= 005) enables the output of a list of unresolved external references to a userdefined data area. This operand and the UNRES operand are totally independent of each other. Details are provided in the desription of the BIND macros in the „Executive Macros“ manual [7]. When INTVERS=SRVxxx (xxx >= 006) and UNRES=DELAYWARN are specified in the BIND macro, the list of external references from earlier load operations which remained unresolved can be output to the user-defined data area either as an alternative or in addition.