CCSID-Umstellung

[mahones]

Hallo zusammen,

wir haben auf unserem IBM i immer wieder "Probleme", mit Drittanbietern zu kommunizieren.
Meistens ist dafür der unterschiedliche Zeichensatz verantwortlich.
Somit wird in vielen Programmen, SQL, etc. UTF-8 eingebettet, was dadurch natürlich dezentral gelagert ist.

Nun meine Frage: kann man die CCSID "einfach" ändern?
Die technische Antwort "Ja, mit > CHGSYSVAL SYSVAL(QCCSID) VALUE(XXXXX) <" bringt uns natürlich nicht weiter...daher hier noch ein paar weitergehende Infos.
Wir haben auf unserem System die 65535.
Die meisten Benutzer haben *SYSVAL, wenige 273 oder 1141.
Die meisten Dateien haben die 273.

Nun ist also die Überlegung, "alles" umzustellen.
Neben der Frage, welche CCSID wir nehmen sollten, ist die Black box, was das für Auswirkungen hat...

Gibt es da Erfahrungen, Warnungen, Ermutigungen, o.ä.?
Wo (Objekte, IFS, etc.) müsste man noch schauen, wo ist das alles umzusetzen?

Danke schonmal für euer konstruktives Feedback!

[Andreas_Prouza]

Ich kann zumindest aus Erfahrung sagen, dass ich mehr Probleme mit Systemen hatte die im Systemwert 65535 hinterlegt hatten als einer "korrekten" CCSID.
Eine Mischform von 65535, 273 (bzw. 1141) finde ich spannend und würde mir da mehr Kopfzerbrechen verursachen.

Ich würde mal prüfen ob und welche CCSID eure Tabellen hinterlegt haben (ob es da vielleicht auch eine Mischform gibt).

Der Unterschied zwischen 273 und 1141 ist, dass im 1141 das "€" Zeichen einen eigenen Hex Wert hat.
Beim 273 gibt es einen "Währungs"-Hex-Code, wo im Systemwert hinterlegt ist, welche Währung hier angenommen werden soll.
Kurz gesagt: Ich verwende immer 1141.

[Fuerchau]

Seit ich dieses Forum betreue schreibe ich mir die Finger wund, dass die IBM i mit einer gültigen CCSID installiert wird. Somit laufen alle Jobs erst mal in der SBCS der Sprachumgebung.
Die ID 65535 ist quasi der Tod bei jeder Kommunikation in die Außenwelt.

Die System-QCCSID passend zur Haupt-Sprache umzustellen stellt i.d.R. kein Problem dar.
- Die Systemdateien sind alle mit einer CCSID ausgestattet.
- DDS Dateien erhalten alle eine CCSID auf Dateiebene
- SQL-Tabellen erhalten alle eine CCSID auf Feldebene

ODBC-Jobs (QZDASOINIT) z.B. werden grundsätzlich auf eine CCSID, abgeleitet von der Systemsprache erstellt.

Mit Einführung von Unicode CCSID 1200 (nicht die alte 13488) und ACS wird auch das Verwenden von Bildschirmdateien mit 1200 komfortabel, da die Java-5250 die CCSID 1200 unterstützt.

Im Kommunikationsverhältnis wird dann häufig 1208 bemüht, was einfach aus/von 1200 und ggf. mit Verlusten auch in die CCSID der Zieltabellen gewandelt werden kann.

Problematisch wird es nur mit Dateien, die mit der CCSID 870 o.ä. erstellt werden. In diesem Fall sind die Jobs ebenso auf 870 umzustellen. Ein Parallelbetrieb von 273 und 870 innerhalb eiens Jobs ist nicht möglich.

Lange Rede kurzer Sinn:
Ja, wenn alle Dateien auf der Systemsprachen-CCSID basieren, ist eine Umstellung von QCCSID unauffällig.

[holgerscherer]

Danke schonmal für euer konstruktives Feedback!

Die Vorredner haben meines Erachtens nach schon alles geschrieben, eine Testumgebung wäre hilfreich, bevor Ihr den Goldenen Knopf drückt.

[mk]

Hi,

ich habe des Öfteren einfach den Systemwert qccsid geändert. I.d.R. läuft alles.

Auch auf die Gefahr hin das etwas nicht läuft. Ist aber besser als dieser Murks mit dem 65535

Gruß
Michael

[Pikachu]

Bei Query/400 *QRYDFN wird bei CCSID 65535 oft !! benützt. Das muß man vielleicht anpassen...