CCSID-Probleme

[Fuerchau]

Zuerst: Es gibt keine unerwarteten Phänomene, sondern nur erwartete Ergebnisse;-).

1. Die CCSID der SRC-PF's lässt sich nachträglich noch ändern. Da die Basis vorher 65535 war, wird keine Codewandlung der Quellen durchgeführt.
2. Probleme gibt es nur dann, wenn die CCSID, bzw. Hostcodepage, der 5250-Sitzungen nicht korrekt eingestellt sind (1141/273).
3. In den Programmquellen sollten in Feldnamen kein #$§ verwendet werden sondern ausschließlich Buchstaben/Zahlen/Unterstrich.
4. In den Quellen sollten keine Sonderzeichen (sog. Variante Zeichen) hart codiert sein, da dies bei Dateizugriffen u.U. nicht mehr funktioniert.
5. Jede Tabelle mit der Gearbeitet wird (DDS/SQL) sollte, und das ist die Regel, immer eine CCSID ungleich *HEX ausweisen.
6. Zwischen Bildschirm und Job wird i.d.R. keine Codewandlung durchgeführt, daher muss 5250-Codepage zur Job-CCSID passen, sonst gibts Chaos in den Daten bei Sonderzeichen.
Wenn die Job-CCSID 65535 ist, gibts generell zwischen Bildschirm und Datenbank (über den Job) keine Codewandlung, so dass Daten nur an Terminals mit derselben Codepage wieder korrekt angezeigt werden können.
7. Die CCSID des ILE-Programmes betrifft nur die eingebetteten Konstanten. Ein-/Ausgabedaten werden grundsätzlich zwischen Job und Datenbank codegewandelt.

Wenn du mit ODBC zugreifst, erhält der ODBC-Job (QZDASOINIT) automatisch immer eine CCSID entsprechend der Stammsprache des Systems.

Also wie gesagt: Es gibt keine seltsamen Phänomene. Der Techniker hat einfach keine Ahnung!

Deine HTTPPOSTCLOB-Daten sollten auf jeden Fall funktionieren, wenn
- Der Job auf 1141 steht
- Die Daten von/in Hostvariablen vom Typ UCS2 mit CCSID 1200 definiert sind.
- Die Codewandlung funktioniert dann intern implizit durch die Job-CCSID oder explizit mit %char(fromUCS2) bzw. %UCS2(fromChar).

[bie-dro]

Danke für diese ausführliche Erklärung zur CCSID. Jetzt wird mir vieles klarer.

Ich denke, ich werde die Felder als UCS2 definieren, damit ich da auf der sicheren Seite bin.

Gruß
Artur Janzen