Kompatiblität der CCSIDs 273 und 1141 / Probleme mit SQL

[B.Hauser]

Was passiert denn wenn Du 'CCSIDTST' explizit auf die erwartete CCSID oder auf eine CCSID 13488 oder CCSID 1200 castest?

Birgitta

[BenderD]

... ich tippe mal eher auf eine fehlende *TBL zur Umsetzung.

D*B

[Fuerchau]

@Dieter
Im SQL sind die TBL-Objekte nicht mehr relevant. Dies wird komplett im System geregelt.
Wie soll denn die AS/400 aus den chinesischen Zeichen (28709) ggf. Latin-2 Zeichen (1153) extrahieren, vor allem, wenn sie im chinesisch nicht vorkommen?
Zum Zeitpunkt des Vergleiches der CCSID's kann das System nicht entscheiden, dass man nur auf invariante Zeichen selektiert.
Immerhin wird durch den Optimizer automatisch für Konstanten eine interne Hostvariable generiert.
Gerade für SQL gilt das selbe wie für native (naive) Zugriffe per RLA:
Die Job-CCSID muss zur Systemumgebung passen!

Beim embedded SQL habe ich das Problem nicht, so lange der Zugriff auf die QSYS2-Tabellen nicht erforderlich ist. Allerdings wird der eingebettete SQL ja ggf. wieder gegen die Tabelle-Definitionen geprüft (Feldvorhanden, Zugriffspfade für Indexoptimierungen usw.). Wie soll SQL dann die Namen ermitteln?
Spätestens aber bei der Verwendung von Prozeduren/Funktionen werden diese in den SQL-Tabellen gesucht. Bei falscher CCSID des Jobs gibts entweder obige Fehlermeldung oder die Namen werden nicht gefunden. Beides führt aber leider zu negativen SQL-Codes.

Bei Remote-SQL (also QZDASOINIT, CLI) greift der ODBC-Treiber grundsätzlich auf die Systemtabellen zu und gerade dann muss die CCSID passen.
Deshalb halte ich das Funktionieren unter TL16306 eher für einen Bug als ein Feature!

[BenderD]

... was gegen Deine Annahme spricht ist, dass sich 273 nach 1025 casten lässt und 1141 nicht!
Wie immer der cast bewerkstelligt werden mag, es spricht sehr viel dafür, dass er über externalisierte "Tabellen" geht - ob das nunt *TBL ist, weiß ich nicht (und interessiert mich eigentlich wenig), es spricht aber einiges dafür.

D*B

[Fuerchau]

Wir wissen ja beide, dass IBM da oft "vergesslich" ist.
Ich habe nun nicht so viel Möglichkeiten. Wer weiß denn genau, wie sich da IBM verhält.
Auf einem V6R1-System mit deutscher Sprache habe ich ebenso keine Probleme beliebige CCSID's per CHGJOB oder SQL-CAST zu verwenden (kein Wunder dass alle Probleme haben, wenn es keine Fehlermeldung mehr gibt).
Aber anscheinend verhält sich das System anders, wenn die Primärsprache eine DBCS-CCSID hat.
Dieses konnte ich noch nie testen.

In einem meiner älteren Posts (ich weiß nicht mehr wo) hatte ich auch festgestellt, dass das System im Zweifel intern über Unicode geht. D.H. CCSID1 => UCS2 => CCSID2. Dies geht halt immer.

[schatte]

Mein ursprüngliches Problem bezog sich ja auf Job-CCSID 1025 und Feld-CCSID 1141.
Das Problem hat ja erstmal nichts mit der Primärsprache des Betriebssystems zu tun, da es ja auch auf einem anderen System mit Primärsprache 2929 nachstellbar ist.

[schatte]

Als Workaround zur Codepage 1025 empfiehlt die IBM die Nutzung der Codepage 1154 (Cyrillic Multilingual with euro). Damit ist mein Problem gelöst.

Vielen Dank an alle.