Anwendung Rumänisch/Deutsch

[niceguy]

Ich habe die Anforderung, deutsche und rumänische Sonderzeichen in einer DB zu verwalten. Die Dateien haben derzeit CCSID 273 eingetragen. Ich hab's bisher geschafft die Sonderzeichen in die DB zu bringen, indem ich Client Access einmal mit Codepage 273 und einmal mit 1153 konfiguriert habe - mir fehlt aber die Idee, wie ich auf einer Sitzung deutsche und rumänische Sonderzeichen eingeben und anzeigen kann.
Gleiches Problem habe ich auch beim Druck - der Drucker ist auch als Client Access Sitzung konfiguriert.

Hat jemand schon Erfahrungen damit?

[Fuerchau]

Tja, geht nicht gibts eigentlich nicht aber genau das GEHT NICHT !

Auf Grund der CCSID 273 sind per Definition keine rumänischen Schriftzeichen enthalten.
D.h., in der DB kannst du zwar die Hexcodes der CCSID's speichern aber je nach CCSID des Terminals haben sie eine andere grafische Ausgabe.

DA KANNST DU LEIDER SO NICHTS DRAN MACHEN.

Beim Drucken gehts noch einigermassen, da man auf Feldebene der PRTF eine CHRID angeben kann. Hierzu muss man allerdings genau wissen, welche DAten denn nun vorliegen.
Ausserdem muss der Drucker die Schriften hardwareseitig unterstützen( Codepages 852/856 o.ä.), da per CA keine Softfonts geladen werden können.

Bei Windows klappt das ja ganz gut, aber 1. wird UNICODE verwendet und 2. mit TrueType-Schriften eine Schrift als Bitmap ausgegeben.
Dies wird von der AS/400 so nicht unterstützt.

[niceguy]

Danke für die rasche Antwort - auch wenn ich damit nicht weiterkomme. Kann eine Änderung der CCSID der Dateien helfen - gibt's eine CCSID die deutsche und rumänische Sonderzeichen enthält?

[Fuerchau]

Eindeutig Jein !
SBCS-CCSID's können dies nicht, DBCS-CCSID's können dies, z.B. UNICODE (CCSID13488).

Das Problem beim Drucken und 5250-Terminal bleibt bestehen.

Und, wenn du deine DB auf eine DBCS-CCSID umstellst sind ALLE Programme (incl. Query) davon betroffen (so gut wie Redesign).

CCSID's werden sprachraumbezogen definiert: Latin1 - Latin6.
Sprachraumübergreifend ist ausschließlich DBCS und UNICODE.

[JustMe]

Und, wenn du deine DB auf eine DBCS-CCSID umstellst sind ALLE Programme (incl. Query) davon betroffen (so gut wie Redesign).

Ebenfalls Jein. Wenn man alles brav über Views/logische macht, stellt ein "alter table" alles um und die Programme merken nichts. Die Umsetzung erfolgt in den Views/logischen.

R.

[Fuerchau]

DBCS-CCSID's erweitern Zeichenfelder (doppelte Zeichenbreite). Für Programme sind das dann Grafik-Felder !
Ohne Programmänderung geht da gar nichts !
SBCS-CCSID können (eingeschränkt) jederzeit konvertiert werden. Ggf. wird ein CPF-Fehler ausgelöst, wenn es keine Umsetztabelle (z.B. von Deutsch nach Rumänisch) gibt.
Dann kann nur über einen Umweg (CCSID 65535) konvertiert werden, wobei aber tatsächlich KEINE Codeumsetzung stattfindet.

Das ist auch das Problem einer CA-Sitzung:
Das Einstellen der Hostcodepage bedeutet AUSSCHLIESSLICH eine Darstellungsanpassung und KEINE Codewandlung !!!

[JustMe]

lies einfach genau, was ich geschrieben habe und probiers mal aus.

Ich habe bei einem Kunden vor Ort den Kundenstamm auf Unicode umgestellt. Ein "alter table" hat die physische umgestellt. Alle (in Worten *alle* damit du es mitkriegst) Programme sind ohne Änderungen oder Umwandlung einfach weiter gelaufen. OS/400 eben.

R.

[Fuerchau]

Bei UNICODE gibt es eine Spezialbehandlung, da UNICODE beim Lesen und Schreiben immer entsprechend gewandelt wird (im Gegensatz zu anderen DBCS).
Allerdings funktioniert das nur dann korrekt, wenn die JOBCCSID auch auf die jeweilige SPRACHCCSID eingestellt wird.
Ist diese sowieso immer gleich (273 oder 65535), kann man sich UNICODE auch sparen, da immer von der gleichen Sprache ausgegangen wird.
Stellt man den Job auf 273 und einen anderen Job auf 890, kommt es dann beim Lesen zu CPF-Meldungen, dass ggf. Daten nicht umgesetzt werden können da es von UNICODE zur JOBCCSID (wenn die Daten aus einer anderen CCSID stammen) keine Entsprechung gibt.

Um also mit mehreren Sprachen umzugehen MUSS die Job-CCSID entsprechend der Sprache eingestellt werden. Die DB kann dann zwar UNICODE enthalten, man muss sich aber damit abfinden, dass es bei Umsetzungen zu Fehlern oder Verlusten kommt.

Ich bleibe also dabei: Wenn man gemischtsprachige Anwendungen unterschiedlicher Latin-Räume entwickeln will kommt man um die Verwendung von DBCS (oder auch Unicode) IM PROGRAMM nicht herum.

Das Problem der CA-Sitzung bleibt jedoch weiterhin bestehen, da es keine UNICODE-Unterstützung für DSPF's gibt. DBCS-CCSID's können verwendet werden (wenn die entsprechende Unterstützung installiert ist), sind aber KEIN UNICODE !
De Hosttabelle der CA-Sitzung ist KEINE Codewandlung sondern die grafische Übersetzung eines Hexcodes.
Wenn dieser nicht passt, kommt es eben zu fehlerhaften Darstellungen.
Eine GLEICHZEITIGE Darstellung unterschiedlicher Latin-Räume ist mit SBCS absolut nicht möglich.
Und DBCS für DSPF's bedeutet eben eine Anpassung der Programme !!!
(Was im Übrigen auch für PRTF's gilt.)

[niceguy]

Ich bin mittlerweile einen Schritt weiter. In der Codepage 870 (Latin 2) gibt es rumänische und deutsche Sonderzeichen. Beim Kopieren mit CPYF *MAP erfolgt eine Umsetzung z.B. von Codepage 273 auf 870.

Also habe ich die Datenbibliothek der Anwendung kopiert, alle Dateien von Codepage 273 auf 870 geändert und dann die Daten mit CPYF *MAP *REPLACE kopiert - jetzt ist alles korrekt umgesetzt.
Analog bin ich bei Display-Files, Menüs und MSG-Files vorgegangen. Da habe ich die Sourcen kopiert, umgesetzt und dann alles neu umgewandelt - bis jetzt funktioniert alles.

[Fuerchau]

Für die meisten Daten wird das auch so funktionieren. Hoffentlich hast du auch den Job auf CCSID 273 während des CPYF gestellt.

Aber bedenke folgenden Schwierigkeiten:

In Programmen darfst du keine Hexwerte (Zeichen) verwenden, die in den CCSID's unterschiedliche Positionen haben.
Z.B.:
in 273 hat das "ä" den Code x'C0'
in 870 hat das "ä" den Code x'43'

Wenn du nun im Programm die Daten mit "ä" vergleichst funktioniert das ausschließlich in CCSID 273, da dein Programm mit der zur Compilzeit gültigen CCSID erstellt wird und zur Laufzeit Textkonstanten keiner CCSID-Umsetzung unterliegen.

Dies betrifft alle sog. "varianten Zeichen", das sind Zeichen die in unterschiedlichen CCSID's unterschiedliche Hex-Werte aufweisen.

Wenn du den CPYF mit Job-CCSID 65535 durchgeführt hast, erfolgte KEINE Übersetzung der deutschen Zeichen in korrekte Hexwerte in 870.

Mittels DSPPFM und F10 kannst du die Hexcodes überprüfen.

Zur Laufzeit ist dann wichtig, dass Job-CCSID zur Hostcodepage der CA-Sitzungen passen.