ACUCOBOL-GT is not a linked language. Instead, when a subprogram is called it is loaded dynamically at runtime. ACUCOBOL-GT
does not use the name specified in the PROGRAM-ID paragraph. Instead, the name specified in the CALL statement is treated
as the filename of the object file to load. Actually,
runcbl maintains two names for each called object file: its call name (the exact name specified in the CALL statement) and its filename
(the name by which the object file is actually found).
An object module can be in one of three states:
- Active. This is the state of any program that has been called and has not yet exited. It also applies to the first (or main)
program of a run unit. An active program is always memory resident.
- Loaded but inactive. A loaded program is one that is memory resident but not running. This is the state of a program that has been called and
has also exited. It remains in memory until it is the object of a CANCEL verb. A program in this state keeps its files and
data items in the same state that they were in when the program exited. Note that programs with the INITIAL PROGRAM attribute
are never in this state because they are automatically canceled when they exit.
- Not loaded. This is the initial state of all object files. By default, not loaded indicates that the program is not in memory. However,
if the logical cancel mechanism is enabled, the program may be cached in memory. See Memory Management for more information.
EXIT PROGRAM
ACUCOBOL-GT conforms to the 1985 COBOL standard, which specifies that a called program should execute an implicit EXIT PROGRAM
if execution runs off the end of the Procedure Division. ACUCOBOL-GT versions prior to 9.1 executed an implicit STOP RUN in
this case.