Highlights G7-Migration - GSE Graeber Software Entwicklung
Werbung
G7-Migration UNISYS-Migration 20 Highlights 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 Datenzugriffe auf ISAM-Dateien in CALLs auf G7-Schnittstellen-Module umgesetzt, die in der Zielumgebung den Zugriff auf die Oracle-Datenbank übernehmen. Die SQL-Zugriffe auf RDMSDatenbanken werden in SQL-Statements (ESQL) konvertiert, die auf eine Oracle-Datenbank zugreifen können. Die Zugriffe auf die DMS-Datenbank (IMPART, DEPART, FIND, FETCH, STORE, LOCK, UNLOCK, MODIFY, DELETE, CREATE, etc.) werden in CALLs auf das von G7 bereitgestellte CobolProgramm G7-DMS umgesetzt, das seinerseits auf spezielle G7-Codasyl-Schnittstellen-Module zugreift, die mit dem G7-SQL-Generator erzeugt werden. Diese Schnittstellen-Module sorgen in der Zielumgebung für die Umleitung der DMS-Zugriffe auf die relationale Datenbank. Die Programmlogik wird bei der Konvertierung 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 G7-Entwicklungs-Pakets) und eines sehr komfortablen Debuggers (MicroFocus-ServerExpress bzw. -NetExpress bzw. AcuBench) wesentlich einfacher als in der UNISYS-Umgebung. TIP, RDMS, DMS und DPS werden in der Zielumgebung nicht mehr benötigt. Alle transaktionsrelevanten Daten werden in der relationalen Datenbank (Oracle) gespeichert und verwaltet. 2. Alle Batch-Programme werden weitestgehend automatisch umgesetzt. Sie laufen im wesentlichen ohne manuelle Änderungen mit der relationalen Datenbank. Die ECL-Jobs (mit IPF- und CTS-Prozeduren) werden mit dem G7-Job-Konverter in PERL-Skripts konvertiert. Für die Ausführung der ECL-Jobs stellt G7 eine ECL-Laufzeitumgebung bereit. 3. Für die Batch-Ablauf-Steuerung gibt es unter Windows NT/200X, UNIX und Linux sehr leistungsfähige Standard-Software (z.B. UC4). 4. Die Datenzugriffe aus den Dialog-Programmen und den Batch-Programmen auf ISAM-Dateien oder FMS8-Dateien werden durch die G7-Schnittstellen-Module (Adapter) automatisch auf eine relationale Datenbank umgeleitet. Für Datenzugriffe auf ISAM-Dateien werden SQL-Statements dynamisch generiert, weil der Zugriff kontextabhängig ist. Das gleiche gilt für die Zugriffe auf FMS8-Dateien. Die Datenzugriffe auf eine relationale Datenbank (via ACOB$RDMS) werden in SQL-Statements konvertiert. Für die Datenzugriffe auf eine DMS-Datenbank werden in der Zielumgebung mit dem G7-SQL-Generator aus der Schema-Beschreibung Zugriffsmodule generiert. 5. Die Transaktionssteuerung in der Zielumgebung übernimmt das Datenbank-System. Die in den Programmen aufgerufenen Module für das Setzen von Transaktionspunkten (Start/Commit/Rollback) werden so abgebildet, daß sie diese Information transparent an das Datenbank-System übermitteln. 6. Die Masken (DPS-Printouts) werden durch den G7-Maskenkonverter automatisch migriert und in der relationalen Datenbank abgebildet. Die D$-Routinen für die Maskenbearbeitung werden durch das in der Zielumgebung verfügbare G7-Programm mit dem Namen G7-DPS abgebildet. Es leitet die Anweisungen des Programms an den G7-Presentation-Manager weiter. Der G7-Presentation-Manager (WindowsProgramm 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-Beschreibungen werden auf seinem PC lokal gespeichert und durch die G7Ablaufsteuerung automatisch aktualisiert, sofern auf dem Server 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. Die in den Programmen dynamisch generierten Masken (SYSAAA) werden durch ein G7-Tool dynamisch in Masken für die Darstellung mit dem G7-Presentation-Manager umgesetzt. 7. Für die Konvertierung der Daten aus den ISAM-Dateien und den FMS8-Dateien in die relationale Datenbank wird der G7-Datenkonverter eingesetzt. Er wird aus den vorher mit dem G7-DatenstrukturKonverter in das G7-DataDictionary übernommenen Datenstrukturen generiert und übernimmt die Daten aus sequentiellen Files, die aus den Original-Dateien auf dem UNISYS-System erstellt werden. Sie werden (ohne Code-Konvertierung) in das Zielsystem per Filetransfer übertragen. Der G7-Datenkonverter startet den SQL-Loader, der die Daten in die relationale Datenbank lädt. Für das Entladen der RDMS-Datenbank bzw. der DMS-Datenbank auf dem Quell-System wird ein Standard-Tool eingesetzt. Nach deren Übermittlung an das Zielsystem werden die Daten für den ORACLE-Loader aufbereitet und in die Datenbank geladen. © GSE G7-Migration® Highlights der G7-Migration® Seite 3 8. Da die Programme 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 erforderlich, um die zwischenzeitlich geänderten Programme auch in der Zielumgebung nochmals zu testen. 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 dem in der Zielumgebung eingesetzten Hardware-Umfeld. 10. Ein mittleres G7-Migrations-Projekt mit 300 Dialog-Programmen (TIP-Transaktionen), 500 BatchProgrammen, 500 Jobs und 100 Datenstrukturen kann in ca. einem halben Jahr von zwei bis drei Mitarbeitern des Kunden unter Coaching durch den 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 weniger als 500 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 Cobol-Compilers und –Debuggers, 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 G7Entwicklungs-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), des G7-Entwicklungs-Systems, 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. © GSE G7-Migration® Highlights der G7-Migration® Seite 4 17. Die laufenden Kosten für den Einsatz der Anwendungen (Hardware und Software) sind auf einem Windows NT/200X- oder Unix-Rechner signifikant geringer als auf dem UNISYS-Rechner. 18. Neben dem Betriebssystem, dem G7-Migrations- und Entwicklungs-Paket, dem relationalen Datenbanksystem (ORACLE, INFORMIX, DB2, SQL-Server) mit embedded SQL oder ODBC-Schnittstelle, dem Cobol-Compiler mit Debugger (NetExpress) und einzelnen Standardtools (Cygwin, 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 und der G7-Broschüre beschrieben. Die daraus entstehende Projekt-Studie ist die Entscheidungsbasis für das weitere Vorgehen im eigentlichen Migrations-Projekt. © GSE G7-Migration®
