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

[edv90020]

Hallo Forum,

ich blicke durch die vielen CCSID nicht mehr durch. Folgendes haben wir vor:

Für die verschiedenen Sprachräume wollen wir eigene Partitionen erstellen. Als Primärsprache soll Englisch sein und als Sekundärsprache der jeweilige Sprachraum.

Derzeit sind wir in Deutschland (CCSID 273) und Frankreich (derzeit missbrauchen wir dei CCSID 273 für den französichen Zeichensatz) eine System.
Polen (870) auch ein eigenes System.

Folgende Sprachen sollen folgen:

- Czech
- Croatia
- Hungarian
- und weitere Osteuropäische Länder
die über den Zeichensatz 870, Latin-2 Multilingual abgedeckt werden können

sowie Bulgarien, Russland und Ukraine (Cyrillic)

Weitere Westeuropäische Länder werden auch folgen.

Nun zu meiner Frage:

Welche Code Page (wie für Latin-2 Multilingual) muss man verwenden für die Cyrillischen Zeichensatz. Gibt es ein Latin-1 Multilingual Zeichensatz für die Westeuropäischen Länder?
Wir wollen so viele Länder wie möglich in eine Partition rein packen können.

Eigentlich suche ich ein eine Tabelle, die mir sagt mit dieser Code Page folgende Länder abgedeckt.

Welche Parameter müssen richtig gedreht werden ?! Was ist zu beachten.

Was ist überhaupt der Unterschied zwischen der CCSID 273 und 1141 (Deutsch) oder 870 und 1153(Latin-2 Multil.)

Schon mal für jede Info und jeden Link ein riesen Dankeschön...

[BenderD]

Hallo,

das riecht nach Unicode, also UTF8 oder UTF16 (beide Standard, auf AS/400 nicht besonders gut unterstützt, wg. variable length) oder UCS16 (eine Art Unicode für arme und kranke).
Ansonsten brauchst du dann für jeden Benutzer die entsprechende Sprachbibliothek QSYSxxx und die passende Einstellung des Jobs, für die Zeichen, die der 5250 dann anzeigen können soll.
Das ganze gehört sorgfältig geplant und da gibt es auch spezielle Systemliteratur und Redbooks (zu finden auf publib.boulder)

D*B

Hallo Forum,

ich blicke durch die vielen CCSID nicht mehr durch. Folgendes haben wir vor:

Für die verschiedenen Sprachräume wollen wir eigene Partitionen erstellen. Als Primärsprache soll Englisch sein und als Sekundärsprache der jeweilige Sprachraum.

Derzeit sind wir in Deutschland (CCSID 273) und Frankreich (derzeit missbrauchen wir dei CCSID 273 für den französichen Zeichensatz) eine System.
Polen (870) auch ein eigenes System.

Folgende Sprachen sollen folgen:

- Czech
- Croatia
- Hungarian
- und weitere Osteuropäische Länder
die über den Zeichensatz 870, Latin-2 Multilingual abgedeckt werden können

sowie Bulgarien, Russland und Ukraine (Cyrillic)

Weitere Westeuropäische Länder werden auch folgen.

Nun zu meiner Frage:

Welche Code Page (wie für Latin-2 Multilingual) muss man verwenden für die Cyrillischen Zeichensatz. Gibt es ein Latin-1 Multilingual Zeichensatz für die Westeuropäischen Länder?
Wir wollen so viele Länder wie möglich in eine Partition rein packen können.

Eigentlich suche ich ein eine Tabelle, die mir sagt mit dieser Code Page folgende Länder abgedeckt.

Welche Parameter müssen richtig gedreht werden ?! Was ist zu beachten.

Was ist überhaupt der Unterschied zwischen der CCSID 273 und 1141 (Deutsch) oder 870 und 1153(Latin-2 Multil.)

Schon mal für jede Info und jeden Link ein riesen Dankeschön...

[edv90020]

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

[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.