Anwender einer IBM /36 haben es heutzutage nicht leicht. Sicher ist meist lediglich, daß das MDT-System an der Grenze seiner Kapazität anbelangt ist und daß Ersatz beschafft werden muß. Die Frage nach dem Ziel der Wanderung - der "Migration" - beantwortet sich jedoch nicht von allein. Zur rein blauen Lösung - AS/400 mit /36-Emulation beziehungsweise Neuentwicklung der Applikationen für IBMs Midrange-Bestseller - gibt es mittlerweile einige mehr oder weniger erprobte Alternativen Quellcode-Umsetzung in die Unix-Welt mit dem Paket Unibol, Entwicklung auf der /36 für die AS/400 als Zielmaschine (Asna) oder der Look-and-feel-treue Umzug in die DEC- Welt (VMS oder Ultrix), beispielsweise mit dem Digital- Vertriebspartner GST aus Göttingen. Über das jeweilige Für und Wider sowie eventuelle weitere Lösungen unterhielt sich die COMPUTERWOCHE mit /36-Anwendern und -Abwanderern sowie mit Partnern, die sie unterstützen. Die IBM bekämpft zunehmend das Image des Anwendungssystems /400 als eines weiteren proprietären Systems; die Anzeigenkampagne für die jüngst ausgelieferten neuen Modelle stellt die Offenheit der Architektur und des Betriebssystems, die leichte PC-Anbindung etwa, in den Vordergrund. Gleichwohl sind sich selbst eingeschworene "IBM-Fans" wie Erhard Eggert, DV-Leiter der Rödermarker Jado Design, Armatur und Beschlag AG, durchaus bewußt, daß sie sich "ein für allemal festgelegt" haben auf die AS/400.Jado hatte zwei /36-Maschinen im Einsatz, die irgendwann beide mit ihrer Kapazität am Ende waren.
Einen der beiden Rechner hat man inzwischen in Ruhe geschickt. Die Applikationen auf der noch vorhandenen alten Maschine werden momentan überarbeitet, um sie für den /36-Emulationsmodus auf der AS/ 400 vorzubereiten. Man nutzt aber die HW-Umstellung auch für eine Revision, indem man neue AS/400-Native-Anwendungen zukauft. Eggert geht davon aus, daß die Kapazitäten der neuen HW-Welt allemal ausreichen, auch zukünftigen Bedarf zu befriedigen. Bei den Aufrüstmöglichkeiten sieht er "das Ende der Fahnenstange" noch lange nicht erreicht. Allerdings, gibt er zu, computern IBM-Kunden nicht gerade billig.
Diese Erfahrung machte auch eine österreichische Wirtschaftsprüfungs-Gesellschaft; die Verantwortlichen dort rüsteten allerdings ihren /36-Nachfolger - eine AS/400-B20 für alles in allem rund 200 000 Mark nicht auf, als die Platte von war, sondern zogen eine auf den ersten Blick spektakuläre Konsequenz: Mit Hilfe eines freiberuflichen Programmierers optimierten sie ihre Anwendungen und gingen zurück auf eine /36 mit zwei Platten. Eine der COMPUTERWOCHE namentlich bekannte Mitarbeiterin berichtet, dieses Verfahren sei um die Hälfte billiger gewesen als der Zukauf einer zweiten Platte für die AS/400 (auf der die alten, noch nicht optimierten /36-Anwendungen emuliert worden waren). Die AS/400 des Anwenders steht übrigens weiterhin in Lohn und Brot - und zwar für Lohnabrechnung und Textverarbeitung, die im vorliegenden Fall auf der /36 nicht möglich sei.
Ludwig Schuster ist freischaffender Programmierer; er war der Dienstleister bei der Re-Migration auf die österreichische / 36, und ihn wundert die Systemnostalgie gar nicht: "Die /36-Emulation auf AS/400 ist nach meiner Erfahrung in der Regel spürbar langsamer als die /36 selbst. Man kann sich das eigentlich sparen. Will man emulieren und parallel dazu die Anwendungen für den Native-Modus neu entwickeln, dauert das unter Umständen Jahre und wird unbezahlbar", so der Praktiker.
Die "paar Prozent mehr Prozessorleistung" der AS/400 interessierten ihn gar nicht, denn die Platten seien nach wie vor dieselben, und hier liege in der Regel der Leistungs-Bottleneck. Bei kaufmännischen Anwendungen ist laut Schuster die Zentraleinheit zu 80 Prozent mit Plattenzugriffen beschäftigt. Seine Empfehlung an wanderungswillige /36-Anwender: Abwarten, bis etwas Besseres kommt als die AS/400.
Sind die Kapazitäten der alten Maschine offensichtlich ausgereizt, empfiehlt der Freiberufler den Anwendern, die Plattenbelegung und die Batch-Programme untersuchen und optimieren zu lassen. Damit, meint Schuster, könne häufig "eine Neuinvestition so lange hinausgeschoben werden, bis es etwas Vernünftiges im RISC-Bereich gibt". Momentan sieht er für diese Alternative allerdings noch ziemlich schwarz: Eine RISC-Lösung, zumindest von IBM, erwies sich als "Enttäuschung", so Schuster empört. Bedienerloser Druckerbetrieb in kaufmännischen Anwendungen etwa ist nach seinem Wissen nicht möglich. Darüber hinaus erhielt sein Verdacht, IBM habe kein Interesse an einer Förderung der RS/6000, auf der CeBIT neue Nahrung: "Als wir auf dem IBM-Stand waren und uns nach der RISC-Maschine erkundigen wollten", schildert Schuster, "sagte man uns: Nehmen Sie doch die AS/400."
Ähnliches bekamen auch die DV-Verantwortlichen eines der Redaktion bekannten Midrange-Anwenders zu hören allerdings von ihrer Geschäftsleitung. Die war von der IBM gebrieft, wie der betroffene DV-Chef der COMPUTERWOCHE berichtet. Er, der eine Unix-Lösung als /36-Nachfolge vorgezogen hätte, beansprucht Anonymität - um den Frieden am Arbeitsplatz zu wahren. Noch rettet der Open-Systems-Anhänger sich mit einer "bis zum Geht-nicht-mehr" hochgerüsteten /36er über die Runden. Er beklagt aber den täglichen Druck der IBM, die mit "hartem Zwang für die AS/400" arbeite, indem sie den Noch-/36-Anwendern die Unterstützung entziehe.
Vom Kosten-Nutzen-Standpunkt hat der Anwender sogar Verständnis, wenn "die IBM sich in ihren Entwicklungslabors die Arbeit dadurch erleichtert, daß sie nur noch AS/400Anwendungen schreibt und die restlichen /36er auch dahinzwingt". Unfair findet er es aber, daß Alternativen, wie etwa die Migration auf Unix via Unibol, von der "IBM massiv behindert werden", wie er erfahren hat. Der Asna-Lösung (RPG-III-Entwicklung für die AS/400 auf der /36) mag er aus eigener Erfahrung nicht über den Weg trauen: Eine richtige AS/400-Anwendung könne man damit nicht entwickeln, obwohl das Tool eine Menge Funktionen abdecke. Man dürfe sich keinesfalls "blind darauf verlassen, was einem die Anbieter erzählen". Wolfgang Siegmund, auf die AS/400-Welt spezialisierter DV-Berater aus Schenefeld bei Hamburg, ist natürlich prinzipiell von IBMs Midrange-Alternative überzeugt. Gleichwohl zieht er es vor, ausschließlich mit den Anwendern zusammenzuarbeiten; eine vertragliche Bindung mit der IBM möchte er nicht eingehen, um so unabhängig wie möglich zu bleiben.
Das Ziel einer /36-Migration ist für ihn keine Frage, einen Königsweg gebe es jedoch nicht. Es müsse zwischen den Alternativen /36-Emulation und Neuentwicklung für den AS/400-Native-Mode abgewogen werden. Neuentwicklungen, so Siegmunds Ratschlag, machen dann am meisten Sinn, wenn schon die alten Anwendungen "strukturiert programmiert und sauber dokumentiert" sind. Software mit diesen Merkmalen gebe es in der /36-Welt durchaus. Waren allerdings bei der Entwicklung "echte Programmierer" am Werk, für die Kommentarzeilen und eine nachvollziehbare Programmstruktur unnötiger Luxus sind, sieht es anders aus. Eigner solcher Applikationen, empfiehlt Siegmund, "tun gut daran, zunächst die /36-Umgebung auf der AS/400 weiterzufahren".
Die gleiche Überlegung führt den Consulter auch dazu, die blaue Lösung einer anderen Architektur, etwa auf VMS- oder Unix-Basis, vorzuziehen: "Wenn die Leute irgendeine uralte RPG-Gurke haben, dann ist es schon in ihrer gewohnten Umgebung schwer genug für sie", stellt er fest und fragt: "Um wieviel größer werden diese Probleme wohl erst, wenn diese Leute auf ein völlig neues System umsteigen?"
Der Klage vieler Emulierer, sie benötigten mit ihrer alten Maschine eine AS/400 mit unangemessen großer Hardwarekapazität, hält der Berater entgegen, das müsse kein so großes Problem sein: Beschränkung auf das für den DV-Betrieb Notwendige sei die Devise. "Wenn sie allerdings alles installieren, was die IBM so bietet, dann dürfen sie sich nicht wundern, wenn die Platte überlastet ist", warnt er.
Solche praktischen Überlegungen sollten nach Siegmunds Ansicht grundlegend für eine Investitionsentscheidung sein. Gleichwohl, lenkt er mit Blick auf die Frage der Systemoffenheit ein, befinde man sich mit der AS/400 "auf einer Schiene, von der man nicht ohne weiteres ausweichen kann". Technisch, meint Siegmund, könne die AS/400 genauso offen sein wie jedes RISC-System - wenn die Hersteller mitspielen würden. Aber da kämen "natürlich wirtschaftliche Überlegungen mit ins Spiel", gibt der Berater zu bedenken.
Systemoffenheit ist für viele AS/400-Anwender offenbar gar kein Thema. Holger Diekow zumindest, DV-Koordinator beim Heppenheimer Arzneimittelvertrieb Upjohn GmbH, fühlt sich wohl in seiner DV-Umgebung. Wie die nach der Abschaffung der /36 aussehen würde, darüber hatte er ohnehin nicht zu befinden. Direkt nach der Ankündigung der Architektur, berichtet Diekow, sei von seiten der amerikanischen Upjohn-Mutter die Entscheidung gefallen, "das System als strategische Hardwareplattform einzusetzen". Diekow hatte also keine Alternative, vermißt eine solche aber auch nicht: "Wenn ich selbst hätte entscheiden müssen, wäre ich auch auf die AS/400 gegangen", bekräftigt er.
Das gleiche Ziel, nur mit mehr Aufmerksamkeit für mögliche Alternativen, steuert Jürgen Lauth an. Der DV-Chef und AS/400-Anwender beim Waagen-Hersteller Soehnle GmbH kommt von der /36 und fährt bis zur endgültigen Ablösung auch noch ein Exemplar dieser HW-Gattung.
Vor der Entscheidung, den ,blauen Weg fortzufahren, berichtet Soehnle, hat man im schwäbischen Murrhardt verschiedene Alternativen "analytisch untersucht". Dabei habe man sich konzentriert mit dem Unix-Weg befaßt, so Lauth, denn "die fortschreitende Marktakzeptanz von Unix ist unübersehbar".
Rein wirtschaftliche Gründe sprachen bei Soehnle letzten Endes für IBMs Angebot: Die weiterhin verwendbare Peripherie inklusive Verkabelung sei etwa von Bedeutung gewesen, vor allen Dingen jedoch die Softwarekosten:
"Man hat diverse bezahlte Lizenzen für Anwendungsprogramme, die ja meist hardwaregebunden sind, wenn sie von der IBM kommen", gibt Lauth zu bedenken. Sie könnten ohne lizenzrechtliche Probleme nicht einfach auf anderen Systemen lauffähig gemacht werden. Neue, andere Anwendungssoftware bedeute nicht nur höhere Lizenzkosten, sondern auch weitere Risiken sowie den Zwang zu einer kompletten Umschulung der Fachbereiche.
Ganz banale, aber kaum zu überwindende Hindernisse können es Lauth zufolge sein, die einer Migration bestehender Anwendungen in eine andere Systemwelt entgegenstellen: "Bei keinem Standardpaket der Welt garantiert Ihnen jemand, daß Sie hundertprozentig alle Sourcen bekommen", und ohne die gehe nichts, konstatiert der Soehnle-Mann. Unibol als Wanderstab hat er sich nach eigenem Bekunden Ende 1990 angesehen, und zwar in Form des Sinix-Derivates auf SNI-Hardware. Sein Urteil: "Die Programme laufen in einer in sich abgeschlossenen Umgebung auf den Unix-Rechnern." Die vollständige Funktionalität (zum Beispiel im Hinblick auf QUERY oder IDDU) habe damals noch Wünsche offengelassen.
Das Streben nach Systemoffenheit schätzt Soehnles DV-Chef zwiespältig ein. Unix wäre für ihn durchaus eine überlegenswerte Alternative, wenn er in der Situation wäre, eine DV "auf der grünen Wiese" neu aufstellen zu können. Das offene System gibt es nach seiner Überzeugung indes nicht. So ist es ihm ein "echter Dorn im Auge", daß etwa die Unix-Derivate häufig nur den Kernel gemeinsam haben und Anwendungen nur dann portierbar seien, wenn sie nicht in der Shell, sondern auf Kernel-Ebene programmiert würden. Das aber sei ungleich aufwendiger oder gegebenenfalls mit funktionalen Restriktionen oder Komforteinschränkungen behaftet. "Wenn Anwender, die auf einer bestimmten Unix-Umgebung entwickelt haben, quasi über Nacht auf eine andere Unix-Umgebung wollen, dürfte das meist nicht ohne Probleme gehen", ahnt der Soehnle-Mann und leitet daraus folgenden Schluß ab: "Damit sind wir wieder in einer proprietären Welt". Aus welchem Grunde sonst, fragt Lauth suggestiv, rühme sich wohl "ein berühmter Datenbankanbieter", alle Unix-Derivate zu vereinen. Ein mittelständisches Unternehmen könne sich keine aufwendigen "Hardware- und Schnittstellen. Basteleien und Experimente" leisten.
In Deutschland gibt es bisher erst ein Beispiel für einen /36-Anwender, der seine Anwendungen 1:1 auf eine DEC-VAX unter VMS portiert hat: die Otto Bock Orthopädische Industrie GmbH & Co. in Duderstadt. Mit Hilfe des Migrationspaketes "GST-Convert" auf der Basis eines DEC-Compilers - von der Göttinger Gesellschaft für Softwaresysteme und -Technologien mbH (GST) konvertierte Reiner Sangmeister 100 MB an Programmen: "Ungefähr 1100 Online-Programme, 2000 Prozeduren, zirka 500 Masken und etwa 200 Kommandoprozeduren", zählt der DV-Chef des südniedersächsischen Unternehmens auf.
Drei bis vier Tage habe das Umkopieren der Programme auf die Platte der VAX -gedauert; das eigentliche Umsetzen mit GST-Convert, so Sangmeister, sei in zwei Nächten durch gelaufen. Ein verlängertes Wochenende sei zusätzlich dafür draufgegangen, die Daten von der /36 herüberzuschaufeln. Vorangegangen ist nach Sangmeisters Bericht eine Testphase von etwa einem halben Jahr, in der mit Dummy-Daten sowie mit Kopien der Masken, Prozeduren und Programme der Ernstfall geprobt wurde. Die bisherigen Erfahrungen, so Sangmeister, konnten ihn zufriedenstellen.
Für Otto Bocks Migrationshelfer, die GST, ist als Digital-Vertriebspartner "die Fokussierung auf DEC eine strategische Frage", so Geschäftsführer Reinhard Lorentz. Daher werde es neben der VMS-Version auch kein GST-Convert für ein anderes Unix als DEC-Ultrix geben. Er hält es aber auch für entscheidend, Oberhaupt eine praktikable Alternative zur AS/400 anzubieten.
Die Emulation von Betriebssystem und Anwendungen der /36 auf dieser Maschine findet er verfehlt: "Monströse Überkapazitäten von bis zu 60 Prozent" seien erforderlich und machten diese Lösung extrem unwirtschaftlich. Außerdem sind die AS/400 und die /36 so verschiedene Maschinen, daß im Emulationsmodus die /36 Anwendungen auf der neuen "nicht wiederzuerkennen" seien - entgegen anderslautenden Berichten.
RPG-Anwendungen von er /36 auf den Native-Modus der AS/400 umzustellen, da haut Lorentz in die gleiche Kerbe wie Ludwig Schuster, sei wirtschaftlich nicht vertretbar: Ein Anwender aus seiner Bekanntschaft zum Beispiel sitze seit etwa anderthalb Jahren daran. Wegen der Unterschiedlichkeit der Hardware, meint Lorentz) sei "das so ziemlich das Komplizierteste, was man machen kann", und nicht zu bezahlen.