Concepts › Audit Phase › Set Walk Processing › Prior Pointers

Prior Pointers

When walking a set containing prior pointers, if the prior db-key of a record occurrence does not point back to its prior record in the set, CA IDMS/DB Audit saves the db-key of the current record in a save table and continues set walking. At end-of-set, CA IDMS/DB Audit retrieves each saved db-key and attempts to walk prior from that point. This process of walking, saving, and retrieving db-keys is continued until all saved db-keys have been processed.

For example, in Figure 2.36, CA IDMS/DB Audit walks a set occurrence owned by ENGLISH. No error is detected until the David Lee record is retrieved: the prior db-key does not point to John Doe.

Since the David Lee record is the last member of the set and an integrity error was detected in the set, CA IDMS/DB Audit returns to the owner record, ENGLISH, and walks the set again, creating extract records for each record occurrence retrieved. When the David Lee record is retrieved, the record db-key is placed in the save table. CA IDMS/DB Audit continues set walking until end-of-set is reached. CA IDMS/DB Audit then retrieves the saved db-key and begins walking prior from the saved db-key to its prior record, Joan Brown.

The following situations demonstrate the effect of specifying DBKEYTBL or not:

• When DBKEYTBL is specified: because Joan Brown's prior db-key (2501-08) is already in the DBKEYTBL, CA IDMS/DB Audit stops walking prior at this point
• When DBKEYTBL is not specified: CA IDMS/DB Audit continues walking prior to the records John Doe and Carol Smith until it reaches the owner record ENGLISH, or until the SETLIMIT value is reached

In either case, CA IDMS/DB Audit then checks the save table for additional saved db-keys. After all saved db-keys have been processed, CA IDMS/DB Audit stops creating extract records for the set.

Figure 2.36: Set Walk, Prior Pointers