3.1. Introduction

The MODULE references known to CHKMOD are compiletime references, i.e., references that the compiler is aware of. These are the references that involve a consistency check at runtime. More precisely, CHKMOD considers a MODULE M to reference a MODULE N if and only if M does one of the following:

• bind(N), new(N), unbind(N), or dispose(N): the argument N must be the identifier N or the STRING constant "N".

• uses N.f (or just f) where f is an interface field of N. A use of p.f, where p is a POINTER to a data section of N, is not considered a reference to N since the compiler is not aware that p points to N. For example, suppose the MODULE M contains the following, where p has been initialized outside M to point to a data section for N:

  CLASS c (INTEGER f; ...);
  POINTER(c) p;
  ...
  p.f := 0;

  The above code is not sufficient to make the compiler aware that M references N. It only knows that p points to a record or data section of the CLASS c; presumably N is of the CLASS c, but this is not checked even at runtime (although some future release of MAINSAIL may provide such a check).

Many of the commands simply manipulate the src and dst MODULE sets. A src MODULE is opened and examined to obtain information about it. The entries in the src MODULE set are actually (MODULE name, file name) pairs, where the file name is the (library or object) file from which the MODULE came. A given pair can occur at most once, but the same MODULE name can occur multiple times. For example, the same MODULE could have been obtained from several different libraries, or there could be several MODULEs with the same name.

Unlike a src MODULE, a dst MODULE is not opened when it is added to the dst MODULE set since no information is obtained about it; it is just a MODULE name. Since the dst MODULE set contains MODULE names rather than (MODULE name, file name) pairs, a given MODULE name can occur at most once in the dst MODULE set.

Note that the terms “src MODULEs” and “dst MODULEs” are a bit misleading. The “src MODULEs” are not source code (they are objmods). They are not the source for any sort of copy operation, and the “dst MODULEs” are not a destination of such an operation. Furthermore, the “dst MODULEs” are not really MODULEs; they are just MODULE names, but no MODULEs of the specified names need exist. For the purposes of CHKMOD, therefore, you should think of “src MODULEs” and “dst MODULEs” as arbitrary terms that do not have their usual English meaning.

3.4. Commands to Add, Remove, and Show MODULEs

• addSrcModules modList: add the indicated MODULEs to the src MODULEs. More precisely, add pairs (m,f), where m is the name of the MODULE contained in the file f. If an entry in modList is not a valid MODULE name, then it is assumed to be the file name f; otherwise, it is assumed to be the MODULE name m, and f is formed from the entry in the standard way for the target system (e.g., the file name foo-usp.obj is formed for the MODULE name FOO on a SPARC UNIX system). In any case, the target file is opened and information (such as the MODULEs it references) is obtained from it.

• addSrcLibrary libName {modNameList}: add the indicated MODULEs (in library libName) to the src MODULEs. If modNameList is omitted, all the MODULEs in the library are added.

• remSrcModules {modNameList}: remove the indicated MODULEs from the src MODULEs. More precisely, remove every pair (m,f) for which m is in modNameList. If modNameList is omitted, all src MODULEs are removed.

• remSrcLibrary libName {modNameList}: remove the indicated MODULEs (in library libName) from the src MODULEs. More precisely, remove every pair (m,libName) for which m is in modNameList. If modNameList is omitted, remove all MODULEs from libName; i.e., remove (m,libName) for all m.

• showSrcModules: show the current src MODULEs. Each pair (m,f) is displayed as m (f), i.e., the MODULE name followed by the parenthesized file name of the library file or object file from which the MODULE was obtained. An example of the output is:

  src modules:
    $ARYMOD (/sys.dir/sys-usp.olb)
    $CVRLR (/sys.dir/sys-usp.olb)
    $DATDIO (/sys.dir/sys-usp.olb)
    $DATTIO (/sys.dir/sys-usp.olb)
    $DEBUG (/sys.dir/sys-usp.olb)
    $DPYEXE (/sys.dir/sys-usp.olb)
  
  6 src modules

• addDstModules modNameList: add the MODULE names to the dst MODULEs. The names must be valid MODULE names, but no attempt is made to find or open the MODULEs.

• addDstLibrary libName {modNameList}: add the indicated MODULEs (from library libName) to the dst MODULEs. If modNameList is omitted, all the MODULEs in the library are added.

• remDstModules {modNameList}: remove the indicated MODULEs from the dst MODULEs. If modNameList is omitted, all dst MODULEs are removed.

• remDstLibrary libName {modNameList}: remove the indicated MODULEs (in library libName) from the dst MODULEs. If modNameList is omitted, all the MODULEs from the library are removed.

• showDstModules: show the current dst MODULEs. An example of the output is:

  dst modules:
    EDIT
  
  1 dst module

• target {targetSystem}: subsequent MODULEs are for the indicated target system. This allows CHKMOD to deal with MODULEs compiled for a different target from the one CHKMOD is running on.

• outputFile {fileName}: Append subsequent output to the indicated file, which is created if necessary. This command may be given at any time to change where subsequent output is written. Omitting fileName causes the output to be written to logFile. Each time a command is given that causes output, the file is opened, positioned to the end, the output written, and then the file is closed.

• quit: exit CHKMOD.

• <eol>: no effect.

• ?: show commands. The output looks something like:

  target           {targetSystem}
  outputFile       {fileName}
  addSrcModules    modList
  addSrcLibrary    libName {modList}
  remSrcModules    {modList}
  remSrcLibrary    libName {modList}
  showSrcModules
  addDstModules    modList
  addDstLibrary    libName {modList}
  remDstModules    {modList}
  remDstLibrary    libName {modList}
  showDstModules
  showAllRefs
  findRefs
  checkConsistency
  quit
  <eol>

The showAllRefs commands shows, for each src MODULE, all MODULEs that it references, as defined above. These MODULEs need not be in either src MODULEs or dst MODULEs. An example of the output is:

All references:
  $ARYMOD (/sys.dir/sys-usp.olb)
    $ERRMOD
    $KERMOD
    $TXTDIO

  $CVRLR (/sys.dir/sys-usp.olb)
    $ERRMOD
    $KERMOD
    $TARGET
    $TXTDIO

  $DATDIO (/sys.dir/sys-usp.olb)
    $ERRMOD
    $KERMOD
    $TXTDIO

  ...

In this example, $ARYMOD references $ERRMOD, $KERMOD, and $TXTDIO; $CVRLR references $ERRMOD, $KERMOD, $TARGET, and $TXTDIO; and $DATDIO references $ERRMOD, $KERMOD, and $TXTDIO.

3.7. findRefs

The findRefs commands find all src MODULEs that reference any dst MODULE. This information could also be determined by examining the output of the showAllRefs command described above, but not as conveniently. An example of the output is (with a single dst MODULE, EDIT):

There are references to:
  EDIT

From:
  $DEBUG (/sys.dir/sys-usp.olb)
  $DPYEXE (/sys.dir/sys-usp.olb)
  BUF (/sys.dir/sys-usp.olb)
  DATMGR (/sys.dir/sys-usp.olb)
  DBEX (/sys.dir/sys-usp.olb)
  E29 (/sys.dir/sys-usp.olb)
  MAI (/sys.dir/sys-usp.olb)
  MAINED (/sys.dir/sys-usp.olb)
  MAINVI (/sys.dir/sys-usp.olb)
  MEDT (/sys.dir/sys-usp.olb)
  MTFDBG (/sys.dir/sys-usp.olb)
  MTFEDT (/sys.dir/sys-usp.olb)
  NULMGR (/sys.dir/sys-usp.olb)
  NXTDIF (/sys.dir/sys-usp.olb)
  RECOM (/sys.dir/sys-usp.olb)
  TM9 (/sys.dir/sys-usp.olb)
  TXTMGR (/sys.dir/sys-usp.olb)
  UCREX (/sys.dir/sys-usp.olb)

This information could be used to determine which MODULEs need to be recompiled if a change is made to EDIT's interface, keeping in mind that this shows only those references that are known to the compiler, as explained earlier. Be aware that there could be other MODULEs that reference EDIT interface fields only through POINTERs (i.e., using the syntax pointer.field) and hence do not show up here, even though such MODULEs may also need to be recompiled if EDIT's interface were changed.

3.8. checkConsistency

The checkConsistency command reports interface inconsistencies among the src MODULEs. It also lists referenced MODULEs that are not among the src MODULEs, since CHKMOD is not able to check the interface consistency of such MODULEs.

An interface inconsistency reported as M (f) references N indicates that when the MODULE M (the one stored in the file f) was compiled, it saw a declaration of the MODULE N's interface that is incompatible with the declaration that N saw of its own interface when it was compiled. Either M or N (or both) needs to be recompiled, since one (or both) of them is out of date. Note that it is OK (and no inconsistency is reported) if M knows only about some initial part of N's interface, as long as there is not an inconsistency in this initial part; i.e., new interface fields can be added to the end of N's interface declaration without creating an interface inconsistency.

An example of the output is:

Interface inconsistencies:
  $DEBUG (/sys.dir/sys-usp.olb) references SHOVAL (/sys.dir/sys-usp.olb)

The following modules are referenced by one or more modules but are
not among the src modules (some may be FLI or "dummy" modules):
  FORMAT
  PRTMOD
  MDDIS
  OSDCNF
  LKUPMD
  XXFLI
  XTXFLI
  XMXFLI
  $SUNGRF
  $MDGBL
  $ACPUID
  $OSDGBL
  $SYSITF
  $XDPYEXE

In the above example, all the “missing” MODULEs are in fact either FLI or dummy MODULEs (as established by the system PROCEDURE setModName). However, when this is not the case, any missing MODULEs that are not FLI or dummy MODULEs should be added to the src MODULE set and the consistency check carried out again.

3.9. Use of CHKMOD