Wie immer gibts mal wieder durcheinander

Die CCSID dient der Speicherung der Daten (also den Code), die CHRID dient der Darstellung (wenn man so will quasi den Font).

Innerhalb eines Sprachraum (e.g. Latin-1) gibt es für jeden Code einer CCSID einen entsprechenden Code in der anderen.
Nimmt man also CCSID 273 Deutsch, dann enthält dieser Zeichensatz auch alle französischen Zeichen, genauso wie CCSID 500 (gerne als International benannt) oder eben die französische CCSID (297).

Ich kann also durchaus französische und deutsche Zeichen in einer DB mischen.

Wichtig ist einzig und allein:
Die Terminal-CCSID (Hostcodepage) muss zur JOB-CCSID passen !
Steht die Job-CCSID auf 65535 (*HEX), muss die Terminal-CCSID zur DB-CCSID passen.

Bleibe ich allerdings in einer Terminalwelt (z.B. nur französisch) ist das alles egal, da die Daten genauso angezeigt werden, wie sie eingegeben werden.
Erst wenn ich die Daten mische und gemeinsam Anzeige, kommt es zu den üblichen Falschdarstellungen.

Nochmal zu Latin-1:

Wenn ich die System-Sprachlib's vorschalte fangen leider die Schwierigkeiten an, da auch die IBM nicht in der Lage ist, seine Sprachobjekte mit einer korrekten CCSID's auszuliefern (die haben nämlich alle 65535).

Dies erfordert, dass sowohl der Job als auch das Terminal in der der Sprache zugeordneten CCSID eingestellt sein muss.

Innerhalb eines Sprachraumes (hier also Latin-1), ist die CCSID des DB letztlich egal, solange diese auch zum Sprachraum gehört.
Begründet wird dies damit, dass eben beim Lesen/Schreiben zwischen DB- und Job-CCSID eine Codewandlung stattfindet.

Zwischen Terminal und Job kann man zwar auch eine Codewandlung einschalten, aber hierzu sind auch CCSID's auf Feldebene in einer DSPF erforderlich und wer hat das schon je gemacht.

Kommen wir nun zu einem anderen Sprachraum (z.B. Latin-2).
Auch hier gilt, innerhalb des Sprachraumes passen alle CCSID's zueinander.

Sollen nun Daten in einer gemeinsamen DB (Latin-1 und Latin-2) gespeichert werden, so ist natürlich die beste Lösung Unicode (hier CCSID 13488 bzw. als UCS-2 benannt).
Das erfordert aber nun mal ILE und/oder SQL.
Bleibt man bei SQL, brauchen die Programme nix zu tun, da automatisch von UCS-2 in die Job-CCSID bzw. umgekehrt gewandelt wird, lediglich die DB ist mit UCS2 einzurichten.

Bei RecordLevel-Access sind natürlich jede Menge Fehlerquellen vorprogrammiert, also sollte man dies natürlich lassen.

Nun muss man sich aber die Frage stellen, ob denn die "gemeinsamen" Daten auch tatsächlich gemeinsam ausgegeben werden.
Ist das nämlich (wie meistens) nicht der Fall, reicht für die DB die CCSID 65535 (*HEX), für die Job's und Terminal eben die Sprach-CCSID.

Problematisch wirds nun mit FTP/ODBC/DRDA/IFS !
Bei allen diesen Verwendungen muss man nun anfangen mit CCSID's zu jonglieren, temporär umkopieren, CCSID's nun doch zuordnen usw. usw.

Bei Sprachtrennungen in eigenen Lib's kann jedoch jede DB ihre Sprach-CCSID aufweisen und alles in in Butter.

Wirklich alles ?

Da gibt's ja noch ggf. PRTF's !
Anzusteuernde OUTQ's, MSGF's u.v.m.

Am einfachsten sind da noch die PRTF's.
Hier ist es wichtig, dass zum Erstellzeitpung des Spools (nicht der PRTF !) per OVRPRTF die zur CCSID gehörende CHRID eingestellt wird, denn sonst klappts nicht mit der richtigen Codepage im Drucker.

So...
Das wärs mal wieder fürs erste.