CCSID 273/37 und Java-Objekte im IFS

[Ahrendt]

Generell hast du sicherlich Recht mit den Hexwerten. In meinem speziellen Fall sehe ich das aber nicht als so problematisch an. Es geht hier um fix definierte Hexwerte in Zahlungsverkehrsformaten. Hier ist z.B. das Ä mit dem Hexwert 4A vorgegeben. Ob es in der Darstellung ein Ä oder [ ist ist egal. Wichtig ist, daß der Wert 4A rauskommt...- das fertige Format geht dann von der AS/400 über einen GatewayPC über ISDN an die Deutsche Bundesbank... .

Hier habe ich aber dadurch noch ein ganz anderes Problem. Der Anwender (Kunde) sieht in seiner Anwendung (DSPF zur Zahlungsauftragerfassung) aufgrund seiner Einstellungen (CCSID in Job-66353, Emulation mit ClientAccess 500 MNCS -)

Sonderzeichen; in der Datenbank ist dies mit korrekten "deutschen" Hexwerten belegt und es geht ok raus.

Gerne hätte ich natürlich die Darstellung als ÄÖÜß UND in der Datenbank korrekte Hexwerte. Dies scheint aber nur zu funktionieren, wenn ich die Hexwerte in der Datei per Programm manipuliere - Umsetzung 37 nach 273 im Ausgang und 273 nach 37 im Eingang. Dann ist es in der Ansicht richtig und auch im Hexwert.

Die Werte für die CCSID im Userjob, Emulation und Systemwerte kann ich leider nicht ändern. Ich habe nur die Möglichkeit die Dateien mit einer bestimmten CCSID zu erstellen und meinen eigenen Job zu verändern.

[Fuerchau]

Das Thema CCSID ist auch hier wieder falsch betrachtet !
Wenn die Emulation auf CCSID 500 steht MUSS der Job auch auf 500 stehen.
Beim DB-Zugriff wird zwischen 500 und 273 oder 500 und 037 korrekt gewandelt.

Wichtig ist, dass das Terminal IMMER zum Job passen muss. 65535 kann nur dann verwendet werden, wenn ich innerhalb des Systems konsistent bin und auch die DB besser auf 65535 steht.
Sobald ich aber ein Aussenverhältnis eingehe muss ich mich darum kümmern.

Das Thema CCSID wird im übrigen genauso stiefmütterlich behandelt wie das Thema Sicherheit. Irgendwie wirds schon hinhauen.