Newly created objects in a journal-centric environment - 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
2024
First publish date
1999
Last updated
2024-10-22
Published on
2024-10-22T10:04:43.803975

In a data group that uses journal-centric configuration for object types of *FILE, *DTAARA, *DTAQ, *LIB, or *IFS, new objects created on the source system that are journaled to the user journal of the data group are eligible for replication. The following events occur for newly journaled objects, regardless of whether they are newly created or just newly journaled:

  • User journal replication detects the journal entry for the start of journaling and adds the object to internal tracking within MIMIX so that it can be replicated. MIMIX also creates the needed data group file entry, object tracking entry, or IFS tracking entry.

  • If the object does not exist on the target system, user journal replication processes create the object on the target system. Replication proceeds normally after the object has been created.

  • All subsequent object changes including moves or renames, file member operations (adds, changes, and removes), file member data updates, object changes, authority changes, and object deletes are replicated through the user journal.

  • In configurations that use single-threaded database apply processing and default cooperative processing for files, MIMIX attempts to place files that are related due to referential constraints into the same apply session. This eliminates the possibility of constraint violations that would otherwise occur if apply sessions processed the files independently. However, there are some situations where constraints are added dynamically between two files already assigned to different apply sessions. In this case, the constraint may need to be disabled to avoid the constraint violations. In the case of cascading constraints, where a modification to one file cascades operations to related files, MIMIX will always attempt to apply the cascading entries, whether the constraint is enabled or disabled, to ensure that the modification is done. In data groups configured to allow target constraint management, MIMIX initially attempts to place newly created files with referential constraints in the same apply session as the referenced file. The next clear pend start of the data group may reassign files that are constrained together to different apply sessions. For more information, see Target constraint management.