Bei UNICODE gibt es eine Spezialbehandlung, da UNICODE beim Lesen und Schreiben immer entsprechend gewandelt wird (im Gegensatz zu anderen DBCS).
Allerdings funktioniert das nur dann korrekt, wenn die JOBCCSID auch auf die jeweilige SPRACHCCSID eingestellt wird.
Ist diese sowieso immer gleich (273 oder 65535), kann man sich UNICODE auch sparen, da immer von der gleichen Sprache ausgegangen wird.
Stellt man den Job auf 273 und einen anderen Job auf 890, kommt es dann beim Lesen zu CPF-Meldungen, dass ggf. Daten nicht umgesetzt werden können da es von UNICODE zur JOBCCSID (wenn die Daten aus einer anderen CCSID stammen) keine Entsprechung gibt.

Um also mit mehreren Sprachen umzugehen MUSS die Job-CCSID entsprechend der Sprache eingestellt werden. Die DB kann dann zwar UNICODE enthalten, man muss sich aber damit abfinden, dass es bei Umsetzungen zu Fehlern oder Verlusten kommt.

Ich bleibe also dabei: Wenn man gemischtsprachige Anwendungen unterschiedlicher Latin-Räume entwickeln will kommt man um die Verwendung von DBCS (oder auch Unicode) IM PROGRAMM nicht herum.

Das Problem der CA-Sitzung bleibt jedoch weiterhin bestehen, da es keine UNICODE-Unterstützung für DSPF's gibt. DBCS-CCSID's können verwendet werden (wenn die entsprechende Unterstützung installiert ist), sind aber KEIN UNICODE !
De Hosttabelle der CA-Sitzung ist KEINE Codewandlung sondern die grafische Übersetzung eines Hexcodes.
Wenn dieser nicht passt, kommt es eben zu fehlerhaften Darstellungen.
Eine GLEICHZEITIGE Darstellung unterschiedlicher Latin-Räume ist mit SBCS absolut nicht möglich.
Und DBCS für DSPF's bedeutet eben eine Anpassung der Programme !!!
(Was im Übrigen auch für PRTF's gilt.)