Sekundärsprache Griechisch

[KM]

Hallo zusammen,

kann mir jemand sagen was ich alles einstellen/ändern muß, um in einer iSeries Access Sitzung Daten auf Griechisch einzugeben und wieder anzeigen zu lassen ? Geht das überhaupt ?

Folgende Einstellungen haben wir bereits vorgenommen:

- Sekundärsprache 2957 installiert und der LIBL vorangestellt
- iSeries Access Sitzung umgestellt (Host-Codepage = 875 Griechenland;Tastaturbelegung = Griechenland)
- Job geändert (Sprachen-ID = ELL; Landes-ID = GR; Standard-ID des codierten Zeichensatzes = 875)
- DEVD geändert (Tastatur-ID = GNB; Zeichen-ID = 925 875)

Wir bekommen zwar jede Menge Sonderzeichen angezeigt, jedoch ist das kein griechisch. Was müssen wir noch ändern ?

Gruß,
KM

[Fuerchau]

Korrekt funktioniert das mit CA-Express erst ab V5. Die Device wird dann mit der richtigen CHRID/TastaturId generiert.
Vor V5 wird das Device wieder auf die Systemstandardeinstellung (QCHRID) zurückgestellt.

Ggf. wird noch griechisches Windows benötigt (wegen der Sonderzeichen). Dies läßt sich auch über Systemsteuerung->Sprache nachinstallieren.

Der Rest scheint so OK.
Anzumerken ist jedoch noch, dass die Datenbank dann nicht auf 273 stehen darf. Das gleiche gilt auch e.g. für MSGF's.

[KM]

Hallo Fuerchau,

vielen Dank für die Antwort. Ich habe jetzt auch herausgefunden, warum nur Sonderzeichen angezeigt wurden. Standardmäßig wird nämlich bei einer iSeries Access Sitzung die Schriftart IBM3270 angezeigt und diese kann griechisch und andere Schriften nicht darstellen. Ich habe die Schriftart dann auf Courier oder Fixedsys geändert. Dann wird griechisch auch richtig dargestellt.
Unsere Dateien haben die CCSID 65535. Das dürfte dann auch korrekt sein. Demnächst kommt das gleiche nochmal mit Polnisch auf uns zu.

Gruß,
KM

[Fuerchau]

CCSID 65535 ist eigentlich das schlimmste was einem passieren kann !
Es findet keinerlei Codewandlung zwischen JOB und DB statt. In diesem Fall ist es sogar egal welche CCSID dein Job hat, da zwischen Device und Job normalerweise auch keine Codewandlung stattfindet.

[KM]

Die CCSID steht bei uns standardmäßig auf 65535. Welche CCSID sollte ich denn Deiner Meinung nach für die Datenbankdateien einstellen ? Was habe ich für Nachteile mit 65535 ? Ich verstehe das Problem nicht ganz.

[Fuerchau]

Dies insgesamt zu erklären ist hier vielleicht etwas aufwändig.
Grundsätzlich gilt jedoch eigentlich:

Das System sollte eine QCCSID/QCHRID in den Systemwerten entsprechend der Primärsprache enthalten, da auch die Systemdateien in einer CCSID ausgeliefert werden.
Eigene DB's sollten in der vorzugsweisen CCSID erstellt werden.

In einer mehrsprachigen Umgebung (Deutsch, Englisch, Französich, ...) Latin1-Welt erfolgt eine korrekte Umsetzung zwischen den Sprachen. Insbesonders beim Austausch mit Fremdsystemen (IFS, ODBC) können Sonderzeichen korrekt übertragen werden.

Hast du in einer DB unterschiedlichste Sprachen mit CCSID 65535 erfasst, kannst du die Daten ausschließlich an Terminals mit der gleichen Konstellation darstellen an denen sie auch erzeugt wurden.
Erfasst also ein Franzose an einem franz. Terminal Sonderzeichen (éèáàê...) können diese an einem deutschen oder englischen Terminal nicht korrekt wiedergegeben werden.
Steht der Job aber auf der gleichen CCSID wie das Terminal (273 Deutsch, 297 Französisch) und die Datenbank ist auf 273, können die Daten an jedem Terminal mit Latin1-CCSID korrekt wiedergegeben werden.

Etwas anders siehts leider mit der Latin2-Welt (griechisch, polnisch, tchechisch,...) aus (nicht wenn sie in sich geschlossen bleibt), wenn Daten mit Latin1 ausgetauscht werden müssen. Hier gibt es beim Hin- und Rückkonvertieren ggf. Zeichenverluste was aber im einzelnen zu prüfen ist.

Der absolut korrekte Weg wäre die Verwendung von DBCS oder neu ab V5 die Verwendung von UNICODE (CCSID 13488) für eine neutrale mehsprachige Umgebung (ich kenne niemand der das macht).

Schau mal bei IBM zum Thema "Globalization".

[KM]

Vielen Dank für diese ausführliche Info !!!
Ich werde mich mal schlau machen.

Gruß,
KM

[Fuerchau]

Ich biete dir gerne auch mal einen Workshop zum Thema CCSID, da wärst du nicht der erste.

[Rincewind]

Hiho,

zu beachten ist auch dass in Griechenland das Datumsformat anders aussieht

Da sind wir nämlich mal drüber gestolpert und mussten am tag der Einführung alles erneut prüfen (Ich liebe diese Live Tests)

Das Datum steht meine ich in MDY format, kann aber auch anders sein (jedenfalls nicht DMY und nicht YMD sondern verdreht)

Rince

[Fuerchau]

Das Datumsformat ist eigentlich unkritisch, wenn man intern mit einem einheitlichen Format (*ISO, YYYYMMDD) arbeitet.
Im Job kann man das Format individuell einstellen.

Bei RPGIV ist die Anweisung TIME kritisch, da sie das Datum immer im Jobformat liefert !
In RPGLE wird das Datumsformat der H-Zeile verwendet.

[KM]

Da wir jetzt auch Polnisch benötigen, stellt sich für mich die Frage, ob für die reine Datenerfassung bzw. Datenanzeige überhaupt die Sekundärsprache Polnisch benötigt wird. Würde es nicht ausreichen, wenn wir die Einstellungen an DEVD, Tastatur, USRPRF, Sprachen-ID, Landes-ID, Host-Codepage, usw. auf Polnisch umstellen ? Wie schon erwähnt sind unsere Datenbankdateien alle mit CCSID 65535 erstellt. Uns ist jetzt auch klar, dass wir für die Datenausgabe die gleichen Einstellungen benötigen wie für die Datenerfassung, damit die Zeichen wieder korrekt dargestellt werden. Brauchen wir dann die Sekundärsprache überhaupt ? Oder wird diese nur für Systemmeldungen o.ä. benötigt ?

Gruß,
KM

[Fuerchau]

Die Sekundärsprache wird für alle Systemfunktionen und Meldungen benötigt, die polnische/griechische User verwenden können.
Denke dabei mal an WRKSPLF, beantworten von Druckernachrichten, DSPMSG usw.

Wenn eure Datenbanken schon auf 65535 stehen dann sollten auch die Jobs auf 65535 stehen damit auch garantiert keine Code-Wandlung durchgeführt wird.

Wie siehts mit euren PGM-Quellen aus ?
Welche CCSID wird da verwendet ?
Verwendet ihr in den Programme konstante "variante" Zeichen ?

Das "#"-Zeichen ist. z.B. variant, d.h. wenn gegen eine polnische/griechische Eingabe verglichen wird, das Zeichen aber in der Quelle deutsch ist, ist der Vergleich negativ.
Den Link auf nichtvariante Zeichen habe ich schon mal im Forum abgelegt.