Utility Statements › RESTRUCTURE › Usage

Usage

How to submit the RESTRUCTURE statement

You submit the RESTRUCTURE statement only through the batch command facility. When submitting RESTRUCTURE statements, you must run the batch command facility in local mode.

The base restructuring table

The RESTRUCTURE statement modifies record occurrences according to the specifications in a base restructuring table. You assemble the base restructuring table from IDMSRSTT macro statements that define the changes to be made. Typically, you use the IDMSRSTC utility to generate the IDMSRSTT macro statements; however, the statements can also be coded manually.

Note: For more information and a description about the IDMSRSTT macro statements, see IDMSRSTT Macro Statements.

The spill file

If you specify a set-name in the SETPTR statement of IDMSRSTT during RESTRUCTURE processing, a spill file of work records that describes new pointers being added to database records is generated. If the database restructure includes the addition of new prior pointers to existing sets, you use the spill file as input to the RESTRUCTURE CONNECT utility statement. The information in the spill file and the specifications in the base restructuring table are used during RESTRUCTURE processing to connect the new prior pointers.

Database keys of restructured records

During RESTRUCTURE processing all changes to the database are made in place (that is, no unload/reload occurs). As a result, database keys are not changed by a restructure operation.

Back up the database

Back up the database before performing a restructure operation. If the database restructure is unsuccessful, you can then restore the database from the backup copy.

Remove logically deleted records

You cannot use the RESTRUCTURE utility statement to make changes that will modify the prefix portion of a record if there are logically deleted records in the database area to be modified. To ensure there are no logically deleted records, use the CLEANUP utility to erase them before performing a restructure operation.

Restructure ready mode

All areas to be processed are readied in exclusive update mode for RESTRUCTURE processing.

Modifying CALC and sort keys

During a restructure operation, you should not modify CALC and sort keys.

Note: For more information about modifying database components, see the CA IDMS Database Administration Guide.

Native VSAM data sets

You cannot use RESTRUCTURE to restructure records in native VSAM data sets.

New pointers

New pointers in an owner record are initialized to the database key of the owner record (indicating an empty set). In a member record, new pointers are initialized to -1.

To connect new pointers for existing sets, use the RESTRUCTURE CONNECT utility statement. To connect pointers for new sets, you must run a user-written program after the restructure process is complete.

Consideration when using data compression routines

If the named subschema references a data compression routine and a compressed record is involved in the restructure (for example, changing the record to fixed length), the subschema will be modified. To modify the subschema, it must be nonreentrant. If necessary, relink the subschema as nonreentrant and run it from another load library.

If the subschema resides in a dictionary load area, this is not a consideration.

Restructuring a database

To restructure a database, follow these guidelines:

1. Back up the database.
2. Compile a new schema that describes the database after restructuring. The new schema must have a different name or version number from the schema that describes the existing database.
3. Execute the IDMSRSTC utility to generate the IDMSRSTT macro statements that define the changes to be made to the database. Verify that the statements are correct; make any necessary modifications.
4. Assemble the base restructuring table.
5. Link edit the base restructuring table.
6. Execute the RESTRUCTURE utility statement to restructure the database. Use a subschema that was compiled under the old schema.
7. Compile a subschema under the new schema. Give the new subschema a temporary name to distinguish it from the old subschema.

   If no new pointers have been added to existing sets, skip to step 10.

8. Execute the RESTRUCTURE CONNECT utility statement to connect the new prior or owner pointers for existing sets in the restructured database. Use a subschema that was compiled under the new schema.
9. Validate the restructure using IDMSDBAN, CA OLQ, CA Culprit, or some other retrieval program.
10. Recompile, under the new schema, all subschemas that use the changed records or sets.
11. Alter all access modules referencing changed records or owner and member records of changed sets.
12. Drop and recreate SQL views of records whose element descriptions have changed.