Policy descriptions - assure_mimix - 10.0

For a complete description of all policy values, see online help for the Set MIMIX Policies (SETMMXPCY) command. The Data group definition and Audit rule parameters on the command are not technically policies, but they must have values specified in order to set a value for any policy.

Data group definition-

Select the scope of the policies to be set. When the value *INST is specified, the policies being set by the command apply to all systems and data groups in the installation, with the exception of any policy for which a data group-level override exists. When a three-part qualified name of a data group is specified, the policies being set by the command apply to only that data group and override the installation-level policy values.

Audit rule- The audit rule must specify a value of *NONE when setting a value for a policy.

Automatic object recovery

Determines whether to enable functions that automatically attempt to correct common object replication errors that may occur during replication from the system journal and changes reported by target journal inspection. When this policy is enabled, a recovery action is automatically started when an error is detected. Recovery actions that require synchronizing information from the source node to the target node use the time specified in Source capture delay (SRCCAPDLY) policy.

Automatic database recovery

Determines whether to enable functions that automatically attempt to correct common file errors that may occur during replication from the user journal and changes reported by target journal inspection. When this policy is enabled and an error is detected, MIMIX™ Software will generate a recovery and attempt to replicate the transaction again. Recovery actions that require synchronizing information from the source node to the target node use the time specified in Source capture delay (SRCCAPDLY) policy

Automatic audit recovery

Determines whether to enable automatic recovery actions for audits. When enabled, audits that support automatic recovery will check their comparison results for known problems and will attempt to correct any detected errors by automatically starting recovery actions.

Object recovery notify on success

Determines whether object replication processes that successfully process an object while using the configured third delay/retry cycle will send an informational (*INFO) notification. This policy is only valid when the Automatic object recovery policy is enabled.

Audit notify on success

Determines whether activity initiated by audits, including recovery actions, will automatically send an informational (*INFO) notification upon successful completion. If an audit is run when the Automatic audit recovery policy is disabled, successful notifications are sent only for the compare phase of the audit.

Notification severity

Determines the severity level of the notifications sent when a rule ends in error. This policy determines the severity of the notification that is sent, not the severity of the error itself. The policy is in effect whether the rule is invoked manually or automatically.

This policy is useful for setting up an order precedence for notifications at the data group level. For example, if you set this policy for data group CRITICAL to be *ERROR when the value for the installation-level policy is *WARNING, any error notifications sent from data group CRITICAL will have a higher severity than those from other data groups.

Object only on target

Determines how recovery actions should handle correcting objects configured for replication that exist only on the target node. The only-on-target error may have been detected by replication processes, target journal inspection, or audits (#OBJATR, #IFSATR, #DLOATR, #FILATR, and #FILATRMBR). This policy is used by the resulting recovery actions when the Automatic recovery policies (Database, Object, and Audit) are enabled and a virtual switch is not in progress.

See Policies in environments with more than two nodes or bi-directional repli-cation for additional information.

Journaling attribute difference action

Determines the recovery action to take for scenarios in which audits have detected differences between the actual and configured values of journaling attributes for objects journaled to a user journal. This type of difference can occur for the Journal Images attribute and the Journal Omit Open/Close attribute. Differences found on either the source or target object are affected by this policy. For objects replicated due to a journal-centric configuration, the value of the attribute on the source system object is considered the MIMIX configuration for journaling for the object.

MIMIX configured higher

Determines the recovery for correcting a difference in which the MIMIX™ Software configuration specifies an attribute value that results in a higher number of journal transactions than the object's journaling attribute.

MIMIX configured lower

Determines the recovery action for correcting a difference in which the MIMIX™ Software configuration specifies an attribute value that results in a lower number of journal transactions than the object's journaling attribute.

DB apply threshold action

Determines what action to pass to the Compare File Data (CMPFILDTA) command or the Compare Record Count (CMPRCDCNT) command when it is invoked with *DFT specified for its DB apply threshold (DBAPYTHLD) parameter. The command’s parameter determines what to do if the database apply session backlog exceeds the threshold warning value configured for the database apply process. This policy applies whenever these commands are used and the backlog exceeds the threshold.

The shipped default for this policy causes the requested command to end and may cause the loss of repairs in progress or inaccurate counts for members. You can also set this policy to allow the request to continue despite the exceeded threshold.

DB apply cache

Determines whether to use database (DB) apply cache to improve performance for database apply processes. When this policy is enabled, MIMIX uses buffering technology within database apply processes in data groups that specify *YES for journal on target (JRNTGT). This policy is not used by data groups which specify JRNTGT(*NO), which use multithreaded database apply processing, or by data groups whose target journals use journal caching or journal standby functionality provided by the IBM feature for High Availability Journal Performance (IBM i option 42). To make any change to this policy effective, end and restart the database apply processes for the affected data groups. For more information about using database apply cache, see the Assure MIMIX Administrator Reference book.

Access path maintenance

Determines whether MIMIX can optimize access path maintenance during database apply processing as well as the maximum number of jobs allowed per data group when performing delayed maintenance. Enabling optimized access path maintenance improves performance for the database apply process. This policy is ignored by data groups configured for multithreaded database apply processing.To make any change to this policy effective, end and restart the database apply processes for the affected data groups. For more information about optimizing access path maintenance, see the Assure MIMIX Administrator Reference book.

Optimize for DB apply

Specify whether to enable optimized access path maintenance. When enabled, the database apply processes are allowed to temporarily change the value of the access path maintenance attribute for eligible replicated files on the target system. Eligible files include physical files, logical files, and join logical files with keyed access paths that are not unique and that specify *IMMED for their access path maintenance.

Maximum number of jobs

Specify the maximum number of access path maintenance jobs allowed for a data group when optimized access path maintenance is enabled. The actual number of jobs varies as needed between a minimum of one job and the specified value. The default value is 99.

Maximum rule runtime

Determines the maximum number of minutes an audit can run when the Automatic audit recovery policy is enabled. The compare phase of the audit is always allowed to complete regardless of this policy’s value. The elapsed time of the audit is checked when the recovery phase starts and periodically during the recovery phase. When the time elapsed since the rule started exceeds the value specified, any recovery actions in progress will end. The shipped default for this policy of 1440 minutes (24 hours) prevents running multiple instances of the same audit within the same day. Valid values are 60 minutes through 10080 minutes (1 week).

Audit warning threshold

Determines how many days can elapse after an audit was last performed before an indicator is set. When the number of days that have elapsed exceeds the threshold, the indicator is set to inform you that auditing needs your attention. The shipped default value of 7 days is at the limit of best practices for auditing.

Audit action threshold

Determines how many days can elapse after an audit was last performed before an indicator is set. When the number of days that have elapsed exceeds the threshold, the indicator is set to inform you that action is required because the audit is out of compliance. The shipped default of 14 days is the suggested value for this threshold, which is 7 days beyond the limit of best practices for auditing.

Audits included for compliance

Specifies which audits will be evaluated for compliance. For each indicated audit, MIMIX™ Software evaluates whether the last run of the audit exceeds the days specified for the Audit warning and Audit action thresholds (AUDWARN and AUDACT).

To specify multiple audits by name, a plus sign (+) in the + for more prompt, and press Enter.

Audit runs

Determines whether audits are allowed to run when requested and applies to all auditing requests regardless of whether they are invoked by the automatic scheduler or manually by user action. When set to *ENABLED, the audits are allowed to run when requested or scheduled. When set to *DISABLED, auditing requests are prevented from running. Use this value when you need to disable auditing completely, such as when performing a backup from a target system, during system or network maintenance, or on a test data group.

For additional information, see Guidelines and considerations for auditing and Changing auditing policies.

Audit options policies

Three audits support multiple comparison options: File Data (#FILDTA), Directories (#IFSATR), and Folders (#DLOATR). Each of the three audits have separate audit options policies for setting the comparison option to use. These policies support the ability to specify different values to use for all-objects audit requests and for prioritized and differences audit requests. All-objects audit requests select all objects within the data group’s configured name space for the class of objects checked by the audit. Prioritized and differences audit requests select objects based on their object-auditing priority or previous auditing differences. By design, each run of a prioritized or differences audit may select a unique subset of the objects replicated by the data group that are within the class of objects checked by that audit.

The auditing option you choose for audits depends on your environment, and especially on the data compared by the #FILDTA, #DLOATR, and #IFSATR audits. When choosing a value, consider how much data there is to compare, how frequently it changes, how long the audit runs, how often you run the audit, and how often you need to be certain that data is synchronized between source and target systems.

Regardless of the values you use for audit options during daily operations, Precisely strongly recommends that you run all audits using auditing option values that perform the most extensive checking:

• Before performing a planned switch to the backup node

• Before switching back to the original production node

FILDTA audit percent. options

Specifies the percentage of file records to compare in file members of each physical file (PF) that is selected for auditing by a run of the File Data (#FILDTA) audit. You can specify different values for all-objects audits and prioritized objects audits. Differences audits, which can be invoked only from the Assure Unified Interface, use the value specified for prioritized audits. When 100 is specified, one hundred percent of the records for each file member are compared for the selected files. This is the most extensive check available and is the shipped default value. When 20 is specified, twenty percent of the records for each file member are compared for the selected files. (It will take 5 audit runs to check all data that existed at the time the first audit started.) When 5 is specified, five percent of the records for each file member are compared for the selected files. (It will take 20 audit runs to check all data that existed at the time the first audit started.)

IFS audit options

Specifies whether to compare attributes and data, or only attributes, of the objects selected for auditing by a run of the Directory (#IFSATR) audit. When Attributes and Data (*ALL) is selected, all attributes and data within the selected IFS objects are compared. This is the most extensive check available and is the shipped default value. When Attributes (*ATTRONLY) is selected, only attributes of the selected IFS objects are compared.

DLO audit options

Specifies whether to compare attributes and data, or only attributes, of the DLO objects selected for auditing by a run of the Folder (#DLOATR) audit. When Attributes and Data (*ALL) is selected, all attributes and data within the selected DLO objects are compared. This is the most extensive check available and is the shipped default value. When Attributes (*ATTRONLY) is selected, only attributes of the selected DLO objects are compared.

Run rule on system

Determines the system on which to run audits. This policy is used when audits are invoked with *YES specified for the value of the Use run rule on system policy (USERULESYS) parameter on the Run Rule (RUNRULE) or Run Rule Group (RUNRULEGRP) command. When *YES is specified in these commands, this policy determines the system on which to run audits. While this policy is intended for audits, any rule that meets the same criteria will use this policy.

The policy’s shipped default value, *MGT, runs audits from the management system. In multi-management environments where both systems defined to a data group are management systems, the value *MGT will run audits only on the target system.

You can also set the policy to run audits from the network system, the source or target system, or from a list of system definitions. When both systems of a data group are in the specified list, the target system is used.

When choosing the value for the Run rule on system policy, also consider your switching needs.

Action for running audits

Determines the type of audit actions permitted when certain conditions exist in the data group. If a condition exists at the time of an audit request, audit activity is restricted to the specified action. If multiple conditions exist and the values specified are different, only the most restrictive of the specified actions is allowed. If none of the conditions are present, the audit requests are performed according to other policy values in effect.

Inactive data group

Specify the type of auditing actions allowed when any replication process required by the data group is inactive. For example, a data group of TYPE(*ALL) is considered inactive if any of its database or object replication processes is in a state other than active. This element has no effect on the #FILDTA and #MBRRCDCNT audits because these audits can run only when the data group is active.

Replication process in threshold

Specify the type of auditing actions allowed when a threshold warning condition exists for any process used in replicating the class of objects checked by an audit. If a checked process has reached its configured warning value, auditing is restricted to the specified actions. Most audits check for threshold conditions in all database and object replication processes, including the RJ link. #FILDTA audits only check for threshold warning conditions in the RJ link and database replication processes. #DLOATR audits only check for threshold warning conditions in object replication processes.

Audit severity Specifies the severity to associate with audits that have a status of *NOTRUN or *IGNOBJ. The selected severity determines whether audits with these statuses roll up into overall status of MIMIX. The severity also affects the order in which audits are displayed in interfaces, the color displayed in interfaces that use color, and the icon displayed with the status in the Assure Unified Interface interfaces.

Not run audit status Specifies the severity to associate with audits that have a status of *NOTRUN. Audits with this status are the result of the Action for running audits (RUNAUDIT) policy, or the data group was inactive when a #FILDTA or #MBRRCDCNT audit was requested.

Ignored objects audit status Specifies the severity to associate with audits that have a status of *IGNOBJ. Audits with this status indicate that some objects were ignored because they were considered active or could not be compared, typically due to locks or authorizations. The value for this policy also determines whether any ignored objects in an audit are counted as differences regardless of the audit status.

Audit history retention Determines criteria for retaining historical information about audit results and the objects that were audited. History information for an audit includes timestamps indicating when the audit was performed, the list of objects that were audited, and result statistics. Each audit, a unique combination of audit rule and data group, is evaluated separately and its history information is retained until the specified minimum days and minimum runs are both met. When an audit exceeds these criteria, system manager cleanup jobs will remove the historical information for that audit from all systems and will remove the audited object details from the system on which the audit request originated. The values specified at the time the cleanup jobs run are used for evaluation.

Minimum days Specify the minimum number of days to retain audit history for each completed audit. Valid values range from 0 through 365 days.The shipped default is 7 days.

Minimum runs per audit Specify the minimum number of completed audits for which history is to retained. Valid values range from 1 through 365 runs. The shipped default is 1 completed audit.

Object details Specify whether to retain the list of audited objects and their audit status for each completed audit of library-based objects. The specified value in effect at the time an audit runs determines whether object details for that run are retained. The specified value has no effect on cleanup of details for previously completed audit runs. Cleanup of retained details occurs at the time of audit history cleanup. The shipped default is *YES.

DLO and IFS details Specify whether to retain the list of audited objects and their audit status for each completed audit of DLO and IFS objects. The specified value in effect at the time an audit runs determines whether object details for that run are retained. The specified value has no effect on cleanup of details for previously completed audit runs. Cleanup of retained details occurs at the time of audit history cleanup. The shipped default is *YES.

Synchronize threshold size Determines the threshold, in megabytes (MB), to use for preventing the synchronization of large objects during recovery actions initiated by database replication, object replication, or audits. When any of the Automatic system journal recovery, Automatic user journal recovery, or Automatic audit recovery policies are enabled, all initiated recovery actions use this policy value for the corresponding synchronize command's Maximum sending size (MB) parameter. This policy is useful for preventing performance issues when synchronizing large objects.   

Number of third delay retry attempts Determines the number of times to retry a process during the third delay/retry interval. This policy is used when the Automatic system journal recovery policy is enabled. Object replication processes use this policy value when attempting recovery of an in-use condition that persists after the data group’s configured values for the first and second delay/retry intervals are exhausted. The shipped default is 100 attempts.

This policy and its related policy, Third delay retry interval, can be disabled so that object replication does not attempt the third delay/retry interval but still allow recoveries for other errors.

Third delay retry interval Determines the delay time (in minutes) before retrying a process in the third delay/retry interval. This policy is used when the Automatic system journal recovery policy is enabled. Object replication processes use this policy value when attempting recovery of an in-use condition that persists after the data group’s configured values for the first and second delay/retry intervals are exhausted. The shipped default is 15 minutes.

Source capture delay Determines the delay (in minutes) between detecting the need for a recovery action that requires a synchronization request and capturing the affected file records, attributes, authorities, or the entire object from the source system. Recovery actions initiated by replication processes and target journal inspection can delay these capture operations. There are two delay settings, one for recoveries during normal replication, and one for recoveries during the testing phase of a virtual switch. During the recovery phase of a virtual switch, MIMIX ignores both delay settings in this policy and immediately captures any needed source information for recoveries that have been identified. Recovery actions are only performed when the Automatic database recovery and Automatic object recovery policies are enabled. Changes to either value become effective automatically as the replication manager checks for recoveries to process.

Replication recovery processing Specifies the time, in minutes, to delay before capturing information needed for a recovery action that requires a synchronization request. During the delay, the recovery action is not processed and any additional replication recoveries for subsequent errors of the same type on the same object or file record range will not initiate additional capture requests, thereby reducing the number of captures. The shipped default is *NONE.

Virtual switch testing Specifies the time, in minutes, to delay before capturing information needed for a recovery action that requires a synchronization request during the application testing phase of a virtual switch. During the delay, any additional replication recoveries needed for subsequent errors of the same type on the same object or file record range will not initiate additional capture requests, thereby reducing the number of captures. The shipped default is 5 minutes.

Recovery processing Specifies criteria that the replication manager uses when processing recovery requests on the source system. Changes to this policy are effective immediately.

Maximum number of jobs Specifies the maximum number of active asynchronous jobs that the replication manager can use to perform recovery activity. The replication manager's persistent job for controlling recovery requests is not included in this number. Valid values range from 1 through 100. The shipped default is 10.

Number of retries per recovery Specifies the number of times a recovery request can be retried if the first attempt to process it is not successful. A retry is requested when an error occurs while capturing or applying the object or its attributes, which are often due to an in-use condition. Valid values range from 1 through 100 and the special value *DISABLED, which will prevent attempts to automatically retry processing recoveries. The shipped default is 5.

Switch warning threshold Determines how many days can elapse after the last switch was performed before an indicator is set for the installation. When the number of days that have elapsed exceeds this threshold, the indicator is set to inform you that switching may need your attention. The shipped default is 90 days, which is considered at the limit of best practices for switching.

The indicator is associated with the Last switch field. The Last switch field identifies when the last completed switch was performed using the default model switch framework (DFTMSF) policy.

Switch action threshold Determines how many days can elapse after the last switch was performed before an indicator is set for the installation. When the number of days that have elapsed exceeds this threshold, the indicator is set to inform you that action is required. The shipped default of 180 days is the suggested value for this threshold, which beyond the limit of best practices for switching.

The indicator is associated with the Last switch field. The Last switch field identifies when the last completed switch was performed using the default model switch framework (DFTMSF) policy.

Default model switch framework Determines the default MIMIX Model Switch Framework to use for switching. This value is used by configurations which switch via model switch framework. The shipped default value is MXMSFDFT, which is the default model switch framework name for the installation. If the default name is not being used, this value should be changed to the name of the MIMIX Model Switch Framework used to switch the installation.

Independent ASP library ratio Determines the number for n in a ratio (n:1) of independent ASP libraries (n) on the production system to SYSBAS libraries on the backup system. For each switchable independent ASP defined to MIMIX by a device resource group, a monitor with the same name as the resource group checks this ratio. When the number of independent ASP libraries falls to a level that is below the specified ratio, the monitor sends a notification to inform you that action may be required. This signals that your recovery time objective could be in jeopardy because of a prolonged independent ASP switch time.

Determines the threshold at which a request to compare record counts (CMPRCDCNT command or #MBRRCDCNT audit) will not perform the comparison due to commit cycle activity on the source system. The value specified is the maximum number of uncommitted record operations that can exist for files waiting to be applied at the time the compare request is invoked. Each database apply session is evaluated against the threshold independently. As a result, it is possible that record counts will be compared for files in one apply session but will not be compared for files in another apply session. For additional information see the Assure MIMIX Administrator Reference book.

System ASP threshold warnings

Specifies thresholds as a percent of storage used by the system auxiliary storage pool (ASP 1) at which certain types of warnings are displayed. The thresholds for journal receivers that are eligible for deletion and for delayed recoveries are evaluated independently.

Delay data recoveries

Specifies the threshold for delaying file member data recoveries. When the percentage of storage used by ASP 1 on the source system of a data group exceeds the specified value, MIMIX delays processing of new recoveries for member data of *FILE objects. Other recoveries are not affected and continue to be processed. The delayed recoveries are automatically submitted after the storage used by ASP1 on the source system is less than the threshold value.

Delete-eligible jrn. receivers

Specifies the threshold for warning that journal receivers eligible for deletion exist on a system. When the percent of storage used by ASP 1 on a system exceeds the specified value and the number of journal receivers on that system exceed configuration requirements, MIMIX displays a warning (yellow) status for the journal manager on that system to indicate the presence of receivers that are eligible for deletion. Receivers that are no longer considered necessary for MIMIX should be evaluated and, if they are not needed for other processes, deleted to reduce storage constraints on the system.

Procedure history retention

Specifies criteria for retaining historical information about procedure runs that completed, completed with errors, or that have an acknowledged status. History information for a procedure includes timestamps indicating when the procedure was run and detailed information about each step within the procedure. System cleanup jobs use the policy values at the time they run to evaluate whether procedure history information can be removed. Each procedure run is evaluated separately. If the history information includes more runs than the minimum runs setting, then any runs older than the minimum days are removed by system cleanup jobs.

Minimum days

Specifies the minimum number of days to retain procedure run history. The default value is 7.

Minimum runs per procedure

Specifies the minimum number of completed procedure runs for which history is to retained. This value applies to procedures of all other types except *SWTPLAN and *SWTUNPLAN. The default value is 1.

Min. runs per switch procedure

Specifies the minimum number of completed switch procedure runs for which history is to retained. This value applies to procedures of type *SWTPLAN and *SWTUNPLAN that are used to switch an application group. The default value is 12.

Directory depth

Determines the number of directory levels to be checked by the directory data protection report. The policy value at the time the report runs determines the number of sub-directories included in the resulting report. The default is 3.

Status for extraction

Determines whether MIMIX status can be collected in a format suitable for extracting by other applications such as Ironstream Hub. MIMIX does not install or configure applications that extract the collected status data. To make any change to this policy effective, end and restart collector services on the systems specified in the policy.

The All-obj. audit and Priority audit policies are no longer preferred for changing audit scheduling criteria. For more information about using the preferred method, see Scheduling audits and reports.