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

[Fuerchau]

Voraussetzung ist natürlich, dass die Jobumgebung zum User passt.
Da kann man über die Spracheinstellung im USRPRF und Systemwerte entsprechende Einstellungen für die automatische Anpassung der Job-CCSID machen.
Die 5250-Sitzung des Users muss dann ebenso der Sprache zugeordnet sein.
Beispiel:
User Deutsch = Job 273 = Codepage 1141
User Französisch = Job 297 = Codepage 1147
User Polnisch = Job 870 = Codepage 1153

Alleine durch die Möglichkeit, dass der Job mal in 273/297 (Westeuropa) oder in 870 (Osteuropa) sein kann, darf die DB nicht mit 273 erstellt sein.
Neutrale Zeichenfelder, also invariante Zeichen, sollten in 65535 erstellt werden (hier gibts aber ODBC-Probleme), alle anderen Zeichenfelder müssen in Unicode (UCS2/UTF16) erstellt werden.
Dann kann man durchaus zwischen Unicode und DSPF (nicht Unicode) Daten austauschen.
Wichtig ist natürlich, dass bei der falschen CCSID-Quelle (also deutschen Daten auf polnischen Sitzungen und umgekehrt) Verfälschungen passieren.
Wenn du die Sprache in der PF hast, kannst du ja eine Änderung der Daten ablehnen, eine Anzeige wäre da unschädlich.

Ein generelles Problem hast du natürlich mit dem Rest der Anwendung.
Schließlich müssen sich alle Programme wärend der Sitzung so verhalten. Du kannst es nicht auf eine Datei beschränken.
Sobald ein Programm in einer Umgebung (Job 870, Datei 273) aufgerufen wird, fällt der Open schon auf die Nase.

[Ottersberg]

Danke für die Antwort. Ich hatte deinen letzten Kommentar so verstanden, dass es nicht nur um die Darstellung, sondern auch um die Änderbarkeit in verschiedenen Sprachen geht. Also unabhängig von der Sitzungs- und Job-Einstellung. Habe ich dann falsch verstanden.

Diese Lösung werde ich wohl einsetzen. Anzeige immer, Ändern nur bei bestimmten Sprachen. Die anderen Sprachen werden wir dann erst mal mit SQL "erfassen" und dann später mal mit einem .NET-Programm.

[Fuerchau]

Auch da musst du allerdings aufpassen!
Machst du z.B. im iSeries Navigator per SQL einen

insert into mytable (text) values('griechische zeichen')

Wird der reine SQL-Text als SBCS an die AS/400 übergeben und mit der Default-CCSID (bei QCCSID 65535 wird dies ggf. 037 sein) übergeben und damit geht dein kyrillisch verloren.
Auch wenn ich mich nun selber bewerbe, du kannst es mit meinem Upload/400 tun:

Erfasse die Fremdsprachen entsprechend in Excel (das kann Unicode), lege die sprachspezifischen Felder als Unicodefelder (UCS2) an und lade die Daten dann per Upload/400 auf die AS400.
Dann bleibt es auch Unicode / UCS2.

[Ottersberg]

Wird der reine SQL-Text als SBCS an die AS/400 übergeben und mit der Default-CCSID (bei QCCSID 65535 wird dies ggf. 037 sein) übergeben und damit geht dein kyrillisch verloren.

Wie kann ich das prüfen? Ich hatte es nämlich genau so getestet, wie du das oben beschrieben hast und danach passten die Daten. Die Ausgabe mit select sah genauso aus, wie ich es eingegeben hatte.

[Fuerchau]

a) mit welchem Programm (STRSQL, also 5250, Navigator)
b) CCSID's der Datei, des Jobs, ggf. Connection-Einstellung

Alternativ muss per Navigator auch "insert into MyTable (Text) values(N'Sprachtext')" funktionieren.
Die Konstante in N'...' wird als UTF16 interpretiert und das Zielfeld sollte auch N[VAR]CHAR definiert sein.

[Ottersberg]

Über den Navigator, wie du geschrieben hattest.

Der Job hat CCSID 273.
Die Datei zeigt über DSPFD keine CCSID, da es verschiedene sind.
Die betroffene Spalte zeigt über DSPFFD:
ID des codierten Zeichensatzes . . . . . : 13488
UCS2- oder Unicode-Konvertierung . . . . : *CONVERT
Die Spalte ist im DDS definiert als:
A TEST 100G CCSID(13488)

Im Navigator selbst habe ich nur diese Daten gefunden. An der Connection selbst sehe ich nichts entsprechendes. Gibt es noch mehr?
Die JDBC-Eigenschaften aus "SQL-Prozeduren ausführen" zeigen package ccsid: 13488
SQL-Details für Job zeigt nach einem Insert, die Anweisungs-CCSID 273 an. Nach einem Select die 13488.