Guidelines for unload/reload where there are dependent areas and/or indexes

Products

• IDMS
• IDMS - Database

Issue/Introduction

Unload/reload is often run against an area which may contain cross-area pointers. Similarly, a user- or system-owned index may reference a record in an area being processed with unload/reload. This document addresses various questions about how this is handled.

Environment

Release: All supported releases.

Resolution

In designing a database, it is not unusual for the records in one area to be connected by sets to records in other areas. When performing an unload/reload, the utility notices these cross-area pointers and points them out in the AREA RECORD DEPENDENCY TABLE in the UNLOAD output report.

All areas which are related in this way to the area being unloaded are called dependent areas.

All areas that have set connections to records in the area being unloaded must be defined in the subschema and DMCL(s) specified in the UNLOAD, and must be available for update by the UNLOAD and RELOAD jobs, but those dependent areas do not also need to be unloaded and reloaded. When the utility runs, it may update pointers in these dependent areas if necessary, but it will not perform a full unload/reload of them.

If the cross-area pointers are for member records stored VIA an owner record that resides in the area being reloaded, performance degradation may occur in applications when accessing these member records until the member area is processed as well.

Since only the named area(s) will actually experience a full RELOAD, only those areas need to be processed with a FORMAT between the UNLOAD and the RELOAD.

For indexes, the extent to which the sets in dependent areas are updated is complete: the reload step IDMSDBL3 will rebuild system-owned and user-owned indexes completely as part of the RELOAD process, even if they are in a dependent area. The only caveat to this is that it will rebuild them as they are, so if there is any corruption in those indexes, that should be corrected before running UNLOAD/RELOAD. The UNLOAD/RELOAD will adopt orphans - it just won't fix any broken chains (bad pointers) in the index records, should those exist.

If a RELOAD does not complete successfully, the area(s) that are named in the UNLOAD/RELOAD as well as all dependent areas should be restored.

There is no way to know for certain whether or not updates occurred in the dependent areas, or to what extent, which is why they should be restored.