Resolving audit runtime status problems - assure_mimix - 10.0

*FAILED

If the failed audit selected objects by priority and its timeframe for starting has not passed, the audit will automatically attempt to run again.

The rule called by the audit failed or ended abnormally.

• To run the rule for the audit again, select option 9 (Run rule). This will check all objects regardless of how the failed audit selected objects to audit.

• To check the job log, see Checking the job log of an audit.

*ENDED

The recovery varies according to why the audit ended.

 To determine why the audit ended: 

1. Select option 5 (Display) for the audit and press Enter.

2. Check the value indicated in the Reason for ending field. Then perform the appropriate recovery, below.

If the reason for ending is *DGINACT, the data group status became inactive while the audit was in progress.

1. From the command line, type WRKDG and press Enter.

   • If all processes for the data group are active, skip to Step 2.
   • If processes for the data group show a red I, L, or P in the Source and Target columns, use option 9 (Start DG). Note that if the data group was inactive for some time, it may have a threshold condition after being started. Wait for the threshold condition to clear before continuing with Step 2.

2. When the data group is active and does not have a threshold condition, return to the Work with Audits display and use option 9 (Run rule) to run the audit. This will check all objects regardless of how the ended audit had selected objects to audit.

If the reason for ending is *ENDJOB, user action ended the audit. Either the Stop action for the audit was used from the Assure UI portal, option 10 (End) was used from the Work with Audits display or the Work with Recoveries display, or a user manually ended the audit job with the ENDJOB command.

Objects that have not yet been recovered or submitted for recovery will not be available in the Object Correction Activity window in the Assure UI portal, but you may still be able to manually recover the objects from the audit results. Objects for which a recovery was submitted (*RCYSBM status) are identified in audit results and those recoveries will be processed through replication processes.

 If the reason for ending is *MAXRUNTIM, the Maximum rule runtime (MAXRULERUN) policy in effect was exceeded. Do one of the following:

• Wait for the next priority-based audit to run according to its timeframe for starting.

• Change the value specified for the MAXRULERUN policy using Setting policies - general. Then, run the audit again, either by using option 9 (Run rule) or by waiting for the next scheduled all-objects audit or priority-based audit to run.

If the reason for ending is *THRESHOLD, the DB apply threshold action (DBAPYTACT) policy in effect caused the audit to end.

1. Determine if the data group still has a threshold condition. From the command line, type WRKDG and press Enter.

2. If the data group shows a turquoise T in the Target DB column, the threshold exceeded condition is still present. Wait for the threshold to resolve. If the threshold persists for an extended time, you may need to contact your MIMIX administrator.

3. When the data group no longer has a threshold condition, return to the Work with Audits display and use option 9 (Run rule) to run the audit. (This will check all objects.)

*NOTRUN

The audit request was submitted but did not run. Either the audit was prevented from running by the Action for running audits policy in effect, or the data group was inactive when a #FILDTA or #MBRRCDCNT audit was requested.

A status of *NOTRUN may be expected during periods of peak activity or when data group processes have been ended intentionally. However, if the audit is frequently not run due to the Action for running audits policy, action may be needed to resolve the cause of the problem.

To resolve this status:

1. From the command line, type WRKDG and press Enter.

2. Check the data group status for inactive or partially active processes and for processes with a threshold condition.

3. When the data group no longer has a threshold condition and all processes are active, return to the Work with Audits display and use option 9 (Run rule) to run the audit. (This will check all objects.)

*IGNOBJ

The audit ignored one or more objects because they were considered active or could not be compared because of locks or authorizations that prevented access. All other selected objects were compared and any detected differences were recovered.

To resolve this status:

1. From the Work with Audits display on the target system, type 7 (History) next to the audit with *IGNOBJ status and press Enter.

2. The Work with Audit History display appears with the most recent run of the audit at the top of the list. Type 8 (Display difference details) next to an audit to see its results in the output file.

3. Check the Difference Indicator column to identify the objects with a status of *UN or *UA.

4. When the locks are released or replication activity for the object completes, do one of the following:

• Wait for the next prioritized audit to run.

• Run the audit manually using option 9 (Run rule) from the Work with Audits display,

*DIFFNORCY

The compare phase of the audit detected differences but automatic recovery actions were not attempted due to policies in effect when the audit ran. Either the Automatic audit recovery policy was disabled or the Action for running audits policy prevented recovery actions while the data group was inactive or had a replication process which exceeded its threshold.

Recovery via the Assure UI portal is preferred. Do the following:

1. Go to the Assure UI portal and select the Correction Activity action to access the Object Correction Activity window.

2. Check the status of the objects with differences. If any differences from the audit remain and have not already been resolved, use the available actions to correct the object differences.

Manual recovery: If policy values were not changed since the audit ran, checking the current settings will indicate which policy was the cause. Use option 36 to check data group level policies and F16 to check installation level policies.

• If the Automatic audit recovery policy was disabled, the differences must be manually resolved.

• If the Action for running audits policy was the cause, either manually resolve the differences or correct any problems with the data group status. You may need to start the data group and wait for threshold conditions to clear. Then run the audit again.

To manually resolve differences do the following:

1. Type 7 (History) next to the audit with *DIFFNORCY status and press Enter.The Work with Audit History display appears with the most recent run of the audit at the top of the list. Type 8 (Display difference details) next to an audit to see its results in the output file.

   Note: The object status in the audit results reflects the time that a difference was detected. The status is not updated as a result of recovery actions performed by the replication manager.

2. Check the Difference Indicator column. All differences shown for an audit with *DIFFNORCY status need to be manually resolved. For more information about the possible values, see Interpreting audit results - supporting information.

To have MIMIX always attempt to recover differences on subsequent audits, change the value of the automatic audit recovery policy.

*NOTRCVD

The comparison performed by the audit detected differences. Some of the differences were not automatically recovered.

Recovery via the Assure UI portal is preferred. Do the following:

1. Go to the Assure UI portal and select the Correction Activity action to access the Object Correction Activity window.

2. Check the status of the objects with differences. If any differences from the audit remain and have not already been resolved, use the available actions to correct the object differences.

Manual recovery: Do the following:

1. Type 7 (History) next to the audit with *NOTRCVD status and press Enter.

2. The Work with Audit History display appears with the most recent run of the audit at the top of the list. Type 8 (Display difference details) next to an audit to see its results in the output file.

   Note: The object status in the audit results reflects the time that a difference was detected. The status is not updated as a result of recovery actions performed by the replication manager.

3. Check the Difference Indicator column. Any objects with a value of *RCYFAILED must be manually resolved. For any objects with values other than *RCYFAILED or *RECOVERED, run the audit again. For more information about the possible values, see Interpreting audit results - supporting information.