Man stelle sich ein DV-System vor, das maximal 8 MB Hauptspeicher hat, dessen Programme dort aber nicht mehr als 64 KB belegen dürfen. Ein Mehrplatzsystem, das nicht mehr als acht Arbeitsplätze unterstützt, dessen Programme seit Jahren nicht mehr weiterentwickelt wurden, das die Daten nicht von den Anwendungen trennt, mit dem weder Client-Server-Ansätze noch eine funktionale PC-Anbindung möglich ist, geschweige denn E-Mail- oder Faxintegration.
Die Steinzeit? Mitnichten - die Rede ist von mehreren tausend IBM-S/36-Maschinen, die in Deutschland immer noch im Einsatz sind. Kaum zu glauben, aber die ehemals heißen Kisten versehen immer noch ihren Dienst, selbst in ansonsten durchaus modernen DV-Umgebungen. Reginald Alberth, technischer Direktor der AS/400-Anwendervereinigung Common, weiß gar von Installationen zu berichten, die durch wilden Zukauf von gebrauchten "36ern" langfristig überleben sollen. Insbesondere im Handel, aber auch bei Banken - etwa für die Auslandsabrechnungen - stehen sie noch, Abteilung modernes Antiquariat mit beschränktem Nutzwert. Denn es gibt keine Zukunft mehr für S/36-Anwendungen.
Zumindest nicht, wenn sie noch auf den ihnen einmal zugedachten Maschinen laufen. Nicht nur, daß seit Jahren keine neuen Applikationen mehr entwickelt werden, auch der technische und administrative Support wird immer schlechter und teurer, wie eine Studie der D. H. Andrews Group feststellt. Und weil die "Mühlen" eben schon so lange laufen, werden sie anfälliger für Ausfälle. Auch der Stromverbrauch ist hoch, deutlich höher als etwa der einer AS/400 mit ähnlicher Ausbaustufe - obwohl es die gar nicht gibt, so leistungsschwach wie die S/36 war eine AS/400 noch nie.
Also ein teures Vergnügen, sich heute noch eine solche Maschine zu leisten. Aber das Beharrungsvermögen der typischen S/36-Klientel ist beachtlich, wie ein IBM-Sprecher - und nicht nur der - seufzend feststellt. "Viele Anwender stellen keinerlei Ansprüche an Modernität", so etwa Alberth. "Sie sind zufrieden, wenn ihre Software läuft, freuen sich an der Zuverlässigkeit und einfachen Bedienung ihrer Maschinen." Leider seien die Systeme ziemlich unzerstörbar, so Michael Stockmann vom AS/400-Marketing, "und gerade der kleinere Mittelstand kümmert sich nicht sonderlich um IT".
Das gilt offenbar selbst für drängende DV-Probleme, etwa dem der Datum-2000-Umstellung. Der Systemverantwortliche eines S/36-Kunden: "Jahr 2000? Welches Problem?" Recht blauäugig, denn beinahe alle Anwender müssen sich auf die Suche nach neuen Applikationen machen. Umschreiben ist häufig nicht mehr möglich: Die Sourcecodes sind nicht mehr zu finden.
Die S/36 substantiell anders als die /38
Innovationen werden häufig nur dort erwogen, so IBM-Marketier Stockmann, wenn ein unmittelbarer Zwang dazu besteht, mithin die Systeme partout nicht mehr genügend Kapazität bieten oder wirklich kurz davor sind, ihren Geist aufzugeben. Das ist aber nur ein Teil der Wahrheit.
Der Rest der Geschichte lautet, daß eine naheliegende Migration, nämlich die auf den "Nachfolger" der S/36, die AS/400, anfangs kein angenehmes Unterfangen war. Nachfolger steht hier in Anführungszeichen, denn das weltweit inzwischen 400000mal installierte Mittelstands-Zugpferd der IBM ist eigentlich das Folgesystem der /38 und eine substantiell andere Maschine als die S/36, wie der Andrews-Report betont.
Trotzdem gab es einen Migra- tionspfad für S/36-Anwender, der auf den ersten Blick sinnvoll erschien und der auch nach der Einführung des Flaggschiffs im Jahr 1988 vieltausendfach beschritten wurde. Und zwar allein bis Ende 1993 weltweit 70000mal. Die S/36-Anwendungen liefen dabei in einer Art Emulation im sogenannten S/36-Environment, einem Software-Layer in OS/400. Dort liefen sie zumeist langsam, ziemlich langsam zum Ärgernis vieler Kunden. Zudem benötigten sie deutlich mehr Ressourcen als vorher, insbesondere in puncto Plattenbedarf, weil die Programmobjekte größer wurden.
Diese Art der Migration hatte schnell einen schlechten Ruf, und die Firma IBM brillierte damals nicht gerade bei dem Versuch, auf die Sorgen und Nöte ihrer Kunden einzugehen. Der Ansatz hatte laut IBM-Sprecher Peter Reichert aber auch sein Gutes, wenn man es denn so nennen will. Der Druck auf die Anwender, auf native AS/400-Applikationen und damit in eine zukunftsträchtigere Umgebung umzusteigen, war hinreichend groß, dieses auch zu tun. Doch die Alternative zur Alternative hatte nicht nur Attraktives zu bieten: Die Anwendungen auf die AS/400 zu migrieren oder sie zu wechseln bedeutete anfangs einen erheblichen Aufwand, zudem waren Neuschulungen für Bediener und Operatoren fällig.
1994 - zu spät, wie manche Analysten meinen - wurde alles anders: Die neu eingeführte AS/400 Advanced 36 fegte sämtliche Migrationsprobleme vom Tisch. OS/400 und SSP, das S/36-Betriebssystem, laufen beide - inzwischen sogar parallel - auf einer Grundlage. Dieser endlich gefundene Stein der Weisen schlummerte schon lange in den Schubladen Rochesters, ehe sich der deutsche IBM-Vertrieb bequemte, die Systeme auch anzubieten. Hurtig reagierte Big Blue erst, wie Alberth zu berichten weiß, als mancher Anwender begann, auf Fremdplattformen umzusteigen.
Von "Tausenden zufriedenen Kunden" spricht IBM, die nun mit der RISC-CPU des Power-PC (im neuesten Modell 436) einer glorreichen Zukunft entgegensahen. OS/400 ist in der Lage, SSP-Programme aufzurufen; damit war die Integration der alten Anwendung in eine moderne IT-Umgebung gewährleistet. Aus dem Dilemma der extremen Hardwarelimitationen wurden die S/36-Kunden ebenfalls befreit.
Auf der Hybrid-AS/400 stehen nun maximal 96 MB RAM, 4 GB Plattenkapazität und bis zu 160 Twinax-Adressen (beim Modell 436) zur Verfügung. Die Applikationen laufen eins zu eins, Umstellungen sind nicht erforderlich. Die Performance steigert sich dabei um den Faktor acht bis 30 (im Batch-Betrieb), so die IBM-Angaben; D. H. Andrews errechnete einen durchschnittlichen Leistungsgewinn um den Faktor drei. Raid 5 und Plattenspiegelung waren plötzlich auch kein Wunschthema mehr.
Ein Anwender dieser Lösung ist zum Beispiel die Liebenzeller Mission. Das international tätige Missionswerk hat 1994 eine Ad- vanced 236 eingeführt; 70 Arbeitsplätze, Standard- sowie selbstentwickelte Software laufen nun unter SSD und OS/400. Vor allem über die Performance äußert sich der Anwender höchst positiv. Im Februar letzten Jahres kam auch ein Modell 436 hinzu, das noch schneller läuft. In näherer Zukunft plant man eine Konsolidierung der Server von drei auf einen, die Integration von Mail und Kalender aus Office/400 in alle Anwendungen sowie die Fax- und E-Mail-Integration.
Einmal auf einer Advanced /36, sei der Aufwand für die "schleichende" Migration der Altanwendungen auf OS/400 dann minimal, so IBM-Mann Reichert. Lediglich das Datei-Management der /36 müsse in das Datenbank-Management der AS/400 gebracht werden, und dies sei eine einfach zu bewerkstelligende Konversion.
Doch auch hier zeige sich wieder ein schier unglaubliches Beharrungsvermögen der Kunden, so Reichert. Viele lassen ihre S/36-Anwendungen unverändert. Mit den bekannten Problemen: Datum-2000-Lösungen oder innovative IT-Ansätze sind Fehlanzeige. Den Kunden müßten - am besten über Referenzinstallationen - die Vorteile neuer Technologien gezeigt werden, damit sie zu Veränderungen bereit seien. Lösungen zur Anbindung oder Einbindung der alten Anwendungen würden akzeptiert, wenn sie handfeste Vorteile brächten. So etwa, wenn die alte Anwendung mit einem Wireless-LAN (via OS/400) eine tolle Lösung fürs Lager bringt. Das wird gewollt.
Die dritte Möglichkeit, der S/36-Zukunftsfalle zu entkommen, ist die Migration auf Unix oder ein PC-LAN. Tools zur Migration oder für den Ablauf der Altanwendung in einer S/36-Emulationsumgebung sind vorhanden: So etwa das aus Irland stammende "Unibol", vertrieben und betreut von SNI. Oder "Open /36" von Universal, das ebenfalls die Ursprungsanwendung in ihrer bisherigen Form unter Unix abbildet.
Solche Lösungen, favorisiert nur von einer Minderheit der S/36-Nutzer, scheint IBM nicht immer gern zu sehen. So berichtet ein Kunde, der AS/400-Vertrieb habe ihn massiv unter Druck gesetzt, als er von S/36 auf AIX wechseln wollte. Er werde große Probleme bekommen, die Lösung werde nicht laufen, er möge doch lieber die "sichere" AS/400 in Erwägung ziehen. Das tat er nicht, ist hochzufrieden mit Funktionalität und Performance des Emulators und hat die Option, seinen RPG-Code nach C und damit in eine offene Umgebung zu migrieren.
Auch Reichert erkennt allerdings Gründe, die eine Migration auf andere Plattformen sinnvoll machen: Insbesondere Kunden, die ihre S/36 nur noch als Batch-Maschine im Hintergrund laufen lassen und schon eine neue IT-Infrastruktur errichtet haben, müssen den Methusalem rausschmeißen, wenn sie konsolidieren wollen. Die neue Struktur könne eine AS/400, ein Unix- oder NT-System sein. Reichert erkennt aber durchaus eine Konkurrenzsituation im eigenen Hause: Unix- und NT-Server hat Big Blue schließlich auch im Angebot.
Doch deren Angebot ist schwer an den (S/36-)Mann zu bringen. Auch Karlheinz Peter, Geschäftsführer des Softwarehauses PKS, das sich auf die Migration von AS/400- und S/36-Anwendungen auf NT oder Unix spezialisiert hat, bestätigt das Beharrungsvermögen dieser Klientel. Das schwäbische Unternehmen arbeitet jetzt mit dem Source-Konverter "AX/Ware", der den Quellcode in MF-Cobol/2-Sourcen wandelt und dann auf die Zielplattformen AIX, HP-UX und NT migriert. Kunden sind vor allem Softwarehäuser, die ihre AS/400-Branchenlösungen auf weiteren Plattformen (vor allem NT) anbieten wollen, aber auch größere Endanwender.
Peter sieht einen Willen zur Veränderung vor allem da, wo neben einer S/36 (respektive einer Ad- vanced /36 oder einer AS/400) schon zusätzliche IT-Komponenten installiert sind, was allerdings häufig der Fall sei. Dort würden Client-Server-Konzepte, Intranets, vielfach auch Lösungen für Windows NT (nicht aber für Unix) gewünscht, die alten Maschinen als Fremdkörper empfunden.
Häufig können Anwender auf die alte Software aber nicht verzichten, weil es eine auf die individuellen Bedürfnisse zugeschnittene Lösung war, die durch keine Standardsoftware ersetzbar ist. Dann werde eben migriert und die Applikation in die neue Umgebung eingebunden. Doch diese flexibelste aller Optionen wähle nach wie vor nur eine Minderheit, so Peter.
Performance-Probleme inzwischen behoben
Folgt man IBM, gibt es dafür gute Gründe: Schließlich lassen sich PC-LANs, Windows-95- oder -NT-Clients über eine AS/400 hervorragend integrieren. Durch die Implementierung von Standards wie TCP/IP oder SQL sei die Plattform offen für innovative IT-Konzepte. Und die früher bemängelten Performance-Probleme dieser Features seien inzwischen behoben. Selbst ein NT-Port auf dem optionalen, integrierten PC-Server der AS/400 soll in weniger als einem Jahr verfügbar sein.
"In dieser Umgebung profitiert der Anwender von der Sicherheit und Robustheit der AS/400, ohne auf offene Konzepte und Standardsoftware verzichten zu müssen", erklärt IBM-Sprecher Reichert. "Warum also nicht diese Option wählen?" Fragt sich nur, warum plötzlich so viele AS/400-Softwarehäuser unbedingt NT als zusätzliche Plattform anbieten wollen...
Angeklickt
Den Anwendern der S/36, und das sind immer noch etliche tausend von einst 70000, bescheinigen auch IBMer eine geradezu unglaubliche Ausdauer. Unbeeindruckt von heute anachronistischen Defiziten machen sie mit ihrem System weiter. Big Blue ist es - nicht zuletzt wegen des eigenen lange Zeit bestenfalls halbherzigen Migrationsangebots - nicht gelungen, die Anwender zum Wechsel auf die AS/400 zu bewegen. Inzwischen haben sich die Möglichkeiten deutlich verbessert - aber auch die der Alternativen wie beispielsweise Unix und Windows NT.
*Levi Stein ist freier Journalist in München