Betriebssystem-Migration im Wandel: Mußten früher bei entsprechenden Turnkey-Projekten noch Umstellungsmodule (Kernels) gebildet und abgegrenzt werden, besteht heute die Möglichkeit einer integrierten, softwaregestützten Migration von DOS/VSE nach MVS an einem Stichtag (Cut-Over).
Bei der traditionellen Methode stellt die Kernelbildung einen Kompromiß dar. Eigentlich will der Auftraggeber bis zu einem Stichtag seine VSE-Produktion fahren, Anwendungsentwicklung betreiben und nach dem Stichtag das gleiche unter MVS tun. Da eine stichtagsbezogene Umstellung ohne Anwendungsentwicklungsstop sowie die simultane Lösung aller Probleme nicht möglich war, versuchte man durch Kernelbildung erstens, die Zahl der Probleme überschaubarer zu gestalten, und zweitens, das Einfrieren der Anwendungsentwicklung und -wartung zeitlich und mengenmäßig auf ein Kernel zu begrenzen.
Migrationsablauf schafft kritische Phase
Umstellungstools wurden bis dato ausschließlich für partielle Unterstützung prozedural oder auf Basis eines Generators/Konverters im Rahmen der Kernelumstellung eingesetzt. Im Nachgang dieser maschinengestützten Umstellung war immer noch qualifiziertes Personal notwendig, um die verbleibenden Restprobleme abzuarbeiten. Die Kernelbildung in Verbindung mit Nacharbeiten erhöht außerdem die Übernahme-/Übergabe-Risiken, insbesondere durch die Schwierigkeit bedingt, Kernels nicht sauber abgrenzen beziehungsweise vollständig erfassen zu können.
Dadurch entsteht eine kritische Phase, die durch das Nebeneinander von VSE- und MVS-Produktion gekennzeichnet ist, mit einer Vielzahl von Risiken durch Dateisharing, doppelter Systemwartung, einschließlich doppelter Programm- und Job-Versionen und dem Einsatz von Interimslösungen, die diese Problemkreise umschiffen sollen.
Eine Mehrbelastung des Personals über die Umstellungszeit stellt ein weiteres Problem bei der traditionellen Methode dar. Des weiteren mußten Hardware-Ressourcen für zwei Produktionssysteme verfügbar gemacht werden. Angestrebte Umstellungsendtermine mußten durch ein permanentes und aufwendiges Projekt- und Problem-Management hart erarbeitet werden, um der Gefahr einer "ewigen" Umstellung und der Umstellungsmüdigkeit zu entgehen.
Die integrierte Methode verfolgt das Ziel der Stichtagsumstellung zum sogenannten Cut-Over. Erreicht wird dieses Ziel mit einer Massenkonvertierung, in der das gesamte DOS-Material auf einen Schlag auf äquivalentes MVS-Material umgestellt wird.
Eine solche Massenkonvertierung läuft natürlich nicht auf Anhieb. Über Fehlerprotokolle muß sich an das gewünschte Ergebnis herangetastet werden, indem das Tool über Parameter und Exits angepaßt wird, nicht jedoch das DOS-Material! Somit ist sichergestellt, daß, wenn ein Problem erkannt und gelöst wurde, es beim nächsten Lauf nicht mehr auftritt, selbst wenn neues DOS-Material hinzugekommen ist! Damit ist auch erklärt, warum ein Einfrieren der Anwendungsentwicklung und
-wartung bei einer integrierten Methode nicht notwendig ist.
Mit der integrierten Convert-Methode werden während einer Massenkonvertierung folgende Phasen abgewickelt:
In der Analysephase wird eine Inventur mit Vollständigkeitsprüfung durchgeführt. Ausgangspunkt ist die DOS-Produktions-JCL und gegebenenfalls die CICS PPT, um das gesamte umzustellende DOS-Material zu finden. Dadurch wird vermieden, daß Daten-"Leichen" mitumgestellt werden. Die Chance gründlich aufzuräumen, wie sie ein Wechsel der Produktionsumgebung bietet,
kommt so schnell nicht wieder. Dies bezieht sich auch auf eine einheitliche Implementierung von Standards bei Jobnamen, Stepnamen, Programm- und Dateinamen, auch unter Berücksichtigung von Sicherheitssoftware Ó la RACF.
Basierend auf der Analysephase ist jetzt bekannt, welcher Konverter für Programmiersprachen und Utilities auf welchem File laufen muß. Dies geschieht in der nun folgenden Konvertierungsphase automatisch. Auch hier sind unter Umständen umfangreiche Anpassungsarbeiten erforderlich, damit die automatische Konvertierung korrekte Ergebnisse liefert.
ICL-Generierung ist der schwierigste Arbeitsschritt
In allen vorangegangenen Phasen wurden Informationen für die JCL-Generierung gesammelt: Datei-Informationen aus den Programmen, DOS-Jobs, DOS-Prozeduren, SLI's eventuell Include's. Die JCL-Generierung ist der schwierigste Teil einer Umstellung, insbesondere unter der Bedingung, die Job-Control letztlich zu hundert Prozent automatisch gestützt zu erzeugen.
Die tool-gestützte integrierte Umstellung (Abb. 1) berücksichtigt aber nur die eine Seite der Medaille. Um sicherzustellen, daß die Produktion auch nach dem Cut-Over in der neuen Produktionsumgebung trotz der mangelnden Erfahrung von AV und Operating sauber läuft, ist es zweckmäßig, die Produktion bereits unter DOS zu automatisieren. Dies funktioniert natürlich nur, wenn sowohl in der DOS- als auch in der MVS-Umgebung die gleiche Software zum Einsatz kommen kann. Die integrierte Convert-Methode sieht auch diesen Service der RZ-Automation als Modul vor.
Eingriffe der AV erhöht die Fehlerquote
Der Ablauf einer Umstellung (Abb. 2) sähe dann so aus:
Die Projektplanung legt alle zur Zeit bekannten Aktivitäten fest. Die ungefähre Terminplanung ergibt sich bereits aus dem Angebot. Dieses ist um systemtechnische Aktivitäten, wie Installation des MVS, der MVS-Subsysteme (CICS, DB2, IMS DB/DC, NCP, JES2) sowie sonstiger lizerizierter Software zu ergänzen.
Bei der Einrichtung des automatischen RZ besteht durch geeignete Tools die Möglichkeit, das Risiko des Cut-Over drastisch zu verringern. Um so weniger Eingriffe durch Operating und AV erforderlich sind, desto geringer ist die Fehlerquote.
In der Regel stellt sich nach der ersten automatischen Analyse der DOS-Umgebung bereits heraus, daß mehr Programme im Source fehlen beziehungsweise überflüssig sind, als irgend jemand vorher gedacht hätte. Abhängig von der prompten Unterstützung durch den Auftraggeber ergeben sich hier Zeiten zwischen drei sind sieben Wochen allein für die Analyse. Die Analysephase ist unbedingte Voraussetzung für die nachfolgende tool-gestützte Umstellung des DOS-Materials. Somit wird die Analyse voll genutzt für die gesamte Migration.
Die Umstellung selbst ist meist unproblematisch, wenn es sich nicht um Assembler- und Cobol-II-Konvertierung oder um exotische beziehungsweise selbstgeschriebene Utilities handelt. Sofern dafür einheitliche Standards verwendet wurden, wird auch dies nach entsprechender Anpassung automatisch umgesetzt. Viel schwieriger gestaltet sich die JCL-Generierung, weil sich hier viel Diskussionsstoff ansammelt, insbesondere über Namenskonventionen und sonstige Standards.
Entscheidenden Anteil auf den Testaufwand hat das eingesetzte Umstellungswerkzeug. Die integrierte Convert-Methode versucht eine hundertprozentig automatische Konvertierung zu erreichen. Das reduerert
die Testproblematik und den Nachbereitungs- beziehungsweise Korrekturaufwand. Trotzdem ist der Test sehr zeitintensiv. Das hängt auch von den Anforderungen ab, die ein Kunde an Testergebnisse stellt. Generell ist zu sagen: Der Testplan muß durch den Anwender erstellt werden. Er ist derjenige, der seine Anwendungen kennt und weiß, wie wichtig sie sind.
Nach dem Cut-Over verspricht eine automatisierte Produktion einen reibungslosen Anlauf. Wurde vorher unter VSE die Voraussetzung für einen automatischen RZ-Betrieb unter MVS geschaffen, ist das Risiko
eines Fehlschlages erheblich gemindert. In dieser Anfangsphase garantiert im übrigen der sogenannte Stand By schnellstmögliches Reagieren auf eventuelle Anlaufprobleme.
*Falk Brauchmann ist Geschäftsführer der Gedos GmbH, Meerbusch. Arnim Breycha ist Leiter des Geschäftsbereichs Umstellungen der Interprogram GmbH, Langenfeld.