Oft sind nicht alle Subschemata von den Änderungen des Schemas betroffen. Daher kopiert BCHANGE zu Beginn der Umstrukturierung den COSSD in die Datei COSSD.O, sodass trotz Umstrukturierung noch alle alten Subschema-Informationen vorhanden sind. Wollen Sie diese alten Subschemata übernehmen, so müssen Sie, nachdem BALTER die Umstrukturierungsphase erfolgreich abgeschlossen hat, mit dem DDL-Compiler einen Lauf zum Übernehmen der alten Subschemata durchführen.
Bei dem Compilerlauf zum Übernehmen der Subschemata liest der DDL-Compiler aus der Datei COSSD.O alle alten Subschemata aus und prüft sie durch Neuübersetzen auf Verträglichkeit mit dem neuen Schema. Dabei unterscheidet er drei Fälle:
die alte Subschema-Beschreibung ist mit dem neuen Schema unverträglich
das alte Subschema ist auf Grund von logischen und/oder physischen Veränderungen im Schema mit dem neuen Schema unverträglich, d.h. die Ausführung von DML-Anweisungen ist betroffen
das alte Subschema ist von Änderungen im neuen Schema nicht betroffen
In den ersten beiden Fällen legt der DDL-Compiler weder im DBCOM noch im COSSD Subschema-Information ab. Nur im letzten Fall, wenn ein Subschema nicht von den Schemaänderungen betroffen ist, übernimmt er es aus der Datei COSSD.O, compiliert es neu und trägt die Subschema-Information in den neuen DBCOM und in den neuen COSSD ein. Für jedes übernommene Subschema müssen Sie anschließend mit dem Dienstprogramm BGSSIA eine neue SSIA generieren und diese im DBDIR eintragen.
Beachten Sie bitte, dass "Verträglichkeit" nur bedeutet, dass die Sicht des alten Subschemas auf das neue Schema die gleiche geblieben ist wie auf das alte Schema. Es bedeutet nicht, dass etwa bei Verwenden der "COPY [ALL] RECORD[S]"-Klausel automatisch die Sicht auf die (aufwärtskompatiblen) Änderungen im neuen Schema gewährt wird; möchten Sie diese erlangen, müssen Sie das Subschema neu übersetzen.
Bild 31: Systemumgebung beim Übernehmen der Subschemata
Den Compilerlauf zum Übernehmen der kompatiblen Subschemata können Sie wahlweise durchführen; lassen Sie ihn weg, so müssen Sie alle Subschemata einzeln neu übersetzen und die jeweilige SSIA neu generieren und in das DBDIR eintragen.
Verträglichkeiten/Unverträglichkeiten der Subschemata
schemaname und PRIVACY LOCK FOR COPY.....
eine Änderung des Schemanamens und der PRIVACY LOCK-Angaben wirkt sich nicht auf das Übernehmen der Subschemata aus!
Diese Änderungen müssen Sie erst bei nachfolgenden Subschema-Übersetzungen berücksichtigen.
PRIVACY LOCK FOR COMPILE
bei dem Compilerlauf zum Übernehmen der Subschemata kopiert der DDL-Compiler diese PRIVACY-Angaben aus der alten Subschema-Beschreibung, sodass Zugriffssperren für das Übersetzen von Anwenderprogrammen erhalten bleiben.
bezeichner
nicht verträglich ist ein altes Subschema mit dem neuen Schema, wenn Sie in der LOCATION MODE-Klausel, der WITHIN-Klausel (Satzartebene) oder der SET OCCURRENCE SELECTION-Klausel einen bezeichner hinzugefügt oder gelöscht oder den bisherigen bezeichner umbenannt haben, sofern die entsprechende Satzart bzw. der Set in dem Subschema liegt.
Anweisungen zum Übernehmen der Subschemata
Der DDL-Compiler benötigt zum Übernehmen der Subschemata folgende Anweisungen:
Anweisung | Standardwert | Bedeutung |
| - | Übernehmen der Subschemata veranlassen |
| YES | Listing der Subschemata ausdrucken |
| NO | Unverträglichkeiten der zum neuen Schema inkompatiblen Subschemata diagnostizieren und in Form von Fehlermeldungen auflisten |
| - | Eingabe der Anweisungen beenden |
Tabelle 46: Anweisungen zum Übernehmen der Subschemata
Kommandofolge für das Übernehmen der Subschemata
Mit folgenden Kommandos können Sie einen DDL-Compilerlauf zum Übernehmen der Subschemata starten (siehe Abschnitt „Schema-DDL übersetzen"):
|
Für jedes übernommene Subschema müssen Sie mit folgenden Kommandos anschließend die SSIA erzeugen und im DBDIR eintragen (siehe Abschnitt „Subschema Information Area (SSIA) erzeugen mit BGSSIA"):
|