MÜNCHEN (mer) - Einen erweiterten Adreßraum, aber auch erhebliche Probleme während der Stabilisierungsphase der Systeme brachte der HUK-Coburg-Versicherungsgruppe die Umstellung des Betriebssystems MVS/370 auf MVS/XA. Besondere Kopfschmerzen bereiteten den Coburger Systemspezialisten sporadische Fehlermeldungen, die nur mühsam in den Griff zu kriegen waren. DV-Chef Klaus Otto und Günter Brettel, Leiter der Softwareentwicklung, berichteten jetzt auf einem IBM-Kundenseminar in München über ihre Erfahrungen.
Die ständig steigenden Anforderungen nach neuen oder verbesserten Dialogverfahren ließen die HUK-Verantwortlichen Mitte 1983 erkennen, daß es bei weiter wachsender Komplexität der TP-Anwendung in absehbarer Zeit zu Engpässen beim virtuellen Speicher auf dem installierten IBM-Rechner 3081 kommen könnte. Der Benutzeradreßraum des Systems hatte unter der Betriebssoftware MVS/SP 1.3.1 nach Abzug der Systemanteile noch eine Größe von 7,5 Megabyte. Davon belegte allein die TP-Anwendung 6,8 MB.
Responsezeiten in Gefahr
Überlegungen, das TP-Programm zu teilen und auf zwei Anlagen beziehungsweise innerhalb eines Systems in zwei Adreßräumen laufen zu lassen, erschien den DV-Entscheidern als nicht zweckmäßig. Es war zu befürchten, daß sich durch eine derartige Maßnahme das Antwortzeitverhalten drastisch verschlechtern würde.
Zudem planten die Coburger eine Schichtverkürzung im Rechenzentrum von drei auf zwei Schichten. Diese Maßnahme, so räumten die Referenten ein, sei allein durch den Einsatz von MVS/XA nicht zu realisieren gewesen.
Nach Prüfung aller zur Verfügung stehenden Möglichkeiten entschieden sich die Verantwortlichen für eine Umstellung der Betriebssoftware auf MVS/SP 2.1.1 (MVS/XA). Beeinflußt wurde diese Entscheidung durch zwei wesentliche Faktoren: Ein zusätzlich verfügbarer virtueller Speicher im Benutzeradreßraum von 1 bis 1,5 MB und die spätere Nutzung der 31-Bit-Adressierung.
Es sollten in der ersten Stufe nach dem Einsatz von MVS/XA umfangreiche Tabellen aus dem TP-Programm in den oberen Speicherbereich des Systems (Extended Private Storage) verlegt und so nochmals etwa zwei Megabyte im unteren Adreßraum hinzugewonnen werden.
Auch mit den betrieblichen Forderungen an das neue BS hielt die HUK-Gruppe nicht hinter dem Berg: Höhere Systemverfügbarkeit, keine Verschlechterung der Antwortzeiten bei steigenden Transaktionsraten in den Bildschirm-Anwendungen und die Minimierung von Fehlern bei der Betriebssystem-Software zählten zu den Erwartungen der Versicherungsleute. Bei letzterem, so klagten die Referenten, sei jedoch bis heute noch keine wesentliche Verbesserung eingetreten.
Als "gebrannte Kinder" (O-Ton) einer Umstellung von DOS auf MVS im Jahre 1981 wollten die Coburger das Problem diesmal vorsichtiger angehen. Um das Risiko so klein wie möglich zu halten, planten sie einen Zwischenschritt bei der Installation ein. Die wichtigsten bisher eingesetzten Programmprodukte wurden durch neueste XA-fähige Versionen abgelöst, jedoch auch weiterhin unter dem alten Betriebssystem gefahren.
XA-Vorplanung verlangt erhöhte Aufmerksamkeit
Um nach Möglichkeit eine reibungslose XA-Umstellung sicherzustellen, legten die HUK-Manager besonderes Augenmerk auf die zu schaffenden Voraussetzungen:
- Externe Unterweisung der Mitarbeiter aus der Systemgruppe auf MVS/XA sowie die hausinterne Operator-Schulung.
- Zeitliche Aufwandschätzung der erforderlichen EC-Einbauten an den eingesetzten Systemen 3081-D und 3081-G sowie der Platten- und TP-Steuereinheiten.
- Umstellung auf XA-Verträglichkeit der von IBM erworbenen Programmpakete für Plattenplatz- und Bandverwaltung durch die Stuttgarter (gegen Berechnung).
- Erarbeiten eines Backup-Planes bei Einsatzproblemen von MVS/XA.
- Forderung an die IBM, zum Einsatzzeitpunkt von XA Software-Unterstützung bereit zu halten.
Wie sich die terminliche Abwicklung der verschiedenen Umstellungsschritte im einzelnen ergab, ist in Abbildung 1 zusammengefaßt. Neben allgemeinen Schwierigkeiten wie beispielsweise einem fehlerhaften Print-Output im JES 3 - es wurde jeweils nur ein Puffer aus dem Spool gedruckt - bescherte insbesondere die Stabilisierungsphase beider 3081-Systeme den Beteiligten "zwei fürchterliche Tage" (O-Ton). So etwa sporadisch auftauchende Fehlermeldungen (0C4) oder Probleme mit dem Page-Overlay. Hier gelangten immer wieder Daten aus dem Adreßraum B in den Adreßbereich A.
Trotz allem haben sich jedoch die Erwartungen in das neue Betriebssystem nach Meinung der Referenten im allgemeinen erfüllt. Nach der Umstellung und dem anschließenden Tuning des Systems konnten die Coburger immerhin ein Plus von 2,5 Megabyte für ihren Benutzeradreßraum verbuchen. User-Programme wurden dabei nicht verändert.
Auch ging die Zahl der IPL's (Initial Programm Loading) zurück. Wie mit RMF-Messungen festgestellt werden konnte, sind die Pfade zu den Platteneinheiten jetzt gleichmäßiger ausgelastet. Die Antwortzeiten der Bildschirmanwendungen blieben trotz gestiegener Transaktionsraten unverändert, jedoch verzeichneten die DV-Manager einen Anstieg des externen Pagings.
Ein "Stand-alone-Restore" mit DF/DSS, so die Vortragenden, ist unter dem neuen Betriebssystem nicht mehr möglich. Außerdem müssen die Operateure bei der Bandverwaltung auf ihre gewohnte Fehlermeldung "Mount Pending" in Zukunft verzichten.
Obwohl die Umstellung nach Aussagen der Referenten zufriedenstellend verlaufen ist, wollen sie jedoch auf keinen Fall bei einem neuen MVS/XA-Release als Erstinstallation den Vorreiter spielen.