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

[Schnichels]

Hallo,

danke für die ausführlichen Antworten. Jetzt wissen wir Bescheid.

mfG

Jürgen Schnichels

[Schnichels]

Doch noch ein paar Fragen:

RPG/400 ist immer Quellenart RPG?

RPG IV ist immer Quellenart RPGLE?

Es reicht nicht aus aus einer RPG einfach einen RPGLE Quelle zu machen und diese dann umzuwandeln. Mann muss diese mit CVTRPGSRC umsetzen, dann ist eine RPGLE Quelle entstanden, wenn ich diese dann umwandele habe ich ein RPG IV Programm aber ohne ILE Funktionen?

Jetzt kann ich in diese Quelle ILE Funktionen einbauen, dann habe ich ein ILE Programm?

So richtig?

mfG

Jürgen Schnichels

[B.Hauser]

Hallo Jürgen,

wenn Du von RPGIII auf RPGIV konvertieren willst benötigst Du den Befehl CVTRPGSRC.
Bei diesem Befehl werden die Bestimmungs-Arten umgesetzt.
H-Bestimmungen sind in RPGIV nicht mehr an ein Spalten-Format gebunden, sondern werden durch Schlüssel-Worte angegeben.
In den F-Bestimmungen gibt es einige Änderungen, z.B. ein Datei-Name kann in RPGIV bis zu 10 Stellen lang sein.
E-Bestimmungen und L-Bestimmungen und Teile der I-Bestimmungen werden in D-Bestimmungen, die es in RPG400 noch nicht gibt umgewandelt. Faktor1, Faktor2 und Ergebnis sind in RPGIV 14 Stellen lang, OpCode 10 stellen. Der Convert-Befehl bereitet die C-Bestimmungen im neuen Format auf.
Das Ergebnis ist immer noch RPG400, das jetzt nach RPGIV aussieht.
Für weitere Anpassungen z.B. Ersetzen von Z-ADD in EVAL brauchst Du ein Tool oder viel Fleiss.
In diesen geänderten Quellen kannst Du alles machen, was in RPGIV z.Z. möglich ist, z.B. Built-in-Funktionen einbauen, Qualifizierte Datenstrukturen definieren u.v.m.

Wenn Du RPGLE-Quellen mit Auswahl 14 umwandelst, wirst Du feststellen, dass auch ein anderer Compile-Befehl verwendet wird.
RPG400-Quellen werden mit CRTRPGPGM erstellt, während für RPGIV der Befehl CRTBNDRPG verwendet wird.

Sobald Du wirklich mit ILE anfängst, wirst du feststellen, dass vieles z.B. auch die Umwandlung nicht mehr so einfach geht. Und man des öfteren vor Problemen steht, die man sich zu RPGIII-Zeiten noch nicht mal vorstellen konnte.

Noch eine Anmerkung:
Falls Du SQL in deinen Quellen verwendest, muss die Quellen-Art für RPG400 SQLRPG und für RPGIV SQLRPGLE sein.
Ansonsten haben RPG400 Quellen immer die Quellen-Art RPG und RPGIV und ILERPG-Quellen die Quellen-Art RPGLE

Birgitta

[Schnichels]

D A N K E !!!!!!!!!!!!!!!!!!!!!!!!!!

[Fuerchau]

Ein, mittels CVTRPGSRC umgesetztes Programm ist im Sinne von ILE tatsächlich ein ILE-Programm.
Es besteht zwar nur aus einem Modul, verwendet aber trotzdem die Service-Programme der Laufzeitumgebung und ist deshalb als ILE-Programm anzusehen.
OPM-Programme (RPG) verwenden keine Service-Programme.

Nachzusehen über DSPPGM, ziehmlich zum Schluß werden die verwendete Service-Programme und Funktionen aufgelistet.

Aber: Es ist alles eine Betrachtungsweise.

[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).