The Interface Module is a collection of information which acts as a go-between for the application program on one hand, and the rest of the system on the other. It acts as an interface (hence the name) between the program and system so that neither has to know any details about the working of the other.This means that either side of the interface could be completely changed, without having to change anything on the other side. Only the Interface Module itself may have to be changed.
The main functions of the Interface Module are to:
An Interface Module can exist in two forms. When an application program is being developed, the information making up the Interface Module is normally put into an ordinary text file, where it can be easily inspected and edited. The file should have the same name as the program, but with a file extension of .ifl.
When the system interface for a program has become relatively stable, the Interface Module can be saved in compiled form – this leads to a more efficient running of the system. The compiled form has the same name as the source file, but a file extension of .ifc.
Strictly speaking, the source file is the Interface File although that term is often used to mean either source or compiled forms of the Interface Module.
The program compifl is provided to compile an Interface File. Perform the usual startup procedure for ADAM program development then type:
in response to the command language prompt. filename
may optionally include the .ifl
extension.
filename.ifl
will be compiled into filename.ifc
.
When an ADAM program is first loaded, it searches for the required Interface Module, reads it and uses the information therein to set up the common blocks used by the parameter system to control its behaviour. The program will accept either source or compiled form of the Interface Module.
By default, the program will look for its Interface Module in the directory where the executable file
was found. It looks firstly for a compiled file, name.ifc
(where name is the name of the program’s
executable file); if that is not found, it looks for a source file, name.ifl
This behaviour can be altered by defining a list of directories in which the program will search before using the default. The process is fully described in Appendix B.
An Interface File for a single program consists of a number of Specification Fields contained between INTERFACE and ENDINTERFACE statements. There are four possible types of Specification Field under ADAM1, the Parameter Specification, the Help Library Specification, the Message Specification and the Action Specification. They are all optional (depending upon the application).
Specification Fields may consist of a number of subfields as shown in the example below. Examples in this document will use ‘.’ to represent possible lines not shown.
programname
is a character string giving the name of the Interface Module. It must be the same as the
name of the program and unique in any given ADAM system.
For efficiency, a group of related programs can all be linked into a single executable file called a monolith (see SG/4). If the monolith is to be run from ICL, the individual Interface Files must be concatenated into a single file for the whole monolith and the monolithic Interface File must have the same filename as the executable file. The structure of a monolithic Interface File is as follows:
where programname_1
, programname_2
, etc. are the names of the individual programs. They must
comply with the rules for action names (see Appendix A.1).
When monoliths are run directly from a Unix shell, the individual program Interface Modules are used.
Details of Interface File parsing are given in Appendix A, but the following points should be sufficient for now.
#
(apart from within quoted strings).