COBOL Manual for TNS/E Programs (H06.08+, J06.03+)

in the CONSULT directives. When trying to resolve unqualified external references, the compiler
searches the files of the tertiary search list in the order that they appear. If the compiler resolves
an external reference from the tertiary search list, the object program that the compiler finds is not
bound into the target file. Programs resolved from the tertiary search list do not have to be in the
system library. They can be elsewhere and can be bound in later or can be referenced in a run-time
library.
ECOBEXT File
If you did not provide search lists, or if the compiler did not find the necessary external references
on them, in ZCOBDLL, or in ZCREDLL, it uses the ECOBEXT file to perform parameter validation,
but does not import any object code. Programs resolved from ECOBEXT are available to the
program at load time.
When you install the ECOBOL compiler, the ECOBEXT file is stored on the subvolume
$SYSTEM.SYSTEM. If you move the ECOBEXT file to another subvolume, use the CONSULT directive
to tell the compiler where to find it.
NOTE: The preceding paragraph applies only to the NonStop system. For the locations of files
on the PC, see NonStop COBOL for TNS/E (ETK) (page 964).
ECOBEX0 and ECOBEX1 Files
Each RVU of the ECOBOL compiler includes three files: ECOBEX0, ECOBEX1, and ECOBEXT.
These represent the most recent, next most recent, and third most recent RVUs of the Guardian
environment, respectively. If you need access to a routine that was added (or to a parameter that
was added to an existing routine) in the most recent version of the Guardian environment, include
a CONSULT directive specifying ECOBEX0 in your compilation. The compiler then validates all
calls of Guardian system routines from ECOBEX0 instead of from ECOBEXT.
When you install the ECOBOL compiler, the ECOBEX1 and ECOBEXT files are stored on the
subvolume $SYSTEM.SYSTEM. If you move either file to another subvolume, use the CONSULT
directive to tell the compiler where to find it.
NOTE: The preceding paragraph applies only to the NonStop system. For the locations of files
on the PC, see NonStop COBOL for TNS/E (ETK) (page 964).
CALL and ENTER Statement Processing: Detailed Explanation
In processing CALL and ENTER statements, the compiler attempts to:
1. Find the called program (see Finding the Called Program) or the entered program (see Finding
the Entered Program)
2. Validate the parameters in the calling program against those expected by the called program
(see CALL (page 293) and ENTER (page 319))
3. Generate any necessary instructions to present the parameters from the calling program in
the form that the called program expects (see Presenting Parameters to the Called Program)
4. Generate any necessary instructions to deliver a returned value (from the GIVING clause of
an ENTER statement) in the form that the calling program expects (see Delivering the Returned
Value)
5. Bind or link the object code for the called program into the target file or postpone the binding
or linking until the first time the loadfile is loaded for execution (see Linking the Object Code)
Finding the Called Program
When the compiler reaches the end of a separately compiled program, it identifies all program
names that were explicitly referenced by CALL statements in that program. If a CALL statement
specified an identifier instead of an explicit name, the compiler cannot validate the parameters
518 Program Compilation