ILE Quellen IFS vs Source Files

[BenderD]

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

[B.Hauser]

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

[BenderD]

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]

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

[Andreas_Prouza]

wenn ich die CopySrc auf den SrcFile drinn lasse klappt es nicht

Was schreibt das Spool/Joblog?

[Malte]

Moin Andreas,

leider nicht so viel:

RNS9311 Beendigung 50 24.11.25 16:46:52,876182 QRN4CPP QDEVTOOLS *STMT QCMD QSYS 01C8
Ausgangsmodul . . . . . . . : GRP4CPP
Ausgangsprozedur . . . . . : cleanup
Anweisung . . . . . . . . . : 19
Nachricht . . . : Umwandlung gestoppt. Interner Fehler aufgetreten.
Fehlercode ist 1.
Ursache . . . . : Mögliche Fehlercodes sind: 1 - Fehler im Front-End des
Umwandlungsprogramms aufgetreten. 2 - Fehler während des Befehlsaufrufs
aufgetreten. 3 - Fehler im Back-End aufgetreten. 4 - Fehler im Befehl
aufgetreten. 5 - Speicherzuordnungsfehler im Befehl aufgetreten. 12 -
Speicherzuordnungsfehler im Front-End aufgetreten. 13 - Lesefehler im
Front-End des Umwandlungsprogramms aufgetreten. 14 - Schreibfehler im
Front-End des Umwandlungsprogramms aufgetreten. Fehlerbeseitigung: Den
Kundendienst benachrichtigen und die Fehlercode-ID mitteilen.


PS: ich habe grade mal das Objekt gelöscht und Tada auf einmal klappt es
PPS: es klappt doch nicht immer ich muss da wohl beim Hin und her Kopieren und CCSID Ändern was kaputt gemacht haben

[BenderD]

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.

...bei korrekter CCSID der Quelldatei und Job CCSID klappt das auch mit den varianten Zeichen. Der UTF8 macht aus dem varianten Zeichen ein invariantes und das ist dann bei anderer Job CCSID der Griff ins Klo. Ich habe es zwar nicht ausprobiert, denke aber, dass GIT keine CCSID kennt.

D*B

[Fuerchau]

Das klappt automatisiert mit DB-Dateien, allerdings nicht bei IFS-Dateien. Da muss man die Codewandlung schon selber machen.
Und wenn der Compiler der AS/400 die Daten wirklich von UTF8 korrekt umwandelt, müsste man ja am Spooler sehen. Und dann hat man i.d.R. den Vorteil von UTF8 wieder verloren.
Denn die Codeanweisungen sind immer im invarianten Zeichensatz, nur Textkonstanten können im varianten Zeichensatz sein.
Also ist eine UTF8-Speicherung nur für Kommentare sinnvoll, und dann wohl eher für die nicht-1252-Welt.
Dazu kommt, wie du schon sagst, Windows kennt keine CCSID und welche CCSID die Datei beim Hochladen auf die AS/400 bekommt, entscheidet erst mal wieder die Einstellung des NetServer, die häufiger auf 1252 oder gar noch auf 850 steht.

[Malte]

Das Compilen habe ich jetzt hinbekommen in dem ich in jede Quelle einmal rein gegangen bin und gespeichert habe danach hat es funktioniert.

[Andreas_Prouza]

Was steht vor diesem Fehler im Joblog?
Da muss es noch mehrere Einträge geben vom Startzeitpunkt des Build-Prozess.

Das Compilen habe ich jetzt hinbekommen in dem ich in jede Quelle einmal rein gegangen bin und gespeichert habe danach hat es funktioniert.

Das klingt danach, dass die Quelle nicht UTF-8 war und erst durch das Speichern die Source mit UTF-8 gespeichert wurde.

Ich mache folgende Steps:
1. CPYTOSTMF die Source ins IFS (mit UTF-8)
2. Source ins GIT
3. Ich klone das Projekt vom GIT auf den lokalen PC
4. Source wird von OBI auf die IBM i ins IFS übertragen
5. Source wird via CHGATR mit CCSID auf 1208 (utf-8) gesetzt
6. Source wird kompeliert mit TGTCCSID *JOB

Mit diesen Steps funktioniert das sehr gut. Hatte ich auch schon früher mit den ganzen Sonderzeichen ohne Probleme probiert.
(Eventuell gibt's probleme wenn der JOB keine korrekte CCSID hat. Also *HEX)

[Fuerchau]

2 Dinge sind da ausschlaggebend:
- CHGATR mit CCSID auf 1208
- JOB keine korrekte CCSID

[Malte]

@Andreas das JobLog hab ich jetzt leider nicht mehr.

@Fuerchau je genau ich hatte das mit CHGATR nachträglich geändert.

Das was mich jetzt grade noch stört ist das wenn ich im IFS eine neue Source erstelle ist diese in CCSID 850 ob wohl ich im RDI eigentlich auf UTF-8 gestellt habe.

Und was auch schade ist das ich beim neu erstellen meine Templates nicht verwenden kann