*Dipl. Inf. Horst Schwarz ist Leiter der Software-Entwicklung der Gesellschaft für Computeranwendungen mbH, Linz.

Die Entwicklung von Großrechnersoftware, insbesondere Software für IBM-Großanlagen, kann bereits heute auf komfortablen PCs oder Workstations durchgeführt werden und wird sich in der nächsten Zeit zunehmend dorthin verlagern. Horst Schwarz* zeigt die Entwicklung von DB2-kompatiblen Applikationen am PC.

Während seit etwa drei Jahren leistungsfähige PC-Systeme zur Simulation von Großrechnerdialogsystemen wie CICS, Datenzugriffsmethoden wie VSAM oder Cobol-Sprachübersetzer mit voller IBM-Großrechnerkompatibilität verfügbar sind waren Möglichkeiten zur Nachbildung leistungsfähiger Mainframe-Datenbanksysteme, wie zum Beispiel DB2, am PC bisher nicht bekannt.

Durch das Aufkommen relationaler Datenbanksysteme am PC, deren Leistungsumfang im Grundsätzlichen dem von Großrechnersystemen kaum mehr nachsteht, ist es möglich geworden, nun auch am PC Anwendungsprogramme mit Datenbankzugriffen zu entwickeln, auszutesten und zu betreiben, die in praktisch unveränderter Form auf den Großrechner übertragen werden können.

Voraussetzung ist eine fast adäquate PC-Datenbank

In diesem Zusammenhang muß die besondere Bedeutung der Erhebung von SQL zur Norm einer Datenmanipulationssprache für relationale Datenbanksysteme betont werden.

Im folgenden werden praktische Beispiele vorgeführt, in denen die benutzten Werkzeuge wie Realia-Cobol, CICS-PC, VSAM-PC, Professional Oracle, PRO*Cobol-Precompiler und Testhilfen wie Realdeburg (Source-level-debugger) "live" in ihrem Zusammenwirken gezeigt werden. Darüber hinaus wird eine Möglichkeit zur Entwicklung einer echt" verteilten Anwendung mit Datendurchgriff vom PC auf den Host vorgestellt.

Die Beispiele können als Beweis dafür gelten, daß es möglich ist, die Anwendungsentwicklung von Datenbankapplikationen - selbst bei Verwendung so mächtiger Datenbank-Systeme wie DB2 - erfolgreich auf den PC zu verlagern.

Bereits heute lassen sich alle praxisgerechten Applikationen für Großrechner unter Cobol, CICS und VSAM vollwertig auf dezentralen PC-Arbeitsplätzen entwickeln, testen und unter Umständen sogar betreiben. Ein Datenbankbeispiel zeigt, wie auch dafür Entwicklungsleistungen auf Workstations verlagert werden können.

Um die Anforderungen möglichst hoch zu schrauben, wird hierbei das IBM-Datenbanksystem DB2 als Zielsystem angesehen und stellvertretend für eine Klasse von (Großrechner- )Datenbanken betrachtet, welche auf dem relationalen Datenmodell aufbauen. Der Anspruch, auf einem PC die Leistungen des Systems DB2 nachbilden zu können, kann nur verwirklicht werden, wenn man über eine annähernd adäquate PC-Datenbank verfügt, die eine möglichst übereinstimmende Dialogoberfläche und einen entsprechenden Sprachumfang besitzt. In diesem Zusammenhang erlangen das Relationale Datenbanksystem "Professional Oracle" und der Sprachstandard SQL herausragende Bedeutung.

Bereits 1974 wurden von IBM im San Jose Research Laboratory Untersuchungen angestellt, wie das relationale Datenmodell praktisch genutzt werden kann. Die Ergebnisse dieses "System R" genannten Projekts waren:

- SQL (Structured Query Language)

- Query-Compilierung und Optimierung

- Integration von SQL in prozedurale Sprachen

1979 wurde aus diesem wissenschaftlichen Projekt ein kommerzielles Datenbanksystem geformt, welches als "SQL/Data System" für Rechner der mittleren Datentechnik konzipiert wurde. Der Leistungsumfang liegt etwa zwischen Dbase III und der Großrechnerdatenbank DB2. Die Ergebnisse von System R wurden weiterentwickelt, so daß für SQL/DS folgende Eigenschaften hervorzuheben sind:

- SQL-Abfragesprache

- Precompilation der Befehlsfolgen ù Konkurrierende Zugriffe und Transaktionen

1983 wurde von IBM für Mainframes unter MVS das große Datenbanksystem DB2 vorgestellt, das folgende wichtige Eigenschaften besitzt:

- SQL analog zu SQL/DS

- nahezu identische Syntax der inline SQL-Statements

- Möglichkeit der Kommunikation mit TSO, IMS und CICS

Mittlerweile wurde SQL zum Standard erhoben und die meisten relationalen Datenbanken verwenden heute SQL als Datenmanipulationssprache. Für eine erfolgreiche Portierung von Applikationen zwischen unterschiedlichen Datenbanksystemen müssen die SQL-Sprachdialekte weitestgehend übereinstimmen.

Um das mächtige Datenbanksystem DB2 am PC nachzubilden, müssen einige wichtige Anforderungen an ein Produkt gestellt werden, welches die Großrechnerdatenbank am PC emulieren soll. Neben der Transaktionssicherung und Kommunikationsmöglichkeit mit anderen Systemen muß die Systemsprache SQL zwischen den gewählten Datenbanken übereinstimmen.

Eine relationale Datenbank, die diesen Anforderungen gerecht wird, die auf praktisch allen bekannten Rechnerfamilien und -klassen zu finden ist und eine geeignete Schnittstelle zu einem leistungsfähigen Cobol-Entwicklungssystem am PC hat, ist Oracle. Ein Vergleich zwischen den Datenbanksprachen von DB2 und Oracle soll die Möglichkeit der Portierbarkeit von Applikationen aufzeigen:

- Data Manipulation and Retrieval: Für die Datenmanipulation und das Selektieren von Daten aus der Datenbank stehen bei relationalen Datenbanken folgende Befehle zur Verfügung: DELETE FROM, INSERT INTO SELECT und UPDATE. Alle sind in DB2 und Oracle identisch vorhanden.

- Data Definition Commands:

Um Datenstrukturen zu definieren beziehungsweise diese Definitionen zu löschen, sind in beiden Datenbanken die Befehle ALTER TABLE, COMMENT ON, CREATE SYNONYM, CREATE TABLE, CREATE VIEW und DROP realisiert.

Für die physikalische Aufteilung der Datenbank auf die Datenträger beziehungsweise die Speicherzuteilung einzelner Datenbankbereiche sind PC-seitig die Befehle PARTITION, CLUSTER und SPACE verwendet. Inhaltlich gleichwertig sind dazu auf der Großrechnerseite die Befehle STOGROUP, TABLESPACE und DATABASE enthalten.

- Access Control Commands:

Um Zugangskontrollen und Zugriffsmechanismen bereitzustellen, sind in den zu vergleichenden Datenbanken die Befehle GRANT, REVOKE und LOCK TABLE enthalten. In DB2 sind diesbezüglich zwar differenziertere Parameter bestimmbar als unter Oracle, vom Grundsatz her stimmen jedoch auch hier die Funktionalität und Sprachsyntax überein.

- Transaktionsmanagement:

Um ein volles Transaktionsmanagement am PC nachbilden zu können, sind die Befehle COMMIT und ROLLBACK im Oracle-Datenbanksystem realisiert. Die Befehle sind identisch zu DB2.

- Inlineprogrammierung prozeduraler Sprachen:

SQL-Befehle müssen nicht nur als Dialogsprache, sondern auch als Schnittstelle zwischen prozeduralen Sprachen und der Datenbank fungieren. Durch Verwendung eines geeigneten Precompilers können sowohl am PC als auch am Großrechner die Befehle INCLUDE, DECLARE CURSOR, OPEN, FETCH, CLOSE und WHENEVER formal und inhaltlich gleichwertig verwendet werden.

- zusätzliche Hostbefehle:

DB2 ist eine extrem mächtige Datenbank, die bisher nicht vollständig am PC nachgebildet werden kann. Vor allem die Indexmodifikation mit dem Befehl ALTER INDEX und diverse, über SQL-Sprachumfang hinausgehende DB2-Spezialbefehle sind deshalb am PC nicht verfügbar. Dies spielt für die Anwendungsentwicklung jedoch keine wesentliche Rolle.

Für die Abwägung der Portierbarkeit relationaler Datenbank-Applikationen zwischen den Rechnern beziehungsweise Datenbankvertretern müssen folgende Gesichtspunkte beachtet werden:

- die wesentlichen Teile des SQL-Sprachumfangs, die für die Anwendungsentwicklung bedeutsam sind, stimmen zwischen DB2 und Oracle überein.

- Unterschiede in den Befehlen stellt man hauptsächlich bei Kommandos für Tuning und Performanceoptimierung fest. Sie sind jedoch unwichtig, wenn Hostkonforme DB-Applikationen am PC entwickelt werden sollen.

- die interne Steuerung der Datenspeicherung ist in beiden RDBMS grundsätzlich verschieden realisiert. Dies beeinflußt die Portierbarkeit von Datenbankanwendungen aber ebenfalls nicht.

Oracle emuliert die Datenbank-Schnittstelle

Nachfolgend soll die Portierung von Applikationen betrachtet werden, die sich hauptsächlich mit Datenmanipulationen und Datenbankretrieval befassen. Die Einrichtungen für den Datenbankadministrator sind für die Anwendungsentwicklung zweitrangig, so daß Unterschiede hierbei nicht als Beeinträchtigung der Kompatibilität gesehen werden sollen.

Eine typische DB-Applikation läßt sich im Schichtenmodell (siehe Bild 1 ) darstellen.

Für portable Applikationen, wie sie durch SQL intendiert sind, ist es nun möglich, Schichten auszutauschen ohne überlagerte Schichten zu modifizieren.

Bei der Entwicklung Host-kompatibler DB-Entwicklungen am PC müssen unter Beibehaltung der beiden obersten Schichten (Portabilität) die drei unterlagerten Schichten ersetzt werden, um somit eine neue Entwicklungsumgebung (Tools, Dezentralisierung) zu erreichen.

Eine Cobol-Anwendung mit eingebetteten DB2-Befehlen kann also im Schichtenmodell folgendermaßen skizziert werden:

Anwendungs-Programm

Embedded SQL

DB2

MVS

/370

Im Beispiel soll an dieser Stelle folgende Modifikation vorgenommen werden: Die Hardware wird durch kostengünstige PCs ersetzt, hierauf aufbauend wird das Betriebssystem MS-DOS verwendet. Um die Datenbankschnittstelle zu emulieren, wird das oben beschriebene relationale Datenbanksystem Professional Oracle verwendet. Durch das Ersetzen der untersten drei Schichten ergibt sich dann folgender "CLONE":

Anwendungs-Programm

Embedded SQL

Professional Oracle

MS-DOS

80286/80386

Anhand dieser Arbeitsplatzausstattung kann nachfolgend die Entwicklung von DB2-kompatiblen Anwendungssystemen am PC aufgezeigt werden.

Am Beispiel der Integration von relationalen Schreib- und Lesebefehlen in die prozedurale Sprache Cobol soll gezeigt werden, mit welchen Möglichkeiten DB2-kompatible Anwendungen am PC entwickelt werden können:

Wie vom Großrechner bekannt werden die Datenbankaufrufe durch Schlüsselwörter im Text markiert. Werden Variable im Befehl benutzt, so werden auch diese analog zur Host-Version des Precompilers durch Voranstellen eines Doppelpunktes gekennzeichnet:

EXEC SQL

CONNET:userid IDENTIFIED BY: passwd

END-EXEC

Analog zum Großrechner ist auch am PC kein Zugriff auf Datenbestände ohne entsprechende Logon-Prozedur möglich. Neben einfachen Befehlen kann natürlich am PC auch mit komplexen Verknüpfungen wie am Großrechner gearbeitet werden. Die Oracle-PC-Datenbank erlaubt Schachtelungstiefen, die keinerlei ernsthaften Einschränkungen unterliegen:

EXEC SQL

SELECT name, vorname, firma, telnr, info

INTO :name;:vorname;:firma;:telnr;:info

FROM person, firmen

WHERE person, firma = firmen. ident

AND person, interesse = (SELECT

thema FROM seminare WHERE seminartermin = 8.MAI)END-EXEC

Bei Einbettung dieser Befehle in prozedurale Sprachen werden diese Befehle vom SQL-Precompiler in "normale" Cobol-Sprachbefehle ("calls") umgewandelt, diese wiederum vom Cobol-Compiler in ein ausführbares Programm transferiert. Bei Übersetzungsleistungen von zirka 1000 bis 2000 Zeilen/Minute des Precompilers und etwa 5000 bis 10 000 Zeilen/Minute des Cobol-Compilers ergibt sich innerhalb kürzester Responsezeiten ein ausfuhrbares Programm, welches anschließend zum Beispiel zur Fehlersuche oder zur Qualitätsüberwachung mit einem Full-Screen-Debugger getestet werden kann.

Die Bildschirmdarstellung gibt (Bild 2) neben dem Quellcode, den aktuell aktivierten Funktionstasten und Modulkennungen, die Werte einzelner Variablen aus. Um den Programmablauf zu beeinflussen, können die so dargestellten Datenwerte während des Programmlaufes modifiziert werden.

Besonders leistungsfähig sind die PC-Debugger

Bei der Bedienung des Full-Screen-Debuggers kommen erstmals neben der hohen Übersetzungsleistung der Compiler PC-spezifische Hilfsmittel wie

- Mausunterstützung

- Windowtechnik

- Pop-Up-Menüs

zur Geltung. Die DB-Applikation ist durch Verwendung des Cobol-PC-Entwicklungssystems Schritt für Schritt nachvollziehbar. Es kann zwischen folgenden Ablaufvarianten unterschieden werden:

- Einzelschrittabarbeitung

- verlangsamter Programmablauf mit Trace-Möglichkeit

- Normale Ablaufgeschwindigkeit mit Breakpoint-Stop

Im nachfolgenden wird gezeigt, wie DB2-Anwendungen mit anderen Subsystemen (wie CICS, IMS und VSAM) am Großrechner einerseits und am PC andererseits integriert werden können. Für das Testen und Ausführen dieser Applikationen müssen dann auf dem PC vollwertige Nachbildungen dieser Systeme gleichzeitig verfügbar sein.

Auf dem IBM-Großrechner ergibt sich für derartige Anwendungen ein Schichtenmodell (Bild 3).

Um derart anspruchsvolle Entwicklungsarbeiten auf PCs durchführen zu können, müssen die dargestellten Schichten des Großrechnersystems durch PC-Systeme vollwertig ersetzt werden (Bild 4).

Die einzelnen Systemdienste werden wie am Mainframe durch Aufrufkennungen im Quellcode des Anwendungsprogrammes gekennzeichnet. Ein Aufruf an SQL wird wie bereits gesehen in die Kommandofolge

EXEC SQL

END-EXEC

eingeschlossen. Sollen Dienste des CICS-Systems angesprochen werden, so sind diese Befehle durch die Klammerung

EXEC CICS

END-EXEC

eingegrenzt. Um die beiden Systeme gleichzeitig zu verwenden, wird der originale Quellcode (mittels einer Prozedur) nacheinander vom SQL- und danach vom CICS-Precompiler umgesetzt. Der so erzeugte Cobol-Sourcecode wird nachfolgend vom Standard-Cobolcompiler in ein ablauffähiges Programm umgesetzt.

Die DL/I-Kommandos können sowohl über direkte "call" -Kommandos als auch mittels DL/I-Command-Level-Aufrufe codiert sein. Im nachfolgenden Beispiel sind diese Aufrufe daher folgendermaßen codiert:

CALL 'CBLTDLI' using . . .

Zur Veranschaulichung soll folgende Situation angenommen werden:

- In einer CICS-Transaktion werden die Selektionskriterien für Datensätze angegeben, welche zwischen den Datenbanken ausgetauscht werden sollen

- Im DL/I-Statement werden die Daten aus der hierarchischen Datenbank gelesen,

- Im SQL-Statement werden die gelesenen Daten in die relationale Datenbank eingespeist. (Anm.: In der Praxis würde man dabei die Segmente aus der hierarchischen Datenbank im allgemeinen in mehrere Relationen aufspalten-)

Am PC kann nun das Zusammenwirken aller Kommandokombinationen getestet werden. Hierzu holt man mittels Selektionsprogrammen und File-Transfer einen kleinen Ausschnitt der Echt-Datenbank auf den PC. Nach den Testläufen am Kleinrechner können dann die so entwickelten, Source-kompatiblen Anwendungsprogramme mittels File-Transfer zum Host übertragen werden. Dort sind nach erneutem Übersetzungslauf ein abschließender Realtest und Tuningmaßnahmen vorzunehmen.

Für Applikationen mit verteilten Ressourcen ist es wünschenswert, transaktionsorientiert satzweise beziehungsweise selektionsweise vom PC auf die Host-Datenbank zuzugreifen. Dies befreit einerseits von langen Transferzeiten bei großen Host-Datenbeständen, andererseits ermöglicht diese Zugriffsform ein höchstmöglich dezentrales Arbeiten nach dem Server-Requestor-Prinzip.

Benötigt ein PC-Anwendungsprogramm Datenzugriffe zu der zentralen Datenbank am Host, so wird ein Prozeduraufruf gestartet, der den üblichen lokalen Datenbankzugriff ersetzt. Im Softwarepaket PC/DB-Link (ADV-Orga) wird ein solcher Remote-Datenbankaufruf folgendermaßen abgesetzt:

CALL 'KDBS' USING opcode

Verständigungsbereich, Datenbereich, Zugriffsparameter.

Das Kommando wird über eine PC/Großrechner-Verbindungsschicht an eine DB/DC-Transaktion am Host geleitet, welche den Datenzugriff ausführt und die dort erhaltenen Daten an den PC zurücksendet.

Aufgrund der vielfältig verfügbaren Host-Interpreter ist es damit dann auch möglich, nicht nur auf Datenbestände von IBM-Rechnern zuzugreifen, auch ein Durchgriff auf zum Beispiel BS2000-Rechner kann damit realisiert werden.

Ähnlich der Zugriffe auf Host-Datenbanken existieren auch Zugriffsmechanismen für ClCS-Transaktionen, die es erlauben, Datenbestände am Großrechner vom PC-Programm aus zu nutzen.

In gleichem Maße, in dem ein PC-Programm remote auf Datenbestände des Großrechners zugreifen kann muß die Integration der Entwicklungs-PCs in die Großrechner-Umgebung gewährleistet sein.

Genügt es für die einzelnen Entwickler, den PC direkt an den Host anzuschließen, so muß in größeren Entwicklungabteilungen die Kommunikation aller Entwicklungsrechner mit der Zielmaschine gewährleistet werden. Hierdurch kann dann die gemeinsame Nutzung von Copy-Books und Prozeduren sowie eine zentrale Qualitätssicherung garantiert werden.

Typischerweise wird man dann die Entwicklung in einem PC-Netz realisieren, da dort die Rechnerleistung und Bedienoberfläche dezentralisiert am PC verfügbar ist. Die gemeinsam genutzten Ressourcen werden aus Gründen der Integrität am File-Server verwaltet, eine Qualitätssicherungsinstanz übergibt die vorgetesteten Programme zum Endtest an den Host.

Ist das PC-Netz direkt an den Großrechner angeschlossen, so muß der einzelne Entwicklerarbeitsplatz nur mit einem PC ausgestattet werden, da dieser dann mittels Terminalemulation auch die Testsitzungen am Großrechner bedienen muß.

Die Konzeption und Realisierung eines derartigen PC-Großrechner-Verbundsystems für die Programmentwicklung kann hier nur angedeutet werden.

Im folgenden soll darauf hingewiesen werden, daß man die PC-Version von Oracle natürlich nicht nur zur Simulation von DB2-Anwendungen benutzen kann.

Bei der Oracle-Datenbank handelt es sich um ein sehr leistungsfähiges Werkzeug, welches auf den meisten Mikro-, Mini- und Großrechnern durchgängig eingesetzt werden kann. Neben SQL sind dabei auch alle weiteren Werkzeuge, wie das Maskensystem, das Spreadsheet-Modul, der Report-Writer etc. ebenfalls rechnerunabhängig implementiert.

Am Beispiel der Verwendung einer sogenannten "Maus" zeigt sich, wie innerhalb kürzester Zeit und mit hohem PC-Komfort eine portable Dialoganwendung am PC erzeugt werden kann. Der Großrechner kann hierbei weder mit dem Benutzerkomfort noch mit den Antwortzeiten des PCs konkurrieren.

Die Entwicklung von Großrechnersoftware am PC sowie das Betreiben von Großrechnersoftware am PC befinden sich zwar noch in ihren Anfangsstadien, dennoch bieten die verfügbaren Simulationssysteme für Großrechnerapplikationen wie zum Beispiel

Realia-Cobol für IBM VS Cobol Realia CICS-PC für IBM CICS

Professional Oracle mit Precompiler für IBM DB2

IMS-PC für IBM IMS/VS

bereits heute ein voll ausreichendes Maß an Leistungsfähigkeit und Zuverlässigkeit. Die konsequente Weiterentwicklung dieser Tools, das Aufkeimen der Entwicklung von projektbegleitenden PC-Werkzeugen sowie die weiterhin verbesserten Möglichkeiten zur Anbindung der PC-Entwicklungsplätze an Großrechner lassen uns dabei zu folgendem Fazit gelangen:

Obwohl die Großrechnersysteme (insbesondere im Bereich der Datenbanken) noch nicht 100 prozentig am PC nachgebildet werden können reicht die Leistungsfähigkeit der heute verfügbaren PC-Werkzeuge aus, den größten Teil der Programmentwicklung vom Host auf den benutzerfreundlichen und wesentlich preiswerteren PC-Arbeitsplatz auszulagern. Dadurch kann neben einer Entlastung des Host-Rechners die Produktivität und Motivation der Entwickler enorm gesteigert werden. Leistungsfähige Testhilfen garantieren bestens ausgetestete Software. Die Integration der Arbeitsplätze sowohl horizontal (PC-Vernetzung) als auch vertikal (Host-Ankopplung) sichert die Investition fr die Zukunft.

Als entscheidend sollte dabei angesehen werden, daß die hier angestellten Überlegungen nicht nur theoretisch spekulativer Natur sind, sondern durch die Beispiele mit auf dem Markt verfügbaren Werkzeugen praxisgerecht belegt werden.