Consider these recommendations when you check results of audits:
Always review the results of the audits. Audit results reflect only what was actually compared at the time the comparison occurred. For most audits, the vast majority of recovery actions are submitted to the replication manager and have any recovery errors surface as replication errors. The audit results outfile is not updated with status from recoveries that were successfully processed via the replication manager. The audit results may show that some objects may not have been compared due to object activity or due to the auditing option policy value in effect, even when no differences (*NODIFF) are reported. You may need to take actions other than running an audit to correct detected issues. For example, you may need to change a procedure so that target system objects are only updated by replication processes.
Be aware of priority auditing behavior. Priority audits differ from other audits in how they select objects to audit and in the number of objects selected. Be aware of the implications of those differences when checking audit results. Priority audits select replicated objects based on their auditing eligibility. As a result, priority audits cannot check newly created source objects until after their create transactions have been replicated. Priority audits can return results indicating that zero (0) objects were selected. This occurs when no objects were eligible for selection by an audit.
Deleted objects reported as not found. Audits can report not found conditions for objects that have been deleted. A not found condition is reported when a delete transaction is in progress for an object eligible for selection when the audit runs.This is more likely to occur when there are replication errors or backlogs at the time the audit runs.
Fixing one error may expose another. It may take multiple iterations of running audits with recoveries before the results are clean. Recovering from one error may result in a different error surfacing the next time the audit is performed. For example, a recovery that adds data group file entries may result in detecting a database relationship difference (*DBRIND) error the next time the audit is performed, where the root problem is that a library of logical files is not identified for replication.
Watch for trends in the audit results. Trends may indicate situations that need further investigation. For example, objects that are being recovered for the same reason every time you run an audit can be an indication that something in your environment is affecting the objects between audits. In this case, investigating the environment for the cause may determine that a change is needed in the environment, in the MIMIX configuration, or in both. Trends may also indicate a MIMIX problem, such as reporting an object as being recovered when it was not. Report these scenarios to MIMIX Support. You can do this by creating a new case using the Case Management page in Support.