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

[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/docvie...d=nas8N1017400
Ggf. gibts da auch schon eine neuere.

[Ottersberg]

Ich habe ein unerwartetes Problem mit der PRTF. Glaube ich.
Ich hatte zu dem Thema einiges gelesen und dachte es müsste so funktionieren.
Ich habe das erst mal auf ein sehr einfaches Beispiel heruntergebrochen.

PF:

     A          R TESTPFA                 
     A            TEST         100G         CCSID(13488) 

PRTF:

     A          R TEST
     A            TEXT         100G        1FONTNAME('Monotype Sans WT SC' +
     A                                      (*POINTSIZE 12.0))
     A                                      CCSID(13488 *NOCONVERT)
     A                                      SPACEA(1) 

CRTPRTF mit DEVTYPE(*AFPDS)

Auszug aus RPG:

       setll 1 TESTPF.TESTPFA;
       for i = 1 to 24;
         read TESTPF.TESTPFA DS_TESTPF;
         DS_TESTPRTF.TEXT = DS_TESTPF.TEST;
         write TESTPRTF.TEST DS_TESTPRTF;
       endfor; 

Die PF habe ich dann wie vorher erwähnt per SQL mit Daten gefüllt. Per select sieht der Inhalt gut aus.

Der erzeugte Spool ist aber nicht lesbar. Ich nahm an, das wäre normal, wegen der UCS-Daten. Aber es soll wohl nicht normal sein.
Was mache ich hier noch falsch?

[Fuerchau]

Das ist klar, dass der Spool nicht lesbar ist, da du ja UCS2 (also 2-Byte-ASCII) ausgibst.
Hier ist ein Leerzeichen eben nicht X'40' sond X'0020'.
Du solltest per OVRPRTF direkt eine PDF erstellen lassen und auch für die Einbettung der Schrift sorgen.
Der Umweg über ein Spool ist meist nicht erfogreich.
Zusätzlich musst du prüfen, ob dein Font auch ein Unicode-Font ist und nicht ggf. bei X'FF' schon aufhört.

[Ottersberg]

Ich hatte gerade noch eine Idee. Ich habe mit einen Spool mal im Viewer vom Navigator angesehen. Dort wird es korrekt angezeigt.

Passt zu deiner Aussage. Ich hatte auch nicht erwartet, es im 5250 lesen zu können.

Ich brauche einen Spool, da das PDF eine andere Software erzeugt.

[Fuerchau]

Ich denke die werden mit deinem UCS2-Druck Schwierigkeiten haben.