RPG Free Form TR7

[camouflage]

Nur zur Info:

IBM nähert sich mit RPG allmählich wirklich zu einer free form Programmiersprache. Die I/O's haben sie noch im fixed Format belassen, der Rest ist frei. Sogar fixed und freie Statements lassen sich offenbar mischen, ohne dass immer ein /free oder /end-free gesetzt werden muss. Das ist gut so!

Danebst gibt es noch einige signifikate Erweiterungen der DB und SQL.

Wer mag, hier sind die Infos:
https://www.ibm.com/developerworks/c...4_882013aec57a

[B.Hauser]

Die I/O's haben sie noch im fixed Format belassen, der Rest ist frei.

Wobei bei den I/Os nicht die Ein-/Ausgabe-Bestimmungen sondern die Bestimmungsarten I und O gemeint sind.
I braucht man heute sowieso nicht mehr und O allenfalls ganz selten für eine schnelle Liste.

Was mich allerdings etwas stört, dass für jede Free-Format-Zeile (außer in den C-Bestimmungen) ein OpCode angegeben werden muss und bei Procedure Interfaces, Prototypen und Datenstrukturen ist sogar ein END-OpCode erforderlich.

... und alle Befehle sind weiterhin auf die Positionen 8-80 beschränkt.

Birgitta

[Pikachu]

Bei Datenstrukturen ist das gar nicht mal so verkehrt. Bisher entscheidet oft ein einziges S, ob ein Feld noch zu einer Datenstruktur gehört oder nicht.

... bei Procedure Interfaces, Prototypen und Datenstrukturen ist sogar ein END-OpCode erforderlich.

[camouflage]

Noch etwas,
diese Features gehen nur für V7R1 und sind nicht abwärts kompatibel.

[B.Hauser]

Bei Datenstrukturen ist das gar nicht mal so verkehrt. Bisher entscheidet oft ein einziges S, ob ein Feld noch zu einer Datenstruktur gehört oder nicht.

Da für Datenstrukturen, Prototypen und Procedure Interfaces und Stand alone Felder im Free-Format unterschiedliche Opcodes (DCL-DS, DCL-PR, DCL-PI bzw. DCL-S) erforderlich sind, erschließt sich mir die Sinnhaftigkeit der entsprechenden END-Anweisung nicht unbedingt.

Birgitta

[kitvb1]

... und alle Befehle sind weiterhin auf die Positionen 8-80 beschränkt.

Zum Glück... sonst würde irgendein Kasper seinen ganzen SQL Statement (mit CTE dabei) auf eine Zeile schreiben

[Chris.jan]

Also wenn man mal den Spaghetticode von 30 Vorgängern in einem Programm entziffern muss, dann ist mir das konservative Format immer noch am liebsten. Free Format hat leider nicht nur Vorteile.

[B.Hauser]

Also wenn man mal den Spaghetticode von 30 Vorgängern in einem Programm entziffern muss, dann ist mir das konservative Format immer noch am liebsten. Free Format hat leider nicht nur Vorteile.

Wenn Du aber irgendwo über 17 End (von dennen 2 auskommentiert sind) und anschließend auf eine ELSE triffst, dann bist Du über eine halbwegs vernünftige Free-Form-Codierung ziemlich glücklich.
Wobei ich zugegebenermaßen mit Fixed-Form H, D und P-Bestimmungen durchaus leben konnte. Wobei H-Bestimmungen ja eigentlich schon frei waren.
Nur das ständige FREE und END-FREE zwischen den einzelnen Bestimmungsarten hat immens gestört.

Birgitta

Birgitta

[camouflage]

Nur das ständige FREE und END-FREE zwischen den einzelnen Bestimmungsarten hat immens gestört.

Vor allem, dass man nun wieder gnadenlos GOTO's und CAB's ohne das störende Zeugs reinpfriemeln kann.

[camouflage]

Neu kommt mit TR7 auch mit PowerRuby auch Ruby and Rails auf die Power i mit DB i Zugriff.

Dies eröffnet neue Möglichkeiten, nebst PHP, für Webservices. Ich denke da auch u.a. an das XML Handling.

[Fuerchau]

Echte Erweiterungen sind das ja nicht wirklich.
Strukturen können immer noch nur über eigene Templates und Likeds geschachtelt werden.
Und nur die Syntax ohne echten Mehrwert aufzuhübschen bringt heute kaum noch jemanden dazu RPGLE überhaupt neu zu lernen.

Tatsächliche Funktionserweiterungen á la Objektorientierung (Methoden/Ereignisse/Eigenschaften), Speicherverwaltung (NEW / FREE), dynamische Arrays, Laufzeitüberwachung der Zugriffsarten usw. werden wir sicherlich nie bekommen.

Da macht es ggf. mehr Sinn, neben JVM vielleicht noch die .NET-Bibliotheken auf dei AS/400 zu portieren um hier neue Interessen zu wecken.

Ansonsten wird die Anzahl verfügbarer Leute für Anwendungsentwicklung native auf AS/400 weiter zurückgehen und aussterben.
Was dann mit "unserer" AS/400 passiert weiß ich nicht.

Gut zu wissen ist auf jeden Fall, dass ich die nächsten 10 Jahre noch mit AS/400 arbeiten kann bevor ich mich dann zur Ruhe setze (oder auf den Bahamas meinen Reichtum, den ich aus o.g. Gründen dann erwerbe, genieße).

[camouflage]

Hallo Baldur,

Tatsächliche Funktionserweiterungen á la Objektorientierung (Methoden/Ereignisse/Eigenschaften), Speicherverwaltung (NEW / FREE), dynamische Arrays, Laufzeitüberwachung der Zugriffsarten usw. werden wir sicherlich nie bekommen.

Ich fürchte, da wirst du Recht haben. Deckt sich übrigens auch mit der Meinung von Jon Paris und Susan Gantner.

OT
Bahamas ist ein teures Pflaster, also genug Reichtum scheffeln.
/OT