Ein mittelständisches Unternehmen der Orthopädietechnik, mit über 700 Mitarbeitern, löste ihre IBM-/36-Anwendungen durch eine Umstellung auf Digitals Midrange-Rechner VAX 6000-320 ab. Rainer Sangmeister* berichtet über die Entscheidungsfindung und den Ablauf der Umstellung.

Anfang 1990 erreichte die bei uns installierte IBM /36 mit rund 40 Benutzern ihre Leistungsgrenze. Das Antwortzeitverhalten war nicht mehr befriedigend. Mehrere Lösungsvarianten wurden diskutiert. Naheliegend schien die Umstellung auf eine AS/400. Diese Möglichkeit schied aber bald aus dem näheren Betrachtungsfeld aus, da eine "Eins-zu-Eins-Umstellung" in den Native-Mode nur unter sehr hohem Aufwand und teilweiser Neukonzeption der Anwendungen möglich gewesen wäre. Es galt einen Weg zu finden, der es möglich machte, die Anwendungen ohne große Veränderungen beizubehalten und trotzdem eine Hardwareplattform zu finden, die ein Wachstum zuläßt, ohne erneut in eine Sackgasse zu geraten.

Zur gleichen Zeit begann in unserem Hause die Konzeption eines neuen PPS-Systems, wobei Teile der alten Anwendung mit dem neuen System verbunden werden mußten. Mit der Durchführung des PPS-Projektes wurde die Gesellschaft für Softwaresysteme und -technologien (GST) aus Göttingen beauftragt. Die GST schlug als Hardwareläsung eine DEC-VAX vor. Als Begründung führte sie die Aufwärtskompatibilität und die Offenheit der VAX-Systemfamilien an.

Ferner sei sie in der Lage, eine Migration von der /36 auf die VAX vorzunehmen. Nachdem eine kleine Teilanwendung als Pilotprojekt umgestellt war, trafen wir die Entscheidung, die gesamte /36-Anwendung auf die VAX zu konvertieren und erteilten den Umstellungsauftrag an das Göttinger Softwarehaus.

Die GST benutzt den RPG-II-Compiler des Migration Centers der Digital Equipment. Bei diesem ist besonders hervorzuheben, daß er strukturierte Programmierungselemente enthält (wie im RPG III oder im Grünbichler-RPG) Dadurch erweitert sich der Sprachumfang des /36-RPG auf der VAX in einer Weise, die den Anwendern annähernd die Möglichkeiten der /38- oder AS/400-Systeme bietet Genau das entsprach auch der Gesamtstrategie, bei der der Leistungsumfang der bestehenden RPG-Anwendung verbessert und nicht nur eine "Eins-zu-Eins-Umstellung" durchgeführt werden sollte.

Für das weitere Umfeld galt es, eine ebenfalls optimale Lösung zu entwicklen, da keine brauchbaren Werkzeuge am Markt verfügbar waren. Das größte Problem stellten nach Aussage von Herrn Lorentz, Geschäftsführer der GST, die OCL-Prozeduren mit ihrer Variablenvielfalt dar. Digital verfügt zwar im VMS-Betriebssystem über eine eigene Prozedurensprache (DCL), sie weicht aber in der Syntax, im Parameterbereich und in der Art der Funktionen erheblich vom IBM-OCL ab.

Die GST beschlolß, die Prozeduren nicht manuell umzusetzen, sondern ein Konvertierungsprogramm zu schreiben, das die OCL-Prozeduren mit Hilfe eines Preconvert analysiert und in DECs DCL-Kommandosprache maschinell umsetzt. Hierbei war die Behandlung der Sorts eines der größten Probleme. Bei den Sorts ist zwischen zwei Arten zu unterscheiden: Zum einen gibt es feste Sortbestimmungen, zum anderen solche mit Ersatzfunktionen oder Bedingungsausdrücken in den Spezifikationen.

Sorts mit festen Bestimmungen wurden in Dateien mit DCL-Sortierspezifikationen konvertiert und werden vom Sortprogramm über den Dateinamen angezogen. Variable Sorts definiert man zur Laufzeit und stellt sie dann dem Sortprogramm zur Verfügung, so daß auch hier keine manuellen Eingriffe mehr erforderlich sind Neben der OCL-Konvertierung sind weitere Umstellungsschritte notwendig:

- Dateikonvertierung

Die ISAM-Dateistruktur bleibt erhalten. Die Dateien sind im EBCDIC-Format auf die VAX zu übertragen und werden dort im ASCII-Format umgesetzt, wobei auch die Möglichkeit der Verarbeitung von Dateien mit unterschiedlichen Satzarten, die in unserer Anwendung auch vorkommen, unterstützt wird. Weiterhin lassen sich auf der VAX nicht nur die Alternativ-lndizes segmentieren, sondern auch schon der erste Key.

- S & D-Formate

Die Bildschirmformate bleiben als S- & D-Formate auch auf der VAX erhalten. Sie müssen lediglich mittels des Screen-Compilers umgewandelt und in

die Programme eingebunden werden.

- Menüs

Für die Menüsteuerung entwickelte die GST ein Menübasissystem. Dabei trug man der Forderung Rechnung, auch andere Anwendungen in unterschiedlichsten Programmiersprachen einbinden zu können.

- Verwaltung Spool und Jobqueue

Zur Verwaltung der Spoolund Jobsteuerung stellte die GST-Programme zur Verfügung In vier Monaten gelang es der GST, ein komplettes Konvertierungs-Tool zu schreiben und auszutesten. Dann konvertierte sie die Anwendung maschinell auf einer Microvax II. Dabei handelte es sich um folgendes Datenvolumen:

Programme - 1000

Prozeduren - 2300

Ports - 11 00

S & D-Formate- 400

Mit der von der GST gelieferten, umgestellten Anwendung konnten wir nach einer kurzen Schulungsphase mit der Testund der Parallelverarbeitung

beginnen. Für die Anwender war der Schulungsaufwand sehr gering, da lediglich die Tasten belegung in einigen Fällen vom Bekannten abwich.

Für die Operatoren war der Schulungsaufwand größer, die VAX ist im Bereich der Job- und Spoolsteuerung nicht mit der /36 zu vergleichen. Im Testbetrieb wurden dann einige Fehler sichtbar. In einigen Programmen gab es Probleme mit der Overflowsteuerung sowie bei der Belegung von Gruppen stufen auf numerische Felder - dies war bei den ersten Testläufen nicht zu erkennen. Erst nach langwieriger. Suche im Assemblercode stellten die GST Systemspezialisten fest, daß kein Programm- sondern ein Compilerfehler vorlag. Darauf hin wurde das DEC-Migration-Center eingeschaltet. Die GST erhielt ein Compiler-Update womit die Fehler beseitigt werden konnten.

Nachdem die Test- und Parallelphase durchlaufen und das neue Datennetzwerk für den Terminal- und PC-Netzbetrieb installiert war, konnten wir den Echtlauf vorbereiten Hierfür waren 280 Dateien von der IBM auf die VAX 6000-320 zu übertragen und anschließend zu konvertieren. Die Datenübertragung erfolgte problemlos an einem Wochenende über PC', 8-Zoll Disketten und mittels BSC-Protokolls parallel.

Der erste Echtlauf allerdings lief nicht ohne erhebliche Anfangsschwierigkeiten ab: Die Anwendungen liefen zunächst auf der VAX langsamer als auf der /36. Das Datennetzwerk brach mehrmals zusammen. Um den Benutzerbetrieb möglichst schnell stabil zu bekommen, wurde der technische Support von DEC, eingeschaltet. Die Techniker installierten eine neue Netzwerksoftware und nahmen einige Änderungen am Terminalservernetz vor, dadurch stabilisierte sich der Benutzerbetrieb in kurzer Zeit Um die Performance der Anwendungen zu verbessern, lieferte DEC, einen zweiten Prozessor, der auf Abruf bereitstand, und baute diesen auch ein.

Auch mit der doppelten Prozessorleistung war noch kein befriedigendes Antwortzeitverhalten zu erzielen. Ein Grund dafür lag auf der Hand: Statt bisher vier Dual-Session-Bildschirmen auf der /36, hatten wir alle Benutzer mit neuen Multi-Session-Terminals ausgestattet. Darüber hinaus liefen schon einige neue PPS Funktionen auf der neuen Maschine. Somit hatten wir mehr als die doppelte Last als auf der /36 zu verarbeiten.

Die VAX ist als reiner Online-Rechner vorkonfiguriert. Unsere RPG-Anwendungen sind aber aus programmtechnischen Gründen mehr batchorientiert. Erst nachdem die Systemparameter an diese Situation angepaßt wurden, verbesserte sich das Laufzeitverhalten zusehends. Die GST nahm ihrerseits noch einige Verbesserungen am RPG-Laufzeitsystem vor.

Heute arbeiten bis zu 113 interaktive Benutzer am System. Das Laufzeitverhalten der Maschine kann man als gut bezeichnen. Die Programme arbeiten im Dialogmodus wesentlich schneller als auf der /36.