How to resolve a Datacom Return Code 13(017) error
Article ID: 45287
Updated On:
Products
Issue/Introduction
A rare and sporadic error encountered by certain base product applications that use Datacom/AD is a RC 13(017). This error can also be received by user applications running Datacom/DB.
This error indicates an internal error with a database index, and often reflects an out-of-sync condition for a record between the data and index. While this situation should never happen under normal operating conditions, any number of unusual sets of circumstances could lead to this error.
One common situation is that the database area and index are restored from non-Datacom backups, and these backups were taken while the database was open and being updated. Since the non-Datacom utility may not be aware of records in buffers, what is backed up may not have complete integrity, and when restored, it is possible for an index record to exist without a data record, or vice-versa, leading to a RC 13(017) when that record is read.
How to resolve such error?
Environment
z/os, Datacom/DB 15.1
Resolution
To resolve this error, the database must be closed in the MUF, which means that any application that uses this database must be stopped or shut down. Then, DBUTLTY INIT and RETIX functions must be processed against the database to initialize and rebuild the index.
Here is a basic sample job that will rebuild the index using the current index database file.
//DBRETIX JOB ...
//*
//********************************************************************
//* *
//* SAMPLE RETIX OF A DATACOM DATABASE INDEX *
//* *
//* THIS JOB PERFORMS A DBUTLTY RETIX TO REBUILD THE INDEX FOR A *
//* DATACOM DATABASE. IT WILL PROCESS THE INDEX FILE AS IT IS *
//* CURRENTLY ALLOCATED AND DEFINED. *
//* *
//* THIS JOB REQUIRES EXCLUSIVE ACCESS TO THE DATABASE FILES. *
//* APPLICATIONS USING THE DB MUST BE DOWN OR SUSPENDED BEFORE *
//* RUNNING THIS JOB, OR IT WILL FAIL. *
//* *
//* THIS JOB WILL: *
//* 1. TURN OFF ACCESS BY OTHERS TO THE DATABASE. *
//* 2. CLOSE THE DATABASE IN THE MUF. *
//* 3. INITIALIZE THE EXISTING INDEX. *
//* 4. RECREATE THE INDEX FROM THE EXISTING DATA FILES. *
//* 5. PRODUCE A REPORT OF THE DATABASE. *
//* 6. ALLOW ACCESS AGAIN TO THE DATABASE. *
//* *
//********************************************************************
//*
// SET CUS=YOUR DATACOM CUSLIB
// SET CAI=YOUR DATACOM CAAXLOAD or CABDLOAD
// SET CXX=YOUR CXX FILE NAME
//*
//* REBUILD INDEX, PRODUCE REPORT AND RESTORE DATABASE ACCESS
//*
//RETIX EXEC PGM=DBUTLTY,REGION=4M
//STEPLIB DD DISP=SHR,DSN=&CUS
// DD DISP=SHR,DSN=&CAI
//CXX DD DISP=SHR,DSN=&CXX
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ACCESS DBID=###,STATUS=OFF,USERS=FAIL
COMM DBID=###,OPTION=CLOSE
INIT DBID=###,AREA=IXX
RETIX DBID=###,OPTIMIZE=YES,SORT=999999999,SORTDFLT=YES,OPTION1='(I)'
COMM DBID=###,OPTION=STATS
REPORT DBID=###,AREA=CXX,TYPE=A
ACCESS DBID=###,STATUS=WRITE
/*
//
If the MUF is down when rebuilding the index change the SYSIN to the following:
//SYSIN DD *
SET OPTION1=MUF_NOT_ENABLED
INIT DBID=###,AREA=IXX
RETIX DBID=###,OPTIMIZE=YES,SORT=999999999,SORTDFLT=YES,OPTION1='(I)'
/*
Additional Information
- Here is a Comment from a level2:
"When the problem occurs a snap dump is taken. The next horizontal block is not in the dump, since we have never read it. Without seeing the full index, the dump is of limited value. If the problem can be recreated, saving a copy of the index before the load, to see if it is already corrupted, and if not to see the index after the load fails would be extremely helpful.
There is a documented DBUTLTY tool, DBIDCPR, which can be used to check the index prior to the load.
All of these are ways we would approach the problem if it is recreatable. "
Feedback
