Ein Systemwechsel verläuft selten ohne Probleme. Das gilt auch für den Umstieg von einem /3x-System auf die AS/400. Vor allem /36-Anwender stehen häufig vor einem Dilemma: Um ihre Software-Investitionen zu schützen, betreiben sie die teure neue Maschine als /36. Wozu dann die Ausgaben? Hans-Henning Schrader* empfiehlt den umgekehrten Weg - eine /36 als AS/400 zu nutzen.

Zur Zeit der Ankündigung der AS/400 regierte das Pathos, zum Beispiel in Form von Shakespeare-Zitaten: "Dies Königskind...in seiner Wiege noch, verspricht doch schon dem Land vielfachen Segen, den Zeit zur Reife bringen wird" (Heinrich VIII., 5. Akt, 4. Szene) - so zitierte die US-Computerzeitschrift NEWS 3X/400 in ihrem Spezialheft vom August 1988.

Nun weiß man von Elisabeth I. von England. deren künftige Bedeutung Shakespeare hier nach ihrer Geburt vorhersagen läßt, daß auch sie einige verwirrte und weniger erfolgreiche Jahre durchstehen mußte, bevor sie weltgeschichtlichen Ruhm erlangte. War das Zitat mitsamt der darin versteckten Ironie berechtigt? Darauf gibt es, wie meist im Leben, mehrere Antworten, die alle ihren Sinn haben.

Mit AS/400 nicht immer ein nahtloser Übergang

Bleiben wir zunächst einmal beim Pathos: Kaum jemand wird bezweifeln, daß die Welt der mittelgroßen Systeme durch die AS/400 entscheidend verändert wurde. Die IBM hat mit der Maschine einen Kraftakt vollbracht, der bereits mit der Konstruktion der legendären /360 verglichen wird. 6,9 Millionen Lines of Code machten bei Vorstellung der AS/400 am 21. Juni 1988 das Betriebssystem aus, das damit als das größte Software-Projekt in IBMs Geschichte gilt.

Wie hat der Markt diese Maschine aufgenommen? Bevor man hierzu etwas sagen kann, muß man wissen, daß die AS/400 nicht nur den sogenannten "Native Mode", also den eigenen "eingeborenen Modus" beheimatet, sondern auch darüber hinaus den /36er-Mode und den /38er-Mode, der beiden Vorläufermodelle im Bereich der mittleren Systeme. Wir haben es demnach nicht mit einem Markt zu tun, sondern genau genommen mit drei Produkten und infolgedessen mit (mindestens) drei Märkten, die die IBM langfristig zu einem zusammenzufassen sucht.

Daß die AS/400 nicht für jeden ein nahtloses Nachfolgemodell seines mittelständischen IBM-Rechners ist und auch nicht unbedingt für jeden das geeignete Einstiegsmodell, hat die IBM mittlerweile durch ihre eigene Produktpolitik bestätigt. Einige Fakten mögen den nicht immer geraden Weg der AS/400 illustrieren:

- Im März 1989 steht NEWS 3X/400 unter dem Titel "AS/400 Migration Blues" (von Hofberichterstattung nichts zu spüren).

- Eine im Juli 1989 veröffentlichte IDC-Studie zeigt, daß bereits 20 Prozent aller S/3X-Anwender in den USA eine AS/400 bestellt hatten und insgesamt 50 Prozent sich mit dem Gedanken auseinandersetzten. Aber: Über 50 Prozent planten zunächst nur eine Aufrüstung ihrer bereits vorhandenen Maschinen.

- lm September 1989 brachte die IBM die AS/Entry "als Weiterentwicklung der bisherigen IBM 5363 Modelle" auf den

Markt - es handelte sich bei der AS/Entry um eine /36er.

- Seit September 1990 gibt es eine neue zusätzliche Version der AS/Entry, das Modell Y10, das vor Ort in eine AS/400 umgerüstet werden kann, jedoch nicht ausbaufähig genug ist, um größeren /36-Anwendern eine Alternative zu bieten.

Andererseits machte IBM 1989 weltweit knapp unter 20 Prozent ihres Umsatzes mit der AS/400. Für Big Blue ist die AS/400 damit bereits jetzt ein "äußerst profitables System". Dennoch sind Einschränkungen zu machen, was den Erfolg der Maschine angeht:

- Im unteren Bereich, für kleinere Anwender, war es keine überzeugende Alternative.

- Für /38-Anwender stellte sich, zumindest anfangs, die Frage, worin der Zusatznutzen der AS/400 bestehen sollte, da sich die Maschine doch sehr stark an Konzepte der /38 anlehnt.

- Für größere /36-Anwender ergab sich das schwerwiegendste Dilemma: Wozu sollten sie in Hardware und Systemsoftware fünf- oder sechsstellige Beträge investieren und anschließend ebenso hohe Ausgaben für Migration und Schulung auf sich nehmen, nur um statt der /36 eine AS/400 als /36 zu benutzen, - und das eher ein wenig langsamer, ein wenig umständlicher und eben doch nicht zu 100 Prozent kompatibel, sondern vielleicht nur zu 99 Prozent?

Aus der /36 eine AS/400 machen - geht das denn?

Die meisten /36-Anwender gehen davon aus, daß sie an einer

AS/400 nicht vorbeikommen werden, sind also prinzipiell zum Umstieg bereit. Nicht wenige aber scheuen den hohen Eintrittspreis und den geringen anfänglichen Nutzenzuwachs.

Genau diesen Anwendern (und den Beratungs- und Software-Unternehmen, die diesen Anwendern zur Seite stehen) bietet ein Dritt-Anbieter, das US-Systemsoftwarehaus Asna, mit seinem 400RPG/36-Compiler und dazugehörigen Migrationstools einen sanfteren Übergang. Das Motto lautet: Nicht die AS/400 als /36, sondern die /36 als AS/400 nutzen.

Die IBM hat mit der AS/Entry Y10 die Möglichkeit geschaffen, neue Hardware-lnvestitionen in die /36er-Architektur durch die spätere Nachrüstungsmöglichkeit zu schützen - solange der Anwender bescheiden ist, nicht mehr als vier bis sieben Bildschirme einsetzt und weniger als 150 MB Programme und Daten benötigt (soweit der Versuch einer realistischen Einschätzung der Maschine). Dies ist ein Fortschritt, wenn man bedenkt, daß man bisher den Eindruck gewinnen konnte, ein Etikett genuge, um aus einer /36 ein(e) AS zu machen. Für Anwender eines großen Systems /36 haben sich damit keine neuen wirtschaftlich vertretbaren Migrationspfade aufgetan. Ein weiterer Punkt: wenn man Hardware-lnvestitionen schützt, wo bleibt der logische Schritt, auch Software-lnvestitionen zu schützen? Ein einsamer CALL, der jetzt mit Release 6.0 des Y10-, 5363 Betriebssystems kam, ist nicht mehr als eine Geste.

Auch durch Asnas Compiler und Tools wird aus einer /36 keine heimliche AS/400 gemacht. Aber man kann der Sache so nahe kommen, daß man seine Programme auf der /36 1:1 für den Native Mode der AS/400 entwickeln kann. Eine Portierung von der /36 in den Native Mode der AS/400 ist dann ohne jede manuelle Änderung von Programmen oder Datenbeschreibungen möglich.

Der Einstiegspreis in die AS/400-Welt hat sich somit auch für die großen /36er, drastisch reduziert: Er liegt nur noch im vierstelligen Bereich für die Asna-Systemsoftware. Hinzu kommt der Aufwand für Schulung und Einarbeitung des Compilers. Mit dem völlig neuen und sehr komplexen Betriebssystem der AS/400 braucht man sich zunächst nicht auseinanderzusetzen. Die Installation dauert 20 Minuten. Eine Umstellung kann sofort in aller Konsequenz beginnen - oder im individuell gewünschten Tempo. Auf der /36 bleibt unverändert der gesamte gewohnte RPGII-Compiler erhalten; man muß also nicht, aber man kann für die Native AS/400 entwickeln.

RPG/400 auf der /36 etwas näher betrachtet

Um volle /400-Tauglichkeit von Programmen zu erhalten die auf der /36 entwickelt wurden, bedarf es Disziplin bei der Programm-Erstellung. Wenn man die Konventionen der AS/400 bereits auf der /36 einhält - wozu einen natürlich niemand zwingen kann - ist ein vollautomatischer Übergang auf die AS/400 möglich.

Bereits auf der /36 stehen wesentliche RPGIII-Funktionen der AS/400 zur Verfügung: CALL auf Programme und Prozeduren, externe (DDS-)Datenbeschreibungen, RPGIII-Befehle für die Verarbeitung extern beschriebener Dateien, Mehrfachdatenstrukturen und so weiter.

Für das Umsetzen von OCL /36 in CL /400 werden ebenfalls Tools angeboten, unter anderem auch ein (separates) Tool von Asna selbst. Auf der /36 steht ein Subset der Möglichkeiten des Native Mode zur Verfügung. Dieses Subset erlaubt, auf der /36 Programme zu entwickeln, die genauso auf der AS/400 für die AS/400 entwickelt sein könnten.

400RPG/36 bedeutet modulares Programmieren mit externen Datenbeschreibungen. Wer mit alten RPGII-Programmen und ihren bekannten Schwachpunkten kämpft, wird kaum eine einfache Möglichkeit haben, diese Anwendungen an die Standards der AS/400 anzupassen - entsprechend auch nicht an 400RPG/36. Dennoch können in jedes beliebige RPGII-Programm einzelne Elemente von 400RPG/36 eingeführt werden, sei es ein CALL, eine einzelne extern beschriebene Datei eine Mehrfachdatenstruktur und so weiter 400RPG/36 kann beliebig mit RPGII gemischt werden; einen Übergang auf die AS/400 gibt es dann jedoch nur in den /36er Mode (beziehungsweise /38er Mode für Programme mit gemischtem RPGII/ RPGIII Code).

Durch den Einsatz externer Datenbeschreibungen und durch modulare Programmierung mit Hilfe von CALLs - ein CALL-Aufruf ist für den Anwender bei einem interaktiven Programm nicht zu bemerken - erhöht sich die Wartbarkeit und Übersichtlichkeit von Programmen. Es kann in erhöhtem Maß wiederverwendbarer Code eingesetzt werden. I/O-Bestimmungen werden dem Programm bei der Kompilierung automatisch zur Verfügung gestellt, verlangen also keine weitere Aufmerksamkeit. Man muß jedoch auf einige RPGII-Bequemlichkeiten verzichten, wenn man sich an Normen der AS/400 hält.

Bei der Frage, ob es sich überhaupt noch lohnt, für die /36 Programme zu entwickeln, scheiden sich die Geister. Hört man sich bei Softwarehäusern um, die ja von der Programmentwicklung leben, so hört man allseits "Nein".

Sieht man sich jedoch an, welche Projekte bearbeitet werden, wird das Bild weniger eindeutig. Tatsache ist: Die Architektur der /36 wird uns noch einige Zeit begleiten. Wer die AS/400 für "in ein oder zwei Jahren" eingeplant hat, sollte sich sehr ernsthaft mit der Frage beschäftigen, wie er seine Software-Investitionen, insbesondere in eigene und angepaßte Software schützt. Die Möglichkeiten mit

diesem Schutz schon jetzt zu beginnen, sind da.