MIMIX uses named definitions to identify related user-defined configuration information. A multi-part, qualified naming convention uniquely describes certain types of definitions. This includes a two-part name for journal definitions and a three-part name for transfer definitions and data group definitions. Newly created data groups use remote journaling as the default configuration, which has unique requirements for naming journal definitions. For more information, see Target journal definition names generated by ADDRJLNK command.
The multi-part name consists of a name followed by one or two participating system names (actually, names of system definitions). Together the elements of the multi-part name define the entire environment for that definition. As a whole unit, a fully-qualified two-part or three-part name must be unique. The first element, the name, does not need to be unique. In a three-part name, the order of the system names is also important, since two valid definitions may share the same three elements but with the system names in different orders.
For example, MIMIX automatically creates a journal definition for the security audit journal when you create a system definition. Each of these journal definitions is named QAUDJRN, so the name alone is not unique. The name must be qualified with the name of the system to which the journal definition applies, such as QAUDJRN CHICAGO or QAUDJRN NEWYORK. Similarly, the data group definitions INVENTORY CHICAGO HONGKONG and INVENTORY HONGKONG CHICAGO are unique because of the order of the system names.
When using command interfaces which require a data group definition, MIMIX can derive the fully-qualified name of a data group definition if a partial name provided is sufficient to determine the unique name. If the first part of the name is unique, it can be used by itself to designate the data group definition. For example, if the data group definition INVENTORY CHICAGO HONGKONG is the only data group with the name INVENTORY, then specifying INVENTORY on any command requiring a data group name is sufficient. However, if a second data group named INVENTORY NEWYORK LONDON is created, the name INVENTORY by itself no longer describes a unique data group. INVENTORY CHICAGO would be the minimum parts of the name of the first data definition necessary to determine its uniqueness. If a third data group named INVENTORY CHICAGO LONDON was added, then the fully qualified name would be required to uniquely identify the data group. The order in which the systems are identified is also important. The system HONGKONG appears in only one of the data groups definitions. However, specifying INVENTORY HONGKONG will generate a “not found” error because HONGKONG is not the first system in any of the data group definitions. This applies to all external interfaces that reference multi-part definition names.
MIMIX can also derive a fully qualified name for a transfer definition. Data group definitions and system definitions include parameters that identify associated transfer definitions. When a subsequent operation requires the transfer definition, MIMIX uses the context of the operation to determine the fully qualified name. For example, when starting a data group, MIMIX uses information in the data group definition, the systems specified in the data group name, and the specified transfer definition name to derive the fully qualified transfer definition name. If MIMIX cannot find the transfer definition, it reverses the order of the system names and checks again, avoiding the need for redundant transfer definitions.
You can also use contextual system support (*ANY) to configure transfer definitions. When you specify *ANY in a transfer definition, MIMIX uses information from the context in which the transfer definition is called to resolve to the correct system. Unlike the conventional configuration case, a specific search order is used if MIMIX is still unable to find an appropriate transfer definition. For more information, see Using contextual (*ANY) transfer definitions.