DBL searches for the module specified in the START/LOAD-EXECUTABLE-PROGRAM or START/LOAD-PROGRAM command or the BIND macro in various “repositories”. The specified module name may be:
the name of a CSECT or an ENTRY, which must not be masked
the external name of an object module or an LLM
the name of a program in the shared code in class 3/4/5 memory (loaded as anonprivileged subsystem)
the name of a program in the user shared code.
The search is performed in the following stages:
Searching in the link context specified by the user (see "Context as a set of objects"). If nonmasked CSECTs or ENTRYs are found that match the specified symbol name in the load call, DBL passes the start address to the user task and the loading operation is terminated.
Searching in the link context is performed only for the BIND macro.
Searching in the user shared code which was loaded into the common memory pool with the DBL macro ASHARE. A start address is passed and the loading operation is terminated if DBL finds a shareable program (defined with the parameter PROGRAM in the ASHARE macro) or a nonmasked CSECT or an ENTRY with this name.
Searching in the user shared code is executed only in RUN-MODE=*ADVANCED.
Searching in the user shared code is not executed if NAME-SCOPE=*ELEMENT is specified in the START/LOAD-EXECUTABLE-PROGRAM command.
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 nonmasked CSECTs or ENTRYs are found that match the specified symbol name in the load call, DBL passes the load address to the user task and the loading operation is terminated.DBL thus establishes a connection between the user task and the subsystem.In RUN-MODE=*ADVANCED, the user can suppress searching in a nonprivileged subsystem by means of an operand in the load call (SHARE[-SCOPE]=*NONE).
Searching in the user shared code is not executed if NAME-SCOPE=*ELEMENT is specified in the START/LOAD-EXECUTABLE-PROGRAM command.
Searching in the library specified by the user in the load call (LIBRARY or LIBNAM@/LIBNAM/LIBLINK operand). If, in RUN-MODE=*ADVANCED, no such library was specified but a library was assigned to the link name BLSLIB, then DBL uses this default library with the link name BLSLIB. If the specified library is faulty 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 load operation 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 what order 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.
Selecting and assigning a program version
It is possible to select a program version to be used by DBL when searching for primary input and when resolving external references. As far as DBL is concerned, a program is basically a load unit with a specific version. All program definitions (CSECT, ENTRY, COMMON, ...) contained in the load unit inherit that version.
There are two ways of selecting a program version:
Selecting a version before loading and starting:
The SELECT-PROGRAM-VERSION command or the SELPRGV macro is used to select a version of the load unit to be used by DBL in subsequent load calls. The load unit must not be already loaded on selecting the version, but multiple versions of that load unit may exist on the system.
Selecting a version in the load call:
The LOAD-EXECUTABLE-PROGRAM and START-EXECUTABLE-PROGRAM (or LOAD-PROGRAM and START-PROGRAM) commands or the BIND and ASHARE macros can be used to specify a version (with the operand PROGRAM-VERSION or PGMVERS, respectively) in the load call. DBL then searches among the already loaded objects for a load unit with the given name and exactly the same version. DSSM subsystems are also included in the search. DBL treats the subsystem version as a program version and takes all “connectable entries“ (see "System shared code") of the subsystem into account.
Note that a version selection in the load call will always override any previously made version selection.
If the selected version (see points 1 and 2 above) cannot be found among the loadedobjects, DBL assigns a version to the load unit that is to be loaded.
The selected version for a program can be queried by means of the GETPRGV macro.
The program version can also be selected for unloading and unlinking and for the output of link and load information.