ILE Quellen IFS vs Source Files

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

[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

[Andreas_Prouza]

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.

Ich glaube das hängt von der CCSID des Ordners ab.
Ich habe aber bei mir in meinem Home-Verzeichnis 3 files ...
* .profile
* .bash_profile
* .bashrc

... mit dem Inhalt:

export PATH="/QOpenSys/pkgs/bin:$PATH"
export QIBM_CCSID=1208

Dadurch werden alle Files im UTF-8 erstellt:

QIBM_CCSID (CCSID for translation)

When this variable is set to a numeric value, qsh and various utilities use the value for creating files and translating data from the CCSID of the job. The default value is "0" for the default job CCSID. A value of "65535" means no translation is done.

[Fuerchau]

Werden die Profile bei der Anmeldung vom Client ausgeführt?
Export exportiert die Variable in die Umgebung der Verbindung.
Wie sieht das aus, wenn ich auf der IBM was ins IFS kopiere?
Gilt dann auch die CCSID des Exports?
Dies würde bedeuten, dass alle Dateien des Users im IFS grundsätzlich per UTF8 estellt würden.

Und du hast immer noch nicht meine Frage beantwortet:
Was steht in der CCSID des erstellten Moduls?
Die CCSID des Jobs oder der Quelle?

Die IBM ist bei CCSID's schon mal etwas nachlässig.

[Andreas_Prouza]

Und du hast immer noch nicht meine Frage beantwortet:
Was steht in der CCSID des erstellten Moduls?
Die CCSID des Jobs oder der Quelle?

Sorry, hab ich überlesen: Die Job-CCSID steht im Modul drinnen.

Ich arbeite im IFS fast ausschließlich via SSH & Bash.
Bei der Anmeldung wird dann das .(bash_)profile automatisch aufgerufen (ähnlich wie das Start-PGM).

Und ja, mit dieser Env-Variable sind alle (Text-)Files im IFS betroffen. Setze ich aber auch nur für meinen User.
Batch-Jobs, die z.B. PDFs im IFS generieren usw. sind dann entsprechend deren Anforderungen konfiguriert.

Hat mir viele Probleme gelöst.

[Fuerchau]

Ok, somit wandelt der Compiler von UTF8 in die Job-CCSID, somit sind alle Zeichen, die der Job-CCSID nicht entsprechen, automatisch in "?" gewandelt.
Da ein Job keine DBCS-CCSID haben kann (Doppelbyte) scheiden ja Sonderzeichen wie asiatische Sprachen aus.
Und wie ich schon sagt, utf8 ist für Quellcodes eigentlich nicht erforderlich und 1252 für uns Westeuropäer ausreichend;-).

Noch mal nachgefragt, sorry:
Anmeldung bereits bei der IBM oder erst bei QSH oder PASE?

[Andreas_Prouza]

Noch mal nachgefragt, sorry:
Anmeldung bereits bei der IBM oder erst bei QSH oder PASE?

Erst bei Anmeldung in QSH. Wobei es drauf ankommt über welchen Login du auf die Shell kommst, wird dann .profile oder .bash_profile aufgerufen.
Deshalb hab ich alle 3 Files um die gängigsten abzudecken.

Und ja, 1252 wäre auch ausreichend. Ich mach das nach dem Motto: Wenn schon, dann gleich alles UTF-8.
Ich brauch UTF-8 ja auch für viele andere Bereiche rund um IFS.
Z.B. manche Editoren speichern automatisch mit encoding UTF-8.