View Full Version : Verschiedene Sprachen über 5250-DSPF erfassen, in PF speichern und in PRTF ausgeben
Ottersberg
13-12-16, 12:23
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?
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
13-12-16, 12:38
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.
Ich denke die werden mit deinem UCS2-Druck Schwierigkeiten haben.
Ottersberg
13-12-16, 12:54
Angeblich können sie das. Es ist sogar ein Beispiel im Handbuch enthalten, aber leider sehr knapp. Dort steht nur AFPDS-Spool und ein Beispiel für ein PRTF-Feld wie oben mit FONTNAME und CCSID 13488.
Ottersberg
14-02-17, 10:04
Da wir inzwischen auf V7R3 sind, habe ich mal die 5250-Emulation des neuen IBM i Access Clients getestet und dort alle Verbindungsoptionen zu Unicode mal aktiviert. Damit wird jetzt z.B. nicht nur kyrillisch korrekt angezeigt, sondern kann sogar erfasst werden. Und das obwohl die Codepage weiter auf 273 steht.
Erfasst heißt in dem Fall nicht über Tastatur getippt, sondern Copy-Paste.
Einziges Problem ist, dass die Feldlänge wohl nicht richtig erkannt wird. Es wird zwar angezeigt, dass 140 Zeichen eingegeben werden können, aber nach 70 Zeichen können keine Zeichen mehr eingegeben werden.
Ob das jetzt an der Emulation liegt oder ob die DSPF anders aussehen müsste weiß ich nicht. War auch nur mal ein Test. Wir bleiben bei der Lösung die wir momentan haben.
Nur mal zur Info.
...
Wichtig ist also grundsätzlich, dass die Job-CCSID zur Terminal-Codepage passt.
...
Bin mir damit nicht so sicher. Meine meinung ist, dass bessere wäre das DSPF als CCSID = *JOBCCSID umzuwandelen.
Das Schlüsselwort CCSID hat noch weitere Parameter:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzakc/rzakcmstdfusc2.htm
Damit kannst du die sichtbare Eingabe dann auf 70 Stellen beschränken.
Laut Dokumentation wurde Unicode seit V5R4 von der Web-5250 bereits unterstützt.
Warum sich PersonalCommunications nie dazu überreden ließ und erst nun (wie ich vermutete) die Java-Version nach über 10? Jahren sich dazu herab lässt weiß wohl nur die IBM.
Ggf. wird das dann wieder die 1. Funktion sein, die auf grund eines Trumpdekretes wieder abgeschafft wird, da damit ja dem Osten und ins besonders Asian ja Tür und Tor geöffnet wird.
@Kit
Hier verwechelst du 2 Dinge:
CCSID und CHRID.
Bei der Erstellung einer DSPF bekommt diese automatisch die CCSID der Quelle bzw. des aktuellen Jobs, falls diese nicht *HEX ist.
CHRID gibt die graphische Ausprägung der Ein-/Ausgabe an. Der Default ist hier tatsächlich *DEVD.
Hier kannst du natürlich deinen und auch andere Werte angeben.
Nun spielt aber neben deiner Job-CCSID nun auch die DSPF-CCSID eine Rolle, also genauso wie bei einer PF.
Beim Schreiben/Lesen in/aus der DSPF findet nun eine Codewandlung statt.
Zusätzlich kommt nun ein weiterer Aspekt ins Spiel:
Auf Feldebene gibt es ein Schlüsselwort CHRID (ohne weitere Parameter).
Dieses besagt, dass diese Felder zwischen DSPF und Device einer Codewandlung unterliegen, wenn die CHRID der DSPF nicht *DEV ist.
Alle Felder, die CHRID nicht aufweisen, werden nicht codegewandelt.
Nun mach dir mal die Mühe, in allen DSPF's einer Anwendung bei jedem Zeichenfeld noch das Schlüsselwort CHRID (geht leider nicht auf Satz/Dateiebene) zu hinterlegen.
Ich weiß nicht, was sich dei IBM dabei gedacht hat.
Hinzu kommt noch ein weiteres Manko:
Bei der CHRID *DEV kann ich durch simples Austauschen der CCSID's für die PF, den Job und das Device jede beliebige passende Kombination verwenden.
Also 273->273->273, 870->870->870, ...
Hat die DSPF aber CCSID 273, kannst du diese für 870 nicht mehr verwenden, du benötigst für jede Zielccsid einer Ländergruppe (Latin-1/2/...) eine eigene DSPF.
Den Overhead würde ich wirklich niemandem zumuten.