RPGII, RPGIII, RPG400, RPGIV, ILE Was ist was?

[B.Hauser]

Hallo Baldur,

sobald Prozeduren aus Service-Programmen aufgerufen werden, spricht man tatsächlich von ILE, auch wenn das Programm nur aus einem Modul besteht.

Wenn aber nur im OPM-Stil programmiert wird, also nur dynamische Programm-Aufrufe erfolgen, ist das m.E. kein ILE sondern RPGIV.
In RPGIII war ein statischer Prozedur-Aufruf noch nicht möglich, deshalb kann aus konvertierten Quellen ohne entsprechende Bearbeitung kein ILE-Programm entstehen.

ILE ist das Konzept und nicht die Programmiersprache!
Die ILE-Konzepte gelten ebenso für C oder COBOL.

Birgitta

[Sven Schneider]

Hallo Birgitta,
ich möchte mich auch noch einmischen.
Ich muß hier Baldur rechtgeben.

Aus technischer Sicht ist ein mit CRTBNDPGM und DFTACTGRP(*YES) umgewandeltes RPGIV-Programm eine ILE-Objekt, es verhält sich halt wie ein OPM-Programm.

Auszug aus Online-Doku :

Wird dieses Programm aufgerufen, wird es immer in der
Standardaktivierungsgruppe ausgeführt. Die
Standardaktivierungsgruppe ist die Aktivierungsgruppe, in der alle
OPM-Programme (OPM = Original Program Model) ausgeführt werden.

Wird DFTACTGRP(*YES) angegeben, verhalten sich ILE RPG-Programme in
bezug auf die gemeinsame Benutzung von Dateien, den Dateibereich und
RCLRSC wie OPM-Programme.

Statisches Binden in ILE ist nicht verfügbar, wenn ein Programm mit
DFTACTGRP(*YES) erstellt wird. Dies bedeutet, daß beim Erstellen
dieses Programms die Parameter BNDDIR oder ACTGRP nicht verwendet
werden können. Darüber hinaus muß jede Aufrufoperation in der Quelle
ein Programm und nicht eine Prozedur aufrufen.

DFTACTGRP(*YES) ist sinnvoll, wenn versucht wird, eine Anwendung auf
Programmbasis in ILE RPG zu übertragen.


Weil auch CRTBNDRPG nutzt intern CRTRPGMOD und den Linker CRTPGM.
Und da hier ja Service-Progamme der ILE-Laufzeitumgebung statisch gebunden und zur Laufzeit auch genutzt werden, handelt es sich um ein ILE-Programmobjekt.
Jederzeit mit DSPPGM kontrollierbar.

Das Programm läuft halt nur in der Default-Aktivierungsgruppe, kann keine selbst!!! geschriebenen Prozeduren aufrufen und statisches Binden eigener!!! Module/Service-Programme ist nicht möglich.

Das Programm kann sehr wohl aber statisch gebundene Prozeduren der Laufzeitumgebung aufrufen.

Oder um es anders auszudrücken es gibt keinen OPM-Compiler für den Sprachstandard RPGIV.
Technisch wäre das sicherlich möglich, wenn man auf die ILE-Konstukte verzichten würde.

Sven

[B.Hauser]

Hallo Sven,

diese ganzen technischen Gegenheiten waren mir schon bekannt.

Wogegen ich mich einfach wehre ist, dass, wie bisher nach OPM, TopDown in Monsterprogrammen programmiert wird und dann behautet wird, das sei ILE.

Ich habe schon erlebt, dass nur aus einem Grund nach RPGIV konvertiert wurde, weil RPGIII die Anzahl Dateien und Statements nicht mehr verarbeiten konnte. Die Quelle wurde in RPGIII geändert, anschliessend konvertiert und umgewandelt. Die nächste Änderung wurde wieder in der RPGIII Quelle gemacht.

Solange nicht modular nach ILE-Konzepten programmiert wird, ist es für mich kein ILE sondern RPGIV, auch wenn bei der Umwandlung technisch ein ILE-Objekt entsteht.

Und ganz ehrlich, es gibt nur wenige, die wirklich ILE RPG programmieren.

Birgitta

[Fuerchau]

Wenn man auf der "grünen Wiese" ein neues Software-Paket entwickelt (aber wer macht das schon noch auf der iSeries), kann man sicherlich nach ILE-Konzepten Programme entwickeln.
Dann fehlen mir allerdings wesentliche Eigenschaften für ein "richtiges" Konzept:
Klassen mit Eigenschaften und Methoden, Mehrfachinstanzen sowie Vererbung.
Das ist aber eher was für C++/Java und wird es sicherlich niemals in ILERPG geben.

Dann kann ich die Anwendung auch ganz anders konzipieren und meinetwegen auch ILE verwenden.
Solange ich aber auf der Basis bestehender Anwendungen weiterentwickeln muss, kann ich nun mit ILERPG etwas komfortabler neue Funktionen (Builtin's) nutzen und ggf. in Freeformat lesbarere Quellen erstellen (was allerdings Alt-RPGler ziehmlich schwierig finden).

Das eigentlich ILE-Konzept wird allerdings eher selten verwendet:
Integrated-Language-Environment besagt nun mal, dass ich je nach Anforderung die für mich günstigste Sprache für die Entwicklung einer Funktion wähle und dann damit mein Programm zusammenmische.
Also COBOL/RPG/C++/CLP gemischt in Modulen mit dem jeweils Besten was die Sprache zu bieten hat (Java sollte man allerdings wirklich nicht als Modul hinzuziehen).