Free RPG für angefangene

[KingofKning]

Hallo *all,
per Zufall war mir heute mal wieder ein Schreiben von der IBM untergekommen wo die Unterschiede zwischen Free RPG und "Alt" Rpg erläutert wurden. Angeblich ist ja jetzt (Ab Release V5R1) alles so einfach.
Ich als alter Cobol Programmierer würde mir gerne mal Free RPG ansehen/reinschnuppern.
Gibt es eine gute Deutsche Anleitung dazu? (Habe mir heute erst 600 Seite SQL Handbuch in Englisch ausgedruckt da ist Deutsch zur Abwechselung auch mal schön)
Für Hinweise dankbar.

GG

[B.Hauser]

Freie Deutsche Literartur gibt es wahrscheinlich nicht.
... aber ich habe vor einiger Zeit (4 oder 5 Jahre) Mal für den kostenpflichtigen TechKnowLetter (ITP-Verlag/Midrange Magazin) mal 3 Artikel zu dem Thema geschrieben.

Vielleicht hast Du diesen TechKnowLetter abboniert.

Ansonsten ist Free Format relativ einfach. Man muss sich nur merken, dass der OpCode an erster Stelle steht gefolgt von Faktor1 (sofern benötigt) und Faktor2. Einige Opcodes (z.B. MOVE) und Schalter in OpCodes werden im Free-Format nicht unterstützt. Alternativen sind Built-In-Funktionen.
In der RPG-Referenz sind die Alternativen beschrieben.

... übrigens das SQL-Handbuch kann nicht die aktuelle SQL-Referenz für IBM i 7.1 sein (die hat ca. 1800 Seiten).

Birgitta

[KingofKning]

Da war mal wieder das böse Wort " Mal für den kostenpflichtigen TechKnowLetter".

Leider wird hier die EDV als notwendiges Übel betrachtet und dementsprechend stiefmütterlich behandelt.

So bin ich halt darauf angewiesen mir meine Informationen durch Google und Co zu besorgen.
Ich denke vor 20 Jahren hätte ich so keinen Monat überlebt ;-)

GG

[andreaspr@aon.at]

Wenn du RPG selbst schon kannst und dir nur die FREE-Form anschauen willst, sollte das ILE RPG Reference Handbuch ausreichen.

Dort hast du für die meisten Befehle/BIFs auch Codebeispiel dabei. Oft sogar in Free-Form.
Grundsätzlich wird die auch die Syntax sowohl im Spaltenorientierten als auch in Free-Form gezeigt.

Und bei Befehlen wie dem MOVE (die in Free nicht unterstützt werden) gibt es auch eine Beschreibung welche alternativen es gibt.

lg Andreas

[KingofKning]

Wie schon gesagt, bin Cobol Programmierer und fand es immer blöde einem Reportgenerator für die Lösung von kaufmännischen Probleme zu benutzen.

Irgendwie war ich aber wohl der einzige der so dachte......

Naja, wenn ich mal ne Einsteiger Literatur dafür finde schau ich mir es mal an
GG

[Spateneder]

Du solltest Dich nicht so sehr an den Namen dieser altehrwürdigen Programmiersprachen verhaken, sondern mehr darauf achten, wie die verschiedenen Programmiersprachen unterstützt werden und was Du für Deine Arbeit brauchst. Auf der "AS/400 und kompatiblen Systemen" (immerwährenden Dank für diesen Ausdruck an Dieter Bender) wird das wohl doch eher RPG sein.
Als ich vor 27 Jahren angefangen habe, in RPG zu programmieren, hat mir jemand gesagt, das sei eine "tote Sprache". Nochmals vielen Dank für diesen hoch philosophischen Hinweis, den ich gottseidank ignoriert habe!
Fazit: Wenn Du es gewinnbringend einsetzen kannst: Lernen! Wenn nicht: Don't worry, be happy!

[AS400.lehrling]

Wie schon gesagt, bin Cobol Programmierer und fand es immer blöde einem Reportgenerator für die Lösung von kaufmännischen Probleme zu benutzen.

Irgendwie war ich aber wohl der einzige der so dachte......

Naja, wenn ich mal ne Einsteiger Literatur dafür finde schau ich mir es mal an
GG

Cobol,

Ich suche noch Literatur in Deutsch zu Cobol - das möchte ich noch lernen.

Gruß AS400.lehrling

[Fuerchau]

Da COBOL weitestgehend der ANSI-Norm unterliegt ist die IBM nicht ganz so frei, was die Entwicklung der Funktionalitäten angeht.
Ganz anders ILERPG. Da RPG eine ureigene IBM-Sache ist, kann die damit machen was sie will und deshalb gibts da jede Menge praktische Erweiterungen.

COBOL im Nachhinein noch zu lernen macht in meinen Augen da weniger Sinn, außer wenn man eben viel Tipparbeit (COBOL ist sehr erklärend) haben möchte.
Insbesonders bei ILE und Prozeduren ist COBOL da leider sehr nachlässig:

call procedure 'MyProc' using ... returning ...

Allein dieser Aufruf verhindert praktische Konstrukte wie in ILERPG, da der Returning-Wert nicht direkt in einer Compute-Anweisung verwendet werden kann:

DestVar += 10 * MyProc(P1:P2...);

Auch ansonsten ist COBOL leider eben sehr aufwändig im Codieren:

COBOL:
perform varying MyVar from 1 by 1 until MyVar > 100
...
end-perform

ILERPG:
for MyVar = 1 to 100;
endfor;

usw. usf.

Das COBOL nachher zur Laufzeit etwas schneller als ILERPG sein soll hat sich durch die schnelleren CPU's inzwischen in Luft aufgelöst und bewegt sich da eher im Nanosekunden-Bereich.

[AS400.lehrling]

Das COBOL nachher zur Laufzeit etwas schneller als ILERPG sein soll hat sich durch die schnelleren CPU's inzwischen in Luft aufgelöst und bewegt sich da eher im Nanosekunden-Bereich.

Lag das an Notwendiger Interpretation durch die CPU, oder konnten damals nur zu wenige Anweisungen pro Taktzyklus bearbeitet werden

Danke für den Vergleich in Sachen Aufwand Cobol vs RPG.

Gruß AS400.lehrling

[Fuerchau]

Nein, das lag an der Art und Weise der File-IO's.

In RPG/LE werden bei jedem EA-Befehl zusätzlich Moves von/zum Filebuffer generiert.
COBOL benötigt das nicht, da hier direkt mit den Filebuffern gearbeitet wird.

Das selbe gilt auch für SQL, da hier Hostvariablen direkt verwendet werden, während der RPG-Compiler zusätzliche Variablen und Moves generiert.

Aber was kosten heute schon ein paar Millionen Moves an Zeit?

[AS400.lehrling]

Nein, das lag an der Art und Weise der File-IO's.

In RPG/LE werden bei jedem EA-Befehl zusätzlich Moves von/zum Filebuffer generiert.
COBOL benötigt das nicht, da hier direkt mit den Filebuffern gearbeitet wird.

Das selbe gilt auch für SQL, da hier Hostvariablen direkt verwendet werden, während der RPG-Compiler zusätzliche Variablen und Moves generiert.

Aber was kosten heute schon ein paar Millionen Moves an Zeit?

Der Zeitvorteil ist Dank Power7 Geschichte

So wie das System I nur noch im Form vom OS/400 Existiert.

Zumindest - was die Hw angeht.

Gruß aus Aurich

[Fuerchau]

Nun, man muss einfach mal hochrechnen, wieviele Job's gleichzeitig mit wievielen Daten umgehen.
Wartet die CPU meistens auf die EA's ist es unkritisch, aber lass mal die CPU 100% haben und ein Anwendungsprogramm hat die Schuld .