Version 8.2.3
 —  Utilities  —

Functional Overview

When a database autostart fails and the database will not start up, you need to know what can be done to get the database back up and running quickly, with a minimum amount of lost data and with enough information to retrieve any lost updates. The ADAWRK utility can help you make this determination. It can produce the following reports:

Samples and more detailed descriptions of all reports and checkpoint records are provided elsewhere in this document.

The ADAWRK utility will only report on transactions that may need to be corrected as part of the autorestart processing logic.

You can filter all of the Work part 1 autorestart area records processed and reports produced in an ADAWRK run by communication ID, ETID, user ID, and file number.

For information on Adabas database autorestart processing, read Recovery/Restart Design


Replication-Related Data Processing

To internally support replication-related protection records, ADAWRK determines and reports the replication restart point (RRP) of the transactions on Work part 1. The RRP is the timestamp of the start of the oldest committed transaction that was replicated but for which Adabas has not yet received confirmation from the Event Replicator Server. The RRP should be taken into consideration when you are trying to identify transactions that may have been completed and replicated, or scheduled to be replicated, but for which replication processing may have been interrupted. Such transactions may need to be resent to the Event Replicator as part of autorestart processing by the nucleus.

If there is more than one Work data set (from a cluster database), the RRP is located on every Work data set. If, while searching for the RRP, ADAWRK detects that one Work data set has wrapped, then it determines that it has not found the RRP on that Work data set and that replication data may have been lost.

Top of page

ADAWRK EXU User Processing

When a user runs as an exclusive-update (EXU) user, ADAWRK groups the user's updates under the associated communication ID.

Note:
An EXU user is one who specifies the keyword EXU (omitting the keyword UPD) in the record buffer of the OP command to Adabas and does not issue ET commands. No other user can update the file(s) over which the EXU user has exclusive-update control. An EXU user does not have transactional support and cannot back out recent updates. For more information on EXU users and EXU processing, read Competitive Updating and read Exclusive Control Updating.

In the Transaction report, ADAWRK lists only those EXU user updates that may need to be corrected as part of the session autorestart processing. The last such update may be incomplete and subject to being backed out by Adabas.

In the Replication report, ADAWRK lists only those replicated EXU user updates that the Event Replicator server has not confirmed as successfully processed. Some or all updates may appear in both the Transaction and Replication reports.

Top of page