von Birgitta Hauser

Warum eine Konvertierung auf IBM i wichtig ist und worauf man achten sollte! 

DDS (Data Description Specifications) war über Jahrzehnte das Standardwerkzeug zur Definition von physischen und logischen Dateien. Das Problem ist jedoch, dass DDS schon seit Release V5R3M0 stabilisiert ist, also nicht mehr weiterentwickelt wird. Auf der anderen Seite hat sich in SQL, sowohl in der Data Manipulation Language (DML), als auch in der Data Description Language, sehr viel getan. DDL ist heute der strategische Weg für die Weiterentwicklung moderner IBM-i-Datenbanken. 

Warum überhaupt von DDS nach DDL konvertieren? 

IBM entwickelt die Datenbank Db2 for i seit Jahren nur noch auf Basis von SQL weiter. Neue Datenbankfunktionen stehen ausschließlich für SQL-Objekte zur Verfügung.

Dazu gehören beispielsweise: 

• weitere Datentypen (Large Objects, Boolean) 
• Identity Columns und Sequenzen 
• Auditierungsspalten 

Andere Technologien wie Field Procedures und Row and Column Access Control (RCAC) können zwar auch für DDS beschriebene physische Dateien eingerichtet werden, 
jedoch ist beim Ändern oder Erweitern der physischen Dateien zusätzlicher manueller Aufwand notwendig. 

DDS wird zwar weiterhin unterstützt, erhält jedoch seit ReleaseV5R3M0 keinerlei funktionale Erweiterungen mehr. Wer seine Anwendungen langfristig zukunftssicher gestalten möchte, kommt an SQL DDL kaum vorbei. Im Gegenteil: Eine Konvertierung von DDS nach DDL ist der erste Schritt bei der Modernisierung der Datenbank.

Obwohl DDS beschriebene physische Dateien und SQL definierte Tabellen mit native I/O (in Cobol und RPG) als auch mit (embedded) SQL gleich verwendet werden können, gibt es einige Unterschiede.

Schlüssel in DDS beschriebenen physischen Dateien 

DDS beschriebene physische Dateien können mit oder ohne Schlüssel angelegt werden, während SQL beschriebe Tabellen immer ungeschlüsselt sind. 

Für DDS beschriebene physische Dateien können Primary und Unique Key Constraints definiert werden. Beide verhindern, dass doppelte Daten in die Datei eingefügt werden. Bei der Konvertierung von DDS nach DDL werden die eindeutigen Schlüssel aus der physischen Datei in eine PRIMARY KEY-Constraint konvertiert, während nicht-eindeutige Schlüssel verloren gehen.

Da pro Tabelle nur eine PRIMARY KEY Constraint definiert werden kann und man sich diese für einen (zukünftigen) künstlichen Schlüssel (Surrogate Keys) z.B. Identity Columns bewahren sollte, ist eine direkte Konvertierung nicht die beste Lösung, insbesondere, da nur eindeutige Schlüssel konvertiert werden können.

Empfehlung für bestehende Anwendungen 

Vor der eigentlichen Konvertierung sollte zunächst eine neue logische Datei (oder besser noch ein neuer SQLIndex) mit denselben Schlüsselspalten, wie die bestehende physische DDS-Datei erstellt werden. 

Anschließend werden alle Native-I/O-Zugriffe der Anwendung auf diese logische Datei bzw. den SQL umgestellt. 

Anmerkung: SQL Indices können mit native I/O genauso verwendet werden wie DDS beschriebene geschlüsselte logische Dateien. 

Dadurch kann die physische Datei später problemlos in eine SQL-Tabelle konvertiert werden, ohne dass sich die Zugriffslogik der Anwendung ändert.  

Diese Vorgehensweise reduziert das Migrationsrisiko erheblich und erleichtert spätere Datenbankanpassungen.

Ungültige numerische Werte in DDS beschriebenen physischen Dateien 

Ein großes Problem können ungültige numerische Daten darstellen. 

Zwischen DDS beschriebenen physischen Dateien und SQL definierten Tabellen gibt es einen kleinen, aber sehr entscheidenden Unterschied. Werden Daten in DDS beschriebene physische Dateien geschrieben, werden die Daten beim Schreiben nicht geprüft (unabhängig davon, mit welcher Methode die Daten geschrieben werden). Erst beim Lesen werden die Daten geprüft und ggf. konvertiert (also *Blanks in numerischen Spalten in Nullen).

Werden Daten in SQL beschriebene Tabellen geschrieben, werden diese vor dem Schreiben geprüft. Bei ungültigen bzw. unzulässigen Daten erfolgt ein Abbruch. Da die Daten bereits beim Schreiben geprüft werden, erfolgt beim Lesen keine Prüfung mehr. Das bedeutet, das Schreiben in SQL-Tabellen ist langsamer, während das Lesen aus SQL-Tabellen schneller ist, verglichen mit den gleichen Aktionen für DDS-beschriebene physische Dateien.

Geht man davon aus, dass es sich bei ca. 80% der Daten-Operationen um Lesen und nur bei ca. 20% um Schreiben handelt, hat man durch die Tatsache, dass beim Lesen aus SQL-Tabellen keine Prüfung erfolgt, bereits einen kleinen Performance-Vorteil.  

Enthält eine DDS beschriebene physische Datei ungültige numerische Daten, erfolgt bei der Konvertierung in eine SQL-Tabelle ein Abbruch beim ersten ungültigen Wert. Die folgenden Daten gehen u. U. verloren.

Deshalb gilt: 

Vor jeder Konvertierung sollten die Daten in den zu konvertierenden Tabellen auf ungültige numerische Werte geprüft und bereinigt werden. 

Eine sorgfältige Datenbereinigung vor der Konvertierung ist unbeding erforderlich, wenn man Abbrüche und Datenverluste vermeiden will.  

IBM stellt zur Prüfung von ungültigen numerischen Daten in der Bibliothek SYSTOOLS mehrere Services zur Verfügung (VALIDATE_DATA, VALIDATE_DATA_FILE, VALIDATE_DATA_LIBRARY).  

Ebenso sollten die Programme dahingehend geprüft werden, ob sie ggf. ungültige numerische Werte (z. B. durch eine nicht initialisierte Datenstruktur) produzieren. Ohne entsprechende Überarbeitung und Korrektur schlagen die Programme nach der Umstellung bei ungültigen numerischen Werten auf.

DDS Schlüssel-Worte 

DDS bietet zahlreiche feldbezogene Schlüsselwörter, die teilweise seit Jahrzehnten in Anwendungen verwendet werden. In SQL gibt es dafür keine direkte Entsprechung. 

Typische Beispiele sind DATFMT/TIMFMT oder EDTCDE/EDTWRD. 

Diese Schlüssel-Worte steuern ausschließlich die Anzeige bzw. Aufbereitung numerischer Werte und sind kein Bestandteil der eigentlichen Daten. Ursprünglich wurden diese Schlüssel-Worte verwendet, um numerische Werte, z. B. numerische Datums- und Zeitwerte aufzubereiten, damit sie in DDS beschriebenen Display Files oder CL-Befehlen z.B. WRKF einfach gelesen werden konnten.  

SQL DDL trennt Daten und Darstellung konsequent voneinander. Deshalb gibt es keine entsprechenden Schlüssel-Worte. Datenaufbereitungen können in SQL mit skalaren Funktionen (z.B. VARCHAR_FORMAT) durchgeführt werden. 

Erstellt man das SQL Script mit Reverse Engineering (ACS – Access Client Solutions oder der Stored Procedure GENERATE_SQL), werden für nicht unterstützte Schlüssel-Worte entsprechende Kommentare eingefügt. Die einzelnen Schlüssel-Worte bzw. die entsprechenden Display-Files und Programme müssen dann einzeln geprüft werden.

Konvertierung von DDS nach DDL ist der erste Schritt bei der Datenbanken-Modernisierung 

Die Umstellung von DDS auf DDL sollte nicht nur als technische Konvertierung verstanden werden, sondern als erster Schritt!

Nach der Konvertierung können alle SQL Erweiterungen genutzt werden. 

Sie bietet die Gelegenheit – Schritt für Schritt:

Wer die Migration sorgfältig vorbereitet und die Unterschiede zwischen DDS und SQL berücksichtigt, erhält nicht nur eine modernere Datenbankstruktur, sondern schafft auch die Basis für wartbare und zukunftssichere IBM-i-Anwendungen. Sofern im ersten Schritt lediglich eine Konvertierung von DDS nach DDL erfolgt, also keine zusätzlichen Spalten eingefügt werden oder vorhandene Spalten geändert werden, ist noch nicht einmal eine Neu-Compilierung der RPG/Cobol-Programme mit native I/O erforderlich. 

Fazit 

Die Konvertierung von DDS nach SQL DDL ist heute ein wichtiger Schritt auf dem Weg zur Modernisierung von IBM-i-Anwendungen. Erfolgreich wird sie jedoch nur, wenn nicht ausschließlich die Syntax, sondern auch das zugrunde liegende Datenmodell betrachtet wird. 

Besondere Aufmerksamkeit verdienen bestehende Zugriffspfade, der sinnvolle Einsatz von Primary Keys, die Bereinigung historischer Datenbestände sowie die Ablösung DDS-spezifischer Schlüsselwörter durch moderne SQL- und Anwendungsfunktionen. Wer diese Punkte berücksichtigt, schafft eine solide Grundlage für zukünftige Erweiterungen und nutzt die Möglichkeiten der Db2 for i deutlich besser aus, als dies mit klassischen DDS-Dateien möglich ist.