Configuration requirements for IFS objects - assure_mimix - 10.0

Assure MIMIX Administrator Reference

Product type
Product family
Assure MIMIX™ Software
Product name
Assure MIMIX
Assure MIMIX Administrator Reference
First publish date

For any data group IFS entry you create, consider the following:

  • Determine whether the IFS objects you need to replicate are better suited for replication by system journal (object) or user journal (database) replication processes. See Planning for journaled IFS objects, data areas, and data queues.

  • Create, delete, rename, and move operations should not be performed for the highest level directory being replicated. Instead, the highest level directory being replicated should remain static to ensure move and rename operations for objects below the directory are properly journaled. Objects are journaled on behalf of the parent directory.

  • You must have at least one data group IFS entry which specifies a a Process type of *INCLD. You may need to create additional entries to achieve the desired results. This may include entries which specify a Process type of *EXCLD.

  • When specifying which IFS objects in data group IFS entries, specify only the IFS objects that need to be replicated. The System 1 object (OBJ1) parameter selects all IFS objects within the path specified.

  • Consider whether replication of implicitly defined parent objects described in Replication of implicitly defined IFS parent objects addresses your replication needs.

  • You can specify an object auditing value within the configuration. For details, see Configured object auditing value for data group entries.

Additional requirements for user journal replication - The following additional requirements must be met before IFS objects identified by data group IFS entries can be replicated with user journal processes.

Note: If the data group uses the optional journal-centric configuration for objects of type *IFS or *ALL, data group IFS entries are generally not needed to replicate all IFS objects that are journaled to the user journal of the data group. However, data group IFS entries are needed to identify exceptions to exclude from replication. A special-case data group IFS entry may also be needed to ensure not-journaled IFS objects have journaling started to ensure they can be replicated. Also, data group IFS entries are still required for IFS objects that are better suited for replication using the system journal for performance reasons. When a journal-centric data group is created from the Assure UI portal, MIMIX automatically creates the data group IFS tracking entries it needs for the journaled objects. When a journal-centric data group is created from the native user interface, you must manually create the IFS tracking entries using default options on the LODDGIFSTE command.
  • The data group and data group IFS entries must specify the values indicated in Table 19.

  • IFS tracking entries must exist for the objects identified by properly configured IFS entries. Typically these are created automatically when the data group is started.

  • Journaling must be started on both the source and target systems for the objects identified by IFS tracking entries.

  • Also, if any of the following apply, see Planning for journaled IFS objects, data areas, and data queues for additional details.

  • Converting existing configurations - When converting an existing data group to user journal replication for journaled for IFS objects, you must consider whether user journals should be shared and whether IFS objects should be replicated in a data group that also replicated database files.

  • Serialized transactions - If you need to serialize transactions for database files and IFS objects replicated from a user journal, you may need to adjust the configuration for the replicated files. Also, serialization between IFS objects and database files is not supported in configurations that use multithreaded database apply processing.

  • Apply session load balancing - One database apply session, session A, is used for all IFS objects that are replicated from a user journal. Other replication activity can use this apply session, and may cause it to become overloaded. You may need to adjust the configuration accordingly.

  • User exit programs - If you use user exit programs that process user journal entries, you may need to modify your programs. Apply process user exit programs are not supported in data groups that use multithreaded database apply processing.

    Table 1. Critical configuration parameters for replicating IFS objects from a user journal via data group IFS entries.

    Critical Parameters

    Required Values

    Configuration Notes

    Data Group Definition

    Data group type (TYPE)


    Cooperative journal (COOPJRN) *USRJRN  

    Data Group IFS Entry


    Cooperate with database (COOPDB)


    The default, *NO, results in system journal replication

In a data group that specifies IFS objects for journal-centric configuration, you may need a data group IFS entry that specifies *STRJRN as its Object type (OBYTYPE). When *STRJN is specified, all object types that are specified for journal-centric configuration in the data group can be selected. A data group IFS entry that specifies *STRJRN is not evaluated by replication processes. Instead, it is used by the Directories (#IFSATR) audit and by deploy processing to ensure that journaling is started for not-journaled IFS objects matching the specified criteria and the configured journal-centric object types. When *STRJRN is specified, the process type (PRCTYPE) must be Include (*INCLD) and name-mapping is not allowed.