Reorganizing a dictionary
When reorganizing a dictionary, the source and target subschemas are always the same and are determined by the areas of the dictionary being reorganized.
Before reloading the DDLCATLOD area in a segment defined for SQL, you must install stamps either by formatting by area or using the INSTALL STAMPS utility.
REORG an ASF database
If you want to run the REORG utility against an ASF data or definition area, see the CA IDMS ASF User Guide for more information. The CA IDMS ASF User Guide refers specifically to the UNLOAD and RELOAD utilities for unloading and reloading an ASF database, but REORG may be substituted for UNLOAD/RELOAD in this case.
Logically deleted records
You must remove any logically deleted records from the areas being unloaded before executing the REORG utility. To determine if an area has logically deleted records, use PRINT SPACE with the FULL option. If logically deleted records exist, use the CLEANUP utility to remove them from the area.
SQL-defined databases and synchronization stamps
Area and table synchronization stamps in SQL-defined segments are unloaded and reloaded by the REORG utility. For this reason, you must format the target areas using the FILE option so that the format operation does not also store synchronization stamps.
The one exception to this is when unloading and reloading the DDLCATLOD area in a segment defined for SQL. In this case, use the AREA option of the FORMAT statement or use the INSTALL STAMPS utility so that the format operation stores synchronization stamps.
Cross area dependencies
Areas that have physical connections to the areas being reorganized are referred to as dependent areas. You can reorganize an area that has physical connections to other areas without also unloading and reloading its dependent areas. Physical connections include:
The REORG utility keeps track of the inter-area linkages and rebuilds them during the RELOAD phase. For this reason, not only must the target areas be updatable by REORG, but their dependent areas must also be updatable.
Cross segment dependencies
A source area can have physical connections to an area in another segment. To reorganize all related areas, the DBNAME setup option must be used, and it must include all segments with physical connections. When the SEGMENT setup option is used, only areas in the name segment can be reorganized. Areas in connected segments will be processed as dependent areas. Their pointers will be adjusted, but they will not be reorganized. To use the SEGMENT option, the segment named on the setup clause of the REORG statement must also be the name of a DBNAME that includes both the source segment and all segments whose areas are physically connected to the areas being reorganized.
A target area can have physical connections to an area in another segment. To reorganize into such an area, the INTO clause of the REORG statement must identify a DBNAME whose segments include all of the target areas and all of their dependent areas.
Mixed page groups
Mixed page groups are supported. A source DBNAME may include segments with different page-group and different maximum records-per-page values. A segment may have physical connections to segments with a different page-group and/or maximum records-per-page value. Cross segment chained sets must have the same page-group and maximum records-per-page.
Ignoring the order of CALC duplicates
By default, when REORG unloads a CALC record for which duplicates are allowed, it preserves the order of duplicate entries by walking the CALC set in a prior direction and determining the relative position of the record with respect to others with the same CALC key value.
This processing can result in significant overhead. If preserving the order of duplicate entries is not important, you can eliminate this processing by turning on the OPT00093 bit in the RHDCOPTF module.
Processing of DIRECT records
Because DIRECT records have been placed on a specific page by a user, the REORG utility may have difficulty in determining where they should be placed in the target area. If a DIRECT record's old page exists in its target page range, REORG attempts to place the occurrence on the same page. However, if the old page does not exist in the target page range, the record is stored in the target area proportionally to its position in the source area.
If this is not acceptable, you may need to write a user-written program to unload the database and the FASTLOAD utility to reload it.
DCMT VARY PERMANENT considerations
If you run the REORG utility to change an area's low page number and Change Tracking is not used, it is recommended that you remove any permanent status on the affected area before making the new DMCL active within the CV.
When Change Tracking is not used, the PERMANENT feature is implemented by carrying the area's low page number in the journals across cycles of the CV. Changing an area's low-page prohibits future cycles of the CV from properly identifying the area once the new page range is implemented.
If a DCMT VARY SEGMENT/AREA PERMANENT command is still in effect when the new page range is implemented, the area's usage-mode at startup is determined by the value specified in the DMCL. The entry in the journals for the old area's page range remains until the next format of the journals.
The journal entry for the old starting page can be removed without formatting the journal by doing a non-permanent DCMT VARY AREA command against the area prior to changing the DMCL definition in the CV.
|
Copyright © 2014 CA.
All rights reserved.
|
|