View Full Version : ILE Quellen IFS vs Source Files
In welche CCSID kopiert man die CL- und RPG-Quellen aus den Quellenteildateien am besten ins IFS?
Andreas_Prouza
22-11-25, 20:35
Ich speichere sie alle als UTF-8 (ccsid 1208)
Was den GIT Merge Angeht habe ich bis jetzt hauptsächlich gute Erfahrungen gemacht.
Aber wenn du es mal ausprobieren willst kannst du in VScode auch einfach ein lokales GIT Repo erstellen und mal so einen Merge Conflict provozieren.
@Andreas_Prouza ich hatte das mit UTF-8 Probiert aber dann bekomme ich einen Fehler beim Compilern das 1208 nicht unterstützt wir. Muss ich hier noch was angeben beim "CRTBNDRPG"?
PS: ok googlen hilft...
Compile RPG from Unicode source - new TGTCCSID parameter in 7.1, 7.2, 7.3 (https://www.ibm.com/support/pages/compile-rpg-unicode-source-new-tgtccsid-parameter-71-72-73)
PPS: Wenn ich das versuche bekomme ich diesen Fehler:
Umwandlung gestoppt. Interner Fehler aufgetreten. Fehlercode ist 1
1 - Fehler im Front-End des Umwandlungsprogramms aufgetreten.
Kann ich dann keine CoopyBooks meher verwenden mit anderer CCSID ?
Andreas_Prouza
24-11-25, 10:14
Hi Malte,
Die Fehlermeldung sieht für mich wie ein Folgefehler aus. Schau mal ins Spool & Joblog.
Die Copy-Source muss ebenfalls die CCSID 1208 haben.
Im RPG musst du die Copy-Strecke auch anpassen.
Von: /copy qcpysrc,mysource
zu: /copy 'qcpysrc/mysource.rpgle'
Bei mir sieht der Build-Befehl so aus:
CRTRPGMOD MODULE(prouzalib/test1) SRCSTMF('src/prouzalib/qrpglesrc/test1.rpgle.pgm') DBGVIEW(*ALL) REPLACE(*YES) TGTCCSID(*JOB) INCDIR('./src/prouzalib')
Du könntest auch weiterhin die Copy-Sourcen aus den Src-Libs nehmen.
Mit beiden habe ich keine Probleme.
lg Andreas
Hi Andreas,
ich habe jetzt die CopySrc im IFS auch geändert dann habe ich keine Probleme mehr aber wenn ich die CopySrc auf den SrcFile drinn lasse klappt es nicht :(
Ja, der Compiler hat ein Problem mit Misch-CCSID's.
Bei Standard-CCSID's in SRC-PF's wird i.d.R. jede Quelle, da es ja eine Datenbank-Tabelle ist, in die Job-CCSID umgewandelt. Bei IFS macht er das halt nicht per Default, da das ja ansonsten eine Datenbank-Standard-Funktion ist und eine IFS-Datei nicht in einer DB liegt.
Ich frage mich bei UTF8 halt nur, ob Textkonstanten in der Quelle mit Sonderzeichen wie Umlauten nicht automatisch dann auch als UTF8 im Objekt abgelegt wird.
Da Konstanten im Objekt allerdings keiner Codewandlung unterliegen, ist da u.U. Chaos vorprogrammiert.
1208 könnte also eine schlechte Wahl sein. Wenn man keine Sonderzeichen, außer vielleicht Kommentare in der Quelle hat, reicht auch 1252 für Windows-ANSI.
Allerdings sollte man CCSID-abhängige Konstanten sowieso immer aus einer Datei laden;-).
... ich denke mal, der Compiler hat bei Unicode auch Probleme mit Knast (#) und Co (andere invariante Zeichen im EBCDIC). Für mich ist das alles letztlich nicht zu Ende gedachter Murks.
D*B
... ich denke mal, der Compiler hat bei Unicode auch Probleme mit Knast (#) und Co (andere invariante Zeichen im EBCDIC). Für mich ist das alles letztlich nicht zu Ende gedachter Murks.
D*B
Der Compiler verarbeitet per Default die Quelle in der CCSID der Quelle.
Über den Parameter TGTCCSID in den Compile Commands kann eine andere CCSID (z.B. *JOB oder numerischer Wert) angegeben werden. Bei einer von der Quelle abweichenden CCSID wird zunächst die Quelle in die entsprechende CCSID konvertiert und anschließend compiliert.
Schlimmer ist, was zur Laufzeit passiert. Zur Laufzeit werden per Default alle CHAR/VARCHAR Variablen und Spalten in Tabellen/phys./log.Dateien (für native I/O) oder externen Datenstrukturen in die Job-CCSID konvertiert. Zeichen, die nicht umgesetzt werden können, werden durch ein Substitutions-Zeichen x'FE' ersetzt, wodurch Daten verloren gehen können. Das gleiche geschieht i.Ü. auch mit hardcodierten Sonderzeichen. Deshalb sollte man soweit möglich Sonderzeichen in Quellen vermeiden. Nur manchmal sind Sonderzeichen doch notwendig z.B. wenn Regular Expressions verwendet werden müssen ... und dann kann man sich ganz schön wundern. Spätestenfalls wenn das (Service-)Programm in einer Umgebung mit einer anderen CCSID laufen muss.
... dem kann man natürlich gegensteuern, durch entsprechende Schlüssel-Worte in den H- und D-Bestimmungen.
Der Compiler verarbeitet per Default die Quelle in der CCSID der Quelle.
Über den Parameter TGTCCSID in den Compile Commands kann eine andere CCSID (z.B. *JOB oder numerischer Wert) angegeben werden. Bei einer von der Quelle abweichenden CCSID wird zunächst die Quelle in die entsprechende CCSID konvertiert und anschließend compiliert.
Schlimmer ist, was zur Laufzeit passiert. Zur Laufzeit werden per Default alle CHAR/VARCHAR Variablen und Spalten in Tabellen/phys./log.Dateien (für native I/O) oder externen Datenstrukturen in die Job-CCSID konvertiert. Zeichen, die nicht umgesetzt werden können, werden durch ein Substitutions-Zeichen x'FE' ersetzt, wodurch Daten verloren gehen können. Das gleiche geschieht i.Ü. auch mit hardcodierten Sonderzeichen. Deshalb sollte man soweit möglich Sonderzeichen in Quellen vermeiden. Nur manchmal sind Sonderzeichen doch notwendig z.B. wenn Regular Expressions verwendet werden müssen ... und dann kann man sich ganz schön wundern. Spätestenfalls wenn das (Service-)Programm in einer Umgebung mit einer anderen CCSID laufen muss.
... dem kann man natürlich gegensteuern, durch entsprechende Schlüssel-Worte in den H- und D-Bestimmungen.
... die Quelle hat dann utf8, wenn dann eine Quelle auf einer deutschen Maschine einen Knast in einem Namen hat geht es, auf einer Ami-Büchse fliegt einem das dann um die Ohren.
Andreas_Prouza
24-11-25, 16:34
... die Quelle hat dann utf8, wenn dann eine Quelle auf einer deutschen Maschine einen Knast in einem Namen hat geht es, auf einer Ami-Büchse fliegt einem das dann um die Ohren.
Das Problem hast aber auch wenn die Quelle statt IFS in einer Source-Lib ist.
Was das IFS & UTF-8 betrifft, so hatte ich bis jetzt noch keine Probleme mit Sonderzeichen. Also zumindest nicht mehr Probleme als es auch mit den klassischen Src-Libs ebenfalls gab.