Integrity Checker configuration requirements

The basic rules for designing an Integrity Checker configuration are as follows:

• One LICON data set must be created for each set of RECON data sets. (A set consists of RECON1, RECON2, and RECON3.)
• Global option modules contain the names of the LICON data sets. Therefore, if your environment requires multiple LICON data sets, you must prepare the same number of global option modules.
• Global option modules must be named using the following naming convention:

  LIU@INST

  The default name for the global option module. If your environment requires only one LICON data set, use this name.

  LIU@imsid

  If your environment requires multiple LICON data sets, use this format. For imsid, use the IMS ID of each IMS subsystem.

  When multiple global option modules exist, Integrity Checker determines the global option module to use from the IMS ID. If no corresponding global option module is found for an IMS ID, Integrity Checker uses the default module LIU@INST. Even if the corresponding global option module is found, if some options are not defined in that module, the options that are defined in LIU@INST are applied. If LIU@INST is not found or some options are not defined in the LIU@INST, the system default values are used.

  Tip: At sign (@) is a code-page-dependent character. If you are working in an environment where you cannot use the at sign (@), name the modules LIUGINST or LIUGimsid.

Use the following examples to design an Integrity Checker configuration for your environment.

• Single IMS subsystem configuration example
• Multiple IMS subsystems configuration example: Data-sharing environment
• Multiple IMS subsystems configuration example: Non-data-sharing environment
• Multiple IMS subsystems configuration example: Multiple data-sharing environments
• Multiple IMS subsystems configuration example: XRF complex

As a rule, the same runtime options must be defined for each LICON data set. To simplify the explanations, these examples are cases where one global option module refers to one LICON data set.

Single IMS subsystem configuration example

The following figure shows the simplest configuration.

Figure 1. Integrity Checker configuration for a single IMS subsystem

Multiple IMS subsystems configuration example: Data-sharing environment

The following figure illustrates a configuration where two IMS subsystems share databases.

In this environment, two IMS subsystems are used and one set of RECON data sets is used, so the Integrity Checker resources that are required in this environment are as follows:

• Number of LICON data sets: 1
• Number of global option modules: 1

Because only one global option module is required, the name of the global option module is LIU@INST.

Figure 2. Integrity Checker configuration in a data-sharing environment

Multiple IMS subsystems configuration example: Non-data-sharing environment

The following figure illustrates a configuration where two IMS subsystems use a different set of databases. In such an environment, a LICON data set must be created for each IMS subsystem. Each LICON data set requires one global option module.

In this environment, two IMS subsystems are used and two sets of RECON data sets are used, so the Integrity Checker resources that are required in this environment are as follows:

• Number of LICON data sets: 2
• Number of global option modules: 2

Because two global option modules are required, the names of the global option modules are LIU@IMSA for IMS subsystem IMSA, and LIU@IMST for IMS subsystem IMST.

Figure 3. Integrity Checker configuration in a non-data-sharing environment

Multiple IMS subsystems configuration example: Multiple data-sharing environments

The following figure illustrates a configuration for multiple data-sharing environments. In each data-sharing environment, two IMS subsystems use the same set of databases. In such environments, a LICON data set must be created for each data-sharing environment.

Generally, when four IMS subsystems exist, four global option modules are required. However, as shown in the figure, if you create a global option module for each LICON data set and define an alias name for each global option module, you can design the Integrity checker configuration with two global option modules.

Figure 4. Integrity Checker configuration in multiple data-sharing environments

Multiple IMS subsystems configuration example: XRF complex

To use Integrity Checker in an XRF complex, the active IMS subsystems and the alternate IMS subsystems must use the same LICON data set. If they use different LICON data sets, the change log of the DMB is not inherited during takeover, and Integrity Checker might not detect the DMB inconsistency or might deny DBRC authorization even though the correct DBDLIB or ACBLIB is used.

If the number of active IMS subsystems is one, the number of required LICON data set is also one. The name of the global option module is LIU@INST.

If multiple active IMS subsystems exist, define a LICON data set for each set of RECON data sets, and create one global option module for each LICON data set.

For example, in an XRF complex shown in the following figure, create a global option module for each active IMS subsystem. Create LIU@IMS1 and LIU@IMS3, and then assign alias name LIU@IMS4 for LIU@IMS3.

Then, to apply the same runtime options to the active IMS subsystems and the alternate IMS subsystems, assign alias to the global option modules so that the alternate IMS subsystems can also use the same global option modules.

Specifically, IMS subsystems IMS1 and IMS2 are in a same XRF complex, so the two subsystems must use the same LICON data set. Therefore, assign alias name LIU@IMS2 for LIU@IMS1. IMS subsystems IMS5 and IMS6 are alternate IMS subsystems for IMS3 and IMS4, so all these subsystems must use the same LICON data set. Therefore, assign alias names LIU@IMS5 and LIU@IMS6 for LIU@IMS3.

Figure 5. Integrity Checker configuration in an XRF complex