Operating Preparations

Before running CA IDMS/DB Audit, prepare for processing as follows:

Prevent additional updates - During the time the database is being audited, CA IDMS/DB Audit follows the normal CA IDMS conventions regarding locking the area against access. If you specify READYMODE=RETRIEVAL, you must ensure that no other update jobs run against an area being audited.
If you run CA IDMS/DB Audit twice (once for audit and once for fix), you must prevent any CA IDMS updates from taking place in the audited areas until after you apply the fixes. If any updates are made between the time the audit is run and the time the fixes are applied, the corrections may not be valid or new integrity errors may be introduced. Similarly, do not perform any updates until you have completed the REPORT function.
Back up the database - CA IDMS/DB Audit does not write before and after images of changed data to a journal file. Therefore, you should back up the database before initiating fix processing and again after fix processing.

Perform the following preparations within CA IDMS/DB Audit:

Include index area in the subschema - If you specify AUDIT INDEX, you must copy the index areas and associated records and sets into the subschema.
If you specify INDEX, copy the area containing the index members and owners into the subschema.
In the subschema, define all members of sets to be audited - You cannot successfully audit a set unless you define all the set's member record types in the subschema. This includes all members of the CALC set residing in areas for which CALCSET processing will occur.
Specify correct SUBSCHEMA/DMCL and load/core image library - Be sure to specify the correct subschema for the database you wish to audit. If you specify the wrong subschema, CA IDMS/DB Audit can incorrectly flag a large number of pages as having header or footer errors. Because CA IDMS/DB Audit does not access the subschema/DMCL from a dictionary, the correct copies must be in the job's step library or core image library.
Specify RETRIEVAL only for runs with no updates - In the PROCESS statement, specify RETRIEVAL as the readymode for runs that do not update the database. Legitimate runs are AUDIT, FIX=SIMULATE or AUDIT, REPORTS.
With READYMODE=RETRIEVAL, CA IDMS/DB Audit does not lock the database, so you must ensure that no other job updates the database. Otherwise, if the database being audited is in the process of being updated, CA IDMS/DB Audit may incorrectly indicate that the database contains integrity errors.
Specify UPDATE for actual fixing - When you are ready to fix the database, specify READYMODE=UPDATE in the job that is to perform the fixing. Be sure that the database to be fixed is not modified between the AUDIT and the FIX or REPORTS jobs.
Allow sufficient time to audit the database - Because CA IDMS/DB Audit may access every record and set occurrence in the database several times, it can take a long time to audit the database. Recognize that in most cases Standard processing takes longer than QuickCheck processing.
Specify DISK if sets to be audited are large - Large sets, including integrated index sets, require large amounts of storage for the tables used in processing. If you specify DISK to contain these tables, you must allocate two VSAM files before executing CA IDMS/DB Audit.
Allocate enough space for the DBKYWORK file - This step applies to Standard auditing only. The DBKEYWORK file can require a substantial amount of space if you audit integrated indexes whose areas contain many mandatory-automatic (MA) index set members. For every MA index set member, CA IDMS/DB Audit writes two 30-byte records to the DBKEYWORK file. If a member record belongs to more than one index set, two records are written for each set to which it belongs.
Allocate enough space for INDXEXTR and INDXWORK files - The INDXEXTR and INDXWORK files are used for integrated index orphan extract records and for other integrated index error extract records.
For each index orphan found, CA IDMS/DB Audit writes one index orphan extract record to the INDXEXTR file. If you are fixing (simulate or update) index orphans, CA IDMS/DB Audit also writes one index orphan extract record to the INDXWORK file. Be sure to allocate enough sort work space for integrated index orphans.
Include a sufficient area portion - CA IDMS/DB Audit allows partial area auditing and fixing. CA IDMS/DB Audit does not allow fixing, however, when you perform a partial area audit and either of the following situations exists:
- A set containing an integrity error points into a second set with errors, and the owner of the second set is outside the partial area being swept.
- Records are detected as orphans of a set containing integrity errors, and the owner of the set is outside the partial area being swept.
Review the output - Review the reports CA IDMS/DB Audit generates to understand the errors detected and the way they have been fixed.

Validate the logical integrity of any set occurrences CA IDMS/DB Audit fixed. Because CA IDMS/DB Audit cannot analyze logical integrity conditions enforced by user programs, you must correct any logical errors once the physical errors have been fixed. You can use the CA IDMS utility IDMSBCF, FIX PAGE function to fix errors that CA IDMS/DB Audit does not fix. For a list of the types of integrity errors that CA IDMS/DB Audit does not fix, refer to Concepts.