View Full Version : Migration RPG/CL in .net / java etc.
habe da eine frage - es gibt da ja ein produkt "ML-Impact" mit welchem man sämtliche CL/RPG-Anwendungen schnell und problem los in eine andere Plattform migrieren kann (.net / Java); ist dies wirklich so einfach - umfangreiche ILERPG´s mit eingebettetem SQL und "free" ??, hat da schon jemand Erfahrung ?
gruss Heinz
Frank Hildebrandt
17-05-11, 10:01
Wenn da jemand sagt, er könne RPG und CL schnell und einfach zu einer anderen Plattform portieren, dann muss eigentlich jedem klar sein, dass das nichts weiter als eine Aussage eines Verkäufers ist, die mit der Realität nicht viel zu tun hat. Ich kenne kaum eine Anwendung, in der nicht mit z.B. IBM i API`s gearbeitet wird. Es ist ziemlich umwahrscheinlich, dass ML die Funktionen dieser API`s in seiner Ablaufumgebung nachgebaut hat. Bei CL siehts nicht anders aus. Wenn man eine bestehende historisch gewachsende Anwendung zu einer anderen Platform konvertieren will, ob zu LANSA mit .NET oder ML mit .NET oder PKS mit EGL oder ABC mit XYZ, dann wird man nicht umher kommen die vielen IBM i spezifischen Eigenheiten, die sich in der Anwendung befinden zunächst zu beseitigen, was sich i.d.R. in einem mehrmonatigen Projekt äußert.
danke für die schnelle antwort;
wenn ich aber google und nach diesem produkt suche finde ich da eigentlich nur positives ?; natürlich ist nirgends der reale aufwand beschrieben - aber es heißt über alle "schnell und problemlos" - > rpg-code wird analysiert usw. und dann migriert ? -
Frank Hildebrandt
17-05-11, 10:34
Man muss sich jetzt einfach mal vor Augen führen, was notwendig ist, eine bestehende IBM i Anwendung auf eine andere Platform zu heben. Auf der neuen Platform muss eine Runtime-Umgebung gebaut werden, die die Funktionen der Programme auf der IBM i nachbildet. Das Konvertieren des RPG Codes in eine andere Sprache wird da weniger das Problem sein. Wahrscheinlich können auch die meisten Displayfiles konvertiert werden. Aber es gibt mit Sicherheit eine Menge Features unter IBM i, die die neue Platform nicht unterstützt. Schau Dir nur mal die Masse an API`s an, die es unter IBM i gibt. Wird ein soches API in der zu portierenden Anwendung benutzt, dann muss auf der neuen Platform diese Funktion nachgebildet werden, da IBM i dort ja nicht mehr zur Verfügung steht, insofern man alles per Knopfdruck portieren will. Schau Dir die Masse an CL Befehlen an. Diese Befehle erfüllen alle einen bestimmten Zweck, auf den man auf der neuen Platform wahrscheinlich nicht verzichten will. Auch da ist es unwahrscheinlich, dass alle diese Befehle auf der neuen Platform eine Entsprechung finden. Mir fallen da noch spontan Panelgroups ein. Ich kenne eine Menge Kunden, die damit arbeiten. Ich wage mal zu bezweifeln, dass das auf der neuen Platform unterstützt wird. Alte Anwendungen zeichnen sich z.B. auch dadurch aus, dass in Displayfiles DDS Schlüsselwörter verwendet werden, die heute niemand mehr in einer neu zu erstellenden Displayfile verwenden würde. Ich bin mir zu 100% sicher, dass nicht sämtliche DDS Schlüsselwörter in einer Displayfile von ML unterstützt werden. Ich habe mir in meiner Laufbahn schon einiges angesehen, wo versprochen wurde, dass alles per Knopfdruck in eine "MODERNE" Umgebung konvertiert wird. Das mag zu 90% sogar funktionieren und 90% mögen sich auf den ersten Blick ziemlich viel anhören, jedoch äußern sich die verbleibenden 10%, die nicht unterstützt werden in einer riesigen Menge Arbeit.
Ich bleibe dabei. Es gibt das Produkt nicht, das per Kopfdruck und ohne umfangreiche Nacharbeiten eine bestehende historisch gewachsene Anwendung auf IBM i auf eine andere Platform portiert. Und falls es diese Anwendung doch gibt, dann lass ich ein Faß Bier springen.
Zusätzlich muss man unterscheiden, ob man tatsächlich die Plattform wechselt, also weg von der AS/400 geht, oder die aufgeführten "Migrationstools" verwendet.
Bleibt man jedoch auf der AS/400 handelt es sich ja eigentlich nur um ein aufhübschen der Altanwendung.
Dazu gilt, dass nun mal eine Anwendung i.W. nur zwischen 10-30% aus Dialog besteht.
Die Migration der Anwendung besteht also in der Umsetzung der Dialoganwendung.
Die meisten der Tools änderen daher nur den Dialogteil eines Programmes durch Aufrufe von neuen API's an Stelle der alten READ/WRITE/EXFMT für die DSPF's.
Das Programm läuft ja weiterhin auf der AS/400 und kann daher (fast) alle API's des Systems weiter verwenden.
CLP's, die keine Dialoge verwenden sind also auch weiterhin aufrufbar.
Der Migrationsaufwand, also das Aufhübschen der Anwendung, kann sich also, in Grenzen, durchaus lohnen.
Allerdings sollte man dabei nicht vernachlässigen, dass bei migrierten Anwendungen häufig der "Transaktionsdurchsatz" verschlechtert.
Dies liegt nicht an der Migration selber, sondern am Arbeiten mit der neuen Anwendung durch mehr Mausarbeit (Zielen und Clicken) und weniger Tastaturarbeit.
Ich habe schon sehr häufig gesehen, dass man von Eingabe zu Eingabe mit der Maus clickt an Stelle die Tastatur zu verwenden.
Im Durchschnitt dauert z.B. eine simple Auftragserfassung dann 2-4 Mal so lange wie mit dem guten alten Greenscreen.
... die Realität der Magie ist die Illusion
RobertMack
17-05-11, 11:33
OVRDBF FILE(TRAUM) TOFILE(POWER7) OVRSCOPE(*FUTURE)
und wenn angedacht wird, daß die "alten" anwendungen migriert und dann nicht mehr auf der iSeries laufen sollen ?
in anderem technischen umfeld ? wie sieht es dann aus ?
heinz
und wenn angedacht wird, daß die "alten" anwendungen migriert und dann nicht mehr auf der iSeries laufen sollen ?
in anderem technischen umfeld ? wie sieht es dann aus ?
Ein schlechter Tausch. Aber dafür wenigstens "modern". :rolleyes:
Da kann man nicht von einer Migration sondern nur von einer Neuentwicklung (neudeutsch Reengineering, Reverse Engineering) sprechen.
In solchen Fällen ist man meist günstiger, wenn man sich da bereits fertige Lösungen anschaut und nur die Datenübernahme konzipieren muss.
Man gewinnt dann eher (auch neue Funktionalitäten) als sich nur auf neuer Hard-/Software mit den selben alten Hüten zu beschäftigen.