Can you tell me more about ***DBKEY process and messages that are given ?
Article ID: 11805
Updated On:
Products
Issue/Introduction
Can you explain the process when running DDUPDATE 1000 APPLYCXX and the messages that are expected to be seen ?
Environment
Resolution
When you run DDUPDATE 1000 APPLYCXX to add/delete a key , a process starts in the Multi-User , ***DBKEY , and when that process completes the new key gets a status LD (LOADED) and can be used by the applications.
When that process starts , you see message DB02814I with STARTED in the text .
From your MUF : DB02814I - DYNAMIC INDEX ADD STARTED FOR KEY EQTK7 BASE 60 TBL EQT.
When the process ends , you get this message with ENDED instead of STARTED .
Other messages that are possible are :
DB02815I
DYNAMIC INDEX fff aaa
Reason:
The asynchronous index work that is associated with an APPLYCXX add or delete request was interrupted. The fff is either ADD or DELETE. If aaa is ABORTED BY EOJ, it was interrupted by a MUF EOJ request. If aaa is REQUEST ABORTED, it was interrupted by a REQABORT request.
Action:
None. The index work that is required to process the APPLYCXX delete request is rescheduled when the first URT is opened against the affected table.
DB02816E
DYNAMIC INDEX fff UNEXPECTED RETURN CODE cc(iii)
Reason:
The message details database errors that were encountered during the asynchronous index work that is associated with an APPLYCXX delete or add request. The fff is the function, either ADD or DELETE. The cc is the return code, and iii is the internal return code.
Action:
Determine what caused the return code and correct it. The required index work to process the APPLYCXX delete or add request is rescheduled when the first URT is opened against the affected table.
---
When you reqabort the process , cancel the MUF or just EOJ , this ***DBKEY starts again when this base gets opened again . That is what happened in your MUF last night .
extract from DocOps.ca.com :
The 24X7 key addition process reads every row in the table one by one with a row lock as the key is constructed and added to the index. The time to completely accomplish the key addition is based upon the number of rows in the table. The time to finish is less than but nearly equal to the time a user application takes to read the rows of the table in Native Key sequence.
The execution of the addition or deletion occurs in a MUF System Task area with a JOBNAME of ***DBKEY. The ***DBKEY area is dedicated to 24x7 asynchronous index definition additions or deletions.
Note: ***DBKEY is reported in the JOBNAME of the DBUTLTY COMM STATUS report.
The task area has a Jobname of ***DBKEY. Individual keys are added to a list of work to be done when a CA Datacom® Datadictionary™1000 APPLYCXX batch transaction request is processed by CA Datacom®/DB.
When an entry is added to the list of work to be done, the system task is scheduled. At the start of the asynchronous processing for an individual key, the system task opens a URT for the table that is involved. The URT is subject to normal ACCESS rules. After the table is successfully opened, the index work associated with the addition or deletion of the key is processed. When the index work is complete, the key is added or deleted from the CXX and the URT is closed. The system task then processes the next key entry in the list, if there are any.
A module named DBKEYPR processes the asynchronous key maintenance. DBKEYPR is eligible for NEWCOPY
If an addition or deletion request is executing and you want to stop the process, the addition or deletion process can be subjected to a DBUTLTY REQABORT function. An executing addition or deletion request is also interrupted if a MUF EOJ is issued. If an executing addition or deletion is stopped, the addition or deletion process for the key definition is restored to the list when the first URT for the table is opened for non DBUTLTY processing in MUF.
In processing the key definition item, the system task has messages that reflect the start and end of each definition and other useful information.
The asynchronous key addition process includes populating the unique key value statistics for the new key. These statistics are used by SQL for join optimization and reported by running a TYPE=G IXX report.
The DBUTLTY VERINDEX function report shows the status of individual keys in a column labeled STATUS, following the ERROR COUNT column. The STATUS column represents the status of an individual key, listing the same values as a CXX report lists for the key. Most keys have a status of LD for loaded, but keys that are in the process of being added or deleted have a STATUS of NL AD (not loaded adding) or NL DL (not loaded deleting). A key that is in the process of being added or deleted is reported in VERINDEX with a MATCH_COUNT of 0 and is effectively skipped.
Feedback
