Modifying Non-SQL Defined Databases › Changes to Schemas and Subschemas › Procedure for Modifying the Non-SQL Definitions

Procedure for Modifying the Non-SQL Definitions

Step 1: Copy the Original Schema and Global Subschema

1. Create a new schema which is identical to the original schema.
2. Create a global subschema for the new schema with a name which is different from that of any other subschema in the dictionary. Include in the subschema all areas, records, and sets associated with the schema.

Step 2: Modify the New Schema and Subschema

1. Make the necessary changes to the new schema definition.
2. Validate the schema.
3. Regenerate the global subschema, modifying it if necessary.

Step 3: Modify the Segment and DMCL, If Necessary

Note: You need to modify segments and DMCLs only if you add or remove an area or make other changes to the physical definition in addition to changing the schema.

1. Make the appropriate changes in the segment definition. Make sure that subareas and other symbolics are defined appropriately.
2. Generate, punch, and link all DMCLs containing the altered segment.

Step 4: Make Changes to the Data

Note: Not all schema changes require data changes. See Chapter 33, “Modifying Schema Entities” for the steps needed in each case.

1. Backup the area or files.
2. Use the appropriate utility or user-written program to change the data.
3. Verify the change using IDMSDBAN and/or a retrieval program, CA OLQ, or CA Culprit.
4. Backup the altered areas or files.

Step 5: Complete the Change

1. Update the original schema in the same way that the copy was changed.
2. Regenerate all subschemas associated with the original schema that are affected by the change, modifying them if necessary to add new areas, records, or sets.
3. Recompile all access modules affected by the change, using the ALTER ACCESS MODULE statement with the REPLACE ALL option.
4. Drop and recreate all SQL views affected by the change.
5. Make the new subschemas, DMCLs, and files available to your runtime environment.

Considerations

The procedure outlined above requires that changes first be made to a copy of the original schema and only after all other steps have been completed are the changes made to the original schema. This approach ensures that the original schema continues to describe the data until the altered areas are made available to the runtime environment. You should use this (or a similar approach) if during the process:

• CA OLQ, CA Culprit, or dynamic SQL users will be accessing the original schema definition
• Application programs will be compiled against the original schema and must access the data before it has been changed.

If the above is not a concern or if no data changes are necessary, then the initial modifications can be made to the original schema rather than a copy, avoiding the necessity of replicating those changes later.