CCSID-Probleme

[bie-dro]

Hallo Leute,

folgendes Problem:
bei uns ist schon seit Ewigkeiten die CCSID 65535 im System eingetragen (Systemwert QCCSID). Das verursacht immer wieder Probleme. Neuerdings musste ich feststellen, dass unsere Source-PF-Dateien auch die CCSID 65535 haben. Wenn ich daraus ein Programm umwandle, dann bekommt das Programm auch die CCSID 65535. Wenn ich aber ein Programm wandle, deren Source-PF-Datei die CCSID 1141 hat, dann bekommt das Programm auch diese CCSID. Bei der Wandlung mit CCSID 65535 nützt es auch nicht, den aktuellen Job auf CCSID 1141 zu wechseln, das Programm wird trotzdem mit CCSID 65535 gewandelt und funktioniert dann trotzdem nicht. Wir wollen mit HTTPPOSTCLOB Daten über eine API-Schnittstelle einspielen. Und das funktioniert nur, wenn die CCSID auf 1141 eingestellt ist.

Nun meine Frage:
Welche Probleme würden auf uns zukommen, wenn wir die CCSID im System umstellen? Ein IBM-Techniker hat mir vor langer Zeit davon abgeraten, weil dann unerwartete Phänomene auftreten könnten.

Kann ich wenigstens die CCSID der Source-PF-Datei umstellen?

Schöne Grüße
Artur Janzen

[Andreas_Prouza]

Solche Aussagen, wie die vom Techniker heißen nix anderes wie: "Ich hab keine Ahnung, kenne mich nicht aus, formuliere es aber lieber so, dass es trotzdem danach klingt als wüsste ich was."
Bin mir sicher, dass er nicht sagen kann welche Phänomene genau auftreten könnten.

Ich habe auf einem System den Systemwert von 65535 auf 1141 umgestellt, da ich mit *HEX mehr Probleme hatte als nach der Umstellung.
Ich würde das bei einem großen System halt zunächst mal auf dem Testsystem machen und sicherheitshalber eine Zeit lang beobachten und dann auch auf Prod umstellen.

lg Andreas

[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