Migration von System i RPG-Anwendungen
Enterprise Generation Language
Mit der Enterprise Generation Language (EGL) bietet IBM eine moderne Entwicklungsumgebung, um sowohl System-i-native Anwendungen als auch plattformunabhängige Java-Anwendungen zu erstellen. Vieles, was man in RPG vermisst, ist in EGL komfortabel vorhanden. Das reicht von Web-Services über webbasierte User-Interfaces, von Drag & Drop GUI über hochproduktive Assistenten und von Datenbankmodellierung bis hin zur völligen Plattformunabhängigkeit.
Evolution von Mensch und Anwendung
Viele Unternehmen weltweit vertrauen nach wie vor auf System-i-Anwendungen und die Programmiersprache RPG, wenn es um kritische Business-Anwendungen geht. Noch heute laufen RPG-Anwendungen aus den Anfangszeiten ohne Änderung. Im Laufe der Zeit wurden die vorhandenen Anwendungen immer umfangreicher und komplexer. Da die vorhandenen Programme auf neuen Versionen von i5/OS immer ohne Änderung lauffähig waren, gibt es heute eine Vielzahl von Programmen, die nach dem Stand der Technik von vor 15 oder 20 Jahren entwickelt wurden. Ebenso gibt es Programme, die die neuesten Features von RPG IV nutzen; überdies gibt es beliebige Schattierungen dazwischen.
Parallel zu System i und RPG entstanden neue Entwicklungsplattformen wie Java und .NET mit modernen grafischen Benutzeroberflächen. Da sich diese Plattformen inzwischen als Standards etabliert haben, zeichnet sich in der Anwendungsentwicklung ein regelrechter Generationswechsel ab. Um lebensfähig zu bleiben, müssen auch RPG-Entwickler und Anwendungen früher oder später diesen Generationswechsel meistern.
Da die Investitionen in die vorhandenen Anwendungen und Skills in der Regel sehr hoch sind, ist dieser Generationswechsel nur wirtschaftlich sinnvoll zu bewältigen, wenn ein Großteil der vorhandenen Anwendungen und Skills sinnvoll in die neue Welt übernommen werden kann und als Ausgangsbasis für eine schrittweise Erneuerung dient. Die Migration von System i RPG-Anwendungen wird somit zum Schlüssel für diesen Generationswechsel.
Wann macht es Sinn, RPG-Anwendungen zu migrieren?
Für eine Migration gibt es eine Reihe von auslösenden Faktoren die einzeln oder in der Summe dazu führen, dass eine Migration unabdingbar wird.
Erwartete Restlebensdauer ist größer als 5 Jahre
Bereits heute gibt es kaum noch RPG-Entwicklernachwuchs. In fünf Jahren zählt RPG zu den exotischen Programmierumgebungen, für die kein Skill mehr neu aufgebaut wird. Die Wartung vieler kritischer Applikationen ist dann nicht mehr gewährleistet.
Die Anwendung wird auf einer anderen Plattform benötigt
Im Rahmen von Plattformstrategien oder Konsolidierungen wird die Anwendung auf einer Nicht-System-i-Plattform – wie Linux, Unix, Windows oder zOS – benötigt. Im Rahmen von Datenbankstrategien oder Konsolidierungen wird statt DB2/400 zum Beispiel DB2/UDB, Oracle oder SQL-Server benötigt.
Übergang in eine serviceorientierte Architektur
Bestehende monolithische Architekturen müssen in eine Geschäftsprozess- oder serviceorientierte Architektur aufgebrochen werden. Wichtig ist die Unterstützung des Servicekonzepts durch Sprache und Entwicklungsumgebung. Optimale Unterstützung von Web-Services und Sprachen zur Geschäftsprozessmodellierung – wie zum Beispiel BPEL – müssen gewährleistet sein.
Notwendigkeit von grafischen Benutzerschnittstellen
Anwender die hauptsächlich mit Windows- oder Web-Anwendungen arbeiten, empfinden den Übergang zu Green-Screen-Anwendungen als Störung des Bedienablaufes. Es gibt keine sinnvolle Integration zwischen den Oberflächen und die Bedienung ist in der Regel mit erhöhtem Trainingsaufwand verbunden. Zusätzlich werden Green-Screen-Anwendungen vom neuen Management oft als Indikator für eine nicht sehr innovative IT-Abteilung gesehen.
Verbesserung der Agilität
Historisch gewachsene Anwendungen lassen sich nur schwer ändern. Die Einführung neuer Geschäftsprozesse kann dadurch sehr teuer werden und sich erheblich verzögern. Die Wettbewerbsfähigkeit des Unternehmens wird dadurch stark behindert.
Verbesserung der Wettbewerbsfähigkeit
Speziell Anbieter von RPG-Standard-Software haben große Probleme bei der Gewinnung von Neukunden, da bevorzugt Java- oder .NET-Anwendungen gekauft werden.
RPG-Entwickler-Skill wird knapp
Eine größere Zahl von erfahrenen RPG-Entwicklern bereitet sich in den nächsten Jahren auf den Ruhestand vor. Neben reduzierter Innovationskraft ist die Wartung und Entwicklung der vorhandenen Anwendungen gefährdet.
Konsolidierung von Entwicklungsteams
Viele Unternehmen haben heute gemischte Entwickler-Teams mit RPG, Java und eventuell noch älteren 4GL-Anwendungen. Das macht die Entwicklung weniger flexibel und erhöht die Kosten. Die Konsolidierung von verschiedenen Entwicklungs-Teams auf eine einheitliche moderne Sprache und Entwicklungsumgebung erhöht die Flexibilität und senkt die Kosten.
Die Migration – teilweise in Verbindung mit Reengineering oder Modularisierung – ist die Grundlage zur Lösung dieser Probleme. Um eine sinnvolle Migration zu ermöglichen, muss die zu migrierende Anwendung jedoch eine gewisse Mindestqualität aufweisen.
Investitionen schützen
Beim Generationswechsel in der Anwendungsentwicklung gibt es klassischerweise drei grundverschiedene Ansätze:
Ablösung durch Standard-Software
Die vorhandene Anwendung wird ersetzt durch eine Standard-Software eines entsprechenden Anbieters. Der Aufwand ist sehr hoch, da er meist mit organisatorischen Änderungen verbunden ist. Außerdem werden neue Abhängigkeiten geschaffen. Das ist sinnvoll für Standardprozesse, aber nicht für wettbewerbskritische Prozesse, da das Differenzierungspotential stark eingeschränkt wird.
Neuschreiben
Das ist verbunden mit hohen Kosten und Terminrisiken. Oft sind die vorhandenen RPG-Anwendungen nicht ausreichend dokumentiert; vorhandene Funktionsmerkmale werden beim Neuschreiben nicht ausreichend berücksichtigt. Dies kann bei der Einführung der neugeschriebenen Funktionalität zu erheblichen Störungen im Betriebsablauf führen.
Migration
Die Funktionalität der vorhandenen Software wird komplett oder in kleineren Schritten durch automatisierte Verfahren in eine moderne Entwicklungsumgebung übernommen. Risiko und Kosten sind deutlich reduziert. Im Rahmen der Migration können über Reengineering und Modularisierung auch Qualitätsverbesserungen durchgeführt beziehungsweise die Struktur modularisiert werden.
Warum nach EGL migrieren?
Neben Java und .NET bietet sich insbesondere IBMs Enterprise Generation Language (EGL) als moderne Zielumgebung für kritische Geschäftsanwendungen an. EGL verbindet die Stärken von Java mit hochperformanter Native-Code-Generierung für System i und System z. Die Anwendungen laufen somit optimal auf allen wichtigen Plattformen von Windows über Linux, Unix und System i bis hin zu System z.
Eingebettet in Eclipse bietet EGL eine moderne und serviceorientierte Sprache für die effiziente Entwicklung von verschiedenen Anwendungstypen wie Web-Anwendungen, Datenbankanwendungen, Web-Services sowie Batch- und Hochleistungs-Server für schnelle Transaktionsverarbeitung.
Durch die enge Einbindung in die Rational-Toolkette kann die EGL-Entwicklung in einen professionellen Entwicklungsprozess beziehungsweise Lifecycle – beginnend vom Anforderungsmanagement über Modellierung und Coding bis hin zu Test und Deployment – eingebettet werden.
Um eine optimale Migration von RPG-Anwendungen nach EGL zu ermöglichen, arbeitet der Migrationsspezialist PKS Software eng mit dem IBM EGL-Entwicklungslabor in Raleigh zusammen. Neben der Migration der RPG-Anwendungen, ermöglicht EGL durch seine einfache Einarbeitung auch den effizienten Umstieg von RPG-Entwicklern mit wichtigem Business-Know-how in einem Bruchteil der Zeit, die für Java notwendig wäre.
Welche Migrationsszenarien gibt es?
Die Anwendung bleibt auf System i
Wird die migrierte Anwendung ausschließlich auf System i benötigt, so gestaltet sie sich besonders einfach, da die vorhandenen RPG-Programme Schritt für Schritt nach EGL migriert werden können. Oft werden in den Anwendungen i5OS-spezifische Funktionalitäten – wie zum Beispiel CL, Commands, APIs und Systembefehle – benutzt. Nach einer Migration stehen diese auch weiterhin zur Verfügung und müssen daher nicht ersetzt werden.
Typischerweise läuft eine Migration in zwei Schritten ab. Im ersten Schritt wird die vorhandene RPG-Anwendung über ein Server Builder Tool von der 5250-Benutzeroberfläche entkoppelt. Die RPG-Anwendung arbeitet nun mit API-Funktionen, die direkt eine Web- oder Windows-Benutzeroberfläche ansteuern können. Diese grafische Benutzeroberfläche kann über ein GUI Stylesheet mit über 60 neuen Funktionen automatisch aus der vorhandenen DDS-Quelle erzeugt werden. Mit geringem Arbeitsaufwand wird die Anwendung in eine Server-Anwendung verwandelt, die keine interaktive Leistung mehr benötigt und eine grafische Benutzeroberfläche besitzt.
Im zweiten Schritt werden nun die RPG-Programme sukzessive nach EGL migriert. Die erzeugten EGL-Programme können das gleiche API für die Benutzerschnittstelle verwenden wie die RPG-Programme. Neue Funktionalität kann nun in EGL einfach hinzugefügt werden, da eine einfache Integration mit RPG und der grafischen Benutzeroberfläche möglich ist. Neue EGL-Programme können direkt in einer serviceorientierten Architektur entwickelt werden. Im Laufe der Zeit lassen sich so erneuerungsbedürftige Programme in EGL neu erstellen. Außerdem kann man über Refactoring die bestehende Architektur in eine serviceorientierte Architektur überführen.
Als Ergebnis der Migration werden alle plattformspezifischen Funktionalitäten und Datenbankzugriffe der RPG-Programme in EGL Libraries gekapselt. Durch die Auftrennung in Business-Logik und in eine plattformspezifische Schicht wird die Portabilität der Anwendungen deutlich erhöht.
Die Anwendung wird benötigt auf Windows, Unix oder Linux
Da EGL selbst plattformunabhängig ist, können die migrierten RPG-Anwendungen prinzipiell auch auf anderen Plattformen eingesetzt werden. Es gibt jedoch – bedingt durch die umfangreiche Funktionalität von i5OS – einige Besonderheiten die berücksichtigt werden müssen. Auf Windows, Unix oder Linux gibt es standardmäßig keine Datenbank – wie in i5OS. Es wird daher eine Datenbank – wie DB2/UDB, Oracle oder MS SQL-Server – zusätzlich benötigt. Da RPG-Anwendungen gerne Funktionalität, die auf Windows, Unix oder Linux nicht vorhanden ist, aus i5OS benutzen, muss sie aus der Anwendung ausgebaut oder über eine spezielle Service-Library zur Verfügung gestellt werden. Das Ausbauen kann manuell erfolgen; es kann aber auch über regelbasiertes Reengineering teilweise automatisiert werden. Da auf diesen Plattformen kein RPG-Compiler zur Verfügung steht, muss die Anwendung vollständig nach EGL migriert werden, um lauffähig zu sein. Vorhandene Daten aus DB2/400 können mit entsprechenden Werkzeugen automatisch nach DB2/UDB, Oracle oder MS SQL-Server übernommen werden.
Die Anwendung wird benötigt auf System z
Besteht der Wunsch, vorhandene System i RPG-Anwendungen nach System z zu migrieren, so ist dies mit EGL ebenfalls möglich. Es gibt hierfür zwei Lösungsansätze, die sich im Aufwand allerdings erheblich unterscheiden.
Im ersten Ansatz wird die DB2/400-Datenbank nach DB2 auf zOS migriert. Alle RPG Batch-Programme werden ebenfalls nach EGL migriert; sie sind unter zOS Cobol hochperformant. Die Job Control Language CL von System i wird manuell oder teilautomatisch über regelbasierte Systeme nach JCL migriert. Interaktive RPG-Programme können über EGL nach zLinux migriert werden; sie arbeiten ebenfalls mit DB2 auf zOS. Als Benutzeroberfläche wird eine Web-Oberfläche erzeugt. Die interaktiven EGL-Programme laufen dann unter Java und zLinux.
Im zweiten Ansatz werden neben den Batch-Programmen auch alle interaktiven Programme über EGL nach zOS migriert. Um die interaktiven Programme CICS fähig zu machen, ist ein komplettes Reengineering der RPG-/ EGL-Programme notwendig, um von einer prozeduralen Architektur in eine transaktionsorientierte Architektur zu wechseln. Dies kann entweder manuell erfolgen oder ebenfalls teilautomatisiert über regelbasierte Systeme. Ergebnis ist eine reine zOS-Anwendung.
Migrationswerkzeuge
Um die Migration zu ermöglichen, gibt es eine Reihe von Werkzeugen und Libraries.
Migration Tools 400 EGL
• RPG nach EGL-Konverter
• Database Schema Generator
• Database Loader
• Universal Client Xi
• Server Builder 400
• Service Library 400
Wie fange ich an
Die Migration einer RPG-Anwendung ist ein wichtiger strategischer Schritt in die Zukunft; sie erfordert eine sorgfältige Vorbereitung. Was in vielen Jahren von vielen Programmierern entwickelt wurde, kann auch eine Vielzahl von Überraschungen enthalten.
Um eine sichere Migration zu gewährleisten, haben sich folgende Schritte bewährt:
• EGL Skills aufbauen
• Praktische Erfahrungen sammeln mit EGL-Entwicklung
• Vorhandenes RPG Programm nach EGL konvertieren und anschauen
• Vollständige und detaillierte Analyse der vorhandenen Anwendung durchführen
• Proof of Concept mit einem kleinen Teil der Anwendung durchführen
• Migration der Anwendung gemeinsam mit erfahrenen Migrationsspezialisten
• Nutzen der neuen EGL-Möglichkeiten
Sanfter Einstieg in die Zukunft
Der Umstieg nach EGL ist für RPG-Programmierer ein attraktiver Weg, um die vorhandenen Programme schnell zu verbessern und um neue Funktionalität zu erweitern. Die Umstellung kann in kleinen Schritten erfolgen und liefert somit bereits einen Mehrwert im Tagesgeschäft. RPG-/ EGL-Entwickler können nun einfach Dinge tun, die bisher mühsam in Java programmiert werden mussten.
Enterprise Generation Language
Mit der Enterprise Generation Language (EGL) bietet IBM eine moderne Entwicklungsumgebung, um sowohl System-i-native Anwendungen als auch plattformunabhängige Java-Anwendungen zu erstellen. Vieles, was man in RPG vermisst, ist in EGL komfortabel vorhanden. Das reicht von Web-Services über webbasierte User-Interfaces, von Drag & Drop GUI über hochproduktive Assistenten und von Datenbankmodellierung bis hin zur völligen Plattformunabhängigkeit.
Evolution von Mensch und Anwendung
Viele Unternehmen weltweit vertrauen nach wie vor auf System-i-Anwendungen und die Programmiersprache RPG, wenn es um kritische Business-Anwendungen geht. Noch heute laufen RPG-Anwendungen aus den Anfangszeiten ohne Änderung. Im Laufe der Zeit wurden die vorhandenen Anwendungen immer umfangreicher und komplexer. Da die vorhandenen Programme auf neuen Versionen von i5/OS immer ohne Änderung lauffähig waren, gibt es heute eine Vielzahl von Programmen, die nach dem Stand der Technik von vor 15 oder 20 Jahren entwickelt wurden. Ebenso gibt es Programme, die die neuesten Features von RPG IV nutzen; überdies gibt es beliebige Schattierungen dazwischen.
Parallel zu System i und RPG entstanden neue Entwicklungsplattformen wie Java und .NET mit modernen grafischen Benutzeroberflächen. Da sich diese Plattformen inzwischen als Standards etabliert haben, zeichnet sich in der Anwendungsentwicklung ein regelrechter Generationswechsel ab. Um lebensfähig zu bleiben, müssen auch RPG-Entwickler und Anwendungen früher oder später diesen Generationswechsel meistern.
Da die Investitionen in die vorhandenen Anwendungen und Skills in der Regel sehr hoch sind, ist dieser Generationswechsel nur wirtschaftlich sinnvoll zu bewältigen, wenn ein Großteil der vorhandenen Anwendungen und Skills sinnvoll in die neue Welt übernommen werden kann und als Ausgangsbasis für eine schrittweise Erneuerung dient. Die Migration von System i RPG-Anwendungen wird somit zum Schlüssel für diesen Generationswechsel.
Wann macht es Sinn, RPG-Anwendungen zu migrieren?
Für eine Migration gibt es eine Reihe von auslösenden Faktoren die einzeln oder in der Summe dazu führen, dass eine Migration unabdingbar wird.
Erwartete Restlebensdauer ist größer als 5 Jahre
Bereits heute gibt es kaum noch RPG-Entwicklernachwuchs. In fünf Jahren zählt RPG zu den exotischen Programmierumgebungen, für die kein Skill mehr neu aufgebaut wird. Die Wartung vieler kritischer Applikationen ist dann nicht mehr gewährleistet.
Die Anwendung wird auf einer anderen Plattform benötigt
Im Rahmen von Plattformstrategien oder Konsolidierungen wird die Anwendung auf einer Nicht-System-i-Plattform – wie Linux, Unix, Windows oder zOS – benötigt. Im Rahmen von Datenbankstrategien oder Konsolidierungen wird statt DB2/400 zum Beispiel DB2/UDB, Oracle oder SQL-Server benötigt.
Übergang in eine serviceorientierte Architektur
Bestehende monolithische Architekturen müssen in eine Geschäftsprozess- oder serviceorientierte Architektur aufgebrochen werden. Wichtig ist die Unterstützung des Servicekonzepts durch Sprache und Entwicklungsumgebung. Optimale Unterstützung von Web-Services und Sprachen zur Geschäftsprozessmodellierung – wie zum Beispiel BPEL – müssen gewährleistet sein.
Notwendigkeit von grafischen Benutzerschnittstellen
Anwender die hauptsächlich mit Windows- oder Web-Anwendungen arbeiten, empfinden den Übergang zu Green-Screen-Anwendungen als Störung des Bedienablaufes. Es gibt keine sinnvolle Integration zwischen den Oberflächen und die Bedienung ist in der Regel mit erhöhtem Trainingsaufwand verbunden. Zusätzlich werden Green-Screen-Anwendungen vom neuen Management oft als Indikator für eine nicht sehr innovative IT-Abteilung gesehen.
Verbesserung der Agilität
Historisch gewachsene Anwendungen lassen sich nur schwer ändern. Die Einführung neuer Geschäftsprozesse kann dadurch sehr teuer werden und sich erheblich verzögern. Die Wettbewerbsfähigkeit des Unternehmens wird dadurch stark behindert.
Verbesserung der Wettbewerbsfähigkeit
Speziell Anbieter von RPG-Standard-Software haben große Probleme bei der Gewinnung von Neukunden, da bevorzugt Java- oder .NET-Anwendungen gekauft werden.
RPG-Entwickler-Skill wird knapp
Eine größere Zahl von erfahrenen RPG-Entwicklern bereitet sich in den nächsten Jahren auf den Ruhestand vor. Neben reduzierter Innovationskraft ist die Wartung und Entwicklung der vorhandenen Anwendungen gefährdet.
Konsolidierung von Entwicklungsteams
Viele Unternehmen haben heute gemischte Entwickler-Teams mit RPG, Java und eventuell noch älteren 4GL-Anwendungen. Das macht die Entwicklung weniger flexibel und erhöht die Kosten. Die Konsolidierung von verschiedenen Entwicklungs-Teams auf eine einheitliche moderne Sprache und Entwicklungsumgebung erhöht die Flexibilität und senkt die Kosten.
Die Migration – teilweise in Verbindung mit Reengineering oder Modularisierung – ist die Grundlage zur Lösung dieser Probleme. Um eine sinnvolle Migration zu ermöglichen, muss die zu migrierende Anwendung jedoch eine gewisse Mindestqualität aufweisen.
Investitionen schützen
Beim Generationswechsel in der Anwendungsentwicklung gibt es klassischerweise drei grundverschiedene Ansätze:
Ablösung durch Standard-Software
Die vorhandene Anwendung wird ersetzt durch eine Standard-Software eines entsprechenden Anbieters. Der Aufwand ist sehr hoch, da er meist mit organisatorischen Änderungen verbunden ist. Außerdem werden neue Abhängigkeiten geschaffen. Das ist sinnvoll für Standardprozesse, aber nicht für wettbewerbskritische Prozesse, da das Differenzierungspotential stark eingeschränkt wird.
Neuschreiben
Das ist verbunden mit hohen Kosten und Terminrisiken. Oft sind die vorhandenen RPG-Anwendungen nicht ausreichend dokumentiert; vorhandene Funktionsmerkmale werden beim Neuschreiben nicht ausreichend berücksichtigt. Dies kann bei der Einführung der neugeschriebenen Funktionalität zu erheblichen Störungen im Betriebsablauf führen.
Migration
Die Funktionalität der vorhandenen Software wird komplett oder in kleineren Schritten durch automatisierte Verfahren in eine moderne Entwicklungsumgebung übernommen. Risiko und Kosten sind deutlich reduziert. Im Rahmen der Migration können über Reengineering und Modularisierung auch Qualitätsverbesserungen durchgeführt beziehungsweise die Struktur modularisiert werden.
Warum nach EGL migrieren?
Neben Java und .NET bietet sich insbesondere IBMs Enterprise Generation Language (EGL) als moderne Zielumgebung für kritische Geschäftsanwendungen an. EGL verbindet die Stärken von Java mit hochperformanter Native-Code-Generierung für System i und System z. Die Anwendungen laufen somit optimal auf allen wichtigen Plattformen von Windows über Linux, Unix und System i bis hin zu System z.
Eingebettet in Eclipse bietet EGL eine moderne und serviceorientierte Sprache für die effiziente Entwicklung von verschiedenen Anwendungstypen wie Web-Anwendungen, Datenbankanwendungen, Web-Services sowie Batch- und Hochleistungs-Server für schnelle Transaktionsverarbeitung.
Durch die enge Einbindung in die Rational-Toolkette kann die EGL-Entwicklung in einen professionellen Entwicklungsprozess beziehungsweise Lifecycle – beginnend vom Anforderungsmanagement über Modellierung und Coding bis hin zu Test und Deployment – eingebettet werden.
Um eine optimale Migration von RPG-Anwendungen nach EGL zu ermöglichen, arbeitet der Migrationsspezialist PKS Software eng mit dem IBM EGL-Entwicklungslabor in Raleigh zusammen. Neben der Migration der RPG-Anwendungen, ermöglicht EGL durch seine einfache Einarbeitung auch den effizienten Umstieg von RPG-Entwicklern mit wichtigem Business-Know-how in einem Bruchteil der Zeit, die für Java notwendig wäre.
Welche Migrationsszenarien gibt es?
Die Anwendung bleibt auf System i
Wird die migrierte Anwendung ausschließlich auf System i benötigt, so gestaltet sie sich besonders einfach, da die vorhandenen RPG-Programme Schritt für Schritt nach EGL migriert werden können. Oft werden in den Anwendungen i5OS-spezifische Funktionalitäten – wie zum Beispiel CL, Commands, APIs und Systembefehle – benutzt. Nach einer Migration stehen diese auch weiterhin zur Verfügung und müssen daher nicht ersetzt werden.
Typischerweise läuft eine Migration in zwei Schritten ab. Im ersten Schritt wird die vorhandene RPG-Anwendung über ein Server Builder Tool von der 5250-Benutzeroberfläche entkoppelt. Die RPG-Anwendung arbeitet nun mit API-Funktionen, die direkt eine Web- oder Windows-Benutzeroberfläche ansteuern können. Diese grafische Benutzeroberfläche kann über ein GUI Stylesheet mit über 60 neuen Funktionen automatisch aus der vorhandenen DDS-Quelle erzeugt werden. Mit geringem Arbeitsaufwand wird die Anwendung in eine Server-Anwendung verwandelt, die keine interaktive Leistung mehr benötigt und eine grafische Benutzeroberfläche besitzt.
Im zweiten Schritt werden nun die RPG-Programme sukzessive nach EGL migriert. Die erzeugten EGL-Programme können das gleiche API für die Benutzerschnittstelle verwenden wie die RPG-Programme. Neue Funktionalität kann nun in EGL einfach hinzugefügt werden, da eine einfache Integration mit RPG und der grafischen Benutzeroberfläche möglich ist. Neue EGL-Programme können direkt in einer serviceorientierten Architektur entwickelt werden. Im Laufe der Zeit lassen sich so erneuerungsbedürftige Programme in EGL neu erstellen. Außerdem kann man über Refactoring die bestehende Architektur in eine serviceorientierte Architektur überführen.
Als Ergebnis der Migration werden alle plattformspezifischen Funktionalitäten und Datenbankzugriffe der RPG-Programme in EGL Libraries gekapselt. Durch die Auftrennung in Business-Logik und in eine plattformspezifische Schicht wird die Portabilität der Anwendungen deutlich erhöht.
Die Anwendung wird benötigt auf Windows, Unix oder Linux
Da EGL selbst plattformunabhängig ist, können die migrierten RPG-Anwendungen prinzipiell auch auf anderen Plattformen eingesetzt werden. Es gibt jedoch – bedingt durch die umfangreiche Funktionalität von i5OS – einige Besonderheiten die berücksichtigt werden müssen. Auf Windows, Unix oder Linux gibt es standardmäßig keine Datenbank – wie in i5OS. Es wird daher eine Datenbank – wie DB2/UDB, Oracle oder MS SQL-Server – zusätzlich benötigt. Da RPG-Anwendungen gerne Funktionalität, die auf Windows, Unix oder Linux nicht vorhanden ist, aus i5OS benutzen, muss sie aus der Anwendung ausgebaut oder über eine spezielle Service-Library zur Verfügung gestellt werden. Das Ausbauen kann manuell erfolgen; es kann aber auch über regelbasiertes Reengineering teilweise automatisiert werden. Da auf diesen Plattformen kein RPG-Compiler zur Verfügung steht, muss die Anwendung vollständig nach EGL migriert werden, um lauffähig zu sein. Vorhandene Daten aus DB2/400 können mit entsprechenden Werkzeugen automatisch nach DB2/UDB, Oracle oder MS SQL-Server übernommen werden.
Die Anwendung wird benötigt auf System z
Besteht der Wunsch, vorhandene System i RPG-Anwendungen nach System z zu migrieren, so ist dies mit EGL ebenfalls möglich. Es gibt hierfür zwei Lösungsansätze, die sich im Aufwand allerdings erheblich unterscheiden.
Im ersten Ansatz wird die DB2/400-Datenbank nach DB2 auf zOS migriert. Alle RPG Batch-Programme werden ebenfalls nach EGL migriert; sie sind unter zOS Cobol hochperformant. Die Job Control Language CL von System i wird manuell oder teilautomatisch über regelbasierte Systeme nach JCL migriert. Interaktive RPG-Programme können über EGL nach zLinux migriert werden; sie arbeiten ebenfalls mit DB2 auf zOS. Als Benutzeroberfläche wird eine Web-Oberfläche erzeugt. Die interaktiven EGL-Programme laufen dann unter Java und zLinux.
Im zweiten Ansatz werden neben den Batch-Programmen auch alle interaktiven Programme über EGL nach zOS migriert. Um die interaktiven Programme CICS fähig zu machen, ist ein komplettes Reengineering der RPG-/ EGL-Programme notwendig, um von einer prozeduralen Architektur in eine transaktionsorientierte Architektur zu wechseln. Dies kann entweder manuell erfolgen oder ebenfalls teilautomatisiert über regelbasierte Systeme. Ergebnis ist eine reine zOS-Anwendung.
Migrationswerkzeuge
Um die Migration zu ermöglichen, gibt es eine Reihe von Werkzeugen und Libraries.
Migration Tools 400 EGL
• RPG nach EGL-Konverter
• Database Schema Generator
• Database Loader
• Universal Client Xi
• Server Builder 400
• Service Library 400
Wie fange ich an
Die Migration einer RPG-Anwendung ist ein wichtiger strategischer Schritt in die Zukunft; sie erfordert eine sorgfältige Vorbereitung. Was in vielen Jahren von vielen Programmierern entwickelt wurde, kann auch eine Vielzahl von Überraschungen enthalten.
Um eine sichere Migration zu gewährleisten, haben sich folgende Schritte bewährt:
• EGL Skills aufbauen
• Praktische Erfahrungen sammeln mit EGL-Entwicklung
• Vorhandenes RPG Programm nach EGL konvertieren und anschauen
• Vollständige und detaillierte Analyse der vorhandenen Anwendung durchführen
• Proof of Concept mit einem kleinen Teil der Anwendung durchführen
• Migration der Anwendung gemeinsam mit erfahrenen Migrationsspezialisten
• Nutzen der neuen EGL-Möglichkeiten
Sanfter Einstieg in die Zukunft
Der Umstieg nach EGL ist für RPG-Programmierer ein attraktiver Weg, um die vorhandenen Programme schnell zu verbessern und um neue Funktionalität zu erweitern. Die Umstellung kann in kleinen Schritten erfolgen und liefert somit bereits einen Mehrwert im Tagesgeschäft. RPG-/ EGL-Entwickler können nun einfach Dinge tun, die bisher mühsam in Java programmiert werden mussten.
