Sourcen im IFS ablegen?

[ncc1701e]

Servus,
bei uns steht momentan die Idee im Raum das wir unsere Sourcen ins IFS auslagern. An sich klingt das erstmal nicht verkehrt, aber ich hätte dazu noch die eine oder andere Frage und hoffe das mir hier jemand weiterhelfen kann.

Wenn die Sourcen im IFS liegen, wie gebe ich dann eine /include o. /copy Strecke an? Einfach Bsp. '/copy /edv/rpg/ctlopt.rpgle' oder wie muss ich mir das vorstellen.

Zudem sind wir im IFS ja nicht mehr an die 10 Stellen für einen Namen gebunden, wie klappt das denn mit z.B. Displaydateien, kann ich dann bei einem dcl-f einfach den langen Namen angeben?

Jeder hilfreiche Tipp zu dieser Thematik wäre super!

[schatte]

Hallo,

die Objekte werden ja immer noch in das Bibliotheksdateisystem kompiliert. Und dort ist man noch auf 10 Zeichen beschränkt.

Laut RPG Reference müssen die /COPY Anweisung so aussehen:

O/COPY /dir1/dir2/file.rpg
O/COPY /dir1/dir2/file
O/COPY dir1/dir2/file.rpg
O/COPY "ifs file containing blanks"
O/COPY 'ifs file containing blanks'

Wenn man keine Dateiendung angibt, sucht der Compiler nach allen Dateien im angegebenen Verzeichnis mit Endung .rpgle und .rpgleinc

VG

[Pikachu]

Siehe: /COPY or /INCLUDE
Und Vorsicht bei den CCSIDs der Quellen!

[Fuerchau]

Der Compiler konvertiert die Quellen in die Job-CCSID, wenn diese *HEX ist, sollte er die Default-CCSID verwenden. Dies macht er aber auch schon bei den SRC-PF's.

[Pikachu]

Einfach mal mit DSPPGM DETAIL(*MODULE) nachsehen, was im Modul als "ID des codierten Zeichensatzes (CCSID)" eingetragen wird. Bei einer Quelle mit CCSID 819 im IFS, hat's bei mir da unter V5R4 CCSID 500 eingetragen, bei einer Quelle mit CCSID 273 stand da 273 drin.

Der Compiler konvertiert die Quellen in die Job-CCSID, wenn diese *HEX ist, sollte er die Default-CCSID verwenden. Dies macht er aber auch schon bei den SRC-PF's.

[Fuerchau]

Wie immer bei CCSID's:
Was steht zur Laufzeit als CCSID in deinem Job!
Bei *HEX fängt das System (leider) manchmal an zu würfeln, je nach dem, wer diesen Teil des Systems entwickelt hat.
Beim DSPJOB gibt es 2 CCSID's, die CCSID gilt für Lesen/Schreiben, die Default-CCSID gilt für bestimmte Erstellbefehle.
Allerdings hält sich nicht jedes Modul daran.
Es gab mal eine Diskussion hier zur C-Funktion RegEx().
Wenn die LOCALE nicht korrekt gesetzt ist, wird CCSID 037 angenommen, unabhängig davon was im Job steht.
Beim Compiler habe ich mal irgendwo gefunden, dass die CCSID der Hauptquelle verwendet wird und alle Copy/Includes in die CCSID der Hauptquelle gewandelt wird.
Aus dem IFS muss naturlich, sollte die IFS-Datei eine ASCII-CCSID haben, immer in EBCDIC umgewandelt werden. Stelle deinen Job mal auf 273 statt *HEX und schau dann mal, was im Modul dann steht.
Leider werden die Systeme mit der QCCSID *HEX installiert und niemand korrigiert das auf die Hauptsprache des Systems und hinterher wundern sich alle, wieso das mit den CCSID's nicht klappt.

[ncc1701e]

OK, danke für die Erklärungen. Das scheint ja dann alles recht durchdacht zu sein mit den Sourcen im IFS. An die Objekte habe ich garnicht gedacht, also ist es doch sinnvoll weiterhin die 10 Zeichen beizubehalten, echt Schade aber hilft ja nichts.