Tips for data group parameters - assure_mimix

This topic provides tips for using the more common options for data group definitions. Context-sensitive help is available online for all options on the data group definition commands. Refer to Additional considerations for data groups for more information.

Shipped default values for the Create Data Group Definition (CRTDGDFN) command result in a data group that is controlled by an application group, supports both user journal and system journal replication, uses remote journaling and multithreaded database apply processing within user journal replication processes, and supports cooperative processing for logical and physical files, data areas, and data queues via the user journal.

The Change Data Group Definition (CHGDGDFN) command will not allow changing values of parameters required for multithreading in a data group that is configured for multithreading.

Data group names (DGDFN, DGSHORTNAM) These parameters identify the data group.

The Data group definition (DGDFN) is a three-part name that uniquely identifies a data group. The three-part name must be unique to a MIMIX installation. The first part of the name identifies the data group. The second and third parts of the name (System 1 and System 2) specify system definitions representing the systems between which the files and objects associated with the data group are replicated.

Notes:

In the first part of the name, the first character must be either A - Z, $, #, or @. The remaining characters can be alphanumeric and can contain a $, #, @, a period (.), or an underscore (_).
For Clustering environments only, MIMIX recommends using the value *RCYDMN in System 1 and System 2 fields for Peer CRGs.

One of the system definitions specified must represent a management system. Although you can specify the system definitions in any order, you may find it helpful if you specify them in the order in which replication occurs during normal operations. For many users normal replication occurs from a production system to a backup system, where the backup system is defined as the management system for MIMIX. For example, if you normally replicate data for an application from a production system (MEXICITY) to a backup system (CHICAGO) and the backup system is the management system for the MIMIX cluster, you might name your data group SUPERAPP MEXICITY CHICAGO.

The Short data group name (DGSHORTNAM) parameter indicates an abbreviated name used as a prefix to identify jobs associated with a data group. MIMIX will generate this prefix for you when the default *GEN is used. The short name must be unique to the MIMIX cluster and cannot be changed after the data group is created.

Data resource group entry (DTARSCGRP) This parameter identifies the data resource group entry (resource group) in which you want the data group to participate. The resource group provides the association to an application group, and the application group is used for operations such as starting, stopping, or switching. The default value, *DGDFN, will use the resource group whose name matches the first part (name) of the three-part name of the data group definition.

When creating a data group, if a specified name or the value *DGDFN resolves to a name of a resource group that does not exist and the Appl. group for resource group (RSCGRPAG) parameter specifies the name of an existing application group or its value *DFT resolves to the name of the only configured application group, the resource group will be created in that application group.

If you want to create a data group that is not part of an application group, you must specify *NONE.

Appl. group for resource group (RSCGRPAG) This parameter identifies the application group that controls the resource group in which the data group participates. This parameter cannot be changed with the Change Data Group Definition (CHGDGDFN) command.

When creating a data group, you can specify a name or use the default value *DFT, which determines the application group associated with the resource group identified in the DTARSCGRP parameter as follows:

When the identified resource group exists, *DFT resolves to the name of the application group to which the resource group is configured.
When the identified resource group does not exist and there is only one application group configured, *DFT resolves to the application group name and the resource group is created using the first part of the data group name.
When the identified resource group does not exist and there are multiple application groups, the command will fail.
When *NONE is specified for the resource group, *DFT is ignored and the resulting data group is not associated with a resource group or application group.

Data source (DTASRC) This parameter indicates which of the systems in the data group definition is used as the source of data for replication.

Allow to be switched (ALWSWT) This parameter determines whether the direction in which data is replicated between systems can be switched. If you plan to use the data group for high availability purposes, use the default value *YES. This allows you to use one data group for replicating data in either direction between the two systems. If you do not allow switching directions, you need to have second data group with similar attributes in which the roles of source and target are reversed in order to support high availability.

Data group type (TYPE) The default value *ALL indicates that the data group can be used by both user journal and system journal replication processes. This enables you to use the same data group for all of the replicated data for an application. The value *ALL is required for user journal replication of IFS objects, data areas, and data queues. Default cooperative processing for files (MIMIX Dynamic Apply) is supported by *ALL or the value *DB. For additional information, see Requirements and limitations of default cooperative processing for files

Note: In Clustering environments only, the data group value of *PEER is available. This provides you with support for system values and other system attributes that MIMIX currently does not support.

Transfer definitions (PRITFRDFN, SECTFRDFN) These parameters identify the transfer definitions used to communicate between the systems defined by the data group. The name you specify in these parameters must match the first part of a transfer definition name. By default, MIMIX uses the name PRIMARY for a value of the primary transfer definition (PRITFRDFN) parameter and for the first part of the name of a transfer definition.

If you specify a secondary transfer definition (SECTFRDFN), it is used if the communications path specified in the primary transfer definition is not available. Once MIMIX starts using the secondary transfer definition, it continues to use it even after the primary communication path becomes available again.

Reader wait time (seconds) (RDRWAIT) You can specify the maximum number of seconds that the that the object send process and either the database reader or database send process wait when there are no entries available to process. Jobs go into a delay state when there are no entries to process. The j obs wait for the time you specify even when new entries arrive in the journal. A value of 0 uses more system resources. Valid values are 0 through 600. When 0 is specified the database reader process will use a value of 1.

Common database parameters (JRNTGT, JRNDFN1, JRNDFN2, ASPGRP1, ASPGRP2, RJLNK, COOPJRN, NBRDBAPY, DBJRNPRC) These parameters apply to data groups that can include database files or tracking entries. Data group types of *ALL or *DB include database files. Data group types of *ALL may also include tracking entries.

Journal on target (JRNTGT) The default value *YES enables journaling on the target system, which allows you to switch the direction of a data group more quickly. The value *YES is required for multithreaded database apply processing, to allow target journal inspection. The value *YES cannot be changed in data groups that use multithreading.

Replication of files with some types of referential constraint actions may require a value of *YES. For more information, see Considerations for LF and PF files .

If you specify *NO, you must ensure that, in the event of a switch to the direction of replication, you manually start journaling on the target system before allowing users to access the files. Otherwise, activity against those files may not be properly recorded for replication.

System 1 journal definition (JRNDFN1) and System 2 journal definition (JRNDFN2) parameters identify the user journal definitions associated with the systems defined as System 1 and System 2, respectively, of the data group. The value *DGDFN indicates that the journal definition has the same name as the data group definition.

The DTASRC, ALWSWT, JRNTGT, JRNDFN1, and JRNDFN2 parameters interact to automatically create as much of the journaling environment as possible. The DTASRC parameter determines whether system 1 or system 2 is the source system for the data group. When you create the data group definition, if the journal definition for the source system does not exist, a journal definition is created. If you specify to journal on the target system and the journal definition for the target system does not exist, that journal definition is also created. The names of journal definitions created in this way are taken from the values of the JRNDFN1 and JRNDFN2 parameters according to which system is considered the source system at the time they are created. You may need to build the journaling environment for these journal definitions.

System 1 ASP group (ASPGRP1) and System 2 ASP group (ASPGRP2) parameters identify the name of the primary auxiliary storage pool (ASP) device within an ASP group on each system. The value *NONE allows replication from libraries in the system ASP and basic user ASPs 2-32. Specify a value when you want to replicate IFS objects from a user journal or when you want to replicate objects from ASPs 33 or higher. For more information see Benefits of independent ASPs.

Use journal-centric config. (JRNCENTRIC) This parameter identifies which object types that can be journaled to a user journal are considered part of the data group configuration. By default, no object types are specified. When an object type is specified, objects of that type that are journaled to the user journal identified in the data group will be replicated without needing to identify the objects in data group object entries or IFS entries. To use this parameter, the data group type (TYPE) must be *ALL or *DB.

Auto-configure for journals (AUTOCFGJRN) When the data group type (TYPE) is *ALL or *OBJ, a value of *YES for this parameter allows MIMIX to automatically create and delete additional configuration for journals (*JRN objects) that are created or deleted within a library replicated by this data group. The automatically created data group associated with the *JRN object is configured for journal-centric replication and started, or is automatically ended and deleted, according to the journal entries detected by this data group. The default is *NO.

Use remote journal link (RJLNK) This parameter identifies how journal entries are moved to the target system. The default value, *YES, uses remote journaling to transfer data to the target system. This value results in the automatic creation of the journal definitions (CRTJRNDFN command) and the RJ link (ADDRJLNK command), if needed. The RJ link defines the source and target journal definitions and the connection between them. When ADDRJLNK is run during the creation of a data group, the data group transfer definition names are used for the ADDRJLNK transfer definition parameters.

Default cooperative processing for files requires the value *YES. When the value *NO is specified, MIMIX source-send processes are used.

Cooperative journal (COOPJRN) This parameter determines whether cooperatively processed operations for journaled objects are performed primarily by user (database) journal replication processes or system (audit) journal replication processes. The default value, *USRJRN, requires that user journal replication processes use remote journaling (RJLNK(*YES)). The value *USRJRN performs cooperative processing through user journal replication processes for journaled logical files and physical files (default cooperative processing) and journaled data areas, data queues, and IFS objects identified by data group entries that specify *YES for Cooperate with database (COOPDB). The value *SYSJRN performs legacy cooperative processing through system journal replication processes for only journaled PF-DTA and PF38-DTA files identified by data group entries that specify *YES for Cooperate with database (COOPDB).

Number of DB apply sessions (NBRDBAPY) In the native user interface, this parameter determines whether file data replicated from the user journal is applied on the target system using a multithreaded job or one or more single-threaded jobs.

With the default value *THREADED, the installed product determines the default value for multithreaded database apply processing and the value *THREADED resolves accordingly to either *THDLOW, *THDMED, or *THDHIGH.

Numeric values of 1 through 6 identify the number of single-threaded apply sessions to use. When configuring a data group that is not part of an application group, you must specify a number. When more than one apply session is specified, the apply session jobs run in parallel.

Regardless of the value used for files, all journaled IFS objects, data areas, and data queues are processed by the same single-threaded apply session (apply session A).

After a data group is created, changing between a multithreaded value and a numeric value requires a conversion using the Convert RG for Multithreading (CVTRG) command. For more information, see Multithreaded or single-threaded processing.

DB journal entry processing (DBJRNPRC) This parameter allows you to specify several criteria that MIMIX will use to filter user journal entries before they are sent to the database apply (DBAPY) process. Entries that are filtered out are not replicated. In data groups that use remote journaling, the filtering is performed by the database reader (DBRDR) process. In data groups configured to use MIMIX source-send processes, filtering is performed by the database send (DBSND) process.

Each element of the parameter identifies a criteria that can be set to either *SEND or *IGNORE. The value *SEND causes the journal entries to be processed and sent to the database apply process. The value *IGNORE prevents the entries from being sent to the database apply process. Certain database techniques, such as keyed replication, may require that an element be set to a specific value.

For data groups which use the DBSND process, the value *IGNORE can minimize the amount of data sent over a communications path.

The following available elements describe how journal entries are handled by the database reader (DBRDR) or the database send (DBSND) processes.

Before images This criteria determines whether before-image journal entries are filtered out and are not sent to the database apply process. If *IGNORE is specified and *IMMED is specified for the Commit mode element of Database apply processing (DBAPYPRC), journal entry before images are processed and sent to the database apply process. If you use keyed replication, the before-images are often required and you should specify *SEND. The value *SEND is also required for the IBM RMVJRNCHG (Remove Journal Change) command. See Additional considerations for data groups for more information.
For files not in data group This criteria determines whether journal entries for files that are not configured for replication by the data group are filtered out and are not sent to the database apply process.
Generated by MIMIX activity This criteria determines whether journal entries resulting from the MIMIX database apply process are filtered out and are not sent to the database apply process. Filtering out these entries may be necessary in environments which perform bi-directional replication.
Not used by MIMIX This criteria determines whether journal entries not used by MIMIX are filtered out and are not sent to the database apply process.

System setting replication (REPSYSSET) This parameter determines how to process system settings and system values identified for replication by selection rules (data group entries). When there are configured selection rules that identify system settings or system values, replication is performed by capturing values from the source system at a regular interval and applying the captured values according to the specified apply method. When there are configured selection rules, capturing occurs when the data group is started and at the specified Capture interval. The interval defaults to *DAILY, but can also be specified as a number of hours in the range from 1 through 999. The Apply method specified determines how the captured system settings and system values will be handled by the object apply process on the target system. The apply method defaults to *STAGED, which keeps the captured information in a staging library on the target system until a switch is performed. During a switch, the last staged value for each captured system setting or system value is applied to the target system. You can also specify *IMMED to have object processing immediately apply the captured value.

Additional parameters: Use F10 (Additional parameters) to access the following parameters. These parameters are considered advanced configuration topics.

Remote journaling threshold (RJLNKTHLD) This parameter specifies the backlog threshold criteria for the remote journal function. When the backlog reaches any of the specified criterion, the threshold exceeded condition is indicated in the status of the RJ link. The threshold can be specified as a time difference, a number of journal entries, or both. When a time difference is specified, the value is amount of time, in minutes, between the timestamp of the last source journal entry and the timestamp of the last remote journal entry. When a number of journal entries is specified, the value is the number of journal entries that have not been sent from the local journal to the remote journal. If *NONE is specified for a criterion, that criterion is not considered when determining whether the backlog has reached the threshold.

Synchronization check interval (SYNCCHKITV) This parameter, which is only valid for database processing, allows you to specify how many before-image entries to process between synchronization checks. For MIMIX to use this feature, the journal image file entry option (FEOPT parameter) must allow before-image journaling (*BOTH). When you specify a value for the interval, a synchronization check entry is sent to the apply process on the target system. The apply process compares the before-image to the image in the file (the entire record, byte for byte). If there is a synchronization problem, MIMIX puts the data group file entry on hold and stops applying journal entries. The synchronization check transactions still occur even if you specify to ignore before-images in the DB journal entry processing (DBJRNPRC) parameter.

Time stamp interval (TSPITV) This parameter, which is only valid for database processing, allows you to specify the number of entries to process before MIMIX creates a time stamp entry. Time stamps are used to evaluate performance.

Note: The TSPITV parameter does not apply for remote journaling (RJ) data groups.

Verify interval (VFYITV) This parameter allows you to specify the number of journal transactions (entries) to process before MIMIX performs additional processing. When the value specified is reached, MIMIX verifies that the communications path between the source system and the target system is still active and that the send and receive processes are successfully processing transactions. A higher value uses less system resources. A lower value provides more timely reaction to error conditions. Larger, high-volume systems should have higher values. This value also affects how often the status is updated with the "Last read" entries. A lower value results in more accurate status information.

Data area polling interval (DTAARAITV) This parameter specifies the number of seconds that the data area poller waits between checks for changes to data areas. The poller process is only used when configured data group data area entries exist. The preferred methods of replicating data areas require that data group object entries be used to identify data areas. When object entries identify data areas, the value specified in them for cooperative processing (COOPDB) determines whether the data areas are processed through the user journal with advanced journaling, or through the system journal.

Journal at creation (JRNATCRT) This parameter specifies whether to start journaling on new objects of type *FILE, *DTAARA, and *DTAQ when they are created. The decision to start journaling for a new object is based on whether the data group is configured to cooperatively process any object of that type in a library. All new objects of the same type are journaled, including those not replicated by the data group.

If multiple data groups include the same library in their configurations, only allow one data group to use journal at object creation (*YES or *DFT). The default for this parameter is *DFT which allows MIMIX to determine the objects to journal at creation.

Note: There are some IBM library restrictions identified within the requirements for implicit starting of journaling described in What objects need to be journaled. For additional information, see Processing of newly created files and objects.

Parameters for automatic retry processing: MIMIX may use delay retry cycles when performing system journal replication to automatically retry processing an object that failed due to a locking condition or an in-use condition. It is normal for some pending activity entries to undergo delay retry processing—for example, when a conflict occurs between replicated objects in MIMIX and another job on the system. The following parameters define the scope of two retry cycles:

Number of times to retry (RTYNBR) This parameter specifies the number of attempts to make during a delay retry cycle.

First retry delay interval (RTYDLYITV1) This parameter specifies the amount of time, in seconds, to wait before retrying a process in the first (short) delay retry cycle.

Second retry delay interval (RTYDLYITV2) specifies the amount of time, in seconds, to wait before retrying a process in the second (long) delay retry cycle. This is only used after all the retries for the RTYDLYITV1 parameter have been attempted.

After the initial failed save attempt, MIMIX delays for the number of seconds specified for the First retry delay interval (RTYDLYITV1) before retrying the save operation. This is repeated for the specified number of times (RTYNBR).

If the object cannot be saved after all attempts in the first cycle, MIMIX enters the second retry cycle. In the second retry cycle, MIMIX uses the number of seconds specified in the Second retry delay interval (RTYDLYITV2) parameter and repeats the save attempt for the specified number of times (RTYNBR).

If the object identified by the entry is in use (*INUSE) after the first and second retry cycle attempts have been exhausted, a third retry cycle is attempted if the Automatic object recovery policy is enabled. The values in effect for the Number of third delay/retries policy and the Third retry interval (min.) policy determine the scope of the third retry cycle. After all attempts have been performed, if the object still cannot be processed because of contention with other jobs, the status of the entry will be changed to *FAILED.

File and tracking entry options (FEOPT) This parameter specifies default options that determine how MIMIX handles file entries and tracking entries for the data group. All database file entries, object tracking entries, and IFS tracking entries defined to the data group use these options unless they are explicitly overridden by values specified in data group file or object entries. File entry options in data group object entries enable you to set values for files and tracking entries that are cooperatively processed.

The options are as follows:

Journal image This option allows you to control the kinds of record images that are written to the journal when data updates are made to database file records, IFS stream files, data areas or data queues. The default value *AFTER causes only after-images to be written to the journal. The value *BOTH causes both before-images and after-images to be written to the journal. Some database techniques, such as keyed replication, may require the use of both before-image and after-images. *BOTH is also required for the IBM RMVJRNCHG (Remove Journal Change) command. See Additional considerations for data groups for more information.
Omit open/close entries This option allows you to specify whether open and close entries are omitted from the journal. The default value *YES indicates that open and close operations on file members or IFS tracking entries defined to the data group do not create open and close journal entries and are therefore omitted from the journal. If you specify *NO, journal entries are created for open and close operations and are placed in the journal.
Replication type This option allows you to specify the type of replication to use for database files defined to the data group. The default value *POSITION indicates that each file is replicated based on the position of the record within the file. Positional replication uses the values of the relative record number (RRN) found in the journal entry header to locate a database record that is being updated or deleted. The value *POSITION is required for multithreaded database apply processing.

The value *KEYED indicates that each file is replicated based on the value of the primary key defined to the database file. The value of the key is used to locate a database record that is being deleted or updated. MIMIX strongly recommends that any file configured for keyed replication also be enabled for both before-image and after-image journaling. Files defined using keyed replication must have at least one unique access path defined. For additional information, see Keyed replication.

Lock member during apply This option specifies the type of lock used by the database apply process for file members, which in turn determines whether MIMIX allows or restricts access to the data on the target node. This option does not apply to cooperatively processed data areas, data queues, or IFS objects. The default value, *DFT, determines the type of lock used based on the value of the Number of DB apply sessions (NBRDBAPY) parameter. When configured for multithreaded database apply, *DFT resolves to *NONE and the apply process does not hold a lock on file members. When a number is specified for NBRDBAPY, *DFT resolves to *EXCLRD and the apply session holds an *EXCLRD lock on file members. For more details, see Locking members during apply.
Apply session This option determines which apply session to use when processing files. The value *ANY is required when the data group is configured for multithreaded database apply processing. When single-threaded database apply processing is configured, you can specify a session or use the value *ANY to allow MIMIX to use apply session for files and attempt to balance the load between the configured number of apply sessions.

Notes:

In a data group that uses single-threading, any changes take effect the next time the data group is started with *YES specified for the clear pending parameter.
IFS and object tracking entries use only apply session A.
Collision resolution This option determines how data collisions are resolved. The default value *HLDERR indicates that a file is put on hold if a collision is detected. The value *AUTOSYNC indicates that MIMIX will attempt to automatically synchronize the source and target file. You can also specify the name of the collision resolution class (CRCLS) to use. A collision resolution class allows you to specify how to handle a variety of collision types, including calling exit programs to handle them. See the online help for the Create Collision Resolution Class (CRTCRCLS) command for more information.

Note: The *AUTOSYNC value should not be used if the Automatic database recovery policy is enabled.

Disable triggers during apply This option determines if MIMIX should disable any triggers on physical files during the database apply process. The default value *YES is required for multithreaded database apply processing and indicates that triggers should be disabled by the database apply process. For data groups that use multithreading, triggers are disabled at the start of apply processing and are enabled by switch processing. For data groups that use single-threading, triggers are disabled while the file is opened by the database apply job.
Process trigger entries This option determines if MIMIX should process any journal entries that are generated by triggers. The default value *YES is required for multithreaded database apply processing and indicates that journal entries generated by triggers are processed by MIMIX. This option is not valid for tracking entries.

Database reader/send threshold (DBRDRTHLD) This parameter specifies the backlog threshold criteria for the database reader (DBRDR) process. When the backlog reaches any of the specified criterion, the threshold exceeded condition is indicated in the status of the DBRDR process. If the data group is configured for MIMIX source-send processing instead of remote journaling, this threshold applies to the database send (DBSND) process. The threshold can be specified as time, journal entries, or both. When time is specified, the value is the amount of time, in minutes, between the timestamp of the last journal entry read by the process and the timestamp of the last journal entry in the journal. When a journal entry quantity is specified, the value is the number of journal entries that have not been read from the journal. If *NONE is specified for a criterion, that criterion is not considered when determining whether the backlog has reached the threshold.

Database apply processing (DBAPYPRC) This parameter allows you to specify defaults for operations associated with the database apply processes. Each configured apply session uses the values specified in this parameter. The areas for which you can specify defaults are as follows:

Force data interval You can specify the number of records that are processed before MIMIX forces the apply process information to disk from cache memory. A lower value provides easier recovery for major system failures. A higher value provides for more efficient processing.
Maximum open members You can specify the maximum number of members (with journal transactions to be applied) that the apply process can have open at one time. Once the limit specified is reached, the apply process selectively closes one file before opening a new file. A lower value reduces disk usage by the apply process. A higher value provides more efficient processing because MIMIX does not open and close files as often.
Threshold warning (1000s) You can specify the number of entries, in thousands, that the apply process can have waiting to be applied before a warning message is sent. When the threshold is reached, the threshold exceeded condition is indicated in the status of the database apply process and a message is sent to the primary and secondary message queues.
Keep journal log user spaces You can specify the maximum number of journal log spaces to retain after the journal entries are applied. Log user spaces are automatically deleted by MIMIX. Only the number of user spaces you specify are kept.
Commit mode This option determines how to process journal entries that are under commitment control. The value *IMMED is the shipped default and is required for multithreaded database apply processing. For more information, see Processing of transactions under commitment control,
Target constraint management This option determines whether MIMIX will enable and disable foreign key constraints on target system files. Multithreaded database apply processing requires the value *YES, which allows MIMIX to manage these constraints. Single-threaded database apply processing requires the value *NO. The default value, *DFT, resolves accordingly. For more information, see Target constraint management.

Object processing (OBJPRC) This parameter allows you to specify defaults for object replication. The areas for which you can specify defaults are as follows:

Object default owner You can specify the name of the default owner for objects whose owning user profile does not exist on the target system. The product default uses QDFTOWN for the owner user profile.
DLO transmission method You can specify the method used to transmit the DLO content and attributes to the target system. The value *OPTIMIZED uses IBM i APIs and does not support doclists. The *SAVRST uses IBM i save and restore commands.
IFS transmission method You can specify the method used to transmit IFS object content and attributes to the target system. The default value *OPTIMIZED uses IBM i APIs for better performance. The value *SAVRST uses IBM i save and restore commands.

Note: It is recommended that you use the *OPTIMIZED method of IFS transmission only in environments in which the high volume of IFS activity results in persistent replication backlogs. The IBM i save and restore method guarantees that all attributes of an IFS object are replicated.

User profile status You can specify the user profile Status value for user profiles when they are replicated. This allows you to replicate user profiles with the same status as the source system in either an enabled or disabled status for normal operations. If operations are switched to the backup system, user profiles can then be enabled or disabled as needed as part of the switching process.
Keep deleted spooled files You can specify whether to retain replicated spooled files on the target system after they have been deleted from the source system. If you specify *NO, the replicated spooled files are deleted from the target system when they are deleted from the source system. If you specify *YES, the replicated spooled files are retained on the target system after they are deleted from the source system. MIMIX does not perform any clean-up of spooled files on the target system that are within the name space identified by data group object entries. You must delete them manually when they are no longer needed. Also, when *YES is specified and a data group is specified on the CMPOBJA command or when the Libraries (#OBJATR) audit runs, MIMIX does not consider spooled files that exist only on the target system to be differences.
Keep DLO system object name You can specify whether the DLO on the target system is created with the same system object name as the DLO on the source system. The system object name is only preserved if the DLO is not being redirected during the replication process. If the DLO from the source system is being directed to a different name or folder on the target system, then the system object name will not be preserved.
Object retrieval delay You can specify the amount of time, in seconds, to wait after an object is created or updated before MIMIX packages the object. This delay provides time for your applications to complete their access of the object before MIMIX begins packaging the object.
Object send prefix The prefix specified determines whether the data group uses a dedicated job for the object send process or a job shared by multiple data groups. All data groups that specify the value *SHARED will share the same job on the source system. If you specify a three-character prefix, only other data groups that specify the same prefix will share the object send job with this prefix. To change this value, end the data group, change the value specified, and restart the data group.

Note: A shared object send job can process journal entries for objects within SYSBAS or within only one independent ASP. In environments with independent ASPs, each system within the set of data groups sharing the same object send job must be identified consistently within those data groups in the appropriate ASP group parameter (ASPGRP1 or ASPGRP2). This is required regardless of whether a system is currently the source or target for the data groups.

Repl. user profile used date - You can determine whether to replicate the last used date attribute of replicated user profiles. When *YES is specified, the last used date of a source node *USRPRF object that is identified for replication will be checked periodically. When MIMIX detects last used dates on the source node with the same date or the previous day's date, it will update the last used date on the target node’s user profile with the current target node date. The ensures that the date on the target node is either the same as or more recent than the last used date on the source node.

Note: Replicating the last used date is not recommended if you use the last used date to determine when a user profile has actually been used on the target node.

Delete pend.dist. of *USRPRF - You can determine whether MIMIX will automatically delete any pending distributions associated with user profiles (*USRPRF) that are being deleted on the target system by replication processes. The default value is *NO and when this scenario exists, the activity entry for replicating the transaction to delete the user profile will fail. The value *YES allows MIMIX to automatically delete any pending distributions associated with the user profile being deleted from the target system and avoid the need for manual intervention.

Object send threshold (OBJSNDTHLD) This parameter specifies the backlog threshold criteria for the object send (OBJSND) process. When the backlog reaches any of the specified criterion, the threshold exceeded condition is indicated in the status of the OBJSND process. The threshold can be specified as time, journal entries, or both. When time is specified, the value is the amount of time, in minutes, between the timestamp of the last journal entry read by the process and the timestamp of the last journal entry in the journal. When a journal entry quantity is specified, the value is the number of journal entries that have not been read from the journal. If *NONE is specified for a criterion, that criterion is not considered when determining whether the backlog has reached the threshold.

Object retrieve processing (OBJRTVPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle object retrieve requests and the threshold at which the number of pending requests queued for processing causes additional temporary jobs to be started. The specified minimum number of jobs will be started when the data group is started. During periods of peak activity, if the number of pending requests exceeds the backlog jobs threshold, additional jobs, up to the maximum, are started to handle the extra work. When the backlog is handled and activity returns to normal, the extra jobs will automatically end. If the backlog reaches the warning message threshold, the threshold exceeded condition is indicated in the status of the object retrieve (OBJRTV) process. If *NONE is specified for the warning message threshold, the process status will not indicate that a backlog exists.

Container send processing (CNRSNDPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle container send requests and the threshold at which the number of pending requests queued for processing causes additional temporary jobs to be started. The specified minimum number of jobs will be started when the data group is started. During periods of peak activity, if the number of pending requests exceeds the backlog jobs threshold, additional jobs, up to the maximum, are started to handle the extra work. When the backlog is handled and activity returns to normal, the extra jobs will automatically end. If the backlog reaches the warning message threshold, the threshold exceeded condition is indicated in the status of the container send (CNRSND) process. If *NONE is specified for the warning message threshold, the process status will not indicate that a backlog exists.

Object apply processing (OBJAPYPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle object apply requests and the threshold at which the number of pending requests queued for processing triggers additional temporary jobs to be started. The specified minimum number of jobs will be started when the data group is started. During periods of peak activity, if the number of pending requests exceeds the backlog threshold, additional jobs, up to the maximum, are started to handle the extra work. When the backlog is handled and activity returns to normal, the extra jobs will automatically terminate. You can also specify a threshold for warning message that indicates the number of pending requests waiting in the queue for processing before a warning message is sent. When the threshold is reached, the threshold exceeded condition is indicated in the status of the object apply process and a message is sent to the primary and secondary message queues.

User profile for submit job (SBMUSR) This parameter allows you to specify the name of the user profile used to submit jobs. The default value *JOBD indicates that the user profile named in the specified job description is used for the job being submitted. The value *CURRENT indicates that the same user profile used by the job that is currently running is used for the submitted job.

Send job description (SNDJOBD) This parameter allows you to specify the name and library of the job description used to submit send jobs. The product default uses MIMIXSND in library MIMIXQGPL for the send job description.

Apply job description (APYJOBD) This parameter allows you to specify the name and library of the job description used to submit apply requests. The product default uses MIMIXAPY in library MIMIXQGPL for the apply job description.

Reorganize job description (RGZJOBD) This parameter, used by database processing, allows you to specify the name and library of the job description used to submit reorganize jobs. The product default uses MIMIXRGZ in library MIMIXQGPL for the reorganize job description.

Synchronize job description (SYNCJOBD) This parameter, used by database processing, allows you to the name and library of the job description used to submit synchronize jobs. The product default uses MIMIXSYNC in library MIMIXQGPL for synchronization job description. This is valid for any synchronize command that does not have JOBD parameter on the display.

Recovery window (RCYWIN) Configuring a recovery window¹or a data group specifies the minimum amount of time, in minutes, that a recovery window is available and identifies the replication processes that permit a recovery window. A recovery window introduces a delay in the specified processes to create a minimum time during which you can set a recovery point. Once a recovery point is set, you can react to anticipated problems and take action to prevent a corrupted object from reaching the target system. When the processes reach the recovery point, they are suspended so that any corruption in the transactions after that point will not automatically be processed.

By its nature, a recovery window can affect the data group's recovery time objective (RTO). Consider the effect of the duration you specify on the data group's ability to meet your required RTO. You should also disable auditing for any data group that has a configured recovery window. For more information, see “Preventing audits from running” in the Assure MIMIX Operations book.

Recovery windows and recovery points are supported with the MIMIX CDP™ feature, which requires an additional access code.

Tips for data group parameters - assure_mimix - 10.0

Assure MIMIX Administrator Reference