Wie richte ich die i5 für mehrere Sprachräume ein?

[BenderD]

man muss hier erst mal zwischen Speicherung und Darstellung unterscheiden!
Für die Speicherung würde ich immer Unicode nehmen und das auch in einer einheitlichen Datenbasis speichern. Dann kann man alle Unicode fähigen Frontends (Office Schnittstellen, Web Frontends etc.) optimal mit Daten versorgen.
5250 als Frontend kann keinen Unicode, setzt aber Unicode in seinen Zeichensatz um, soweit es geht (ansonsten kommen Ersatzzeichen), wenn denn der Job nicht auf 65535 steht, sondern korrekt eingestellt ist. Das zusammen fassen verschiedener Länder unter einem Zeichensatz geht hierbei genauso, wie bei den Partitionen, mit demselben Preis, dass ein Franzose dann halt mit seinem ca ira und der Spanier mit seinen Fragen Probleme hat.

D*B

Wie du schon sagst, Unicode. Damit habe ich mich auch schon lange beschäftigt. Aber da es mit 5250 nicht umzusetzten geht, gehen wir über den weg über mehrere Partitionen. Also Autarke Systeme.
Wir wollen aber auch nicht pro Land eine eigene Partition bzw. System erstellen.

Nun versuchen ich so viele Länder wie möglich in eine Sprach-Umgebung zu stecken. Mit 870 für Latin-2 geht das wunderbart. Mit Deutschland und Frankreich geht es gerade auch noch (aber eigentlich nicht ganz richtig die franzosen in den deutschen Zeichensatz zu packen).

Welchen Zeichensatz verwende ich für Cyrillische Zeichen ? 1025 ? 1123 oder doch 1154?
wenn ich wüssten welche CodePage die richtige ist, würde es mir für den Anfang helfen.

PS
Danke für die schnelle Antwort

[KM]

Hallo,

für kyrillisch würde ich 1154 nehmen. Da hast Du wenigstens gleich das Euro-Zeichen mit drin, falls das mal benötigt wird.

Gruß,
KM

[edv90020]

Hallo,

für kyrillisch würde ich 1154 nehmen. Da hast Du wenigstens gleich das Euro-Zeichen mit drin, falls das mal benötigt wird.

Gruß,
KM

Danke für den Hinweis. Dann bin ich schon ein kleines Stück weiter.


@BenderD
Die komplette geschichte mit Unicode (Speichern, Darstellen) usw. kenne ich. Bei einer Neuentwicklung würden wir auch so angehen aber aus historischen Gründen (die Masse an Dateien - > 5.000 - und Progammen - > 16.000) ist das mit unserer Anwendung nicht händelbar. Dort steckt 18 Jahre Entwicklung. Ein weiteres Problem: Unsere Programme bestehen größtensteils aus RPG Programmen und für Unicode benötigen wir ILE RPG.

Deswegen die Lösung über die LP/eigene Systeme. Damit könne unsere Kollegen im Ausland arbeiten (Voraussetzung natürlich die Anwendung wurde übersetzt)

Gruß

[BenderD]

wenn man diesen Weg geht, dann steht man in 20 Jahren immer noch an derselben Stelle, weil ja alle neuen Programme dann zwangsweise an derselben Krankheit leiden wie die alten!
Ich sehe da durchaus Alternativen, ohne die vorhandenen Programme anzupacken und für die Datenbank ein konsequentes Redesign vorzunehmen und diese Unicode fähig zu machen. Wir haben sowas z.B. schonmal mit zusätzlichen Unicode Feldern und generierten SQL Triggern gemacht, die die Unicode Felder mit parallelem Inhalt pflegen.

D*B

Danke für den Hinweis. Dann bin ich schon ein kleines Stück weiter.


@BenderD
Die komplette geschichte mit Unicode (Speichern, Darstellen) usw. kenne ich. Bei einer Neuentwicklung würden wir auch so angehen aber aus historischen Gründen (die Masse an Dateien - > 5.000 - und Progammen - > 16.000) ist das mit unserer Anwendung nicht händelbar. Dort steckt 18 Jahre Entwicklung. Ein weiteres Problem: Unsere Programme bestehen größtensteils aus RPG Programmen und für Unicode benötigen wir ILE RPG.

Deswegen die Lösung über die LP/eigene Systeme. Damit könne unsere Kollegen im Ausland arbeiten (Voraussetzung natürlich die Anwendung wurde übersetzt)

Gruß

[Fuerchau]

Wie immer gibts mal wieder durcheinander

Die CCSID dient der Speicherung der Daten (also den Code), die CHRID dient der Darstellung (wenn man so will quasi den Font).

Innerhalb eines Sprachraum (e.g. Latin-1) gibt es für jeden Code einer CCSID einen entsprechenden Code in der anderen.
Nimmt man also CCSID 273 Deutsch, dann enthält dieser Zeichensatz auch alle französischen Zeichen, genauso wie CCSID 500 (gerne als International benannt) oder eben die französische CCSID (297).

Ich kann also durchaus französische und deutsche Zeichen in einer DB mischen.

Wichtig ist einzig und allein:
Die Terminal-CCSID (Hostcodepage) muss zur JOB-CCSID passen !
Steht die Job-CCSID auf 65535 (*HEX), muss die Terminal-CCSID zur DB-CCSID passen.

Bleibe ich allerdings in einer Terminalwelt (z.B. nur französisch) ist das alles egal, da die Daten genauso angezeigt werden, wie sie eingegeben werden.
Erst wenn ich die Daten mische und gemeinsam Anzeige, kommt es zu den üblichen Falschdarstellungen.

Nochmal zu Latin-1:

Wenn ich die System-Sprachlib's vorschalte fangen leider die Schwierigkeiten an, da auch die IBM nicht in der Lage ist, seine Sprachobjekte mit einer korrekten CCSID's auszuliefern (die haben nämlich alle 65535).

Dies erfordert, dass sowohl der Job als auch das Terminal in der der Sprache zugeordneten CCSID eingestellt sein muss.

Innerhalb eines Sprachraumes (hier also Latin-1), ist die CCSID des DB letztlich egal, solange diese auch zum Sprachraum gehört.
Begründet wird dies damit, dass eben beim Lesen/Schreiben zwischen DB- und Job-CCSID eine Codewandlung stattfindet.

Zwischen Terminal und Job kann man zwar auch eine Codewandlung einschalten, aber hierzu sind auch CCSID's auf Feldebene in einer DSPF erforderlich und wer hat das schon je gemacht.

Kommen wir nun zu einem anderen Sprachraum (z.B. Latin-2).
Auch hier gilt, innerhalb des Sprachraumes passen alle CCSID's zueinander.

Sollen nun Daten in einer gemeinsamen DB (Latin-1 und Latin-2) gespeichert werden, so ist natürlich die beste Lösung Unicode (hier CCSID 13488 bzw. als UCS-2 benannt).
Das erfordert aber nun mal ILE und/oder SQL.
Bleibt man bei SQL, brauchen die Programme nix zu tun, da automatisch von UCS-2 in die Job-CCSID bzw. umgekehrt gewandelt wird, lediglich die DB ist mit UCS2 einzurichten.

Bei RecordLevel-Access sind natürlich jede Menge Fehlerquellen vorprogrammiert, also sollte man dies natürlich lassen.

Nun muss man sich aber die Frage stellen, ob denn die "gemeinsamen" Daten auch tatsächlich gemeinsam ausgegeben werden.
Ist das nämlich (wie meistens) nicht der Fall, reicht für die DB die CCSID 65535 (*HEX), für die Job's und Terminal eben die Sprach-CCSID.

Problematisch wirds nun mit FTP/ODBC/DRDA/IFS !
Bei allen diesen Verwendungen muss man nun anfangen mit CCSID's zu jonglieren, temporär umkopieren, CCSID's nun doch zuordnen usw. usw.

Bei Sprachtrennungen in eigenen Lib's kann jedoch jede DB ihre Sprach-CCSID aufweisen und alles in in Butter.

Wirklich alles ?

Da gibt's ja noch ggf. PRTF's !
Anzusteuernde OUTQ's, MSGF's u.v.m.

Am einfachsten sind da noch die PRTF's.
Hier ist es wichtig, dass zum Erstellzeitpung des Spools (nicht der PRTF !) per OVRPRTF die zur CCSID gehörende CHRID eingestellt wird, denn sonst klappts nicht mit der richtigen Codepage im Drucker.

So...
Das wärs mal wieder fürs erste.