Zeichen konvertieren: deutsch <-> polnisch

[it99]

Für unsere Angebotsbearbeitung auf der AS400 wurde ein zusätzlicher Frontend erstellt, der als PC-Programm läuft. Der Datenaustausch mit dem PC-Programm erfolgt über Stored Proceduren, die in ILE-RPG programmiert sind. Dieses funktioniert bei den deutschen Anwendern einwandfrei.
Zukünftig sollen die Mitarbeiter unserer Niederlassung in Polen auch mit dem neuen Frontend arbeiten.
Seither arbeiten die polnischen Mitarbeiter direkt auf der AS400 mit iSeries Access.
Die Datenbank auf der AS400 hat die CCSID 273.
Benutzerprofileinstellungen der polnischen Mitarbeiter: LANGID PLK, CNTRYID PL, CCSID 870
Einstellungen iSeries Access: Hostcodepage 870, Tastaturlayout, Polen 214, Schriftart IBM3270-1250
Die systemweiten Einstellungen der AS400 sind: LANGID DEU, CNTRYID DE, CCSID 273
Die polnischen Sonderzeichen werden bei diesen Einstellungen natürlich nicht korrekt in der AS400 abgespeichert. Bei Anzeige der Daten in Deutschland wird z.B. statt einem @ ein § angezeigt.

Dieses Problem hat der neue Frontend natürlich auch. D.h. die Daten müssen konvertiert werden.
Der Frontend macht Schreib- und Lesezugriffe. Der Zugriff des Frontends erfolgt über den IBM ODBC-Treiber auf Stored Proceduren, die in ILE-RPG geschrieben sind. Der Benutzer, über den die Zugriffe auf die AS400 erfolgen läuft unter den Systemeinstellungen.

Welche Möglichkeiten gibt es, die Datenkonvertierung durchzuführen?

[Fuerchau]

Eine Konvertierung zwischen Deutsch und Polnisch (273/870) ist definitiv nicht möglich!

Die Codepages sind "doppelt" belegt, also ein Hexwert in 273 stellt ein anderes Zeichen dar als der selbe Hexwert in 870 (ausgenommen natürlich der invariante Teil und ein paar andere Zeichen).

Möchtest du nun die Zeichen "neutral" in die DB schreiben, so musst du die CCSID 65535 verwenden.

Da dies in ODBC-Jobs aber nicht geht, da sonst nicht in ANSI gewandelt wird, musst du an den richtigen Stellen casten.

Nichts desto trotz ist dies die schlechteste Lösung, da es für die saubere Darstellung keine Garantie gibt.

Innerhalb der 5250 funktioniert das noch, da zwischen Device und Job keine Codewandlung durchgeführt wird, so dass man bei falscher Codepage des Device durchaus Schrott in die DB schreiben kann so lange am selben Typ Termnial aus Schrott wieder Darstellbares wird. An einem anderen Terminal bleibt es aber Schrott.

Eine Änderung des QZDA-Jobs auf eine andere CCSID hilft hier auch nicht, da beim Wandeln von 273 auf 870 nun Unicode "zwischengeschaltet" wird (früher wurde ein Open der Dateien wegen inkompatibilität abgelehnt) und der Selbe Verlust nun wieder auftritt.

[it99]

Vielen Dank für die schnelle Antwort.

wir haben uns schon überlegt, selbst eine Konvertierungstabelle zu erstellen. Dies ist natürlich nicht sehr performant.

Würde der Einsatz der iconv-API was bringen?

[Fuerchau]

Nein, wie willst du denn konvertieren?
Da du ja alles über Prozeduren regelst, hast du dich von den Möglichkeiten in SQL quasi entkoppelt.

Auf Resultsets von Prozeduren kannst du nicht mehr mit SQL einwirken!

Wenn du mit ODBC zugreifst, musst du folgendes Bedenken:
Windowsanwendungen arbeiten schon mal per se in Unicode. Übergibst du einen Unicodewert an einen SBCS-Parameter, wird hier schon mal von Unicode in SBCS übersetzt. Ist das Windows polnisch, bleibt ja erst mal alles beim Alten, ist das Windows deutsch, geht die polnische Darstellung verloren.
Nun ist der Parameter in ANSI und wird bei der Übergabe an deine Prozedur in die EBCDIC-CCSID des QZDA-Job's gewandelt. Spätestens hier geht dein polnisch aber verloren.

Du kannst versuchen, den QZDA-Job in CCSID 870 zu versetzen (entweder per Prozedur (eigene oder QCMDEXC) mit "CHGJOB CCSID(870)".

Zusätzlich musst du deine Selects in den Prozeduren aber casten "cast(mychar as char(nn) ccsid 65535)", dann betrachtet das System die Daten als "neutral" und wandelt nicht in die JOB-CCSID.
Ebenso ist beim Insert natürlich ein cast auf CCSID 65535 erforderlich.

Nun kann der QZDA-Job (bzw. der Treiber) von der Job-CCSID nach ANSI konvertieren.

Ein Aufruf von iConv hilft dir hier nicht, da der bereits zu spät ansetzt, deine Daten werden ja bereits beim Lesen konvertiert.

Prozeduren sollten keine Resultsets zurückgeben sondern nur gezielt einzelne (oder mehrere) Werte (OUT/INOUT-Parameter).
Sollte mehr Anwendungslogik nötig sein (ins besonders beim Insert) sind hier Trigger bzw. Constraints der richtige Ansatz.

Und zu guter letzt:
Sollte von polnischen Clients auf deutsche Daten zugegriffen werden, verlierst du halt die deutsche Darstellung, was spätestens bei einem Update deine Daten zerstört.

Am besten überarbeitest du deine Prozeduren und stellst diese auf Unicode um.

PS:
Ein CHGJOB CCSID(65535) hat auf SQL keine Auswirkung, im Zweifel nimmt SQL nämlich die Default-CCSID des Jobs und die bezieht sich auf die Primärsprache des Systems.

[Anton Gombkötö]

... sondern auch die betreffenden DB-Felder auf UCS-2 ändern.
Je neuer das Release, desto weniger Arbeit. (weil man sich sehr oft %UCS2 erspart)

[Fuerchau]

%UCS2 wirkt ja nur mit der JOB-CCSID!
Das Gegenstück %CHAR ebenso.
Wandelt man also von UCS2 in die JOB-CCSID hast du Datenverluste.
Wenn du diesen dann wieder mit UCS2 zurückwandelts hältst du diese Verluste auch noch consistent.

Das Ändern der DB macht natürlich Sinn, wenn du keine OPM-Programme mehr hast (oder sonstige RLA-Zugriffe, die UCS2 nicht unterstützen wie Query/400). Spätestens bei DSPF/PRTF ist allerdings einiges mehr zu beachten.

Ich meine so ab V6 ist S2 und %CHAR nicht mehr erforderlich, dass erkennt der Compiler dann automatisch.