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

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

aus COMPUTERWOCHE Nr. 16 vom 20.04.1990

Die Entwicklung von Datenbank-Anwendungen 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.

Die Leistungsfähigkeit moderner PC-Hardware und der hohe Komfort der PC-Software lassen es für Anwendungsentwickler interessant erscheinen, Software nicht mehr in der teilweise schwerfälligen Großrechnerumgebung, sondern auf dem PC zu entwickeln, zu testen, um die Produktivität zu steigern.

Bei der Beurteilung, ob sich die Erstellung von Großrechnersoftware auf dem PC lohnt, muß zwischen Softwarehäusern und Anwendern unterschieden werden. Die Interessenlagen sind nämlich bei beiden verschieden. Bei Softwarehäusern muß außerdem noch differenziert werden, ob sie Standardsoftware erstellen und vertreiben oder Individualentwicklungen machen.

Für die Entwickler von Individualsoftware ist der PC-Einsatz von Vorteil, wenn sie dadurch Reisekosten sparen, sich von der teilweise fremden und starr organisierten Umgebung des Kunden über längere Zeit abkoppeln können und ihre Produktivität durch die besseren PC-Werkzeuge steigern. Dann kann auch ein kleiner Zusatzaufwand wegen der Anpassung an die Mainframe-Umgebung gut verkraftet werden.

Relationale Technik auf Mainframe und PC

Für die Anwender wird der Einsatz des PCs vor allem dann interessant, wenn sie Entwicklung und Wartung auf den PC verlagern können. Das setzt aber voraus, daß keine manuelle Bearbeitung beim Übergang vom PC zum Mainframe - oder auch umgekehrt - notwendig ist.

Kompatible Cobol-Compiler mit leistungsfähigen Debuggern,Emulatoren für TP-Monitore und ebenfalls für die alte hierarchische Datenbanktechnologie sind seit einiger Zeit auf dem Markt. Bei der Entwicklung zukunftsorientierter Datenbanken wird jedoch auch auf Mainframes verstärkt die relationale Technologie eingesetzt. Hier liegt es dank der Normung der SQL-Schnittstelle durch ANSI und ISO nahe, auf dem PC ein eigenständiges relationales System mit SQL-Schnittstelle laufen zu lassen.

Zwar kennt der Standard keine Festlegung von ESQL (Embedded SQL), sondern wählt das Konzept einer "Module Language", um Konflikte mit den Normen der Wirtssprachen, zum Beispiel Cobol, zu vermeiden. Doch sind die Konstrukte der Module eine gewollte Grundlage für die ESQL, wie sie im Anhang zum Standard als Vorschlag für einige Programmiersprachen enthalten sind.

Dynamic SQL gehört ebenfalls nicht zum Standard und ist meiner Meinung nach auch für die normale Anwendungssentwicklung nicht relevant - es sei denn für Dialgmonitor oder universelle Endbenutzer-Schnittstellen zu SQL. Neben DB2 verfügt auch Oracle über solche Funktionen, aber bei aller Ähnlichkeit müssen doch auch die feinen Unterschiede beachtet werden.

Im Gegensatz zur ANSI-Norm ist es in den echten relationalen Systemen auch möglich, Befehle zur Datendefinition über ESQL abzusetzen. Das entspricht den ursprünglichen Prinzipien einer einheitlichen Sprache zur Datenmanipulation und -definition. Außerdem darf auf diese Weise jeder Befehl, der am Terminal benutzt werden kann, auch im Anwenderprogramm erscheinen.

Dagegen setzt der ANSI-Ausschuß das Prinzip der Trennung von Anwenderprogrammierung und Datenbankadministration; er grenzt DDL-Befehle von den anderen ab und läßt sie somit auch nicht mehr in den Anwendungsprogrammen zu. Damit trägt die Regelung nach ANSI wohl den Erfordernissen der professionellen Anwendungsentwicklung und des organisierten DV-Betriebes Rechnung.

Die Datenbank-Management-Systeme, die erst nachträglich eine SQL-Schnittstelle erhielten - wie zum Beispiel Adabas - erlauben keine DDL-Befehle in ihrem SQL-Dialekt. Also dürfen in portablen Anwendungsprogrammen auch keine DDL-BEfehle - nicht einmal zum Einrichten temporärer Tabellen - vorkommen.

Rollback-Funktion darf nicht unterschätzt werden

Unsere Erfahrungen beruhen auf dem Einsatz von Oracle, DB2 und Adabas mit seiner SQL-Schnittstelle AdaSQL. Auf dem PC benutzten wir Oracle - zusammen mit einem Cobol-Compiler und einer CICS-Emulation von Realia. Oracle ist eines der wenigen echt relationalen Systeme auf dem PC; es verfügt über einen Precompiler für Cobol (Pro*Cobol) und besitzt auch auf dem Microcomputer grundlegende Sicherheitsmechanismen.

So wird die Datenbank auf Anforderung oder nach Programm- und Systemabbrüchen durch einen Rollback wieder in einen konsistenten Zustand versetzt. Die letztgenannte Eigenschaft sollte nicht unterschätzt werden, da sie auch im Test auf dem PC eine große Hilfe ist.

Wer nun glaubt, dank des SQL-Standards oder der von den Herstellern diverser Produkte immer versprochenen DB2-Kompatibilität könnten problemlos portable Programme erstellt werden, irrt sich leider: Es gibt eine Fülle von kleinen Abweichungen oder individuellen Ergänzungen, die man kennen muß, damit es bei der Portierung keine böse Überraschung gibt.

Hier nun einige Kostproben der Probleme, die schon vor Beginn der Programmerstellung erkannt und gelöst werden müssen: Während DB2 und Oracle die Norm bei den ausfahrenden SQL-Befehlen erfüllen, besitzt AdaSQL auch hier einige gravierende Abweichungen; der Befehl selbst wird nicht durch EXEC SQL, sondern durch EXEC ADABAS eingeleitet.

Die Norm wird nicht überall erfüllt

Spezifische Befehle können explizit durch Schlüsselwörter wie READ PHYSICAL SEQUENCE, READ LOGICAL SEQUENCE oder READ ISN vorgegeben werden. Ohne eigene Angabe wird ein FIND unterstellt. Deshalb gibt es auch zu AdaSQL keinen Optimizer, wie die rein relationalen Systeme ihn haben.

Daß dies neben Nachteilen wie der geringeren Datenunabhängigkeit auch Vorteile hat, ist wohl jedem DV-Profi klar: Durch Vorgabe des Zugriffsweges, kann die Performance direkt beeinflußt werden, ohne daß bei einem Release-Wechsel ein abweichendes Verhalten des Optimizers zu befürchten. Die Parameter, die ein Adabas-Befehl über die in Standard-SQL vorgesehenen hinaus benötigt, werden durch das Schlüsselwort OPTIONS eingeleitet. Der FETCH-Befehl von Ada-SQL verfügt nicht über eine INTO-Angabe, mit der in SQL üblicherweise angegeben wird, wohin die zu lesenden Datenbankfelder zu übertragen sind. Adabas überträgt diese Felder immer in eine Struktur, die der Vorübersetzer automatisch aus dem Dictionary "Predict" ins Programm kopiert. Das ist sicher recht komfortabel, hat aber den Nachteil der Starrheit.

(wird fortgesetzt)