Daß PCs und Workstations selbst in ehemals reinen Großrechnerumgebungen zum gewichtigen Faktor der Unternehmens-DV geworden sind, belegen die Diskussionen um "Downsizing" oder "Client-Server". Inwiefern die Umsetzung dessen, was hierbei konzeptionell ersonnen wird, einer Technologie der vierten

Generation bedarf, erläutert André Bartels*.

Über Sprachen der vierten Generation (4GL) mit ihren deskriptiven Sprachkonstrukten geht das, was heute im Großrechnerbereich als Technologie der vierten Generation (4GT) bezeichnet wird, weit hinaus. Dabei handelt es sich vielmehr um interaktive Anwendungsentwicklungs-Umgebungen der vierten Generation, die beispielsweise auch intelligente Editoren oder die Integration eines Data-Dictionary bieten.

Die Erweiterbarkeit hin zu einer vollständigen CASE-Umgebung muß in diesem Zusammenhang genauso genannt werden wie die Möglichkeit, Werkzeuge für den Aufbau von Expertensystemen zu integrieren. Die Unterstützung von Standard-SQL ist selbstverständlich. Darüber hinaus sollte das System nicht nur herkömmliche formatierte Daten verarbeiten, sondern auch auf komplexe Objekte mit hochrekursiven Strukturen zugreifen können.

Besonders wichtig ist jedoch ein Merkmal, das die Programmierhilfen der vierten Generation schon frühzeitig von den Sprachen der dritten Generation unterschied, nämlich die Portabilität. So beschränkt sich beispielsweise die Portabilität einer Cobol-Anwendung auf die Semantik, die vom Cobol-Standard abgedeckt wird

Beschränkt auf Semantik des Cobol-Standards

Das schließt die Logik, das String-Handling sowie arithmetische und Programm-Kontrollfunktionen ein, nicht jedoch Transaktions-Management, Terminalinteraktion, Definition grafischer Benutzeroberflächen oder Datenbankinteraktionen, um nur einige Beispiele zu nennen.

Gerade diese Funktionen sind jedoch für kommerzielle Anwendungen essentiell. Um sie für Cobol-Anwendungen zur Verfügung zu stellen, werden Application Programming Interfaces (API) zu externen Dienstleistungen (Betriebssystem, TP-Monitore, DBMS etc.) genutzt. Dabei ist typischerweise für jede Kombination von Funktionen und Laufzeitumgebung ein gesondertes API erforderlich.

Die Implementierung der API sieht in vielen Fällen folgendermaßen aus: Zunächst werden High-level-Statements in den Quellcode der Anwendung eingebettet; um diese Statements in Low-level-Aufrufe zu übersetzen, kommen dann Precompiler zum Einsatz.

Da jedes API speziell für eine Laufzeitumgebung ausgelegt ist, sind die Anwendungen nicht portabel, müssen also neu codiert werden, wenn sie auf anderen Plattformen laufen sollen. Zwar gibt es innerhalb des Produktspektrums eines Hardware-Anbieters manchmal Unterstützung für mehr als eine Plattform. Doch das erweitert den Grad der Portabilität lediglich innerhalb dieses Spektrums.

Aus diesem Grund kann Cobol nicht angemessen in Organisationen genutzt werden, die unterschiedliche Betriebssystem-Umgebungen einsetzten. Ungeeignet erscheinen Sprachen der dritten Generation auch für Unternehmen, die Downsizing realisieren, also von einer zentralen DV zu einer netzwerkorientierten DV migrieren wollen.

Die 4GT hilft hier weiter, denn sie definiert eine API-Menge für alle Systemumgebungen. Das ist der Grund, warum die mit einer 4GT erstellten Anwendungen ohne Änderungen in anderen Umgebungen laufen können. Eingeschlossen ist hier die horizontale Portabilität von Anwendungen zwischen verschiedenen Herstellerumgebungen - insbesondere im Großrechnerbereich - sowie auch die vertikale Portabilität im Sinne des Downsizing von großen zu kleinen Prozessorumgebungen. Letzteres bietet überhaupt erst die Möglichkeit, auf evolutionärem, die bisherigen Investitionen schützendem Wege zu einem echten Client-Server-Computing zu kommen.

Präsentation von der Anwendungslogik getrennt

Heute gibt es typischerweise zwei Ansatzpunkte, an denen Anwendungen "geschnitten", also in Client und Server aufgeteilt, werden sollen: Der eine betrifft die Trennung der Anwendung von der Datenhaltung und ist im Datenbankbereich längst gang und gäbe. Schnittstelle sind hier die Datenbankbefehle die zum Beispiel in SQL abgesetzt werden.

Die zweite heute bereits realisierbare Variante des Client-Server-Computings besteht darin, die Anwendung derart zu schneiden, daß die fachliche Anwendungslogik und die Datenhaltung auf dem Großrechner bleiben, die Präsentation jedoch auf PCs oder Workstations verlagert wird, um dort die komfortablen, endbenutzergerechten "Graphical User Interfaces" (GUI) zu nutzen.

Von Hand oder durch spezielle Programme

Die Separierung der Präsentation von der Anwendungslogik kann zum einen von Hand erfolgen, indem auf dem PC Programme geschrieben werden, die die Präsentation also Bildschirm-Input und -Output, übernehmen. Zum anderen ist der Einsatz von spezieller Präsentationssoftware wie "Easel" möglich.

Im letztgenannten Fall müssen die Mainframemasken auf dem PC noch einmal definiert werden, wobei der 3270-Datenstrom die Basis für den Datenaustausch bildet. Dadurch wird aber der 3270-Datenstrom auf die Ebene eines API gehoben, weshalb jede Änderung der Mainframe-Maske auf dem PC nachvollzogen werden muß. Bei einem komplexen Netzwerk dürfte hier die Verteilung der Softwarekomponenten auf alle im Netz angeschlossenen Workstations Probleme aufwerfen.

Hinzu kommt ein anderes praktisches Problem, das viele Unternehmen haben: Es bereitet einige Schwierigkeiten, die Verarbeitungsleistung eines Großrechners und die grafischen Fähigkeiten einer Workstation - beispielsweise unter Presentation Manager, Windows 3 oder OSF/Motif - zu kombinieren: Der Anwender kann wohl kaum von einem Tag zum anderen alle Terminals gegen Workstations austauschen.

Um diese Probleme zu losen, ist es unerläßlich, daß eine Anwendung auf "dummen" Terminals sowie auf "intelligenten" Workstations simultan ablaufen kann. Außerdem muß sich die Anwendung hinsichtlich der Präsentation gegenüber dem Endbenutzer und dem Anwendungsentwickler genauso transparent verhalten, wie sie es gegenüber Datenhaltungssystemen, TP-Monitoren oder Betriebssystemen tut.

Auf der technischen Seite ist dafür auf der Workstation eine Schnittstelle zum entsprechenden GUI notwendig. Die Maske wird dann automatisch in einem GUI-Fenster aufgebaut. Auf diesem Weg können Anwendungen, die auf dem Mainframe entwickelt wurden und ablaufen, nach der Portierung auf eine Workstation die Vorteile einer grafischen Benutzerschnittstelle nutzen.

Dabei müssen alle relevanten Informationen auf der lokalen Workstation liegen. Wenn ein Benutzer die Anwendung aufruft, prüft die auf der Workstation liegende Schnittstelle, ob diese Informationen verfügbar sind. Sollte dies nicht der Fall sein, so richtet die Workstation-Schnittstelle eine entsprechende Anfrage an die Mainframe-Schnittstelle. In der Folge werden alle Masken und alle dazugehörenden Informationen (Hilfe-Masken, Hilfsroutinen Masken-Verarbeitungsregeln, Regeln aus dem Data Dictionary sowie Benutzer- und Fehlermeldungen) automatisch auf die Workstation transferiert.

Nach diesem Transfer werden alle diese Objekte automatisch auf der lokalen Workstation gespeichert und compiliert. Die gesamte Verarbeitung auf der Präsentationsebene läßt sich von nun an lokal ausführen. Das bedeutet, daß nur der absolut notwendige Datenaustausch zwischen Mainframe und Workstation erfolgt und somit das Netz nicht unnötig belastet wird.

Konsistenz zwischen Host und Workstation

Dieses Verfahren ist natürlich nur dann möglich, wenn zugleich für die entsprechende Administration im netzwerkartigen Mainframe-Workstation-Verbund gesorgt wird. Insbesondere gilt dies für die Gewährleistung der Konsistenz zwischen Mainframe und Workstation. Dazu ist jede Maske mit einem Zeitstempel zu versehen und dieser Stempel zu überprüfen, bevor auf die Maske zugegriffen wird.

Sobald der Stempel der lokalen Maske nicht mehr mit dem Stempel der Maske auf dem Mainframe übereinstimmt (weil diese zum Beispiel aus Wartungsgründen geändert wurde), beginnt der Download-Prozeß von neuem. Dieses Verfahren: stellt sicher, daß selbst in großen Client-Server-Umgebungen die aktualisierten Komponenten automatisch verteilt werden.

Technologischer Sprung in der kommerziellen DV

Client-Server eröffnet aber noch weitergehende Perspektiven: So ist es durchaus möglich, den anwendungslogischen Teil selbst zu schneiden und in einem Netz von Rechnern zu verteilen. Die 4GT kann für diese Anwendungsart Sprachelemente zur Verfügung stellen, die den Entwickler von der Programmierung auf Netzwerkebene befreit. Diese "kooperative Verarbeitung" bedeutet nicht nur einen technologischen Sprung in der kommerziellen Datenverarbeitung, sondern stellt auch ganz neue Anforderungen an das Design von Anwendungen.