Zeichensatz beim Download von AS/400 ändern?

[Chris.jan]

Wir haben hier ein deutsches System mit CCSID 65535 und CHRID 273. Allerdings ohne Sekundärsprache.

Da arbeiten aber auch Tschechen dran, die bei sich in ClientAccess einfach die Host-Codepage mit 870 (Europa erweitert) angegeben haben.

Die kriegen irgendwie (Software) ihre Adressen in Dateien mit CCSID 273 hinein. Ich denke weil die Devices mit Codepage 870 definiert sind.

Aber wenn die jetzt mit ClientAccess was herunterladen wollen, dann ergibt das Sonderzeichen. (So wie es bei mir am Bildschirm mit Codepage 273 aussieht - also so wie die Daten auch in der AS/400 sind).

Wenn ich das auch in 870 ändere, dann sehe ich auf dem Bildschirm praktisch alles "richtig", also mit den passenden tschechischen Sonderzeichen.

Die Option CCSID 65535 umsetzen ja/nein hat nicht geholfen. Benutzerprofile (auch bei denen 273) habe ich auch dafür versuchsweise mal angepaßt, auch kein Erfolg.

Jemand eine Idee wo da der Haken ist?

[Fuerchau]

Der haken ist die Inkompatibilität von 273 nach 870, wie schon zigfach hier im Forum erwähnt.

Hier hilft nur ein 2-fach-Cast (auf jedem Feld):

cast(
cast(
myfeld as char(nn) ccsid 65535
) as char(nn) ccsid 870
)

Der innercast setzt *HEX ohne Codewandlung, der outercast setzt 870 ohne Codewandlung.

Am besten, du erstellst eine View dafür.

ODBC-SQL arbeitet immer mit der CCSID der AS/400, wenn *HEX, dann generiert aus der Sprache.

Ein direkter Cast von 273 nach 870 wird abgelehnt.

[Chris.jan]

Okay, das erklärt natürlich das Problem. Danke für die Info. View werde ich nicht erstellen, das ist zuviel Aufwand für ein "nice to have".

[Fuerchau]

Ich glaube für die Tchechen ist das eher kein "nice to have" sondern schon wichtig, dass der Datenextrakt korrekt ist.

[Chris.jan]

Die arbeiten nun 6 Jahre mit dem System und urplötzlich fragt ein einzelner Mitarbeiter nach nem Download, den die jetzt 6 Jahre lang täglich gemacht haben ohne Probleme mit dem falschen Zeichensatz....

Viel mehr interessiert mich ja wie das überhaupt klappt. Der interaktive Job übernimmt scheinbar die Codepage von der Device mit Codepage 870. Wegen der CCSID 65535 würde ich jetzt mal vermuten, daß das System die Daten binär so speichert wie eingegeben, also ohne Änderung. Und beim Download müßte das doch alles wieder rückwärts ohne Konvertierung klappen. Quasi wieder der gleiche Zeichensatz - aber da nutzt ClientAccess wohl doch die System-Codepage 273 und spuckt Sonderzeichen aus, weil es die Daten für Codepage 273 hält. Richtig verstanden?

[Fuerchau]

Nicht ganz.
Bei 5250 entscheidet der JOB die Art der Speicherung.
Wenn hier 65535 wird nichts zwischen Terminal und Datei gewandelt, deshalb klappt das ja.

Bei ODBC siehts etwas anders aus.
Da der Client ja in ANSI abeitet, klappt das mit 65535 nicht mehr.
Die Daten der Datei liegen in 273 vor und müssen ja irgendwie in 1252 gewandelt werden. Die JOB-CCSID des ODBC-Jobs (QZDASOINIT) wird daher immer eine gültige CCSID und nie *HEX haben.

Die CCSID wird ggf. über die Sprache des Users bzw. Systemsprache eingestellt.
Nun könntest du ja den User auf 870 bringen, allerdings ist dies zu 273 inkompatibel und wird daher abgelehnt.