neue BIFS nutzen %UPPER

[Bratmaxxe]

Moin zusammen,

wir haben eine neue AS/400 Maschine inkl. V7R5. Nun soll es ja möglich sein, auch neue BIFS im RPG Kontext nutzen zu können:

RPG Cafe: New built-ins %LOWER, %UPPER, and %SPLIT

Habe das ganze einmal ausprobiert, aber der Compiler meldet sich (Token ungültig - siehe Anhang):

Hat jemand eine Idee, woran das liegt oder wie man die Ursache beheben kann?

VG
Maxxe

[Dschainers]

Also bei mir hat das funktioniert.

Im PDM kommt ein Fehler, da PDM seit Jahren "stabilisiert" ist.
Der Compiler wandelt um und es funktioniert.

[Bratmaxxe]

Danke @Dschainers,
da muss man erstmal drauf kommen funktioniert bei mir ebenfalls!

[Fuerchau]

Das gilt bei PDM schon viele Jahre, dass vieles als Fehler angesehen wird, obwohl es funktioniert.
Allerdings konnte man das auch mal eben mit SQL machen;-):

exec sql values(upper(: MyVar)) into : MyVar.

[Dschainers]

Allerdings konnte man das auch mal eben mit SQL machen;-):

exec sql values(upper(: MyVar)) into : MyVar.

Bist ja ein richtiger Schlaufuchs!

[Fuerchau]

Schlauf-Uchs? Ist das sowas wie Schlumpf-Ochs?

[Dschainers]

Schlauf-Uchs? Ist das sowas wie Schlumpf-Ochs?

oder Schlaumeier....

[Fuerchau]

Auch da kenne ich nur die Schaum-Eier;-). Das N-Wort geht ja nicht mehr.

[camouflage]

IBM Champignon!

Uebrigens, gibt noch mehr, auch ältere BIFs, die in SEU nicht mehr unterstützt sind, z.B. %scanrpl etc.

[B.Hauser]

PDM ist mit Release 6.1 eingefroren worden, also alles was danach eingeführt wurde ist nicht unterstützt ... und das ist schon einiges.

[Pikachu]

Sind SETLL / SETGT / READ / READE / READPE / WRITE / UPDATE / DELETE in RPG eigentlich auch Legacy und sollen/müssen schnellstens durch SQL in RPG ersetzt werden? Gibt’s die in Fully Free RPG überhaupt noch und falls ja warum?

[B.Hauser]

Sind SETLL / SETGT / READ / READE / READPE / WRITE / UPDATE / DELETE in RPG eigentlich auch Legacy und sollen/müssen schnellstens durch SQL in RPG ersetzt werden? Gibt’s die in Fully Free RPG überhaupt noch und falls ja warum?

Native I/O gibt es noch! Allerdings sollte man Native I/O nicht 1:1 in embedded SQL ersetzen!
Warum?
1. Jedes SQL-Statement muss mindestens ein Mal durch die volle Optimierung (FULL OPEN) was sehr zeitaufwändig ist. Sofern der ODP offen bleibt, sind die Folge Aufrufe wesentlich schneller (10-20 Mal).
2. Vergleicht man native I/O mit dem SQL-Pendant, so wird native I/O zumindest beim ersten Durchlauf gewinnen (keine Optimierung versus volle Optimierung). Ein einzelner Chain ist wahrscheinlich nach wie vor schneller als der entsprechende SELECT ... INTO. SQL ist sicher schneller, wenn geblockte Verarbeitungen erfolgen können.
3. SELECT * sollten vermieden werden und gezielt nur die Spalten, die benötigt werden ausgewählt werden. Dadurch kann zum einen das übertragene Datenvolumen reduziert werden und zum anderen kann der Optimizer u.U. einen IOA (Index only access ... alle Informationen befinden sich in Schlüssel-Werten, so dass ein Zugriff auf den eingentlichen Datensatz nicht (mehr) notwendig ist.
4. Anstatt die Zugriffe einzeln zu machen, ist es geschickter, die benötigten Tabellen entsprechend zu verjoinen. Dadurch reduziert man zum einen die Anzahl der FULL OPENS und zum anderen kann der Optimizer seine volle Power ausspielen.
5. Statisches SQL sollte dynamischem SQL vorgezogen werden, da bei jedem OPEN (nach dem PREPARE) wieder ein FULL OPEN erfolgt (es sei den man würde mit Parameter-Markern arbeiten, die dynamischen SQL Statements sichern und nur neu "PREPAREN" wenn sich das Statement geändert hat.
6. Bei der COMPILE-Option CLOSQLCSR sollte man den default *ENDACTGRP nicht ändern. Bei *ENDMOD werden am Ende des Moduls alle ODPs geschlossen, und bei Folge-Aufrufen muss wieder ein FULL OPEN erfolgen. Ebensowenig sollte man mit Aktivierungsgruppe *NEW arbeiten, da alles was zu dem Programm gehört (also auch die ODPs) am Ende des Programms gelöscht werden.