Der Umstieg von DOS/VSE auf MVS kostet Zeit, Nerven und belastet letztlich den Geldbeutel nicht unerheblich. Zudem müssen verschiedene DV-Fachbereiche aufeinander abgestimmt werden. Norbert Bönner und Roland Awischus* erläutern in ihrem Beitrag, welche Hilfestellung Tools bei diesem Prozeß geben können.
Aufgrund des überall gegebenen Größenwachstums innerhalb der
Datenverarbeitungsabteilungen stellt sich sicherlich für jede RZ-Leitung früher oder später die Frage der Kapazitätsausweitung.
Bei einer Umstellung dieser Art sind vielfältige Überlegungen anzustellen. Zunächst einmal darf man nicht davon aus gehen, daß mit der Umstellung des Betriebssystems und der Umstellung der Anwendungen die Sache erledigt ist. Es sind vielmehr auch im Umfeld sehr viele Faktoren zu berücksichtigen, auf die sich der Einsatz eines größeren
Betriebssystems auswirkt. Deswegen ist in zweierlei Hinsicht die Forderung nach einer integrierten Umstellung wesentlich:
Einerseits, weil sehr viele Bereiche der Datenverarbeitung und der angrenzenden Gebiete betroffen sind, wie etwa die Anwendungsprogrammierung, die RZ-Abläufe, Arbeitsvor- und Nachbereitung bis hin zu den Einsätzen in der Fachabteilung.
Andererseits ist das Umstellungsprojekt selbst ein integriertes Vorhaben, da dort verschiedene Bereiche der Datenverarbeitung angesprochen werden und involviert sind. So ist die Einrichtung eines Umstellungs-Projektmanagements unerläßlich, welches für die ordnungsgemäße Durchführung der gesamten Umstellung verantwortlich ist.
Daneben ist ein Support für das bisherige Betriebssystem notwendig. Es müssen Fachleute zur Verfügung stehen, die bei Rückfragen helfend eingreifen können. Auf der anderen Seite muß auch das neue Betriebssystem Systemunterstützung erfahren, denn alle bisherigen Prozeduren sind sinngemäß auf das neue zu übertragen. Weiterhin ist eine organisatorische Beratung notwendig, denn sicherlich werden sich durch den Einsatz des neuen Betriebssystems auch organisatorische Abläufe innerhalb des Rechenzentrums ändern. Für die Anwendungsentwicklung ist ein frühzeitiges Training vorzusehen, so daß die Entwicklung neuer Anwendungen nahtlos fortgesetzt werde kann .
Die Frage ist, welche Ziele man bei einer BS-Umstellung verfolgt. Zunächst einmal soll diese Umstellung sicherlich in kürzester Zeit vollzogen werden. Dabei dürfen nur geringe Ressourcen beansprucht werden. Es soll eine minimale Unterbrechung in den Rechenzentrumsabläufen auftreten. Die Kosten sollen überschaubar und möglichst im voraus zu planen sein.
Die konventionelle Methode einer Umstellung auf ein neues Betriebssystem geht in der Regel so vor sich, daß sukzessive verschiedene Anwendungsbereiche jeweils isoliert für sich umgestellt werden und erst wenn ein Anwendungsbereich auf dem neuen Betriebssystem implementiert ist, geht man dar an, den nächsten Anwendungsbereich umzustellen. Für die Umstellung bedeutet das, daß zunächst die Struktur des neuen
Betriebssystems geplant wird.
Nachdem dieser Plan vorliegt . wird das System installiert und währenddessen beginnt die Planung der Migration. Es schließt sich die phasenweise Umstellung an. Man startet mit einem Anwendungsgebiet und alles, was zu diesem Gebiet gehört, wird umgestellt. Pflege und Entwicklung dieses Anwendungsgebietes und auch insbesondere der übrigen Anwendungen laufen weiter, so daß nun an zwei Stellen gepflegt werden muß: auf dem alten System, welches ja immer noch parallel läuft und in den schon fertig umgestellten Teilen des Anwendungsbereiches im neuen Betriebssystem.
Weitere Probleme ergeben sich aus den Schnittstellen zu den übrigen Bereichen, die zunächst noch von der Umstellung ausgeschlossen sind.
Es findet sicherlich vielfältiger Datenaustausch statt zwischen dem zunächst umgestellten und den Altsystemen, so daß hier Transfers notwendig sind. Es müssen neue Programme geschrieben oder Abläufe festgelegt werden, die diese Datentransfers sicherstellen.
Jede Implementierung einer neu umgestellten Anwendung verursacht eine Produktionsunterbrechung. Je nach Anzahl der Anwendungsbereiche können sich erhebliche Ausfallzeiten ergeben, die den gesamten Betrieb nachhaltig stören. Die Schnittstellenproblematik zwischen den verschiedenen Anwendungsgebieten und
unterschiedlichen Umstellungszuständen führt häufig zu redundanten Modulen.
Gegenüber der konventionellen Umstellung bietet die automatisierte Umstellung einige unübersehbare Vorteile. Hier wird nämlich ein Umstellungstool eingesetzt, welches die eigentliche Umstellung der Anwendungen und Jobs vornimmt.
Der Umstellungsarbeit durch das Tool vorausgehend muß auch bei diesem Verfahren ein Plan für die Struktur des zu erreichenden Systems erstellt werden. Schon während der Installation des neuen Betriebssystems kann die eigentliche Migration
beginnen und die Pflege und Entwicklung der Anwendungsbereiche ungestört fortgesetzt werden. Am Ende der Umstellungsphase gibt es nur eine sehr kurze kritische Phase, in der das Produktionssystem für kurze Zeit gestoppt werden muß, um nachher seinen Betrieb unter dem neuen System wieder aufnehmen zu können. Bei dem hier zugrunde liegenden Beispiel des Umstellungstools Exodus von Synapse (DOS/ VSE nach MVS) kann diese Produktionsunterbrechung an einem Wochenende erfolgen, so daß der Betriebsablauf nicht gestört wird.
Während der Vorbereitungszeit bleibt die laufende Produktion unbeeinflußt, es tritt
keine Parallelverarbeitung auf. Durch den Einsatz des Umstellungstools wird eine sorgfältige Systembereinigung möglich; denn dieses Tool deckt Fehler auf, die sich während der VSE-Produktionszeit eingeschlichen haben. Ein einfacheres umfassenderes Testen ist möglich, da alle Anwendungsbereiche auf einen Schlag, also ohne Schnittstellenprobleme. umgestellt werden. Die Tool-Umstellung bietet damit auch die Möglichkeit eines intensiveren Trainings unter MVS.
Der Tool-Einsatz gewährleistet erstens, daß man die Kosten genau abschätzen kann, so daß sich für die Gesamtumstellung ein fester Preis ergibt und zweitens lassen die Probeläufe des Umstellungstools einen festen Zeitplan für die Umstellung zu. Die Untersuchung der Ergebnisse verschiedener automatisierter Umstellungen hat gezeigt, daß neben der Reduktion der unmittelbaren Kosten um zirka siebzehn Prozent, die Umstellung insgesamt dreimal schnelIer vollzogen werden kann als eine konventionelle Umstellung. Durch den Zeitvorteil werden Kapazitäten weniger gebunden und gewährleisten einen reibungslosen Produktionsbetrieb innerhalb der DV-Abteilung.
Teilt man die Kosten einer MVS Umstellung auf, zeigt sich, daß der Löwenanteil durch die Umstellung der Hardware verschlungen wird, das sind zirka 63 Prozent. Etwa gleich große Anteile nehmen die Migration mit zirka neun Prozent und die eigenen Ressourcen mit zirka zehn Prozent ein. Hinzu kommen die Kosten für Training, sonstige Software und Beratung.
Wie läuft so eine automatisierte Umstellung sinnvollerweise ab und welche Programme kommen hier zum Einsatz? Wie wird der MVS-Generator, das eigentliche Umstellungstool, effektiver eingesetzt?
Zunächst sind sicherlich alle VSE-Jobfolgen, alle VSE-Sourceprogramme und ebenfalls alle VSE-Dienstprogramme dem MVS-Generator zur Verarbeitung vorzulegen. Daneben wird den Steuerungstabellen angegeben, wie die Umsetzung zu erfolgen hat, das heißt:, welche Namenskonventionen einzuhalten sind, wie Dateinamen umgesetzt werden sollen und welche sonstigen Ausnahmen zu berücksichtigen sind. Der MVS-Generator behandelt die vorgelegten Daten nach den Angaben, die in den Steuerungstabellen hinterlegt sind und erzeugt MVS-Job folgen, MVS-Sourceprogramme und MVS-Dienstprogramme.
Fehler der VSE-Welt werden aufgedeckt
In einer Umstellungsschleife wird dem Umstellungstool immer wieder das gesamte DOS Material zur Verfügung gestellt. Daraus wird MVS-Programmaterial erzeugt, welches unter MVS-Bedingungen einen Test unterworfen wird.
Aus diesem Test ergeben sich Fehler und Mängel des Umstellungslaufes, die dann anschließend in den Steuerungstabelle ihren Niederschlag finden und dort so hinterlegt werden, daß für den nächsten Umstellungsprozeß ein Fehler nur einmal korrigiert werden muß, da er in der Tabelle festgehalten wird.
Somit wirkt sich die Korrektur auf jegliches Auftreten dieses Fehlers aus. Die Umstellungsschleife hat in zweierlei Hinsicht Vorteile: Einerseits wird gewährleistet, daß ein einwandfreies Zielmaterial für das MVS-System erzeugt wird. Zum anderen ergeben sich Rückkopplungen auf die VSE-Umgebung, denn es ergeben sich auch hier Hinweise auf Fehler, die sich in der VSE-Produktionswelt eingeschlichen haben, und die daraufhin korrigiert werden können. Letztendlich wird ein wirklich einwandfreies MVS-Zielmaterial erzeugt.
Ebenfalls ergeben sich für das Projektmanagement wertvolle Hinweise aus dieser Rückkopplung, indem etwa Arbeitsanweisungen bezüglich der Abläufe geändert werden können. Das Projekt umfaßt neben der reinen Umwandlung der Anwendungsprogramme und Jobcontrollgenerierung auch die Umstellung der Hardware, die zum Einsatz kommende externe Software, Training der Anwender und Benutzer und die Anpassung der Abläufe innerhalb der Rechenzentrumsumgebung.
Wie setzt sich sinnvollerweise die Umstellungsmannschaft zusammen? Nun, wenn wir davon ausgehen, daß ein Umstellungsprojekt für eine Datenverarbeitungsabteilung das größte Projekt ihrer Geschichte und gegebenenfalls in ihrem gesamten Arbeitsleben ist, so sollte man davon ausgehen, daß sie auf jeden Fall externe Beratung hinzuziehen wird.
Zunächst einmal kann sich in Beratungsunternehmen häufiger mit Umstellungsprojekten befassen und dort gezielt Erfahrungen sammeln. Diese Synergie-Effekte kommen dem einzelnen Kunden zugute. Zum anderen ist ein hoher Aufwand in den
Know-how-Aufbau der eigenen Mannschaft zu investieren, um so eine Umstellung mit
eigenen Leuten durchführen zu können. Dieses Wissenspotential ist im Grunde nur für dieses eine Projekt nutzbar. Das bedeutet eine wesentliche, zusätzliche Belastung für die Mitarbeiter, die dadurch unsicherer werden und letztlich die Umstellung eher verzögern,
Firmen sind sicher gut beraten, erfahrene (externe) Mitarbeiter für die Umstellung zu gewinnen. Das Umstellungsteam sollte sich aus einem Projektleiter, aus
Umstellungsspezialisten, die einerseits Fachleute in der RZ-Organisation und -Umstellung sind und anderseits aus der Anwendung kommen und Erfahrungen in der Umstellung von Anwendungsbereichen haben, zusammensetzen. Ihnen zur Seite sollte zur Unterstützung im MVS-Systembereich und im Bereich des Jobcontrolling ein MVS-Systemspezialist stehen.
Die Umstellungsspezialisten passen die Umstellungsoftware an die Bedürfnisse des Kunden an Sie sorgen für die entsprechenden Eingaben in die Steuerungstabelle und starten die eigentlichen Umstellungsläufe. Die Experten machen die Mitarbeiter des Kunden auf die notwendigen Änderungen in den VSE-Abläufen aufmerksam und beraten sie bei den Tests der umgestellten Programme unter MVS. Die Anzahl, der zum Einsatz kommenden Spezialisten, hängt von der Größe und von der Komplexität des Projektes ab. Bei einem größerem Projekt ist es wichtig, eine gut durchdachte Projektorganisation zu haben .
Es sollte ein Projektlenkungsausschuß eingerichtet werden, dessen Mitglieder aus
Mitarbeitern des Kunden und des Umstellungspartners bestehen, die sich in regelmäßigen Abständen zu Sitzungen zusammenfinden, um sich jeweils einen Überblick über den Fortschritt des Projektes machen zu können und notfalls auch in kritischen Phasen eingreifen zu können. Für die Unterstützung des Projektmanagements ist der Einsatz eines Projektplanungstools von Vorteil, das auf einem PC zur Projektkontrolle zum Einsatz
kommen kann. Darüber hinaus sollte ein detailliertes Berichtswesen installiert werden, das
als Informationsmedium für Management und Projektleitungsausschuß dient.
* Dr. Norbert Bönner ist Prokurist, Roland Awischus ist Schulungsleiter bei der Schumann Gruppe, Köln. Der Beitrag erschien bereits in COMPUTERWOCHE FOCUS Nr. 3 vom 11.
August 1989.