IDMS unload not unloading all records in an area
Article ID: 111566
Updated On:
Products
Issue/Introduction
After running the IDMS UNLOAD utility, it may appear that the unload did not unload all records in the requested area. Running the unload utility and comparing the record count from the PRINT SPACE utility that was run prior to the unload, may seem to indicate missing records. Using the RELOAD to load the data back, the utility loaded back all the unloaded data, without errors. Running PRINT SPACE again to get a breakdown of the actual record counts which were reloaded may seem to show many missing records when compared to the original PRINT SPACE. Running IDMSDBAN shows many broken chain messages.
Why would the IDMS Unload utility not unload all records in an area, yet not produce any errors, when IDMSDBAN does show errors?
Environment
Release: All supported releases.
Resolution
In the situation where this error occurred, the area being unloaded had no cross-area pointers. There was one CALC record in the area that owns a via set.
The UNLOAD utility will sweep the area unloading the CALC records when they are encountered. For each one, it will walk any sets owned by the CALC owner and any sets those members own. This means that no VIA records in the area will be unloaded by area sweep. All will be unloaded by walking sets from the CALC owner records.
When this situation occurs, no application programs encountered broken chain errors like 0361 and the UNLOAD also received no errors. These facts mean that if you chase any of the DBAN errors, you will find that every set is totally intact, when walked from the owner. That approach shows no bad pointers at all.
Research showed that the area contained many VIA records whose pointers indicated that they were at some point valid connected members in the mentioned VIA set, but they were not currently connected to any valid set owner.
PRINT SPACE does not walk sets as it doesn't use a subschema. It simply reads each page in an area and counts the records it finds on the pages. This would include all of the invalid "unconnected" VIA member records. This is why it showed different record counts than the UNLOAD - it uses a different mechanism to access the records.
Those "unconnected" VIA records were probably meant to be erased but something left them in a partially erased state. This is most likely the result of local mode update job(s) that were erasing records, but the job(s) did not complete successfully and the affected areas were not properly recovered. (For local updates, CV must be down or the areas varied offline, backup should be taken prior to the local batch update jobs and if the jobs do not complete normally the areas should be restored from the backup).
So, in this situation, research may show that the UNLOAD and RELOAD did indeed unload all of the CALC records and all validly connected members. The reloaded database should contain all valid records and DBA should investigate the reason for the database corruption. If a backup of the area exists from before the UNLOAD/RELOAD, an IDMSDBAN can be run against that backup and it will most likely show the same broken chains as the DBAN run afterwards.
Feedback
