Rund 200 Maanjahre hat die Schweizer Luftfahrtgesellschaft Swissair in ihre erste komplexe Online-Anwendung unter dem IBM-Datenbanksystem IMS investiert, das "Maintenance Control System". Nach Abschluß der ersten großen Echtzeitprojekte - Fernschreibvermittlung, Abfertigungs- und Reservierungssystem - mit der Luftfahrt-Software ACP entschied sich die Swissair 1970, für kommerzielle Online-Anwendungen IMS einzusetzen. Maßgebend waren zwei Gründe: IMS galt als "strategisches Produkt", dessen Verfügbarkeit langfristig sichergestellt ist, und am Softwaremarkt fand sich keine ebenbürtige Alternative. Nach einem Jahr Erfahrungen mit IMS-Online-Betrieb an 20 Stunden pro Tag und sieben Tagen pro Woche hat das Swissair-Rechenzentrum heute "keine Mühe, die ursprünglich geforderten 95 Prozent Verfügbarkeit zu übertreffen": "IMS ist zwar nicht problemlos und kostete mehr als prognostiziert - aber jetzt sind die funktionellen Erwartungen voll erfüllt."
Es wird zwar in Fachkreisen immer vom "Problem IMS" gesprochen, obwohl dies - so verallgemeinert - irreführend ist. IMS funktioniert in einem einfachen System-Environment, eventuell bis auf Leistungsprobleme und hohen Realspeicherbedarf gut, wobei der Aufwand für Einführung und Anwendung auch hier nicht unerheblich ist. Anders stellt sich das Problem in einem komplexen Online- Betrieb wie im Falle der Swissair, wo IMS als Teil von 2 IBM 370-158, loosly coupled, z. Z. unter SVS/ASP und mit 2 DPI Frontend-Prozessoren betrieben wird. Zudem wird der Großteil unserer Stapelverarbeitung auf denselben beiden Systemen abgewickelt.
Das sind unsere Erfahrungen mit einem Online-Betrieb in obigem Sinne:
- Auslegung der Applikationen, der Datenbanken und Programmier-Standards bezüglich daraus resultierender DL/I-Zugriffe etc. wirken entscheidend auf Systembelastung und Antwortzeiten. Allerdings reichen die vorhandenen Richtlinien und Ausbildungsmöglichkeiten nicht aus, um ohne eigene IMS-Erfahrung auf Anhieb eine mindestens annähernd optimale Lösung zu sichern.
- Daten-Redundanz - gemäß IMS-Einsatzdoktrin unbedingt zu vermeiden - kommt oft sehr viel billiger zu stehen als die IMS-Lösung in Form von logischen Verbindungen zwischen Datenbanken.
- Messen, System- und Applikations-Tuning müssen zu einer permanenten Funktion werden. Es versteht sich von selbst, daß dies qualifizierte System-Programmierer erfordert.
- Einer der schwachen Punkte des IMS liegt auf dem Gebiet der BMP/ Batch-Philosophie. In vielen Fällen muß Batch-Verarbeitung aus Performance-Gründen gewählt werden, obwohl man sich damit ein Sicherheitsrisiko bezüglich der Datenbanken einhandelt, das zwar mit organisatorischen Maßnahmen eingeschränkt, aber nicht systematisch vermieden werden kann.
- Unser Environment deckte weitere Schwächen der System Software auf, die nicht IMS betreffen, dieses aber mit treffen. Unter diesem Environment folgerichtig applizierte "shared DASD" führen bei loosly coupled Systems oft und unkontrollierbar zur Blockierung erst der Disk Drives, dann der ganzen Systeme. Auch hier muß mit fehleranfälligen organisatorischen Maßnahmen versucht werden, einem Konzept inhärente Probleme zu umgehen.
- Eine eher überraschende Erkenntnis war, daß wir, auf PL/I standardisiert, damit ungewollt in Kauf nehmen, daß jeder Aufruf eines in PL/I geschriebenen Online-Programms im Vergleich zu Assembler/ COBOL ein Mehrfaches an Instruktionen kostet.
- Von der ursprünglich berechneten CPU-Leistungsfähigkeit von 5 Transaktionen p/S verblieben ca. 1,5 Transaktionen p/S tatsächlich zu erreichender Leistung. Dabei ist allerdings zu beachten, daß "Transaktion" keine gegebene Größe ist und kaum abgegrenzt werden kann, wieviel davon zu Lasten System Software bzw. zu Lasten komplexerer Transaktionen als ursprünglich angenommen wurde, geht.
Ein IMS Online-Betrieb in Swissair-Größenordnungen wirft folgende Probleme auf:
Die gewählte System-Software, das gewählte Betriebskonzept und das Applikations-Design (Datenbanken/ Transaktionen) sind entscheidend für die Effizienz und die Beanspruchung der Hardware eines Systems. Es empfiehlt sich schon bei der Aufstellung funktioneller Anforderungen große Vorsicht walten zu lassen, um leicht einzuhandelnden CPU-intensiven "System-Software Overhead" zu vermeiden.
Wo ein komplexes Batch/Online-Environment zur Lösung gegebener Probleme notwendig und berechtigt ist, bestehen auch heute kaum echte Alternativen, obwohl IMS in diesem Falle die Möglichkeiten der bestehenden Computer bezüglich Performance wahrscheinlich überfordert. Trotzdem glauben wir, mit IMS langfristig richtig zu liegen, würden aber eine nochmalige IMS-Einführung vorsichtiger, langsamer und mit weniger Illusionen angehen.
Ohne straffe, zentrale Kontrolle aller Aktivitäten auf den Gebieten der Projektentwicklung, der System Software, der Hardware und der Operation wird man keine erfolgreiche IMS-Einführung erleben.
Für den Benutzer sind kurze Antwortzeiten und einfache Prozeduren, auch für komplexere Transaktionen, von alleiniger Bedeutung. Erwartungen und Möglichkeiten liegen jedoch oft weit auseinander und können auch mit guter Motivation nicht für beide Parteien zufriedenstellend gelöst werden.
Wenn ein IMS Online-Betrieb eingeführt werden soll, empfiehlt es sich, ein überblickbares Projekt zu wählen, wo Transaktionsvolumen zuverlässig abgeschätzt werden können und nur einfache Datenbanken Voraussetzung sind.
Modifikationen an Applikations-Programmen, Datenbanken und System Software-Komponenten sind wesentlich heikler als bei konventionellen ADV-Abläufen. Dies erschwert die Systempflege und führt oft zu unangenehmen Auswirkungen auf Verfügbarkeit und Qualität des Systems.
Personal- und Ausbildungs-Probleme: Völlig neue Aufgaben
Die Ausbildung und das Umlernen bei Analysatoren und Programmierern brauchen mehr Zeit, als man annimmt. Nebst der Notwendigkeit, Projektmitarbeitern mehr Einblick in die Gebiete Job Control, Operation und System Software zu vermitteln, brauchen die Familiarisierung und das Sammeln der zwingend notwendigen Erfahrung mehr Zeit, als man früher gewohnt war.
Das Betreiben einer IMS-Online Applikation, speziell im Zusammenhang mit Frontend-Prozessoren, stellt die Operateure vor völlig neue Aufgaben. Dabei stellt sich auch hier das Problem des "System Environment", indem IMS nicht als in sich geschlossenes, isoliertes Problem betrachtet werden kann. Sowohl Erstellen von Ausbildungsunterlagen, das Ausbilden und der Aufbau von Betriebsanleitungen für Normalfall, Ausnahmefälle, Switch-Prozeduren, Sicherungs- und Wiedererstellungs-Prozeduren etc. für die Operateure beansprucht viel Aufwand von entsprechend qualifizierten System-Spezialisten.
Betriebs-Probleme: Fest zugeteiltes System nötig
Dank unseren Möglichkeiten mit - unter anderem - vier 370-Systemen konnten wir verschiedene Einsatz-Varianten durchspielen und kamen zum Schluß, daß ein komplexer IMS Online-Betrieb - hohe Verfügbarkeitsanforderungen vorausgesetzt - nur mit einem fest für IMS zugeteilten System praktizierbar ist.
Ein 24-Stunden-Online-Betrieb ist in unserem Falle zwar (nachträglich) benützerseitig verlangt worden, jedoch noch nicht realisiert. Allerdings muß man zugunsten von IMS festhalten, daß die Möglichkeit eines rund um die Uhr gehenden Betriebes nie explizit in Aussicht gestellt wurde. Wir sehen auch keine Lösung, in den nächsten 2 Jahren zu einem 24-Stunden-Betrieb zu kommen. Die Gründe dafür liegen, neben den Migrationsproblemen, in der vorher schon erwähnten BMP/Batch-Philosophie. Weil die "elapsed time" bei BMP ein Mehrfaches derjenigen unter Batch ausmacht, ist man zu IMS-Batch in vielen Fällen gezwungen, was zwangsläufig zur Sperrung von Datenbanken für den Online-Betrieb führt. Außerdem ist es unter IMS heute nicht möglich, Datenbanken Offline zu setzen, ohne den gesamten Online-Betrieb zu diesem Zwecke einzustellen, es sei denn, man nehme einige Risiken in Kauf.
Die Hilfsmittel für den IMS-Einsatz sind unbefriedigend. Die vorhandenen "Utilities" und "management-tools" vermögen nur ungenügend potentielle Verbesserungsmöglichkeiten aufzuzeigen. Man
muß - mit entsprechendem Aufwand - eigene Hilfsmittel entwickeln. Somit stehen sie meist nicht schon zu dem Zeitpunkt zur Verfügung, zu dem man sie am dringendsten benötigen würde.
Wenn man Zeit und Ruhe hat, d. h. nicht laufend neue Projekt-Teile einführen muß, lassen sich mit Ausbildung und Stabilisierungsmaßnahmen eine weit höhere System-Verfügbarkeit erreichen, als allgemein befürchtet wurde.
Wirtschaftlichkeits-Probleme: Kostenschätzung unmöglich
Das eigentliche Problem des IMS-Einsatzes oder des entsprechenden "System Environment" liegt in der offensichtlichen Unmöglichkeit, vorgängig und zuverlässig zu ermitteln, welche Kosten und welche Hardware-Bedürfnisse/Beanspruchungen für ein anspruchsvolles Projekt zu erwarten sind. Es bestehen keine erprobten Methoden, und es fehlt noch die nötige Erfahrung, mit der man früher fehlende Methoden schlecht und recht ersetzte. Dieser Sachverhalt ist grundsätzlich zwar nicht neu, hingegen sind die finanziellen Auswirkungen wesentlich größer, als sie bei analogen Fällen in der Vergangenheit waren.
Aber nicht nur seitens der Hardware, sondern auch seitens des Personalaufwandes sowohl für die Einführung als auch für den laufenden Betrieb liegt man beachtlich über den Erwartungen aus früherer Erfahrung.
Mit dem seit einiger Zeit in Mode gekommenen Kesseltreiben gegen IMS kann man - objektiv - nur beschränkt einig gehen. Naturgemäß werden vornehmlich Probleme und Enttäuschungen hervorgehoben, aber es ist nicht zu bestreiten, daß IMS große Möglichkeiten bietet und Lösungen erlaubt, die sonst kaum - mindestens jedoch nicht billiger - realisierbar wären.
Das Übel: Hang zu perfekten Lösungen
Wenn auch unbestritten ist, daß ein "IMS Online-Environment" höhere Betriebskosten bringt, als man errechnete, und die Leistungen der Computer nicht erbringen, was man erwartete, ist es nicht zulässig, die alleinige Schuld den Herstellern der System Software zuzuschieben. Schließlich wirken weltweit verschiedene Gremien (GUIDE/SHARE etc.) am Wachsen der System Software mit, indem laufend Anforderungen gestellt und seitens IBM akzeptiert werden (müssen), welche sich zwangsläufig in auszuführenden Instruktionen niederschlagen. Zudem läßt sich kaum abgrenzen, inwieweit System Software an sich oder der Hang zu perfekten Lösungen dazu führt, immer das ganze Inventar von Softwarefeatures auszunutzen. Selbst IMS-Transaktionen können nämlich effizient sein, wenn funktionelle Anforderungen nicht maximal gehalten werden.
Ich bin keinesfalls der Ansicht, daß die heutigen Betriebssysteme inkl. IMS als effiziente Software bezeichnet werden können, ich glaube aber auch nicht, daß - wie oft angedeutet wird - dahinter (Verkaufs-) Absicht steht. Vielmehr dürfte IBM dasselbe passiert sein wie jedem EDV-Anwender schon oft, nämlich bei einem komplexen Entwicklungs-Problem die Kontrolle zeitweise etwas verloren zu haben.
* Eduard W. Beer ist Vizedirektor und Chef der Datenverarbeitung bei der Swissair in Zürich.