By default, ADAM application programs attempt to find their Interface Module in the directory containing the executable file. A compiled (.ifc) file will be used in preference to a source (.ifl) file. To allow users to have different versions of the Interface Module for a given program without having multiple copies of the executable file, a search path mechanism has been implemented. This will be particularly useful for private tailoring of the Interface Modules of released software.
The search path is entirely the responsibility of the user – no value is defined in the standard system setup as there is a slight overhead in having one defined when it is not required.
If the search path is not defined, or an Interface Module is not found using it, the program will attempt to use the default.
When a program is loaded, its name is obtained using system routine GETARG and ignoring any path component of the name. If environment variable ADAM_IFL is defined, it is assumed to specify a search path as a list of directory names separated by semi-colons. Each directory in turn is searched for a file with the same name as the program and with extension .ifc or, failing that, .ifl. If such a file is found, it is used as the Interface Module.
When a program is loaded, it attempts to translate the logical name ADAM_IFL using the tables defined by the SYSTEM logical name LNM$FILE_DEV (Normally PROCESS, JOB, GROUP and SYSTEM in that order).
ADAM_IFL may be a search path and, if it is defined, it is used as the filespec, together with a default filespec of ‘filename.IF%’ (where ‘filename’ is the filename of the executable image and ‘%’ is any single character), in a call to LIB$FIND_FILE.
If such a file is found, the type is checked and, if the type is not .IFC or .IFL, the routine continues searching until no more files matching the specification are found. Note that a .IFC file will be found before a .IFL file in any given directory.
Notes: