Verschiedene Sprachen über 5250-DSPF erfassen, in PF speichern und in PRTF ausgeben

[Ottersberg]

Moin,

Bedingt richtig.
Die Zeichen werden nach der eingestellten Codepage in der Emulation angezeigt.
Zwischen 5250 und Job erfolgt nämlich keine Codewandlung.

Stimmt. Habe dort fälschlicherweise "Job" geschrieben.

Bzgl. der FONTNAME-Möglichkeit mit Unicode in der PRTF betrifft dies ausschließlich die PDF-Ausgabe!

Habe ich vergessen. Muss nicht gedruckt werden im eigentlichen Sinne. Es soll ein PDF werden.

Für solche Art der Anwendung bietet sich tatsächlich nur eine ClientServer-Lösung mit z.B. Java oder .NET an.

Das ist schade. Dann werden wir für diesen Spezialfall wohl eine ClientServer-Lösung erstellen müssen.
Ich nehme an verschiedene DSPF mit festen CHRID scheitern auch wieder an der Codepage? Habe dazu noch nicht sehr viel gefunden. Lese noch.

[Fuerchau]

Was sich IBM mit der CHRID an der DSPF gedacht hat entzieht sich mir, da das Ganze etwas kompliziert wird.
Entscheidend dafür ist erst mal die CHRID-Einstellung auf Feldebene in der DSPF.
http://www.ibm.com/support/knowledge...mstdfchrid.htm
Danach entscheidet der Jobwert CHRIDCTL.
Erst wenn dieser (oder über die Hierarchie User->Sysval) letztendlich auf *JOBCCSID kommt, wird zwischen Terminal, DSPF und Job für das entsprechende Feld eine Codewandlung durchgeführt.
Dies betrifft aber wiederum ausschließlich SBCS-Daten, also wiederum kein Unicode.
Außerdem kann es dazu führen, dass wiederum bei Inkpompatiblität der beiteiligten CHRID's ein Öffnen der DSPF scheitert.
Da es hier nun mal wieder um Codewandlung zwischen SBCS-CCSID's geht, ist auch hier eine gleichzeitige Darstellung bzw. Verarbeitung unterschiedlicher Sprachräume (Latin-1 bis Latin-16, ISO 8859) auf der 5250 nicht vorgesehen.

Man sollte generell beherzigen, dass Job-CCSID und 5250-Hostcodepage zueinander passen müssen um korrekte Daten zu bekommen. Dann gibts auch keine Probleme mit dem (ausländischen) Nachbarn.
Alles Andere verkompliziert die Sache nur.

[camouflage]

Ich habe ein ähnliches Unicode-Problem über ein Web-Interface gelöst. Das läuft. 5250-Lösungen, auch mit der neuen CA-Solution (hab ich getestet), kannste wohl vergessen - vor allem wenn ihr ausschliesslich "deutsch" arbeitet.

So wie ich es verstehe, musst du statischen Text welchen du an ein Dokument anhängst, verarbeiten.
Wieso machst du nicht dafür für jede Sprache ein IFS-File, welches du dann mit UTF8 oder was auch immer einlesen kannst. Damit du das File in der Anwendung findest, kannste ja immer noch eine Tabelle mit Sprache/Ablageort erstellen. (Google: Klement IFS)

Wäre jetzt ein Ansatz/Idee von mir.