Performing target journal inspection - assure_mimix - 10.0

Assure MIMIX Administrator Reference

Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX Administrator Reference
Copyright
2023
First publish date
1999
ft:lastEdition
2024-05-07
ft:lastPublication
2024-05-07T13:36:02.962500

The data integrity of replicated objects can be affected if they are changed on the target system by programs or users other than MIMIX. For new installations, shipped default values for journal definitions and data group definitions allow MIMIX to automatically perform target journal inspection to check for such actions. On any given target system, both the system journal (QAUDJRN) and user journals are inspected. Target journal inspection is required when data groups are configured for multithreaded database apply processing.

Any detected creates, changes, or deletes of target system objects within the replication name space by anyone other than MIMIX are logged in an internal database. The MIMIX replication manager periodically checks the internal database for objects that need correction. For changes detected by target journal inspection, the replication manager initiates recovery actions to correct detected target system changes and prioritizes the object for the next priority-based audit.

Target journal inspection also sends notifications to inform you of the users or programs responsible for the detected changes on the target system.

Notes

  • Target journal inspection does not occur for the journals identified in the MXCFGJRN journal definition and journal definitions that identify the remote journal used in RJ configurations (whose names typically end with @R).

  • In environments that perform bi-directional replication, target journal inspection does not report a target object as changed by user when that object is also replicated by a different data group using that system as its source.

  • MIMIX automatically creates journal definitions for the target system’s system journal (QAUDJRN) and user journals. In environments where only user journal replication is configured, the QAUDJRN journal definition on the target system is still needed so that target journal inspection can check for all transactions.

  • Target journal inspection will not identify or automatically correct any operations for implicitly defined parent objects on the target system.

Use by virtual switch procedures: Target journal inspection is also used while running a virtual switch procedure. During the testing phase of a virtual switch, target journal inspection tracks changes to objects within the replication name space on the designated test system. Those changes are then removed during the recovery phase of a virtual switch.

Inspection process details: Target journal inspection consists of a set of processes that run on a system only when that system is currently the target system for replication. Each process reads a journal to check for users or programs other than MIMIX that have modified replicated objects. The number of inspection process on a system depends on how many user journals on the target system are defined to the data groups replicating to that system. There is one inspection process for the system journal (QAUDJRN) regardless of how many data groups use the system as a target system. Each user journal on the target system also has an inspection process, which may be used by one or more data groups. The name of each inspection process job is the name of the journal definition.

The example below shows the relationships between data groups, journals, and configuration in a simple switchable replication environment.

Notifications: Each target journal inspection process sends one notification per user that changed objects on the target node since that process started. Only the first object changed by the user is identified in the notification. However, additional objects changed by the same user are marked in the replicated objects database with the unique ID of the already sent notification.

With default configuration values, inspection processes on a system typically restart once every 24 hours. If the configuration does not allow restarting system-level jobs, the inspection process remains active but resets its internal notification-per-user tracking shortly after midnight based on the system clock.

Target journal inspection does not send notifications during a virtual switch.

Viewing a list of detected objects: The following capabilities are only available when you use the MIMIX portal application in the Assure UI portal:

  • From the Objects Changed on Target window, you can view a list of all the objects changed by a particular user, program, or job, or a list of objects that have the same notification ID. The list also identifies any resulting automatic recovery action. Manual intervention or correction may be required if an automatic recovery action could not be performed or failed to correct the problem. The window is initially filtered according to the location from which it was accessed.

  • From the Virtual Switch Activity window, you can view a list of objects affected by the most recent virtual switch of an application group and any automatic recovery action for each object.

  • From the Replicated Objects window, you can view a list of objects that have been replicated by the instance, filtered to the application group or data group from which it was accessed.

Starting journal location: Target journal inspection is started and ended when MIMIX starts or ends. Starting data groups will start inspection jobs on the target system if necessary. You can also manually start or end the inspection processes for a system with commands that act on system-level processes (STRMMXMGR, ENDMMXMGR).

The first time that a target journal inspection process is started, it begins with the last sequence number in the currently attached journal receiver on the target system. (The starting point is not associated with the location in the source journal from which replication is started.)

When a target journal inspection process ends, MIMIX retains information about the last sequence number it processed. On subsequent start requests, the target journal inspection process starts at the next journal sequence number following the last sequence number it processed if the journal receiver is still available. If the receiver is no longer available, processing starts with the last sequence number in the currently attached journal receiver. Any time a target journal inspection process starts, message LVI3901 is issued to the MIMIX message log and to the job log, identifying where the journal inspection process started.

When starting target journal inspection after enabling target journal inspection in a journal definition where it was previously disabled, processing begins with the last sequence number in the currently attached journal receiver on the target system.

Status: For each data group, status of target journal inspection is included with other target system manager processes. At the system level, the status reported is the combined status of all target inspection processes currently running on that system. More status-related information is available in the Assure MIMIX Operations book.

Example: An application group controls two switchable data groups. Both data groups perform system and user journal replication, but only one data group is configured for remote journaling. Figure 14 shows the journals associated with this configuration.

Figure 14.Example: journals present in a switchable environment.

Note that the remote journals used by the remote journaling environment of data group ABC will never be used for target journal inspection.  

To enable target journal inspection for this example environment requires:

  • Data group definitions ABC and DEF must specify *YES for Journal on target (JRNTGT). Also, because these data groups perform user journal replication, the values of System 1 journal definition (JRNDFN1) and System 2 journal definition (JRNDFN2) must identify the journal definitions for the systems identified as system 1 or system 2, respectively, in the data group name (DGDFN). Often the journal definition names use the same name as the data group. However, it is possible that a data group may be using a journal definition with a different name or sharing a journal definition with a different data group.

  • All of the journal definitions in Table 45 must specify *ACTIVE for the Target journal state (TGTSTATE) and *YES for Target journal inspection (TGTJRNINSP).

Table 1. Example: inspected target journals and their associated journal definitions

Target System of Replication

Inspected Target Journal in Library

Associated Journal Definition

OSCAR

ABC #MXJRN

ABC OSCAR

DEF #MXJRN

DEF OSCAR

QAUDJRN QYS

QAUDJRN OSCAR

HENRY

ABC #MXJRN

ABC HENRY

DEF #MXJRN

DEF HENRY

QAUDJRN QYS

QAUDJRN HENRY