Das Motto "Verändere nie ein lauffähiges Programm" behält seine Gültigkeit

SAA: Altlastenproblem vorläufig unbewältigt

15.09.1988

"Inkompatibilitäten beseitigen" lautet der Anspruch, mit dem die Systems Applications Architecture (SAA) die gestandene IBM-Welt revolutionieren will. Doch das theoretisch Vernünftige erweist sich in der Praxis oft als unrealistisch. "Kommt der SAA-Zug ins Stolpern, noch bevor er richtig gestartet ist?", fragt Günter Szameikat*.

Wenn SAA nur ein Marketing-Gag ist, wird die Frage nach der Motivation von IBM auch für den Anwender langsam interessant. Denn da wird ein Ziel verkündet, das selbst die treuesten DEC- und Unix-Apostel ins Schwitzen bringt: Verfügbarkeit portabler Anwendungssoftware, die sich beliebig auf jeder Rechnerebene einsetzen läßt.

Es ist sicher kaum anzunehmen, daß diese Zielsetzung von IBM dem hehren Wunsch nach Beglückung des Anwenders entspringt. Dem widersprechen alle Erfahrungen aus 30 Jahren monopolisierter Datenverarbeitung. Und auch neue Märkte sind nicht in Sicht, die ein derartiges Engagement lohnen würden. So bleibt als Begründung nur die Verteidigung bestehender Märkte gegen Druck von außen.

Aufsässigkeit üben dabei vor allem zwei Zielgruppen, die bisher für IBM wenig attraktiv waren: Fachabteilungen und Endanwender. Sie sind es, die die Probleme heutiger SW-Produktion am stärksten zu ertragen haben. Weil ihr Informationsbedarf explosiv wächst, geht die fehlende Manpower für Neuentwicklungen und Maintenance vor allem auf ihre Kosten. Software-Engpässe versperren den Ausweg in Richtung Dezentralisierung, zumal hier zusätzliche Schulungs- und Wartungsprobleme auflaufen.

Dieser Druck entlädt sich in der Forderung nach Software, die einheitlich ist in puncto Bedienung und Benutzeroberfläche, sowie in Funktionalität und Performance. Dabei darf es keine Rolle spielen, ob ein PC oder ein Mainframe-Terminal am Arbeitsplatz steht. Die Fachabteilung fordert Dienstleistung und trifft damit, weil sie die Art der Implementierung von Software völlig ignoriert, exakt den schwächsten Punkt: die Abhängigkeit von bestehenden Programm-Ressourcen in den IBM-Rechenzentren.

Das Kernproblem ist dabei der Riesenberg individueller Sourcen, auf dem jeder sitzt, der kommerzielle Applikationen zentral betreut. Als Arbeitsinstrument hat er jedoch nur eine kleine Handschaufel - seinen Editor für Cobol, Assembler oder PL/1. Damit den ganzen Berg entsprechend den Forderungen aus der Fachabteilung umzuschichten und anzupassen ist schlichtweg absurd.

Kann SAA der Hoffnungsschimmer am Horizont der Anwender sein? Im Rahmen realistisch überschaubarer Zeiträume muß die Antwort eindeutig lauten: "Nein." Denn zumindest im Hinblick auf die Beseitigung des Altlastenproblems gehen alle Kompatibilitäts-Bestrebungen an der gegebenen Situation vorbei.

Individuelle Sourcen überwiegend in Cobol

Zur Verdeutlichung mag ein Ausflug in das SAA-Cobol-Konzept dienen: Der überwiegende Teil der individuellen Sourcen ist in Cobol erstellt, womit dieser Sprache eine Schlüsselrolle im SAA-Szenario zufällt. IBM rückt sie deshalb deutlich in den Mittelpunkt und verspricht die mittelfristige Verfügbarkeit entsprechender Tools auf Systemen, die als SAA-fähig erklärt werden.

Damit bekäme dann der Programmierer eine Basis, um auf allen "Baustellen" gleichzeitig arbeiten zu können - vorausgesetzt, er benützt ein SAA-kompatibles Cobol zur Implementierung seiner Applikation. Es wäre ihm möglich, auf einem PC mit entsprechenden SAA-Tools die Anwendung zu entwickeln und dann nach geeigneter Konvertierung mit der Source auf den Großrechner zu wandern. Auch der umgekehrte Fall ist denkbar, denn jede mit einem SAA-kompatiblen Editor erstellte Source soll auf beliebigen SAA-kompatiblen Cobol-Compilern laufen.

So weit, so gut, wären da nicht die für alle Kompatibilitäts-Bemühungen notwendigen Kompromisse. Hinsichtlich der Hardware-Systemumgebungen sind die geringsten Probleme zu erwarten. Mit der Ablösung der /36- und /38-Systeme durch die AS/400-Reihe findet der Programmierer inzwischen Ressourcen vor, die sich von unten (PS/2 mit OS/2) nach oben (3090 mit MVS/XA) durchgehend vergrößern. Und selbst wenn nicht alle Umgebungsbedingungen vorliegen (zum Beispiel beim PC), so sind sie dort doch zumindest definierbar.

Ganz anders ist die Situation beim eigentlichen Cobol-Sprachumfang. Hier werden in SAA Limits und Spezifikationen gesetzt, die in etwa denjenigen von typischen PC-Cobol-Compilern entsprechen. Damit lassen sich PC-Anwendungen ebenso wie /3X-Anwendungen relativ leicht umbauen, weil die existierende Software im Sprachumfang weitestgehend auf einer Teilmenge von SAA-Cobol basiert.

Dramatisch sind dagegen die Unterschiede der Mainframe-Cobol-Versionen zum SAA-Cobol. Das gilt vor allem für OS/VS-Cobol, das etwa 95 Prozent Anteil am gesamten heute bestehenden Cobol-Programmvolumen bei Großrechner-Anwendungen hat. Genau diese Applikationen sind meist bis ins Letzte auf Performance getrimmt. Die Konsequenz: Eine Umstellung der Altsoftware ist gleich-bedeutend mit Leistungsverlust und kompletter Neuprogrammierung.

Daß sich darauf kein Rechenzentrum einlassen wird, läßt sich unschwer voraussagen. Bis auf den Bereich klassischer Neuentwicklung - und dort auch nur, wenn kein absolutes Ausreizen der Leistungsgrenzen gefordert ist - dürfte der Einsatz von SAA-Tools bei großen IBM-Anwendern mittelfristig auf engste Grenzen beschränkt bleiben. Das Motto: "Verändere nie ein lauffähiges Programm!" behält hier seine Gültigkeit.

Deshalb SAA schon abzuschreiben, wäre allerdings genauso verkehrt. Der Kriegsschauplatz ist nur ein anderer: nämlich der Markt der Software- und Systemhäuser, in dem Standards und Normen regieren.

SAA ist Aufforderung an die Softwarehäuser

Die Systems Applications Architecture stellt heute primär eine Aufforderung an die Softwarehäuser dar, Applikationen für alle drei (IBM-) Welten zu entwickeln. Zu diesem Zweck bietet das SAA-Konzept den SW-Schmieden eine wesentlich verbreiterte Implementationsbasis, ohne daß umfangreiche Investitionen in Hardware und teure Entwicklungszeiten für jede Rechnerebene erforderlich würden.

Dieses Angebot steht in direkter Verbindung mit dem Versuch, via SAA im Markt eigene Standards zu setzen beziehungsweise bestehende Normen einzugrenzen. Gleichzeitig bleiben Schlüsselteile von SAA auf IBM-Maschinen beschränkt, so daß enorme Programmierkapazitäten gebunden und von konkurrierenden Konzepten - insbesondere von Unix - abgezogen werden.

Ob diese Rechnung allerdings so aufgeht, ist noch längst nicht entschieden. Daß man hier bei IBM im Vergleich zu früheren Jahren vorsichtiger geworden ist, zeigen die deutlichen Tendenzen, sich in Teilbereichen von SAA an aktuellen Standards zu orientieren.

So geht zum Beispiel aus der SAA-Cobol-Referenz eindeutig hervor, daß der Sprachumfang eines SAA-Cobol-Compilers dem der ANSI-Norm '85 Intermediate Level entspricht, ergänzt durch zusätzliche Anforderungen aus Teilen der High Level Extensions. Unabhängig von allem SAA- oder OSF-Getöse kommt IBM offensichtlich nicht mehr an der eigenständigen Bedeutung von ANSI vorbei. Vergleichbares ist auch bei anderen Programmiersprachen oder bei SQL zu beobachten.

Wenn ein Programmierer im SAA-Modus arbeitet, kann er somit sicher sein, auf der richtigen Seite zu stehen. Da diese Normanpassung aber stets mit einem reduzierten Sprach- und Funktionsumfang einhergeht, dürften sich viele Softwareanbieter zunächst nur zu einer überwiegenden "Me-too"-Argumentation entschließen können. Ein Produkt wird zwar SAA-fähig angeboten, aber wenn höchste Performance und Funktionalität gefragt sind, bleibt die SAA-inkompatible Lösung immer noch erste Wahl.

Neben der einschränkenden Leistungsausprägung sorgt auch die

wachsende Attraktivität des Unix-Marktes dafür, daß Entwicklungs-kapazitäten zunächst nur teilweise auf SAA konzentriert werden. Vor allem Anwender mittlerer Systeme und Behörden üben einen immer stärkeren Druck auf die Anbieter aus, Software für ihre Unix-basierenden Multi-Vendor-Konzepte zu liefern.

Selbst IBM scheint hier Befürchtungen zu hegen, wie die AIX-Announcements in Verbindung mit der OSF-Offensive sehr deutlich zeigen. Diese Zangenbewegung, SAA von oben und AIX von unten, könnte durchaus einige Anwender zurück in die Arme der großen Mutter treiben. Doch letztendlich muß IBM via AIX eine weitere Schwächung von SAA in Kauf nehmen.

Aber trotz allem wird SAA seinen Weg machen - langsam und gemächlich. Dies gilt beispielsweise für das Rechenzentrum, wo man zumindest den absolut unabweisbaren Anforderungen der Fachabteilungen mit abwärtskompatiblen Neuentwicklungen begegnet. Wenn SAA dabei in drei Jahren einen 30prozentigen Anteil an der gesamten Neuprogrammierung ausmacht, sollte IBM sehr zufrieden sein.

Ähnliches gilt für die Software- und Systemhäuser, bei denen die Chance auf neue Märkte im Widerstreit liegt mit dem migrationswilligen Unix-Potential. Realistisch erscheint hier ein Zeitraum von sechs bis acht Monaten bis zur Vorstellung SAA-fähiger Tools. Anschließend ist noch einmal etwa der gleiche Zeitraum bis zur Marktreife entsprechender Applikationen zu veranschlagen.