Umstellung von CA-7 auf TWS/OPC bei SIGNAL IDUNA mit Unterstützung von XINFO

Die Migration betraf 8.000 Jobs und wurde schrittweise über einen Zeitraum von sechs Monaten durchgeführt. Dabei kamen vom Autor in REXX geschriebene Tools zum Einsatz, die 90 % der Konvertierungsarbeit übernahmen.

Information ist eine grundlegende Voraussetzung für jede Migration. Jedes umfangreiche Migrationsprojekt beginnt mit einer Analyse des aktuellen Zustands. In diesem Fall bedeutet das in der Regel die Durchführung langlaufender CA-7 Batch-Terminal-Reports, um alle relevanten Informationen aus der Datenbank zu extrahieren. Diese Rohdaten müssen anschließend in übersichtliche Listen zusammengeführt werden, sodass relevante Details aus verschiedenen Quellen kompakt und leicht lesbar dargestellt werden.

Dabei geht es nicht nur darum, Job-Attribute und deren Abhängigkeiten zu dokumentieren, sondern auch zentrale Fragen zum gesamten Migrationsaufwand zu beantworten:

• Welche Jobs sind überflüssig? Experten gehen davon aus, dass durch das Identifizieren nicht ausgeführter Jobs bis zu 15–20 % des Migrationsaufwands eingespart werden können. Dazu gehören Jobs, die noch nie gelaufen sind, seit einem bestimmten Datum nicht mehr ausgeführt wurden oder keine JCL enthalten, obwohl sie eigentlich ausführbar wären.

• Planungsinformationen: Viele Jobs haben eigene Zeitpläne, aber die Gesamtzahl der unterschiedlichen Zeitpläne in einem Rechenzentrum ist meist relativ gering. Eine maschinelle Übersetzung von Zeitplänen führt oft zu schwer lesbaren Zeitplanstrukturen im Zielsystem.

• JCL-Konstrukte: Die Definitionen innerhalb des Job-Scheduling-Systems (JSS) machen meist nur einen kleinen Teil des gesamten Aufwands aus. JCL, das vom JSS abhängig ist oder spezielle JSS-Utility-Programme nutzt, erfordert besondere Aufmerksamkeit und sorgfältige Anpassung, selbst wenn ein Teil der JCL-Konvertierung automatisiert erfolgen kann.

Dies betrifft drei Bereiche:

• Der Migrationsprozess

• CA-7-Funktionen, die in TWS/OPC nicht verfügbar sind

• Überwachung von Definitionen und Einhaltung von Standards

Im Folgenden werden diese Aspekte einzeln betrachtet.

XINFO erstellt grafische Diagramme, die die im Planungssystem definierten Jobabläufe veranschaulichen. Während der Migration können diese XINFO-Ausgaben als schnelle und effektive Methode genutzt werden, um die Qualität der Konvertierung zu beurteilen. Während lange, schriftliche Listen schwer zu erfassen sind, ermöglicht ein einziger Blick auf das grafisch dargestellte Konvertierungsergebnis eine schnelle Einschätzung, ob etwas übersehen wurde.

Ein schrittweiser Übergang, wie in unserem Fall, bringt die Herausforderung mit sich, Konvertierungspakete zu identifizieren und verbleibende Abhängigkeiten zu erkennen. Das bedeutet, Gruppen von Jobs zu bestimmen, die intern stark vernetzt sind, aber nur wenige externe Abhängigkeiten zwischen bereits konvertierten und noch nicht konvertierten Jobs aufweisen.

Dabei ist zu beachten, dass XINFO Flussdiagramme auf Basis der Datenbanken aller gängigen Planungssysteme unter MVS erstellt, darunter TWS/OPC, Control-M, ZEKE, CA-7, CA-Scheduler, CA-Jobtrac, BAGJAS und APM/HS-5000.

In diesem speziellen Fall gibt es eine Reihe von Funktionen in CA-7, die dem Benutzer in OPC sicherlich fehlen würden, wenn keine Alternative zur Verfügung steht, um diese Lücken zu schließen. Zum Beispiel:

• LDSN: CA-7 speichert Informationen über JOB/DSN-Beziehungen und DSN-Attribute. OPC hingegen nicht. Falls diese Informationen benötigt werden, muss eine alternative Lösung gefunden werden.

• LJCL: CA-7 ermöglicht eine direkte Verknüpfung zwischen JOB und JCL-Mitglied. OPC speichert keinen direkten Verweis auf die ursprüngliche JCL-Bibliothek eines bestimmten Jobs. Um herauszufinden, in welcher Bibliothek sich die JCL eines bestimmten Jobs befindet, ist eine zusätzliche Informationsquelle erforderlich.

• LPRRN, LRLOG: Wann wurde ein bestimmter Job zuletzt ausgeführt? Wie oft lief er in der letzten Nacht? OPC liefert diese Informationen nicht direkt.

Dies sind nur einige der offenen Fragen. Man kann lange darüber diskutieren, ob solche Informationen in ein Job-Scheduling-System (JSS) gehören oder nicht. Letztendlich bleibt jedoch die Tatsache bestehen, dass der Betrieb sowohl während als auch nach der Migration auf diese Informationen angewiesen sein wird.

XINFO stellt diese Daten bereit und schließt somit die Lücke zwischen CA-7 und OPC.

Sowohl Systemadministratoren als auch Entwickler benötigen oft gültige und aktuelle Informationen über Jobstreams und deren Zeitpläne.

Dies lässt sich in CA-7 bequem umsetzen, indem man ihnen einfach Zugriff auf die „Lxxxx“-Befehle von CA-7 gewährt.

In OPC hingegen sind die Listenfunktionen tief eingebettet und können nicht einfach einer Gruppe zugänglich gemacht werden, die nur anzeigen, aber nicht die Datenbank aktualisieren darf.

Auch hier stellt XINFO die JSS-Strukturen von OPC zur Ansicht zur Verfügung – der Benutzer ist nicht online mit dem JSS verbunden.

Sie werden zustimmen, dass die Beantwortung der Frage „Wo stehen wir?“ anhand der Migrations-Roadmap einfach ist, wenn man die beiden JSS in XINFO vergleicht.

Fast immer bedeutet eine Konversion, dass Standard-Namenskonventionen geändert oder korrigiert werden müssen. Auch hier ermöglicht XINFO eine Auswahl basierend auf fast jedem Feld in jeder Tabelle, und der Vergleich der Ausgaben zeigt schnell Abweichungen auf.

Die funktionale Gültigkeit der Konversion kann ebenfalls überprüft werden, wie im beigefügten Beispiel der Abfrage gezeigt, das einen Job zeigt, der auf einen Vorgänger verweist, der noch nicht konvertiert wurde. XINFO zeigt die logische Lücke auf. Das JSS (Job Scheduling System) akzeptiert die Definition eines Vorgängers, der nicht in der Datenbank vorhanden ist. Der direkte Vergleich und die Überprüfung des Vorgängers wird dadurch erschwert, dass OPC in der Regel den Anwendungsnamen und die Betriebsnummer verwendet, um einen Vorgänger zu identifizieren, anstatt einfach den Jobnamen wie in CA-7.

Die Listen, die wir mit unseren Tools erstellen, könnten größtenteils mit XINFO erstellt werden. Sie können in XINFO eigene Definitionen für jede Kombination verfügbarer Attribute erstellen, indem Sie beliebige Tabellen auswählen und zusammenführen. Diese Abfragen können erstellt, getestet und, wenn gewünscht, dauerhaft im System gespeichert werden.

So könnten Sie in XINFO Folgendes generieren:

• Job-Auslöser

• Job-Abhängigkeiten

• Zeitplandaten

• Virtuelle oder logische Ressourcen, die von Jobs verwendet werden

• JCL, das von JSS-Konstrukten und -Hilfsprogrammen betroffen ist

• Obsoleszente Jobs

• Liste aller Jobs mit ausgewählten Attributen

Diese Listen kommen dem, was Sie zur Automatisierung der Konversion benötigen, verlockend nahe. Was derzeit fehlt, ist eine Liste in XINFO, die alle Jobs in einer Trigger-Kette auflistet und die Kette unter Berücksichtigung der SCHID-Logik nachverfolgt (so wie es CA-7 FSTRUC macht). Diese Logik ist bereits vorhanden – schließlich basieren die grafischen Flussdiagramme genau darauf. Was wir brauchen, ist, dass es als DB2-Tabelle der Beziehungen geliefert wird.

Der verbleibende Schritt wäre, die Beziehungen in einem Format auszugeben, das für ein Batch-Update im Zielsystem geeignet ist. (Aber vielleicht sollten wir froh sein, dass noch etwas Arbeit für uns externe Berater übrig bleibt!)

Es gibt einen alten Mythos, der in unserer Branche immer noch herrscht: „Die nächste Migration wird die letzte sein!“

Erinnern Sie sich an Y2K, den EURO usw.? Abgesehen von diesen Migrationsprojekten, welche anderen hatten Sie in all den Jahren davor?

Die nächste Migration steht wahrscheinlich schon bevor oder ist direkt um die Ecke. Ich weiß nicht, was Ihre nächste große Migration sein wird, aber eines weiß ich: Was auch immer es ist, es wird damit zu tun haben, aktuelle Jobs, Programme, Datenbanken, Dateien und ihre komplexen Beziehungen herauszufinden und sie dann zu ändern.
Aber ohne die Produktion zu stören!

Haben Sie Fragen? xinfo@Horizont-it.com