Resolving audit runtime status problems - 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

Audit runtime status is displayed on the Audit summary view of the Work with Audits display. Audits with potential problems are at the top of the list.

You may also need to view the output file or the job log, which are only available from the system where the audits ran. In most cases, this is the management system.

                                Work with Audits                                

                                                             System:   AS01     

 Type options, press Enter.                                                     

   5=Display   6=Print   7=History   8=Recoveries   9=Run rule   10=End         

   14=Audited objects    39=Run rule with override   46=Mark recovered ...       

                                                                                 

      Audit       Audit       ---------Definition---------  Object  Objects     

 Opt  Status      Rule        DG Name    System 1 System 2  Diff    Selected    

 __   *FAILED     #OBJATR     EMP        AS01        AS02        0   *PTY       

Do the following from the management system:

  1. If necessary, do one of the following to access the Work with Audits display.

    • From the MIMIX Intermediate Main Menu, select option 6 (Work with audits) and press Enter. Then use F10 as needed to access the Audit summary view.

    • From a command line, enter WRKAUD VIEW(*AUDSTS) 

  2. Check the Audit Status column.

  • The values *FAILED, *ENDED, *NOTRUN, and *IGNOBJ are considered problems. To resolve the problem, perform the action indicated in Table 136.

  • The values *DIFFNORCY and *NOTRCVD are considered successful audit status values. However, the audit included objects for which there were object level differences that could not be resolved. These objects may require attention. Perform the action indicated in Table 137.

  • These values are considered successful or do not require user action: *AUTORCVD, *CMPACT, *DISABLED, *IGNATR, *NEW, *NODIFF, *QUEUED, *RCYACT, and *USRRCVD.

Addressing problems with audit runtime status

Status

Action

*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, or the audit was stopped from running due to unprocessed entries from system manager.

Note: An audit with *NOTRUN status may or may not be considered a problem in your environment. The value of the Audit severity policy in effect determines whether the audit status *NOTRUN has been assigned an error, warning, or informational severity. The severity determines whether the *NOTRUN status rolls up into the overall status of MIMIX and affects the order in which audits are displayed in interfaces.

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:

Determine the reason for audit status being in *NOTRUN:
  1. Select option 5 (Display) for the audit and press Enter.
  2. Check the value indicated in the Reason for not run field. Then perform the appropriate recovery, below:
If the reason for not running is *DGINACT, the data group status was inactive when the audit attempted to run.
  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 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 previous audit had selected objects to audit.
If the reason for not running is *THRESHOLD, the DB apply threshold action (DBAPYTACT) policy in effect caused the audit not to be run.
  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 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.)
If the reason for not running is *SYSMGRSTS, the system manager had unprocessed entries that stopped the audit from running.
  1. From the command line, type WRKSPSTS and press Enter.
  2. Check the system manager for two pairs between the two systems for the data group of the audit.
  3. Check for a non-zero value in the unprocessed entry count column. If there are non-zero values, wait for the number to be zero. If the non-zero value persists for an extended time, you may need to contact your MIMIX administrator.
  4. When the system manager no longer has a unprocessed entry count, 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.

Note: An audit with *IGNOBJ status may or may not be considered a problem in your environment. The value of the Audit severity policy in effect determines whether the audit status *IGNOBJ has been assigned a warning or informational severity. The severity determines whether the *IGNOBJ status rolls up into the overall status of MIMIX, determines whether the ignored objects are counted as differences, and affects the order in which audits are displayed in interfaces.

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,

The values *DIFFNORCY and *NOTRCVD are considered successful audit status values because most audit recoveries are submitted to the replication manager, and audits do not wait for submitted recoveries to end before the audit completes. Any unresolved differences are reported as replication errors elsewhere in the product.

Addressing audit statuses that identify remaining object level differences

Status

Action

*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.

Note: This status can be expected for a #MBRRCDCNT audit. When the #FILDTA audit for the data group has automatic scheduling enabled for audits with the same selection criteria (all-objects or priority-based objects) as the #MBRRCDCNT audit, the #MBRRCDCNT audit will not perform recoveries. The #FILDTA audit may correct the detected differences.

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.

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.

Note: This status can be expected for a #MBRRCDCNT audit. When the #FILDTA audit for the data group has automatic scheduling enabled for audits with the same selection criteria (all-objects or priority-based objects) as the #MBRRCDCNT audit, the #MBRRCDCNT audit will not perform recoveries. The #FILDTA audit may correct the detected differences.

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.

For more information about the values displayed in the audit results, see Interpreting results for configuration data - #DGFE audit , Interpreting results of audits for record counts and file data, and Interpreting results of audits that compare attributes.