Die IBM-Rechnerwelt gut als besonders geschlossene Gesellschaft. Die verschiedenen blauen Hardwareplattformen sind so proprietär, daß sie zum Teil nicht einmal untereinander Datenfluß erlauben. Im folgenden Artikel stellt der Autor eine in Deutschland erstmals realisierte Lösung zur Ankoppelung bestehender hierarchischer IMS-Datenbanken an Client-Server-Applikationen auf PCs mit einem RS/6000-RISC-Rechner als relationalem Oracle-Datenbankserver vor.
Die Lösung ist als Teilaufgabe im Rahmen eines Großprojektes der ABB Kraftwerke AG bei der ABB Informatik GmbH mit Hilfe der Firmen IBM Deutschland, Geschäftsstelle Mannheim, Oracle Deutschland, Geschäftsstelle Frankfurt/Dreieich und Firma Falsch, Beckdrof bei Hamburg erarbeitet worden.
In vielen Firmen wird heute (vor allem aus Kostengründen) versucht, Mainframe-basierte Anwendungen auf PC-Netze und/oder mittlere Datentechnik zu portieren. Dabei werden neben proprietären Systemumgebungen häufig Unix-Host-Lösungen, vor allem jedoch Client-Server-Architekturen auf heterogenen Rechnern eingesetzt.
"Connectivity" und "offene Systemarchitektur"
Zumindest während einer Übergangsphase (je nach Umfang meist mehrere Jahre), in der die Host-Programme schrittweise abgelöst werden, ergibt sich dabei das Problem, daß die neu entstehenden Anwendungssysteme Daten aus den Altsystemen benötigen. Gleiches wird auch in Zukunft in heterogenen Umgebungen gelten, wo Mainframe-basierte Anwendungen aus Strategiegründen etwa neben PC- oder Unix-Anwendungen bestehen bleiben werden.
Nahezu jeder Hersteller führt heute, auf diese Problematik hin angesprochen, die Schlagworte "Offene Systemarchitektur", "Connectivity" und "vollständige Anwendertransparenz" vollmundig als Werbeargument in seinen Hochglanzprospekten auf.
Bei näherer Betrachtung der konkreten Anforderung bleibt oft nur der Hinweis auf eine "gerade in der Entwicklung befindliche" Superversion des jeweiligen Netzwerkdienstes übrig, deren Auslieferungsdatum jedoch nicht genau bekannt ist.
Auch bei der ABB Kraftwerke AG war die geschilderte Problematik vorhanden: Im Rahmen eines Revirements der gesamten Informationsstruktur (KISS = Kraftwerke Informations System Strategie) wird eine Applikation für den Kraftwerksservice in Client-Server-Architektur auf der Datenbank-Basis von Oracle entwickelt.
Clients sind Standard-PCs, der Server ist eine IBM-RISC-Workstation RS/6000-560, die jeweiligen Betriebssysteme sind DOS beziehungsweise AIX. Client und Server sind über Token-Ring mit Glasfaser-Backbone-Netz verbunden, das Protokoll ist TCP/IP.
Bereits in der Anforderungsanalyse des Projekts war klar, daß zumindest für eine Übergangszeit auch auf "Host-Daten" (IBM 3090/280J Großrechner unter MVS mit IMS-Datenbanken) zugegriffen werden muß, da der Kraftwerksservice betriebliche Schnittstellen zu Einkauf, Materialwirtschaft, Lager, Spedition, kurzum zu nahezu allen Teilbereichen des Gesamtunternehmens ABB Kraftwerke
AG hat.
Die jeweiligen DV-Systeme sind meist große IMS-Anwendungen, die über IMS/DC von einigen hundert Terminals aus bedient werden.
Es war daher mit ein "K.-o.-Kriterium" bei der Auswahl des Servers, ob der Hersteller einen problemlosen Zugriff auf diese Datenbestände garantieren konnte oder nicht.
Im Laufe der Feinspezifikation (Fachkonzept) wurde ein exemplarischer Zugriff (Stammdaten der Lieferanten) ausgewählt und damit eine konkrete Aufgabenstellung formuliert, die im Dezember 1991 der IBM übergeben wurde. Bereits im März 1992 lag ein Demoprogramm vor, mit dessen Hilfe im Dialog einer oder mehrere Lieferantenstammsätze aus einer IMS-Datenbank auf dem Host gelesen und am Bildschirm der RS/6000-Workstation ausgegeben werden konnten.
In einem zweiten Schritt wurde dieses Demoprogramm so modifiziert, daß über die Oracle-Datenbank auf dem Server eine Anbindung der Benutzer-Clients im "Quasi-Dialog" (asynchron) ermöglicht wurde. Im Folgenden werden zum Verständnis notwendige technische Details dargestellt.
Ein Anwender der Service-Applikation will in seinem Dialog auf Daten eines Lieferanten zugreifen, die noch nicht in der Service-Datenbank (Oracle) gespeichert sind. Der transparente Zugriff auf eine Hostdatenbank (IMS), in der die gesuchten Stammdaten vermutlich vorhanden sind, soll möglichst automatisch ablaufen und die gewünschten Daten, oder eine Treffermenge für eine zweite Suche zurückliefern.
In einer Oracle-Client-Server-Anwendung läuft die eigentliche Benutzer-Applikation auf dem Client, benutzt also dessen Ressourcen wie CPU und Bildschirm, und "unterhält sich" mit ihrem jeweiligen "Schattenprozeß" auf der Server-Seite via Oracle SQL*NET.
Für eine reine Client-Server-Anwendung ist dies sehr praktisch: Der Anwender kann niemals in das Betriebssystem des Servers gelangen, da er keinen Zugriff auf die tieferliegenden Schichten hat.
Für unseren Zweck war diese Architektur ein Hindernis für die direkte Kommunikation via APP/LU6.2 mit der IMS-Anwendung; de facto gibt es keinen einfachen Weg aus der Oracle-Anwendung heraus. Die Lösung war ein Umweg über einen "Dämon-Job" auf dem AIX-Server, der über eine Tabelle in der Datenbank mit der eigentlichen Benutzeranwendung kommuniziert.
Der Dialogablauf funktioniert in dieser Konstruktion folgendermaßen: Der Anwender formuliert seine Frage nach dem Lieferanten (oder nach der Menge von Lieferanten, wenn er zum Beispiel nur einen Teil der Kurzbezeichnung kennt) direkt im Dialog der CASH-Anwendung.
In der Zwischentabelle der Datenbank wird eine Request-Satz mit entsprechenden Kennungen für den Multiuser-Betrieb abgelegt und der Anwender informiert, daß eine Abfrage in Richtung Host gestartet wurde. Er kann sich kurzzeitig anderen Tätigkeiten zuwenden oder andere Masken der Anwendung bedienen. Ruft er nach zirka zehn Sekunden die "Request-Maske" wieder auf, hält das System einen "Reply-Satz" für ihn bereit.
Im allgemeinen findet er je nach Fragestellung einen oder mehrere Lieferantenstammsätze vor und kann unmittelbar in seinem Geschäftsvorfall so weiterarbeiten, als ob der Stammsatz aus seiner Oracle-Datenbank käme (Transparenz). Treten Fehler auf (IMS ist nicht aktiv, die Verbindung steht nicht, etc. wird er von dem Hintergrundjob ("Dämon") geeignet informiert.
Für die Zeitsteuerung (Time out bei mehrfachem Request und fehlendem Reply etc.) wurde eine "straight forward" in PRO*C programmiert (C mit embedded SQL für Oracle DB).
Der Anwender spürt also im Regelfall von den Hintergrundaktivitäten nichts. Zur Zeit ist probeweise eine Zeitscheibe für das "Polling" (Nachfragen nach Aufträgen) für den Hintergrundjob von fünf Sekunden eingestellt - es ist daran gedacht, eine übergeordnete Steuerung auf der AIX-Maschine zu schreiben, die den gesamten Verkehr zwischen DB-Anwendung und APPC/LU6.2-IMS-Abfrage überwacht, und die beim Hochfahren der DB automatisch angestartet wird.
Daten auf IMS-Host-Datenbanken können problemlos beim "Downsizing" mit eingebunden werden, zumindest, was den lesenden Zugriff anbetrifft. Im Prinzip ist auf diese Art auch ein Update im "Quasidialog" möglich. Darauf sollte jedoch nur im Notfall zurückgegriffen werden, da hierzu wenigstens ein rudimentäres (selbstprogrammiertes!) Two-Phase-Commit-Protokoll nötig wäre. Das überläßt man aber besser den DB-Herstellern.
Im Zweifelsfall genügt oft ein Batch-Update der Host-Datenbank. Der Aufwand für einen lesenden Zugriff auf Hostdaten ist mit der hier vorgestellten Methode gering, wenn man die geleistete Arbeit für die APPC/ LU6.2/LU6.1-Kopplung einfach einkauft.