CCSID bei RUNSQLSTM

[KM]

Hallo,

wir verwenden unter anderem den RUNSQLSTM mit SRCSTMF. Dafür haben wir eine Datei mit dem SQL-Befehl im IFS liegen. Die Datei hat die CCSID 1252, da sie unter Windows erstellt wurde. Der Befehl enthält z.B. folgenden Teil:

... replace(kmmail, '§', '@') ...

Nachdem der Befehl ausgeführt wurde, steht im Ausführungsprotokoll jedoch:

... replace(kmmail, '@', '§') ...

Mit welcher CCSID wird denn die IFS-Datei standardmäßig interpretiert? Kann das evtl. die 037 sein oder wie kommt der Zeichentausch zustande?

Viele Grüße,
KM

[Fuerchau]

Das kommt darauf an welche CCSID dein Job hat.
SQL muss immer mit einer CCSID arbeiten, außer bei Binärdaten.
Hat dein Job z.B. 1141/273 wird die IFS entsprechend beim Lesen konvertiert.
Hat dein Job aber 65535 muss SQL ja irgendwas machen und nimmt da als Default wohl 037.
Ändere mal deinen Job korrekterweise auf 273 oder 1141.

Ich weiß auch gar nicht, wofür ihr da den Replace macht. Bei korrekten CCSID's ist das nicht nötig.

[KM]

Das hab ich schon fast vermutet. Ich hätte trotzdem gerne gewusst, was dann eigentlich die Default-CCSID ist.

Wenn ich zum Testen den Job mal auf 1141 setze, funktioniert es. Aber das Programm läuft in einer komplizierteren Umgebung. Da kann man leider nicht einfach mal so Job-CCSIDs ändern.

Danke,
KM

[Fuerchau]

Und genau das ist der allgemeine Gedankenfehler:
Ohne CCSID schafft man sich komplexe Umgebungen die man mit CCSID gar nicht hätte.
99,9% aller Datenverarbeitungen sind mit CCSID absolut unproblematisch.
Die restlichen 0,1% treten aber nur dann auf, wenn man sich in mehreren Sprachräumen aufhält, also west-/osteuropa, russisch, griechisch, türkisch, usw.
Dafür hat man dann Unicode erfunden. Zunächst graphic 33488, später dann 1200 und für die IFS-Unterstützung 1208.

Baut man ein System grundsätzlich mit CCSID's auf hat man von der Source-Editierung bis zur Laufzeit wirklich keine Probleme, solange man auch keine varianten Zeichen als Programmkonstanten einbaut.
Ihr macht es auch "zu einfach", nämlich gedankenlos, und damt eben einfach und kompliziert.

Wie wärs einfach mal mit einfach und unkompliziert?

Das Thema CCSID behandle ich bereits seit 1992 und meinen ersten Kontakten zur AS/400.
In früheren Welten (Nixdorf Computer, MS DOS) nannte man das nur Codepage, aber auch da gab es bereits Lösungen.

Ich kann mich noch an komplexe Konvertierungen in der früheren DCW-Fibu erinnern. Hier wurden Codeconvertierungen ausprogrammiert, CHRID's von Terminals abgefragt und die CCSID im Datensatz gespeichert. Auch damals hätte man sich vieles einfach ersparen können, wären die Systeme mit einer CCSID eingestellt worden.