verbotene Variablen, Zeichen und Namen

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