QZDASOINIT und CCSID

[Fuerchau]

Die CCSID wird über die Sprachen-ID des Systems gesteuert die wohl auf DEU steht (da gibts kein *HEX).
Allerdings ist das nicht die Ursache eures CCSID-Problems.
Eure Daten werden nicht korrekt mit CCSID 273 ins System gebracht !
Am besten stellt ihr dann eure Datzeien auf CCSID *HEX um. Allerdings müsst ihr dann in der ODBC-Verwaltung "CCSID 65535 umsetzen" anklicken.
Empfehlenswert ist das ganze allerdings nicht.

[KM]

Ich glaube Du hast mich da etwas missverstanden. Unsere Dateien stehen bereits auf CCSID 65535 und "CCSID 65535 umsetzen" ist auch in der ODBC-Konfiguration angegeben. Das Problem ist aber, dass die QZDASOINIT-Jobs immer mit CCSID 273 gestartet werden, auch wenn wir beim Benutzer QUSER den Ländercode z.B. auf Polnisch setzen und die CCSID auf 1153. Das ändert nichts daran. Wir können doch deshalb nicht ständig unsere Systemwerte ändern. Irgendeine Möglichkeit muss es doch geben von vornherein festzulegen welche CCSID dieser Job haben soll. Ich könnte zwar bei jedem SQL-Programmaufruf zunächst einen CHGJOB ausführen. Allerdings würde das nur unnötig Performance ziehen. Und da es sich um eine Web-Applikation handelt, ist jedes bisschen Performance wichtig.

Gruß,
KM

[Fuerchau]

Dieses Problem läßt sich am einfachsten mit Views umgehen, die die Felder per CAST in UCS2 (Unicode) umsetzen.
Die AS/400 arbeitet nun mal grundsätzlich mit einem Sprachcode.
Aus der Web-Applikation greifst du dann halt auf die View's zu.

[KM]

Ja, daran hab ich auch schon gedacht. Dann müsste ich halt mehrere Views mit diversen CASTs erstellen, je nach Codepage. Oder ich müsste evtl. doch immer einen CHGJOB mit CCSID(*HEX) machen. Bleibt mir wohl nichts anderes übrig, wenn man die CCSID der QZDASOINIT-Jobs nicht vorbelegen kann.

Trotzdem danke,
KM

[Fuerchau]

Das Problem mit dem CHGJOB ist aber ggf. die Wiederverwendung !
Nach Verbindungstrennung bleibt ein Job aktiv und kann für eine andere ODBC-Verbindung verwendet werden. Diese benötigt jdoch ggf. CCSID 273. Da diese Verbindung aber nichts davon weiß, gibts ggf. Salat (ODBC mit Excel/Access).

Die Daten korrekt mittels VIEWS und CAST bereitzustellen ist auf jeden Fall die sicherste (und übrigens auch die eleganteste).