GCOS8-Migration Highlights - GSE Graeber Software Entwicklung

G7-Migration
20 Highlights
BULL GCOS8-Migration
GSE Graeber Software-Entwicklung
Karl-Albrecht Graeber
In den Siefen 51
D-66346 Püttlingen/Saarbrücken
Fon.: +49(0)6806 306 00 70
Fax.: +49(0)6806 306 00 72
E-Mail: [email protected]
www.g7-migration.de
®
Highlights der G7-Migration®
Seite 2
1. Die COBOL-Programme bleiben erhalten. Bei der automatischen Konvertierung werden alle
Transaktions-Steuerungs-Zugriffe und Datenzugriffe in CALLs auf entsprechende G7-SchnittstellenModule (in C bzw. COBOL entwickelt) konvertiert. Die Programmlogik und Programmstruktur wird dabei
nicht geändert, so daß die Mitarbeiter des Kunden ihre Programme auch weiterhin gut pflegen können.
Die Programmpflege ist in der neuen Umgebung wegen der Vielzahl von Tools (auch Tools des G7Entwicklungs-Pakets) und eines sehr komfortablen Debuggers (MicroFocus-ServerExpress bzw. –
NetExpress bzw. AcuBench) wesentlich einfacher als in der GCOS8-Umgebung. Ein
Transaktionsmonitor wird in der Zielumgebung nicht mehr benötigt.
2. Alle Batch-Programme werden weitestgehend automatisch (fast 100 %) umgesetzt. Sie laufen im
wesentlichen ohne manuelle Änderungen mit der relationalen Datenbank. Aus den Jobs werden ShellProzeduren gemacht. Shell-Prozeduren für einzelne Programme werden mit dem G7-ProzedurGenerator aus den Batch-Programmen generiert. Lediglich die Ablaufprozeduren sind entweder manuell
zu erstellen oder über ein Jobsteuerungs-Tool zu konfigurieren.
3. Für die Steuerung der Batch-Abläufe gibt es unter Windows NT/2000 und UNIX sehr leistungsfähige
Standard-Software (z.B. UC4 oder AutoSys/Workload).
4. Die Datenzugriffe (auf UFAS-Dateien oder hierarchische Datenbanken, z.B. IDS2 mit FIND, GET,
ERASE, etc.) aus den Dialog-Programmen und den Batch-Programmen werden durch die automatisch
generierte Schnittstellen-Module (mit embedded SQL) auf eine relationale Datenbank umgeleitet. Die
Transaktionssteuerung übernimmt das Datenbank-System. Durch die G7-Ablaufsteuerung bzw. durch
die Programme werden die Transaktionspunkte automatisch gesetzt und an die Datenbank übermittelt
(Start/Commit/Reset).
5. Die FORMS-Masken (Beschreibungen in Cobol-Copy-Elementen) werden durch den
G7-Maskenkonverter automatisch migriert und in der relationalen Datenbank abgebildet. Die Aufrufe der
Sende- und Empfangsprozeduren für die Masken werden durch gleichnamige G7-Module auf den
G7-Presentation-Manager umgeleitet. Der G7-Presentation-Manager (Windows-Programm in C
programmiert) wird auf einem PC eingesetzt und führt einen TCP/IP-Dialog mit dem korrespondierenden
G7-Schnittstellen-Modul auf dem Server. Alle für den entsprechenden Benutzer vorgesehenen Masken
werden auf seinem PC lokal gespeichert und durch die G7-Ablaufsteuerung automatisch aktualisiert,
sofern auf dem Server in der Maskendatenbank eine Maskenänderung stattfindet. Dadurch entfällt die
ständige Übertragung der Layout-Information vom Server zum PC, es gehen lediglich die Nettodaten und
wenige Steuerungsinformationen über das Netz (Optimierung der Netzbelastung). Die Masken werden
vom G7-Presentation-Manager auf dem PC windows-like dargestellt, bleiben aber in ihrem Aufbau
unverändert.
6. Wenn das G7-Java-Applet für die Darstellung der Masken eingesetzt wird, kann die migrierte
Anwendung (oder Teile davon) auch im Internet/Intranet betrieben werden. Dieses Applet führt im
wesentlichen den gleichen Dialog mit der Anwendung auf dem Server, wie der G7-PresentationManager.
7. Für die Konvertierung der Daten aus den UFAS-Dateien und der hierarchischen Datenbank (IDS2) in
die relationale Datenbank wird der G7-Datenkonverter eingesetzt. Er wird aus den vorher mit dem
G7-Datenstruktur-Konverter in das G7-DataDictionary übernommen Datenstrukturen bzw. dem IDSDatenbank-Schema generiert und übernimmt die Daten aus sequentiellen Files, die aus den UFASDateien bzw. der IDS2-Datenbank auf dem GCOS8-System erstellt werden. Sie werden (ohne CodeKonvertierung) in das Zielsystem per Filetransfer übertragen. Der G7-Datenkonverter lädt die Daten
direkt in die relationale Datenbank.
8. Da die Programme und Masken in der Regel vollständig automatisch konvertiert werden, kann die
Migration jederzeit wiederholt werden. Dadurch entfällt das Erfordernis, die Weiterentwicklung der
Programme während des Migrations-Projektes auf Eis zu legen. Es ist lediglich eine kurze Zeitspanne
(frozen zone) erforderlich, um die zwischenzeitlich geänderten Programme auch in der Zielumgebung
nochmals zu testen.
© GSE
G7-Migration ®
Highlights der G7-Migration®
Seite 3
9. Nach Erfahrungen aus vielen Migrations-Projekten wächst die Performanz der Anwendungen durch die
Migration signifikant. Bei einer Migration nach Unix wurden Verbesserungen der Geschwindigkeit um den
Faktor 2 bis 20 (!) gemessen. Dies ist allerdings abhängig vom Quellsystem und von dem in der
Zielumgebung eingesetzten Hardware-Umfeld. Bei der Migration einer IBM-Mainframe-Umgebung nach
Windows NT wurden auf einem COMPAQ-Rechner mit 2 * 166 MHz bereits PerformanzVerbesserungen gemessen. Bei einem deutschen Großunternehmen ergab die Migration einer
rechenintensiven Anwendung von MVS nach NT auf einem Pentium-Rechner mit 120 MHz vergleichbare
CPU-Zeiten wie auf dem zentralen Großrechner; die Verweilzeiten waren nach der Migration um den
Faktor 10 kürzer. Durch den Einsatz von Intel-Rechnern im GHz-Bereich oder Rechnern mit (mehreren)
Sparc- oder Risc-Prozessoren unter Solaris, AIX, Linux bzw. HP-UX wird eine weitere PerformanzSteigerung erzielt.
10. Ein mittleres G7-Migrations-Projekt mit 300 Dialog-Programmen (Transaktionen), 500 BatchProgrammen, 500 Jobs und 100 Datenstrukturen kann innerhalb von ca. einem halben Jahr mit zwei bis
drei Mitarbeitern vom Kunden und einem Migrations-Berater von GSE durchgeführt werden. Bei einem
größeren Mengengerüst wächst der Aufwand unterproportional. Die externen Kosten für die Migration
(G7-Lizenzen und GSE-Dienstleistungen) betragen für ein mittleres Projekt ca. 250 – 350 T€. Diese
hängen im wesentlichen davon ab, wie viele der anfallenden Arbeiten vom Kunden selbst übernommen
werden. Für das Testen der migrierten Software wird auf jeden Fall ein kompetenter Mitarbeiter des
Kunden benötigt.
11. Die werkzeuggestützte Migration ist mit einem wesentlich geringeren Zeit- und Kostenaufwand verbunden,
als eine manuelle Portierung oder ein komplettes Redesign mit einer Entwicklung in einer anderen
Programmiersprache.
12. Durch die hochautomatisierte Migration werden die Anwendungen schnell und risikofrei mit Hilfe von
Konvertern in die Zielumgebung transformiert und dabei so restrukturiert, daß sie auf eine relationale
Datenbank aufsetzen und in einer windows-orientierten Oberfläche erscheinen. Darüber hinaus werden die
Anwendungen bezüglich Datenbasis und Betriebssystem-Plattform offen und portabel. Der manuelle
Aufwand ist verhältnismäßig gering. Die Kosten für die automatisierte Migration sind erheblich niedriger als
für eine manuelle Migration, eine Neuentwicklung oder den Einsatz von Standard-Software mit
individuellen Anpassungen.
13. Weil die Verfahrenslogik nicht verändert wird, müssen die Benutzer nicht umgeschult werden und bei dem
Einsatz der Anwendungen nach der Migration werden keine unnötigen Fehler gemacht.
14. Die Programmierer müssen nur die Einbettung in das neue Umfeld (Betriebssystem, relationales
Datenbanksystem, Einsatz des [MicroFocus- bzw. AcuCobol] Cobol-Compilers und –Debuggers,
Jobkonfiguration,
G7-Entwicklungsumgebung) erlernen, sie können die Anwendungsprogramme, Masken, etc. ohne
Probleme weiterentwickeln.
15. Wenn die Mitarbeiter des Kunden die Migration mit den G7-Werkzeugen unter Anleitung des
G7-Migrations-Beraters selbst durchführen, werden sie schon frühzeitig mit dem neuen Umfeld vertraut
gemacht (learning by doing).
16. Bei der Weiterentwicklung der Anwendungen sind die Entwickler erfahrungsgemäß in der neuen
Umgebung (u.a. durch verbesserte Debugging-Methoden) wesentlich produktiver als vorher. Das
G7-Entwicklungs-System wird seit Jahren von mehreren Kunden auch für die Neuentwicklung von CobolAnwendungen genutzt. Da das komplette G7-Entwicklungs-Paket im Lieferumfang der G7-Migration
enthalten ist, wird die Weiterentwicklung der Anwendungen in der Zielumgebung stark unterstützt. Mit
den Tools des Cobol-Entwicklungs-Systems (NetExpress bzw. AcuBench), des G7-EntwicklungsSystems, des relationalen Datenbanksystems und den in der Zielumgebung verfügbaren Werkzeugen
und Verfahren können die Anwendungen nach der Migration benutzerfreundlicher und zukunftsorientiert
gestaltet werden.
17. Die laufenden Kosten für den Einsatz der Anwendungen (Hardware und Software) sind auf einem
Windows NT/2000- oder Unix-Rechner signifikant geringer als auf dem GCOS8-Rechner.
© GSE
G7-Migration ®
Highlights der G7-Migration®
Seite 4
18. Neben dem Betriebssystem, dem G7-Migrations- und Entwicklungs-Paket, dem relationalen
Datenbanksystem (ORACLE, DB2, INFORMIX, ADABAS-D) mit embedded SQL oder ODBC-Schnittstelle,
dem Cobol-Compiler mit Debugger und einzelnen Standardtools (COSORT, UC4, etc.) werden keine
weiteren Software-Komponenten auf dem Zielsystem benötigt.
19. Im Gegensatz zur Migration wäre die Neuentwicklung der Anwendungen mit neuen Methoden und
Programmiersprachen mit erheblichen Kosten und Risiken für den IT-Bereich und die Fachabteilungen
verbunden.
20. Um das Migrations-Projekt zu strukturieren und zeit- und kostenmäßig zu quantifizieren, wird immer
zuerst eine Projekt-Analyse durchgeführt. Ziel und Vorgehensweise sind in der G7-Dokumentation
beschrieben. Die daraus entstehende Projekt-Studie ist die Entscheidungsbasis für das weitere
Vorgehen im eigentlichen Migrations-Projekt.
© GSE
G7-Migration ®