In general, a module hierarchy consists of one top-level module and multiple directly required modules below the top-level module, where each submodule can also directly require one or more modules.
For information on when one module must directly require another module, see The Module Hierarchy.
The general steps for creating a module hierarchy are:
Naming the top-level module creates a single top-level module for the KB. The next step is to create additional modules in the current KB.
Creating a New Module
To create a module hierarchy, you must create additional modules in the current KB. Once you have created these modules, you can declared them to be directly required by the top-level module, as well as by other modules in the hierarchy.
Creating a New Module
You can create a new module interactively or programmatically.
Main Menu > Miscellany > Create New Module.
Top-level-moduleattribute of the new Module Information system table.
The module-name cannot:
g2-create-modulecreates a set of system tables for the new module. The
top-level-moduleattribute of the Module Information system table is module-name. All other attributes have default values.
The next procedure creates a new module based on the symbolic name passed as its argument, and assigns the kb-workspace to the new module:
System Tables Associated with a New Module
When you create a new module interactively or programmatically, G2 creates set of associated system tables for the new module. However, these system tables are not installed in the current KB; only the system tables of the top-level module are in effect for the current KB.
classesin an otherwise empty current KB, Inspect displays a workspace like this:
Declaring Directly Required Modules
For each module that requires other modules, you must assign the name of the required module to the
Directly-required-modules attribute in its associated Module Information system table. A module can directly require one or more other modules.
top, and suppose you create a new module named
classes, which you want to be below the module
top in the hierarchy.
Directly-required-modulesattribute, in this example,
concludeaction to change the
Directly-required-modulesattribute of a specific Module Information system table, for example:
Checking for Consistent Modularization
If the current KB contains one or more modules, those modules must conform to G2's rules for consistent modularization, as follows:
module-Athat are referenced in
module-Dto another module.
Notesattributes of the nonconforming modules, nonconforming top-level workspaces, and so on, as shown in the previous figure.
Notesattributes of your items.
G2 does not evaluate the consistency and completeness of all references within the KB that cross module boundaries. For instance, G2 does not validate the existence of procedures and functions that are referenced but not contained in the same module. These and other execution linkage references play no role in how G2 validates the consistency of a module hierarchy.
check for consistent modularization, to check for consistent modularization.
When you issue the
check for consistent modularizationcommand, Inspect displays an Inspect workspace and places on it any messages that describe why the current KB is not consistently modularized.
The following figure shows an Inspect workspace with two messages, produced after executing the
check for consistent modularizationcommand:
In this figure, the messages from Inspect report that the current KB contains at least one top-level KB workspace whose
Module-assignment attribute has the value
unspecified, and that at least one module exists in the KB that is not required by any other module.
Module-assignmentattribute has the value
unspecified. Then, either enter a module assignment for that workspace or delete it.
Directly-required-modulesattribute of the Module Information system table associated with the module that requires it.
In the save KB workspace, include the
including all required modulesstatement in the
Save module ... ascommand.
G2 displays a list of all the modules it will save with a confirmation message.
OK to save the modules.
Main Menu > Save KB.
Save module ... ascommand that appears to specify the name of the module to save.
If any directly or indirectly required module was not loaded from an existing KB file, then when you specify the
,including all required modulesphrase in the
Save module ... ascommand, G2 creates new KB files with names based on the combination of:
The module name in the
Top-level-moduleattribute of each module's associated Module Information system table
Specifying the Filename of a Saved Module
When saving a module that is directly required by other modules, you should save it to a filename that is the same as the module name. This allows G2 to find the directly required module's associated KB file by using G2's default search techniques.
When saving a module, G2 offers defaults as follows:
By default, G2 stores this KB file in a file whose name begins with the
ALL- prefix and ends with the name of the current KB's top-level module.
Deleting a Module
Deleting a module means removing the module, all its associated system tables, and all its associated items from the current KB. Recall that items are associated with a module based on the module assignment of the workspace on which the items reside. Deleting a module does not mean deleting the KB file in which a particular module is stored.
choose a module to deletemenu, select a module to delete.
g2-delete-modulesystem procedure, as described in the G2 System Procedures Reference Manual.
ifrule or an
ifstatement in a procedure to determine whether a particular module exists in the current KB. This procedure accepts a module name as its argument to check whether it is the top-level-module: