Anwendungsentwicklung für den Mainframe auf dem PC (Teil 2)

Trotz SQL-Standard: Portable DB-Entwicklung bleibt schwierig
von Heinz Axel Pürner, Unternehmensberatung Pürner in Dortmund

aus COMPUTERWOCHE Nr. 17 vom 27.04.1990, siehe auch: Teil 1

Die Entwicklung von Datenbankanwendungen für den Mainframe auf dem PC hat eine Reihe von Vorteilen; aufgrund der verschiedenen Implementierungen des SQL-Standards ist sie jedoch nicht ganz unproblematisch und erfordert in jedem Fall Nachbesserungen. Heinz Axel Pürner* berichtet von seinen Erfahrungen.

Während der Standard ein einziges Datenfeld zur Kommunikation zwischen DBMS und Programm - SQLCODE - festlegt, stellen Oracle und DB2 darüber hinaus noch den Bereich SQLCA zur Verfügung.

Für das Feld SQLCODE legt ANSI fest:

Datentyp: PIC S9(4) comp
Wertebereich: = 0 - alles o. k.
< 0 - Fehler
+ 100 - Ende bzw. nicht gefunden

DB2 stimmt mit dem definierten Wert + 100 überein, Oracle setzt hierfür den Wert 1403. Für portable Programme ist also tunlichst mit der Vereinbarung WHENEVER NOT FOUND zu arbeiten. Es ist natürlich auch zu fordern, daß in Oracle der Code angepaßt wird.

Mit der WHENEVER-Vereinbarung können Fehlerbehandlungen bestimmt werden. Die Vereinbarung wird vom Preprocessor umgesetzt in IF ... GO TO ...-Befehle, die er an jeden ausführbaren SQL-Befehl anschließt. Nach ANSI gibt es für WHENEVER die Bedingungen NOT FOUND und SQLERROR; Oracle und DB2 kennen darüber hinaus noch SQLWARNING. Wegen der unterschiedlichen Art der Fehlerbehandlung, kann auf die WHENEVER-Anweisung in portablen Programmen nicht verzichtet werden.

Besonders ärgerlich ist die Fehlerbehandlung in AdaSQL gelöst. Es gibt kein dem SQLCODE entsprechendes Feld. Das Feld ADACODE wird nur als EOF-Anzeiger genutzt; ansonsten müssen tabellenspezifische Felder auf den Return-Code hin abgefragt werden. WHENEVER-Vereinbarungen sind ebenfalls nicht vorhanden. Also muß die Fehlerbehandlung in AdaSQL dringend an die Vorgaben des Standards angepaßt werden.

Die lästigen Abweichungen zwischen DB2, Oracle und dem Standard liegen im Bereich der Deklarationen: Bis einschließlich Version 2.1 kennt DB2 noch keine SQL-Declare-Section, einen durch SQL-Anweisungen gekennzeichneten Bereich zur Deklaration der Host-Variablen. Außerdem ist für Änderungen im DECLARE CURSOR .. FOR noch die Angabe FOR UPDATE OF mit der Aufzählung der Spalten notwendig. Oracle kennt diese Angabe zwar auch, benötigt sie aber nicht. Besser wird dies erst mit dem Einsatz von Version 2.2, in der der Precompiler durch den Parameter STDSQL( ) dahingehend gesteuert werden kann, Standard-SQL oder den alten IBM-Dialekt zu akzeptieren.

Weitere Unterschiede gibt es bei den Datentypen, die die Systeme kennen. Das schlägt dann auf die Anwendungsprogramme durch, wenn die Wandlung von DBMS-internen Datentypen in Cobol-Datentypen zu unterschiedlichen Ergebnissen führt. Analoges gilt auch für unterschiedliche Programmiersprachen, da hier ebenfalls vom internen Datentyp auf den der Wirtssprache gewandelt werden muß und die Güte der Wandlung von der Analogie der beteiligten Datentypen abhängt, die je nach Wirtssprache unterschiedlich sind.

Auch die Namen der Tabellenspalten unterliegen bei DB2 und Oracle einerseits und Adabas andererseits unterschiedlichen Konventionen. Die relationalen Systeme erlauben nicht die Verwendung des in Cobol so beliebten Bindestrichs. Adabas hält sich hier dagegen an diese Cobol-Konvention.

Unterschiedliche Autorisierungskonzepte

Schwierigkeiten haben die älteren, nicht-relationalen Systeme auch mit dem NULL-Wert: Die explizite Implementierung des Wertes "unbestimmt" ist dort nicht vorgesehen. Obwohl Adabas nicht-belegte Felder - im Gegensatz zu DB2 - bei der Speicherung unterdrücken kann und somit gute Voraussetzungen für ein NULL-Handling besitzen sollte, können in AdaSQL keine NULL-Werte verarbeitet werden.

Ein weiterer wichtiger Unterschied zwischen DB2 und Oracle liegt in den unterschiedlichen Autorisierungskonzepten: In DB2-Programmen existieren hierfür keine Befehle, da die Berechtigungsprüfung außerhalb der Programmlogik durchgeführt werden kann. In Oracle-Programmen hingegen muß sich das Programm durch den CONNECT-Befehl explizit anmelden und durch ein COMMIT RELEASE oder ROLLBACK RELEASE abmelden.

In DB2 sind CONNECT und RELEASE unbekannt. Wer also sein Programm mit Oracle entwickeln und testen und unter DB2 einsetzen will, muß vor dem Transfer auf dem Mainframe diese Befehle aus seinem Quellcode entfernen. COMMIT- oder ROLLBACK-Befehle - auch ohne den RELEASE-Parameter - sind für DB2-Programme unter CICS oder IMS/DC tabu: Hier dürfen nur die entsprechenden Befehle der TP-Monitore benutzt werden.

Die Liste der Abweichungen ließe sich noch mit vielen Details fortsetzen. Fazit: Es ist leider nicht so, daß ein auf dem PC erstelltes SQL-Programm ohne Nachbearbeitung auf dem Mainframe übersetzt und eingesetzt werden kann.

Zu den Abweichungen kommt hinzu, daß der Oracle-Precompiler Pro*Cobol auf dem PC noch einige Mängel und Fehler besitzt, die das Produkt eines renommierten Herstellers eigentlich nicht haben dürfte. Diese Fehler zu umgehen bedeutet zusätzlichen Aufwand, der nicht sein müßte. Falsche Fehlermeldungen führen obendrein unerfahrene Anwender in die Irre und kosten Zeit. Der Hersteller muß hier noch einiges zur Steigerung der Qualität des Precompilers tun.

Cobol-Compiler bereiten keine Probleme

Zum Glück sind die Unterschiede bei den anderen Softwarepaketen geringer und weniger sophisticated: Die Cobol-Compiler bereiten keine Schwierigkeiten; ärgerlich ist allerdings, daß bei Realia-Cobol, das auf dem PC eingesetzt wurde, noch kein EVALUATE verfügbar ist. Hervorzuheben bleibt allerdings die hohe Übersetzungsgeschwindigkeit des Compilers sowie der Debugger, der das gründliche Austesten der Programme auch von CICS-Programmen wesentlich vereinfacht.

Die CICS-Emulation von Realia erfüllte ihre Aufgabe fehlerlos und bot vom Leistungsumfang genug, um normale CICS-Anwendungen erstellen zu können. Daher gab es bei der Installation auf dem Großrechner auch hier keinerlei Probleme. Angenehm war es, die BMS-Maps auf dem PC interaktiv mit dem Maskengenerator erstellen zu können: So sieht der Entwickler gleich das Ergebnis seiner Definitionen und kann gegebenenfalls sofort Verbesserungen durchführen. Der Maskengenerator erzeugt die vertrauten BMS-Makros, die nach dem Transfer auf den Mainframe dort ohne weitere Eingriffe übersetzt werden können.

Unabdingbare Tools für die Nachbereitung

Wegen des komfortablen Arbeitsumfelds auf dem PC und der Unabhängigkeit von der DV des Kunden lohnt es sich trotz der Unterschiede, auf dem PC zu entwickeln und zu testen. Kennt der Entwickler nämlich die Portierungsprobleme, so kann er den Nachbereitungsaufwand planen und begrenzen.

Wenn noch ein Hilfsmittel, zum Beispiel ein Generator, zur Verfügung steht, um die verschiedenen Programmversionen für PC oder Mainframe zu erzeugen, so ist der Änderungsaufwand relativ gering. Ein solches Werkzeug ist aber auch die notwendige Voraussetzung, wenn ein Anwender neben der Entwicklung auch die Wartung der Software vom Mainframe auf den PC verlegen will: Für eine ordentliche Durchführung der Entwicklung und Wartung von Software ist es erforderlich, den Quellcode in einer zentralen Bibliothek zu verwalten.

Dort - und nur dort - sind die Programme nach Entwicklung, Test und Abnahme einzustellen und zur Pflege zu entnehmen, bevor sie auf den PC transferiert und im CICS-PC/Oracle-Umfeld geändert und getestet werden. Nach erfolgreicher Änderung ist die DB2-Version zu erzeugen, die Korrektheit zu verifizieren und das Programm nach einer Abnahme wieder in die Bibliothek zu stellen.

Ohne Hilfsmittel oder Werkzeuge besteht die Gefahr, daß das Mainframe-Programm und seine PC-Version sich im Laufe des Anwendungs-Lebenszyklusses auseinanderentwickeln: Jeder Entwickler wird den Nachbereitungsaufwand so klein wie möglich halten wollen und je nach Laune einmal die Mainframe-Version zur Pflege heranziehen, ein andermal die PC-Version, die er sich noch aufgehoben hat.

Das einfachste Hilfsmittel wäre ein Editor mit Prozeduren oder Makros, der die jeweils benötigte Programmvariante erzeugt. Komfortabler ist jedoch ein vollständiger Programmgenerator, der aus eigenem Quellcode die gewünschte Variante des Cobol-Programms erzeugt. Das Produkt Delta ist dafür ein bekanntes Beispiel, das sowohl auf Mainframes als auch auf dem PC läuft. Mit seiner Makrotechnik bietet der Generator auch die Möglichkeit, eigene Makros zu seiner Methodenbank hinzuzufügen und damit - durch Parameter gesteuert - verschiedene Programmvarianten zu erzeugen. Noch komfortabler und komplexer wäre der Einsatz einer Produktverwaltung, aus der heraus unterschiedliche Varianten und Versionsstände generiert werden können. Nur wenn entweder ein Generator oder eine Produktverwaltung eingesetzt werden, halten wir es derzeit für empfehlenswert, den PC in der Entwicklung und Pflege von Mainframe-Anwendungen einzusetzen.

Allerdings ist es auch ohne diese komfortablen Werkzeuge möglich, Prototypen für SQL-Anwendungen schnell auf dem PC zu erstellen oder die Anwendung erstmalig zu entwickeln. Von der Entwicklung pflegebedürftiger Anwendungen sollte jedoch aus den obengenannten Gründen Abstand genommen werden.

Das Ziel, durch die ANSI/ISO-Norm portable Datenbanken erstellen zu können, ist noch nicht erreicht. Es fehlt wohl noch der nötige Druck der Anwender auf die Hersteller. Mit der DB2-Option STDSQL() in der Version 2.2 hat IBM einen großen Schritt in Richtung Standard getan. Damit sollte auch die Akzeptanz der Norm beim Anwender wachsen.

Mit wachsender Akzeptanz des ANSI-Standards für SQL ist wiederum zu erwarten, daß die Übereinstimmung der Produkte wächst. Dadurch verringert sich natürlich der Portierungsaufwand für Programme, was ja das erklärte Ziel der Normung war. Ohne die lästige Nachbereitung wird sich das Entwickeln auf dem PC mit seinen komfortablen Werkzeugen bald durchsetzen.