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 a file name 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 file name (the name by which the object file is actually found).
An object module can be in one of three states:
1. Active. This is the state of any program that has been called but has not yet exited. It also applies to the first (or main) program of a run unit. An active program is always memory resident.
2. 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 attribute are never in this state because they are automatically canceled when they exit.
3. Not loaded. This is the initial state of all object files. It indicates that the program is not in memory.
CALL
When a CALL occurs, runcbl performs these steps:
1. runcbl attempts to call any C or assembly language subprograms that have been linked into the runtime system. This process is detailed in Book 4, Appendix C.
2. If the CODE-CASE configuration variable has been specified, the change to upper case or lower case is applied if appropriate.
3. Next, the list of loaded but inactive programs is searched for a matching call name. If one is found, it is made active and the CALL is complete.
4. Next, all loaded programs (both active and inactive) are searched to see if any are part of an object library (see Chapter 3, section 3.2). For each object library found, the call name is searched for in the list of modules contained in the library. If found, then that module is loaded out of the library and made active.
5. Next, any libraries specified with the "-y" runtime command are searched for a matching call name. Note that programs in a library are searched for by their PROGRAM-IDs.
6. If the program has not yet been found, the disk is searched for the object module.
The name is examined to see if it is a full path name.
If the call name begins with a "\" (back slash), then the call name is treated as the file name, and the object
file (if it exists) is loaded and made active.
If the call name begins with a "/" (forward slash) and the configuration variable APPLY-CODE-PATH is set to off (0), the call name is treated as the file name, and the object file (if it
exists) is loaded and made active.
If the call name begins with a "/" (forward slash) and the configuration variable APPLY-CODE-PATH is set to on (1), then the current CODE-PREFIX is applied to it. Or, if the call name is
not a full path name, the current CODE-PREFIX is applied to it.
The configuration variable CODE-PREFIX (see Runtime Configuration above) consists of a series of prefixes to apply to the call name. These prefixes are applied, in order, until a matching file has been found or all the prefixes have been tried.
For example, to search for object files in both the "/usr/obj/ar" and "/usr/obj/ap" directories, you could set CODE-PREFIX as follows:
CODE_PREFIX /usr/obj/ar /usr/obj/ap
When each file name is being formed, the configuration variable CODE-SUFFIX is
checked to see if it has been defined. If it has, and the call name does not
have an explicit extension specified, then the current value of CODE-SUFFIX is
appended to the file name with an intervening period. An extension is zero to
three characters following a period at the end of the name.
CANCEL
When a CANCEL verb is executed, the following steps are performed:
1. If a CANCEL ALL verb is being executed, all loaded programs that are inactive are set to the not loaded state.
2. Otherwise, the list of active programs is searched for a matching call name. If found, then an active program is being canceled and the CANCEL is ignored.
3. Next the list of loaded but inactive programs is searched for a matching call name. If found, this program is set to the not loaded state.
4. If no matching programs are found, the CANCEL verb has no effect. This is not considered an error.
CHAIN
Finally, a CHAIN verb performs these steps:
1. Any USING parameters are first copied to a safe place. These are made available to the chained program through the CHAINING phrase of the Procedure Division header.
2. All active programs are made inactive.
3. A CANCEL ALL is implicitly executed.
4. A new program is loaded using the same rules that apply to the CALL verb. This becomes the main program of the new run unit.
For more information see the entry for "CHAIN Statement" in Reference Manual section 6.6.