Success-Story Möbel Walther - GSE Graeber Software Entwicklung

In diesem Beitrag wird ein Fall behandelt, in dem die Migration weitgehend automatisch gelungen ist.
Es handelt sich um die Migration des Warenwirtschafts-Systems DIADEM, das bei einem großen
Handelshaus der Möbelbranche auf einem SIEMENS-Rechner H60 unter BS2000 im Einsatz ist. Zur
System-Umgebung gehören folgende Standard-Komponenten des BS2000:
- UTM, ein OLTP-System (Transaktionsmonitor) zur Steuerung der parallelen Verarbeitung mehrerer
Transaktionsprogramme,
- LEASY, ein Datenhaltungs-System zur Realisierung von linearen (satzweisen) Zugriffen auf
indexsequentiell organisierte Dateien über eine CALL-Schnittstelle mit Transaktionssicherung,
- FHS, ein Format-Handling-System für die Bildschirmsteuerung,
- IFG, ein interaktiver Format-Generator (Masken-Generator),
- TDSPOOL, ein Spool-Handling-System für das Management von Druckausgaben in DialogAnwendungen.
Die Anwendung ist teilweise in COBOL-74 und teilweise in COBOL-85 programmiert und besteht aus
etwa 300 Dialog-Programmen, 360 Masken, 20 umfangreichen Prozeduren, 40 Unterprogrammen,
320 Batch-Programmen, 100 LEASY-Dateien (die als Datenbank-Dateien übernommen werden
sollten) und einer großen Anzahl von sequentiell organisierten Dateien. Es mußte sichergestellt
werden, daß die UTM-Ablauflogik und die Zugriffe auf Dateien, Bildschirme und Drucker im Zielsystem
nachgebildet werden und das gesamte System die Leistungsfähigkeit der modernen
Systemplattformen mit einer hohen Performance ausschöpft.
Als Betriebssystem für die Zielumgebung wurde UNIX festgelegt, insbesondere sollte die Anwendung
mit AIX und Micro-Focus-COBOL laufen, da ein IBM-Rechnersystem (RS6000) eingesetzt werden
sollte.
DIADEM sollte datenbankfähig gemacht werden, d.h. alle permanenten Dateien sollten als Tabellen im
Datenbanksystem INFORMIX abgelegt und der Zugriff auf die Daten ohne Programmänderungen
ermöglicht werden.
Das System DIADEM sollte mit Hilfe von Werkzeugen so umgestellt werden, daß die Migration ohne
nennenswerten manuellen Eingriff reproduzierbar ist. Außerdem sollte die Anwendung den Übergang
auf eine grafische Benutzer-Oberfläche sowie in eine Client/Server-Architektur ermöglichen, ohne das
Anwendungs-System nennenswert modifizieren zu müssen.
Für die Migration standen 3 Monate und 3 - 4 Mitarbeiter zur Verfügung.
Realisierungsbasis:
Für die Lösung dieser Aufgabe wurde das Entwicklungs- und Migrations-Werkzeug G7-Migration von
GSE eingesetzt. Dieses System enthält neben einer UNIX-Laufzeit-Umgebung auch EntwicklungsWerkzeuge (Generatoren) für die weitere Pflege der COBOL-Anwendung und Neuentwicklung von
Komponenten unter UNIX, sowie Konvertierungs-Werkzeuge für die Bearbeitung von Programmen,
Masken, Dateien und Prozeduren.
Durch entsprechende Schnittstellen-Techniken sind das Werkzeug-System und die LaufzeitUmgebung sowohl in der Client/Server-Welt portabel, als auch datenbank-unabhängig. Das Werkzeug
ist unter anderem auf den UNIX-Varianten HP-UX, AIX, SINIX, SCO-UNIX, SunOS, AT&T-UNIX
System V und unter WINDOWS NT ablauffähig. Als Datenbanksystem können zur Zeit ORACLE oder
INFORMIX eingesetzt werden. Bildschirme, Tastaturen und Drucker können in der Laufzeit-Umgebung
auf die unterschiedlichsten Typen konfiguriert werden. Die korrekte Speicherung, Darstellung und
Verarbeitung von Umlauten und Sonderzeichen ist gewährleistet. Beim Einsatz von PCs oder NCs
werden die Masken vom G7-Präsentations-Manager grafisch dargestellt. In der NC-Welt werden JavaApplets eingesetzt.
Generelle Vorgehensweise:
Das Migrations-Projekt begann mit der Anpassung der Migrationswerkzeuge und der in der G7Migration vorhandenen Transaktionssteuerung an die Erfordernisse der Quell-System-Umgebung, wie
im folgenden beschrieben. Die Umstellung der Programme, der Masken und der Daten erfolgte
danach mit den angepaßten Werkzeugen fast ohne manuelle Nacharbeit. Für die Umstellung der
Prozeduren wurden Funktionen erstellt, die alle verwendeten Dienstprogramme ersetzen, soweit diese
unter UNIX nicht verfügbar sind, z.B. mußten Sortierfunktionen geschaffen werden, weil das Standard-
Sortier-Programm unter UNIX weniger Möglichkeiten bietet als das entsprechende BS2000Programm. Im übrigen wurden die JOB-Prozeduren innerhalb kürzester Zeit manuell realisiert.
Für die Umstellung hat sich positiv ausgewirkt, daß das Migrations-Werkzeug bereits über eine DatenZugriffs-Schnittstelle mit weitestgehender LEASY-Kompatibilität verfügt, die wahlweise auf einer
ORACLE-Datenbank, einer INFORMIX-Datenbank oder einem C-ISAM-Dateisystem aufsetzt.
Außerdem arbeitet es standardmäßig mit einer Transaktionslogik.
Anpassung der Migrations-Werkzeuge und der Transaktionssteuerung
Die transaktionsorientierte Ablaufsteuerung - entsprechend UTM - war relativ leicht zu realisieren. Es
mußte vor allem in der Dialog-Steuerung die Bildschirm-Bearbeitung ergänzt werden, weil die
Transaktions-Programme den Bildschirm-Monitor nicht direkt aufrufen, sondern nur über den
Nachrichtenbereich dem Steuerungsmodul mitteilen, welche Felder in welcher Weise und mit welchem
Inhalt auf der aktuellen Maske darzustellen sind.
Die Spool-Handling-Funktionen (TD-SPOOL) wurden nachgebildet, indem sie auf den im
Laufzeitsystem enthaltenen Druckermonitor aufgesetzt wurden, der die logischen Drucksteuerzeichen
entsprechend den physikalischen Eigenschaften der einzelnen Drucker in die erforderlichen EscapeSequenzen umsetzt.
Erschwerend für die Umstellung war, daß die Batch-Programme zum größten Teil auch auf LEASYDateien mit COBOL-ISAM-Methoden (READ, START, etc.) zugreifen konnten. Der ProgrammKonverter mußte daher so erweitert werden, daß er aus solchen Zugriffen LEASY-CALLS mit
Parameter-Übergabe erzeugt. Einige kleinere Inkompatibilitäten im COBOL-Code, die nur schwierig
mit dem Programm-Konverter hätten ausgeglichen werden können, wurden durch Änderungen im
Quellcode auf dem BS2000-System überwunden (z.B. gibt es unter UNIX kein EXIT PERFORM).
Die Anpassung des Masken-Konverters an die mit dem interaktiven Format-Generator IFG erstellten
Masken zur Übernahme in das G7-Maskenformat bereitete keine Schwierigkeiten, weil G7 wesentlich
mehr und flexiblere Möglichkeiten für die Maskenbearbeitung bietet als IFG/FHS. Daher konnte das
neue Maskenformat alle Informationen aufnehmen, die für die IFG-Masken benötigt werden.
Zur Vorbereitung der Datei-Konvertierung mußten BS2000-seitig alle inkompatiblen Redefinitionen der
Datensatz-Strukturen aufgelöst werden. Beispielsweise kann folgende Struktur nicht in einer SQLDatenbank abgebildet werden:
10
AFELD PIC S9(7) PACKED DECIMAL.
10
FILLER REDEFINES AFELD.
20 BFELD
PIC S9(4) COMPUTATIONAL.
20 CFELD
PIC S9(3) PACKED DECIMAL.
Um eine automatische Datei-Konvertierung und maschinelle Generierung der Datenbank zu
gewährleisten, mußte außerdem gefordert werden, daß OCCURS-Klauseln in den
DatensatzDefinitionen nur auf Element-Ebene, nicht auf Gruppen-Ebene vorkommen.
Umstellung der Dateien, Programme, Masken und Prozeduren
Die eigentliche Konvertierung der Dateien in das ORACLE-Format erfolgte in zwei Schritten:
- Im ersten Schritt wurden die COBOL-Satzdefinitionen maschinell in das integrierte Data-Dictionary
übernommen und die SQL-Prozeduren für die Definition der Datenbanktabellen automatisch generiert.
- Im zweiten Schritt wurden aus dem Data-Dictionary mit Hilfe des Programm-Generators ein
Programm für das Entladen der Originaldaten im BS2000-System (in ein sequentielles Format) und
ein Programm für das Laden der ORACLE-Datenbank (aus dem unter BS2000 erstellten sequentiellen
Format) im Zielsystem generiert.
Da die Dateien dezimal gepackte und binäre Zahlen enthalten und bei der Übertragung von BS2000
nach UNIX eine Code-Konvertierung (EBCDIC- in ASCII-Code) erfolgte, wurden beim Entladen der
Originaldaten alle numerischen Felder in externes Format umgewandelt. In dem Entladeprogramm
konnte auch noch dem Wunsch des Auftragsgebers entsprochen werden, zwecks Datenbereinigung
alle Felder, deren Inhalt LOW-VALUE war, in SPACES bzw. ZEROES umzuwandeln, je nachdem ob
sie alphanumerisch oder numerisch definiert sind. Für die Generierung beider Programme war jeweils
nur ein Ablaufmodell in der G7-4GL-Sprache und eine Liste mit den in Frage kommenden Dateinamen
erforderlich.
Für die Übernahme der Dateien wurde nur noch das Entladeprogramm (unter BS2000) gestartet, die
entstandenen sequentiellen Dateien per File-Transfer (mit Code-Konvertierung) auf die UNIX-Anlage
übernommen und dort mit dem Ladeprogramm in die Datenbank eingespielt. Auf diese Weise wurde
der Übergang zwischen unterschiedlichen Datenhaltungsformen durch die Migrations-Werkzeuge
sichergestellt.
Nach fehlerfreier Umwandlung der Programme begannen die Programm und System-Tests. Hier stand
ein qualifizierter Mitarbeiter des Auftraggebers für die Beurteilung der Testabläufe und Testergebnisse
zur Verfügung.
Da die Dialog-Programme durch den Programm-Konverter nur unwesentlich geändert waren, gab es
beim Testen nur geringfügige Überraschungen. Das migrierte Dialog-System verhielt sich fast auf
Anhieb wie das Originalsystem.
Auch die Batch-Programme wurden nach geringfügigen manuellen Vorarbeiten vom ProgrammKonverter nur formal geändert. Sie ließen sich auf Anhieb fehlerfrei kompilieren und verhielten sich
beim Testen erwartungsgemäß korrekt.
Inzwischen ist es gelungen, auch ein System für die Konvertierung der BS2000-Prozeduren (JOBs) in
Shell-Scripts zu integrieren, sodaß im Falle der Konvertierung von COBOL-Systemen aus dem
BS2000 und den Komponenten UTM/LEASY/FHS/IFG/TDSPOOL mit Hilfe der G7-Migration nur noch
wenige Arbeiten manuell erfolgen müssen.
Beurteilung:
Unser Fallbeispiel zeigt, daß es unter bestimmten Voraussetzungen problemlos ist, ein bestehendes
Anwendungssystem zu migrieren, wenn die geeigneten Werkzeuge zur Verfügung stehen.
In jedem Einzelfall einer Migration haben Systemumgebung, Schnittstellen und Struktur der Software,
Art der Datenhaltung und Verwendung von Sprachelementen und Systemkomponenten einen großen
Einfluß auf die einzusetzenden Werkzeuge. Daher muß zunächst analysiert werden, welche
Besonderheiten vorliegen und in welcher Weise die Werkzeuge "geschliffen" werden müssen, um eine
optimale, risikofreie und terminlich unkritische Migration zu gewährleisten. Hierzu dient die
Durchführung einer Projekt-Analyse mit Labormigration, die jedem Migrations-Projekt vorausgeht und
in deren Rahmen die technische und organisatorische Planung sowie die Festlegung der benötigten
Ressourcen und Kapazitäten erfolgt. Auf diese Weise wird ein Abenteuer verhindert.
Ergebnis:
Durch die Migration wird die Qualität der Anwendung entscheidend verbessert:
1. Die Anwendung arbeitet mit einer ORACLE-Datenbank oder einer INFORMIX-Datenbank.
Zusätzliche Auswertungen können nun mit SQL oder dem Report-Generator des G7Wartungssystems erstellt werden. Auf die Datenbank kann neben der Anwendung parallel auch direkt
mit SQL und Datenbank-Werkzeugen zugegriffen werden.
2. Die Anwendung läuft auch in Client/Server-Architekturen und erhält eine grafikähnliche Oberfläche
oder kann direkt in grafischen Benutzer-Umgebungen eingesetzt werden.
3. Die Anwendung kann mit dem integrierten Entwicklungs-System weiterentwickelt, ergänzt und
ausgebaut werden.
4. Die Anwendung kann sukzessive um neue Komponenten erweitert werden, die auf die gleiche
Datenbasis zugreifen und mit neuen Methoden erstellbar sind. Auf diese Weise sorgt man für die
Sicherung der in der Software gemachten Investitionen und schafft den sanften Übergang in eine
neue System-Umgebung.
5. Der Lebenszyklus der Anwendung wird entscheidend verlängert, ohne die Fortentwicklung zu
behindern.
6. Die Einbindung des Systems in ein Netzwerk ist wesentlich unproblematischer und
kostengünstiger.
7. Durch das Downsizing sinken die EDV-Kosten für den Betrieb der Anwendung erheblich.
Hardware-Erweiterungen, die bei einer Vergrößerung der Datenbestände und der System-Erweiterung
erforderlich werden, sind um ein Vielfaches preisgünstiger.
8. Das Anwendungs-System wird jetzt auf einem mittleren UNIX-Rechner (mit Single-Prozessor)
eingesetzt (IBM R24) und weist selbst bei Vollast mit über 100 Benutzern keine nennenswerten
Antwortzeiten auf.
9. Die migrierte Anwendung wird multimedia-fähig und offen für Zukunftstechnologien.
(Karl-Albrecht Graeber)
(*) Möbel Walther AG, Gründau - größtes Möbelhaus in Hessen
G7-Migration
Seite 2
(c) GSE GmbH