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

[Ottersberg]

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)

Danke für die Idee. Es sind aber leider ein paar zu viele Texte, als dass ich diese Lösung präferieren würde.




Kommt immer drauf an, wie komplex man die Aufgabe versteht.
Sicherlich kann ich die DPSF mit dem Typ G13488 die Eingabe und Ausgabe der Terminalcodepage in das Programm in UCS2 bekommen und mit der DB verwalten.
Für alle Nicht-G-Felder gilt aber weiterhin, dass der Job in Terminal-CCSID sein muss und die Konvertierbarkeit von/zur DB gewährleistet sein muss.
Dies funktioniert ausschließlich mit kompatiblen CCSID.
Job 870 und DB 273 scheitert einfach, dann ist eben UCS2/Unicode erforderlich.

Wenn ich dies beherzige und die gleichzeitige Darstellung von ost-/west-/sonstigen Sprachen nicht erforderlich ist, kann man das durchaus machen.

Wie kann man das machen?

Ich kann das Programm so gestalten, dass immer nur eine Sprache erfasst werden kann. Die Sprache steht auch mit in der PF.

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

[Fuerchau]

OK, da der Navigator ja mit Java umgeht, wird es wohl so sein, dass der SQL als UCS2-String an die AS/400 gesendet wird. Im OLEDB/ODBC ist das nämlich nicht standard.
Nur so zur Sicherheit kannst du die Konstanten ja trotzdem mal mit N'...' auf UCS2 erzwingen.
Dies sollte dann mit jeder Anwendung funktionieren, wenn keine Parametermarker verwendet werden können.

[Ottersberg]

Im OLEDB/ODBC ist das nämlich nicht standard.

Gut zu wissen (für später). Worauf muss ich da achten? Ist das die Einstellung "CCSID für SQL-Anweisung"?

[Fuerchau]

Das weiß ich nicht auswendig, schau mal in die Doku:
http://www-01.ibm.com/support/docview.wss?uid=nas8N1017400
Ggf. gibts da auch schon eine neuere.