Often not all the subschemas will be affected by schema changes. BCHANGE therefore copies the COSSD into the file COSSD.O at the beginning of restructuring so that all the old subschema information is retained despite the restructuring activity. If copying of the old subschemas is required, it is necessary to carry out a DDL compiler run to copy the old subschemas after BALTER has successfully terminated the restructuring phase.
During this run for copying the subschemas, the DDL compiler reads all the old subschemas from the file COSSD.O, recompiles them and then checks them for compatibility with the new schema. It differentiates between three possible results:
the old subschema description is incompatible with the new schema
the old subschema is incompatible with the new schema because of logical and/or physical changes in the schema, i.e. the execution of DML statements is affected
the old subschema is unaffected by changes in the new schema.
In the first two cases the DDL compiler does not store subschema information in either the DBCOM or the COSSD. Only in the third case, when a subschema is not affected by schema changes, does the computer copy the subschema from the COSSD.O, recompile it and enter the subschema information in the new DBCOM and in the new COSSD. For every subschema copied a new SSIA must be generated using the BGSSIA utility routine and entered in the DBDIR.
Please note that "compatibility" only means that the old subschema’s view of the new schema has remained the same as that of its view of the old schema. It does not mean, for example, that when the "COPY [ALL] RECORD[S]" clause is used the view of the (upwardcompatible) changes in the new schema is retained in the new schema. If you want to do this, you must recompile the subschema.
Figure 31: System environment for copying subschemas
The compiler run for copying compatible subschemas is optional; if omitted, all subschemas must be recompiled individually, and the corresponding SSIAs must be regenerated and entered in the DBDIR.
Subschema compatibility and incompatibility
schema-name and PRIVACY LOCK FOR COPY.....
A change of schema name and of PRIVACY LOCK specifications has no effect on copying the subschemas.
Such changes need only be taken into account when subsequent subschema compilations are carried out.
PRIVACY LOCK FOR COMPILE
In the compiler run for copying the subschemas, the DDL compiler copies these PRIVACY specifications from the old subschema description so that access locks for the compilation of application programs are retained.
identifier
An old subschema is incompatible with the new schema if an identifier has been added, deleted or renamed in the LOCATION MODE clause, the WITHIN clause (record type level) or the SET OCCURRENCE SELECTION clause, and the corresponding record type or set is present in the subschema.
Statements for copying subschemas
The DDL compiler requires the following statements to copy the subschemas:
Statement | Default value | Meaning |
| - | Initiates copying of subschemas |
| YES | Prints out subschema listing |
| NO | Diagnoses incompatibilities of old subschemas with the new schema and lists them in the form of error messages |
| - | Terminates entry of the statements |
Table 46: Statements for copying subschemas
Command sequence for copying subschemas
The following commands initiate a DDL compiler run for copying subschemas (see section "Compiling the Schema DDL"):
|
An SSIA must then be generated for each subschema copied and entered in the DBDIR (see section "Generating the Subschema Information Area (SSIA) with BGSSIA") using the following commands:
|