CCSID's

[msost]

Hallo,

ich dachte imemr das CCSID's steuern, in welcher Codierung ein Zeichen angezeigt oder gespeichert wird. Habe aber folgendes Problem, das ich mir nicht erklären kann (Beispiel ohne Gewähr für die Richtigkeit des Hex Codes):

DSPF: CCSID 273, Zeichen @ ist Hex 7C
Job: CCSID 285, Zeichen @ ist Hex 5B

File: CCSID 500, Zeichen @ ist Hex 7C

Ich hätte erwartet, dass das System bei Eingabe eines @ von 7C auf 5B (DSPF zu Programm/Job) und dann wieder auf 7C (Programm/Job zu Datei) umwandelt.

Schaue ich aber mit DSPPFM auf die Datei, sehe ich 5B. Es scheint also, das von DSPF zu Programm konvertiert wurde, aber nicht beim Schreiben in die Datei.

Wo liegt mein Gedankenfehler?


Grüße

Matthias

[Fuerchau]

Eine Konvertierung findet nur zwischen Job und Datenbank statt wenn keine CCSID auf 65535 steht.
Zwischen DSPF und Job wird generell keine Konvertierung durchgeführt!

Bei dir sieht es so aus, dass die CCSID des Device halt nicht zum Job passt.
M.a.W, der Job nimmt an, dass das Device eben auch auf 285 steht und wandelt dann beim Schreiben von 285 auf 500 und beim Lesen wieder zurück.

[msost]

Hhmm, kommt aber nicht hin:

Job: CCSID 285, Zeichen @ ist Hex 5B

File: CCSID 500, Zeichen @ ist Hex 7C

Wenn also vom Job das @ als Hex 5B kommt, müßte dies in der Datei als 7C gespeichert werden. korrekt?

Genau das passiert hier nicht. In der Datei steht 5B.

*grübel*

[Fuerchau]

Prüfe bitte zur Laufzeit genau die CCSID's!
Um di korrekten Hexwerte zu ermitteln, musst du natürlich den Job in die CCSID der datei anpassen, da ja beim Lesen in die JobCCSID gewandelt wird.
Auch der DSPPFM muss ja lesen.

Alternativ könnte auch SQL mit der HEX-Funktion helfen. Ich weiß nicht, auf welcher Ebene die Codewandlung stattfindet, vor der SQL-Funktion (schlechte Karten, macht allerdings Sinn) oder nach der Funktion.

[msost]

... und mal wieder bin ich aufs Beste stutzig (Obwohl ich gefühlt deinen Ausführungen zugestimmt hätte). Folgendes (vieräugig geprüftes) Szenario:

I-Access Session: 500
Job: 273
Datei 285

Hex-Werte in Datei:
$-Zeichen: 4A
!- Zeichen: 5A
[- Zeichen: 63
]- Zeichen: FC

Daraus ergibt sich folgende Vermutung:

- Sind die Hexwerte des Zeichens in der CCSID der Session und des Jobs gleich, wandelt das System in den Hexwert der CCSID der Datei um ($=5B und != 4F)

- Sind diese unterschiedlich, wird der Hexwert der CCSID des Jobs weggeschrieben ([=4A Session und 63 im Job / ]=5A Session und FC im Job).

Kann das sein?

[Fuerchau]

Fangen wir beim Terminal an:
Die 5250 arbeitet im SBCS-Modus.
Die Zeicheneingabe erfolgt in der Codepage des Terminals (Windows z.B. 1252 ANSI deutsch).
Dieser ANSI-Code wird in den EBCDIC Hexwert der CCSID des Terminals umgewandelt.
Hier kann schon ein Problem auftreten, dass der ANSI-Wert nicht den passenden Code umgewandelt wird.
Dies lässt sich aber durch den Debugger und Anzeige der Variablen im Job feststellen.
Die JOB-CCSID ist da nicht relevant.

Mein Terminal steht auf 500 und ich gebe "[ ]" ein, als Hex landert im Job dann "4A5A".
Bei der Anzeige der Variablen wird mir "ÄÜ" angezeigt.

Stelle ich mein Terminal auf 1141 (deutsch, passend zu Windows) wir dem Programm korrekt "63FC" übergeben.

Dieser Wert wird dann vom Job in die DB-CCSID übertragen.

Es ist also auf jeden Fall wichtig, dass bereits das Terminal eine CCSID bekommt, die dem Eingabegebiet entspricht.

Die richtige CCSID für ein deutsches Terminal ist also 273/1141 und nicht 500!
der Job muss dann dem Terminal entsprechen, dann klappts auch mit der CCSID.

[Fuerchau]

Ergänzung:
Sicherlich wollt ihr auch drucken, dabei taucht dann das nächste Problem auf.
Zwischen Job und PRTF erfolgt wiederum keine Codewandlung!
Bei Verwendung von Druckkonstanten werden diese bei der Erstellung von der SRC-CCSID in die JOB-CCSID umgewandelt und sind dann nicht mehr veränderbar (übrigens wie auch PGM-Konstanten).
Der korrekte Druck wird dann über die CHRID der PRTF bzw. des späteren Spools entschieden.
Default steht hier *DEVD!
Je nach späterem Zieldrucker wird dann von der CHRID im Drucker die Konvertierung in ASCII (Achtung nicht ANSI) umgewandelt.
Im WSCST kann man je CHRID die ESC-Sequenz für die Drucker-Codepage angeben. Für 273 697 ist das dann die 850.

Wenn also die JOB-CCSID nicht zum späteren Druck passt kommen eben falsche Zeichen.
Die CHRID einer PRTF kann man gezielt angeben bzw. überschreiben, wobei ein Überschreiben die enthaltenen Textkonstanten natürlich nicht anpasst.

[msost]

HI vielen Dank für die vielen Info's!
Wir haben hier heute zuletzt mit mehreren Leuten unterschiedliche Szenarien durchdiskutiert. Da mehrere davon das richtige Ergebnis vorhersagen konnten, scheint's angekommen zu sein. Die anderen sind gerade in der Personalabteilung, Papiere abholen...

Danke!