DSEXDBAN output is showing "599704 - PRIOR DBKEY INCONSISTENT - SET UNKNOWN" database errors
Article ID: 38992
Updated On:
Products
Issue/Introduction
Question:
Are these "599704 - PRIOR DBKEY INCONSISTENT - SET UNKNOWN" messages being shown in our DSEXDBAN output a clear indicator that we have broken chains in our CA Dispatch IDMS database files?
Answer:
Actually, no. These particular messages do not unequivocally mean that broken chains exist in the Dispatch database files.
Cause:
The most likely reason for seeing the "DBKEY INCONSISTENT" messages in the DSEXDBAN output is that CA Dispatch was either still active when DSEXDBAN was executed. Or, if CA Dispatch was down, it had not been shut down clean. It's also possible that an Online Viewing Only (OLVO) region was active at the time DSEXDBAN was executing, and that OLVO region user activity caused these messages to be received. "DBKEY INCONSISTENT" messages are indicative of some other task or run unit updating the database while the DSEXDBAN job is executing.
Resolution:
If you run a DSEXDBAN and encounter these "DBKEY INCONSISTENT" messages, your first course of action should be to either rerun, or, schedule another run of the DSEXDBAN job after ensuring that the Dispatch started task is DOWN and that it came down CLEAN as the result of a normal STOPCADS command. In order to get accurate database analysis reporting, you must also ensure that there are no other batch or online applications running that might be updating the CA Dispatch database files at the same time the DSEXDBAN job is executing.
Additional Information:
After encountering a CA Dispatch event such as an ABEND or CANCELLATION in the started task, the best way to ensure the integrity of the database files and that the DSEXDBAN job will provide accurate database analysis reporting would be to RECYCLE the Dispatch started task cleanly before running the DSEXDBAN job.
To get a clean recycle, you will want to restart CA Dispatch using the command S DISPATCH,START=DSSTAR00 so that none of the Dispatch subtasks are started. As Dispatch is coming up, review the startup messages and look for the messages associated to the WARMSTART process. The ideal WARMSTART messages are going to say either "warmstart bypassed" or "warmstart successful". As soon as CA Dispatch comes all the way back up, CA Dispatch should then be immediately brought back down via a regular STOPCADS command. This gives Dispatch a chance to go through it's normal shutdown routines and allows you to review the logs and verify that Dispatch comes down CLEAN prior to running the DSEXDBAN job.
There are a variety of potential messages that can be issued by the Database Analysis job DSEXDBAN that would show conclusive evidence that broken chains do in fact exist. Typically, when broken chains exist in the database, the output from DSEXDBAN will contain messages that include the text of "NOT FOUND". Messages like "NEXT LINK NOT FOUND" or "PRIOR POINTER NOT FOUND" for example.
There are other messages that are indicative of broken chains and/or some other type of database corruption. However, the "NOT FOUND" messages are the ones a customer most often encounters when broken chains actually do exist. If after running the DSEXDBAN job you are unsure of how to interpret the output or whether or not you have broken chains in your database files, you should contact CA Technologies, open a support case, and send your DSEXDBAN in for evaluation.
Environment
Component:
Feedback
