Journal operations - journaled replication - 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

In a data group that does not use journal-centric configuration, if a data group entry identifies a not-journaled file or object that is eligible for user journal replication or cooperative processing, the data group reports a journaling error for the file entry or tracking entry. Audits will automatically detect and audit recovery actions, if enabled, attempt to correct the journaling error if you have not done so manually.

In a data group that specifies object types for journal-centric configuration, only journaled objects of the specified object types are eligible for replication. For the specified object types, objects that are journaled to the user journal of the data group when the data group is started are added to internal name space of objects eligible for replication. After the data group is started, if MIMIX detects a journal entry in the user journal for the start of journaling on an object of a configured object type, MIMIX adds the object to its internal list of objects eligible for replication and begins processing any journal entries for the object. The journaled object is eligible for replication until one of the following occurs:

  • Journaling is ended for the object. When this occurs, the object is removed from the list of objects eligible for replication. Replication can no longer occur. This is not considered an error condition.

  • The object is deleted from the system. The delete transaction is processed and the object is removed from the list of objects eligible for replication.

  • The object becomes journaled to a different journal. Because journaling for the object ended for the journal, the object is no longer eligible for replication by the current data group. The start of journaling to a different journal may or may not result in replication, as follows:

  • If the object has journaling started to a user journal that is not identified by a data group, the object cannot be replicated.

  • If the object has journaling started to the user journal of a different data group that is not journal-centric, the object is only replicated if it can be selected by an existing data group object entry or IFS entry.

  • If the object has journaling started to the user journal of a different journal-centric data group that specifies the same object type, and if that data group detects the journal entry for the start of journaling, that data group adds the object to its internal list of objects eligible for replication and begins processing any journal entries for the object. If the data group where journaling was ended is behind in processing journal entires compared to the new journal-centric data group, the file entry or tracking entry created for the object in the new data group will have a status of *HLDRTY until the original data group processes the end of journaling request.

To ensure that all journal-capable objects within a given library or directory are actually journaled to the journal of a journal-centric data group specifying the journal-capable object types, create a data group object entry or IFS entry that specifies *STRJRN for its object type. Journaling is started for all the objects matching the data group entry when the entry is processed by audits during audit recoveries or by the Deploy Data Grp. Configuration (DPYDGCFG) command. The data group entry is not used to determine replication eligibility. The start of journaling to a journal-centric data group adds the object to the internal list of objects eligible for replication and begins processing any journal entries for the object.