verbotene Variablen, Zeichen und Namen

[mahones]

Hallo zusammen!

Mal wieder bin ich auf der Suche...

Dieses Mal geht es um Zeichen oder ganze Ausdrücke, die im RPG nicht erlaubt sind.
Ich bin zufällig darauf gestoßen, weil ich mit dem RDi auf einem System gearbeitet habe, welches "andere" Einstellungen bzgl. CCSID LANGID, CNTRYID o.ä. hat.
Auf jeden Fall habe ich eine Variable ##CPF genannt, und bekam ständig Fehlermeldungen, dass die Variable CPF nicht definiert sei. Ich habe vergeblich gesucht, wo der Fehler lag, bis ich (auch wieder zufällig) die Source im SEU öffnete.
Und hier stand dann nicht mehr ##CPF sondern ££CPF.

Tja, und seitdem suche ich eine Übersicht, auf welche "Ausdrucksweise" man bei der Programmierung achten muss.

Bei einigen Sonderzeichen ist es mir klar, dass ich sie nicht verwenden darf (Ziffer zu Beginn, ?+*'%!" usw.) - aber spätestens bei Variablennamen, die nicht offensichtlich systemeigen klingen, gibt es vielleicht die eine oder andere Überraschung!?

Ich habe bei meiner Suche im www leider nichts dazu gefunden, aber bestimmt hat jemand etwas dazu in petto...

Vielen Dank schonmal für jegliche Hilfe!

[Fuerchau]

Das Thema heißt "varianter Zeichensatz" und "invarianter Zeichensatz".
Invariant bedeutet eben, dass diese Zeichen in jeder CCSID identisch ist.
Das das "#"-Zeichen auch im Lib-Namen erlaubt ist, ist es halt so, dass man an diese Lib in einer anderen CCSID nur mit "£" wieder drankommt.

Irgendwo in den Tiefen des "iSeries Information Centers", zum Thema Globalisierung, ist der auch definiert.
Im Wesentlichen sind das:

A-Z a-z 0-9 ,.-;?

Die C-Programmierer auf der AS/400 kriegen nämlich einen Fön, da "{}" sehr häufige Zeichen sind und die sind in jeder CCSID anders.

[Fuerchau]

Nachtrag:

Dies gilt übrigens auch für alle verwendeten Konstanten, da diese nur zur Compilezeit in die Job-CCSID (wenn sie denn nicht wieder mal 65535 ist) umgewandelt wird.

Ein "chain ('#') Myfile;" führt dann immer zu %notfound()!

[Pikachu]

ILE RPG Reference V7R2 - Symbolic Names and Reserved Words

[Fuerchau]

In der Referenz sind aber z.B. "#@" aufgeführt, dies sind variante Zeichen!
Ich habe nun den Link gefunden:

http://www-01.ibm.com/support/knowle...et.htm?lang=de

Wie man sieht, ist sogar das Anführungszeichen (COBOL-Fraktion) ein variantes Zeichen!
D.h., dass z.B. in CMD's verwendete Anführungszeichen ggf. auf anderer CCSID nicht funktionieren.

[B.Hauser]

In der Referenz sind aber z.B. "#@" aufgeführt, dies sind variante Zeichen!

Das stimmt schon, aber man sollte auch alles lesen!
Im nächsten Satz steht nämlich:

"The $, #, and @ may appear as different symbols on some codepages."

Am besten fährt man, wenn man seine Namenskonventionen so festlegt, dass keine Sonderzeichen verwendet werden.

Ansonsten gibt es in RPG wenig Beschränkungen.
Mit SQL sollte man etwas vorsichtiger sein, zum einen gibt es einen ganzen Katalog von reservierten Worten und zum anderen sollte man keine Variablen-Namen mit SQ oder SQL beginnen lassen, diese sind für den SQL Precompiler (SQLCA/SCLDA) reserviert.

Birgitta

[Fuerchau]

"The $, #, and @ may appear as different symbols on some Codepages" ist aber genau das Problem eines Compilers, wenn man eine Variable "$X" oder "#X" benennt und mit einer anderen CCSID compiliert.
Da wird dann aus "#" eben "£" und das ist im Namen nicht erlaubt -> ergo Compiler-Fehler.

Wenn man denn die Quelle von der Herkunft in eine SRC-PF mit der richtigen CCSID stellt und seinen Job auch auf eine CCSID (eben nicht 65535), wird die Quelle für den Compiler in die Job-CCSID gewandelt.
Dabei wird z.B. das "#"-Zeichen korrekt der CCSID zugewiesen und der Compiler streikt nicht.

Allerdings erlebe ich es (auch mit V7R1 gerade wieder aktuell) immer wieder, dass die Maschinen nicht auf die korrekte CCSID der aktuelle Sprache gestellt werden sondern systemweit mit 65535 arbeiten.
Anschließend wundert man sich dann wieder warum die Zeichen mit ODBC/FTP o.ä. so komisch aussehen.

Fährt man aber mit einer CCSID auch im System gibt es erheblich weniger Probleme dieser Art.

[Fuerchau]

Nachtrag:
Gerade in SQL sollte man mit Sonderzeichen in Feldnamen vorsichtig sein da bei falscher CCSID diese ggf. nicht gefunden werden und somit der SQL nicht funktioniert.
Leider ist hier das "#"-Zeichen wieder mal ein gern gesehener Favorit.