Concepts › CA IDMS/DB Reorg Reorganization Capabilities › Reorganization Capabilities Controlled by Subschema and DMCL Definition

Reorganization Capabilities Controlled by Subschema and DMCL Definition

Many reorganization capabilities depend on how you have defined the new subschema and DMCL. During reorganization, CA IDMS/DB Reorg compares the area, set, index, and record definitions in the new subschema with those in the old subschema. After comparing the old subschema with the new subschema, CA IDMS/DB Reorg has the capabilities to:

• Expand/reduce the page range of one or more areas of the database. This special feature makes the database adaptable to changes in area size triggered by database growth. When an area needs to be enlarged, you can easily add pages to an area by defining a larger area in the definition of the DMCL.
• Expand/reduce an area's page size. CA IDMS/DB Reorg bases the SMP interval on the page size in the new DMCL. This feature eliminates the need for the area's SMP page interval to reflect the SMP interval with which the area was initialized.
• Change record's page range. CA IDMS/DB Reorg automatically changes a record's page range when you reorganize an area.
• Update cross-area set linkage. You can reorganize a single area--even if it has set linkage with other areas in the database. CA IDMS/DB Reorg determines from the subschema which sets point outside of the area being reorganized and updates the set linkage in these other areas. With CA IDMS/DB Reorg, you do not have to reorganize areas that have set linkage with the area being reorganized. (When using utilities where reorganization of linked areas is required, often a "snowball effect" occurs and the entire database ends up being reorganized.)
• Integrate integrated indexes. CA IDMS/DB Reorg updates the index table entries for all indexes whose member records are reorganized. Just as reorganization of areas containing members or owners of sets whose set linkage crosses area boundaries does not require reorganization of each linked area, CA IDMS/DB Reorg does not require reorganization of the index area just because you reorganized the member record's area. CA IDMS/DB Reorg allows you to copy only two areas of the database and it optionally changes the page ranges of both areas.

  Changing the Page Range of Two Areas:

• Eliminate logically deleted records. When CA IDMS logically deletes records, the data is removed from a record, but the prefix remains intact. CA IDMS/DB Reorg automatically deletes logically deleted records (LDELs) in areas that are being copied. This means that you do not have to use another utility to eliminate logically deleted records prior to using CA IDMS/DB Reorg.
• Expand/reduce the number of index table entries. CA IDMS/DB Reorg allows the SR8 record type to change its record size (a change in record size is otherwise considered to be a restructure feature and is not allowed). Changing the size of an SR8 record by changing the INDEX BLOCK CONTAINS value in the subschema gives you control over the number of levels required to build an index. This change to the subschema does not require recompilation of any programs.
• Move a record type to another area. For performance, backup, or security purposes, you can direct CA IDMS/DB Reorg to move a record type to a different area. This is done by changing the record's WITHIN clause in the new subschema's schema and reorganizing both the record's old area and new area.
• Change a record's location mode. By analyzing statistics from the CA IDMS Journal Analyzer and CA IDMS/DB Analyzer, you may determine that VIA records would be in better locations if they were clustered around a different owner. CA IDMS/DB Reorg also allows you to change a record's current location mode to or from DIRECT, CALC, or VIA. However, because CA IDMS/DB Reorg does not compress or decompress records, the control length of variable or fixed compressed records must not change.
• Optimize VIA records. CA IDMS/DB Reorg reclusters VIA set occurrences so that VIA members are stored physically in set order. This reduces the number of I/Os required to walk the set.