CALL

runcbl searches the DYNAMIC_FUNCTION_CALLS configuration variable for a matching call name or call name prefix. If a match is found and the "dlopen(NULL)" feature is supported (true on most UNIX systems) the call name is searched for as a dynamic function in the current process. If it is not found, the call name is searched for as a dynamic function in each of the loaded shared libraries or DLLs specified with the -y option or with the SHARED_LIBRARY_LIST configuration variable.

If the runtime is acting as an application host in a thin client environment, it checks for the @[DISPLAY]: prefix and, if found, passes the call to the thin client.

The runtime next attempts to call any C subprograms that have been linked into the runtime system. Interfacing to C routines is detailed Calling C Programs From COBOL of A Guide to Interoperating with ACUCOBOL-GT.

If the CODE_CASE configuration variable is defined, the change to upper case or lower case is applied as appropriate.

Next, the list of loaded but inactive programs and their ENTRY points is searched for a matching call name. If a name is found, that program is made active, execution is initiated at the proper point in the program.

Next, all loaded programs (both active and inactive) are searched to see if any are part of an object library. For each object library found, the call name is searched for in the list of modules contained in the library. If found, that module is loaded out of the library and made active. See Object File Utility - cblutil for more information.

Next, on Windows systems the call name is searched for as the name of a routine in a loaded DLL.

Next, any libraries specified with the -y runtime option are searched for a matching call name. Note that programs in a library are searched for by their PROGRAM-IDs.

If the program has still not 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), the call name is treated as the filename, 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 (the default value), the call name is treated as the filename, 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, 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_PREFIXconsists of a series of prefixes to apply to the call name. These prefixes are applied, in order, until a matching file is found or all of the prefixes have been tried. See Code and Data File Search Paths for more information.

For example, to search for object files in /usr/obj/ar, /usr/obj/ap, and the directory containing the calling program, you could set CODE_PREFIX to:

CODE-PREFIX  /usr/obj/ar  /usr/obj/ap  ^

When each file name is 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, the current value of CODE_SUFFIX is appended to the filename with an intervening period. An extension is zero to three characters following a period at the end of the name. If See the topic for CODE_SUFFIX in Appendix H. for more information. is not defined, .acu is appended to the filename. If the file is not found, the file is searched for again, this time without the .acu extension. See the topic for CODE_SUFFIX in Appendix H. for more information.

Note: As with all filenames, upper and lower case are significant on UNIX machines but not on VMS and Windows systems.

Next, on Windows, the call name is searched for as the name of a DLL. If the DLL is found it is loaded and the call name is searched for as the name of a routine in it or any other loaded DLL.

Next, on UNIX, the call name is searched for as the name of a shared library.

Finally, the call name is searched for as the name of a dynamic function in the current process, and then in each of the loaded shared libraries or DLLs specified with the -y runtime command-line option or the SHARED_LIBRARY_LIST configuration variable. Note that to match as a dynamic function in Step 1 of this process, the call name must match a name in the DYNAMIC_FUNCTION_CALLS configuration variable.