Fremdsprachen einführen

[Fuerchau]

Im wesentlichen gar nicht.
GRAPHIC mit entsprechender CCSID ist DBCS, wobei es DBCS gibt, die nicht Unicode sind.
Mit Einführung von Unicode (CCSID 13488) benötigt man die anderen (fast) nicht mehr.
Für Nicht-Unicode-DBCS (z.B. Japanisch) gibt es nämlich spezielle DBCS-5250, die aber leider nicht Unicode unterstützen.

Mit V7 (vielleicht auch schon V6) wurde der SQL-Typ NCHAR/NVARCHAR (N=National) eingeführt, der auch bei vielen anderen Datenbanken schon verwendet wird.
Oracle und SQL-Server speichern die Daten dann allerdings in UTF8, was zur Laufzeit halt ein paar Nanosekunden kostet, dies ständig in WCHAR und zurück zu wandeln.

Zusätzlich wird die CCSID 1200 statt 13488 verwendet.
Die 1200 gilt aber nicht als UCS2 sondern als UTF-16 (also 2/4-Bytes).
D.h., dass NCHAR tatsächlich nur ca. 32K Zeichen als 2-Bytes und alle anderen als 4-Bytes gespeichert werden, während die 13488 eben die 64K Zeichen speichert.
Solange man aber noch nicht mit Codepoints jenseits von 32K zu tun hat, passiert auch nichts, denn die vollständige Unterstützung von UCS4 gibt es auch noch nicht.

Den Unicode-Zeichensatz kann man sich in Windows mal mit der "Zeichentabelle" zu gemüte führen. Da tauchen dann ab Code x'Axxx' dann spezielle Codes auf, die in UTF16 dann 4 Bytes benötigten.

Bei der Umwandlung von UTF-16 in UCS2 gibt es aber bis zu den 64K-Zeichen noch keine Probleme und wann denn vulkanisch oder klingonisch aufgenommen wird steht noch in den Sternen.

Testen kann man das tatsächlich nur mit einer ODBC-Anwendung (Z.B. per Excel, mit MS-Query download, mit meinem Upload/400 upload) oder einer verknüpften Tabelle in Access oder SQL-Server.

Noch ein Tipp zu MS-Query:
MS-Query ist selber keine Unicode-Anwendung (selbst mit Office 2016 noch nicht) und stellt Sonderzeichen eben als Kästchen dar. Trotzdem verarbeitet Excel das dann korrekt.

[dschroeder]

Vielen Dank für die ausführliche Antwort, Baldur.
Wenn ich also folgende Annahmen treffe:
1. Speicherplatz ist uns egal
2. Performancedifferenzen beim Zugriff sind uns auch egal
3. Die meisten (wahrscheinlich alle) Zugriffe werden wir mit SQL machen und die Daten dann im RPG-Programm weiterverarbeiten.

Dann könnte man sagen:
Wenn wir als Datentyp NCHAR einsetzen, machen wir erstmal nichts grundlegend falsch.

Ist das so?
Können wir diese Datentypen im RPG problemlos verarbeiten?

[Fuerchau]

Ja, das ist problemlos, der Feldtyp ist "C".
Aber Vorsicht:
Bei Move/Eval/Prozeduraufrufen erfolgt ggf. eine automatische Konvertierung wenn die Arbeitsvariablen, Parameterschnittstellen nicht auf "C" angepasst sind.
Mit Like-Definition ist die Gefahr gering, Definitionen auf C-Ebene (außen rechts) müssen vermieden werden.

[dschroeder]

Vielen Dank an alle. Ich werde jetzt mal ein paar Tests machen.

[dschroeder]

Ich muss doch noch etwas fragen: Ein Kollege vertrat die Meinung, dass eine Umstellung auf DBCS wegen Fremdsprachen nicht immer notwendig ist. Die gängigen Sprachen (alle mit lateinischen Buchstaben, sowie die mit griechischen und kyrillischen Zeichen) müsste man mit den Single Byte Character Set abbilden können. (Klar: Japanisch geht dann nicht).

Wenn das so ist und ein spanischer Anwender gibt ein Zeichen ein, das unser deutscher Zeichensatz nicht kennt: Dann müsste ein deutscher Anwender ja ein Ersatzzeichen sehen. Wenn der deutsche Anwender das dann wieder speichert, macht er dem spanischen Anwender dann seine Daten kaputt?

[BenderD]

... wenn man denn bei den Daten weiß, wo sie herkommen und wie sie codiert sind, kann man auch eine Unicode View über die Daten stellen; bzw. das Unicode Feld zusätzlich führen und per Trigger erzeugen und konsistent halten. Die Anwendung selber bleibt dabei unberührt. Zu Deiner Ausgangsfrage: selbst bei zurückschreiben der gelesenen Daten bleibt der Inhalt in Hex erhalten solange man keine Eingaben in diesen Feldern macht.

D*B

[dschroeder]

Vielen Dank! Die Idee mit der View werde ich hier mal ansprechen.

[Fuerchau]

Nun ja, das mit den Sprachen verhält sich da etwas anders.
Die CCSID's werden zusätzlich in Sprachgruppen geführt. Diese sind dann mit Latin-1 bis inzwischen latin-15 aufgeteilt.
Alle CCSID's einer Latin-Gruppe lassen sich ohne Verlust hin und her konvertieren.
CCSID's unterschiedliche Latin-Gruppen führen bei der Konvertierung zu Verlusten.
Vor Einführung von Unicode konnte man z.B. zwischen 273 und 870 nicht konvertieren, der Open einer Tabelle schlug fehl.
Ab einem bestimmten Zeitpunkt wurde die Konvertierung wohl auf 2-stufig umgestellt, d.h., 1. Stufe in UCS2, 2. Stufe in Ziel-CCSID.
Solange man dann die Daten nur liest, ist es unkritisch.
Schreibt man die Daten zurück, werden sie nicht mehr korrekt zurückkonvertiert, da bei der Hin-Konvertierung Ersatzzeichen oder "?" verwendet wird. Sporadisch gibt es aber bei einigen CCSID-Kombinationen trotzdem was auf die Finger.
In ILERPG hat man halt das Problem, dass beim Lesen alle Felder die definiert sind (z.B. als DS), gefüllt und beim Update zurückgeschrieben werden.
In SQL kann man gezielt sich auf die Felder beschränken.
Übrigens ab irgendwann kann man beim Update in Free in Klammern die Feldliste angeben.

[Fuerchau]

Die Idee ohne Unicode auszukommen geht eingeschränkt natürlich auch, in dem man für jeden Sprachraum eine eigene Tabelle mit der gewünschten CCSID anlegt und die Daten dort pflegt.
Allerdings ist dann erforderlich, dass Tabelle, Job und Terminal alle mit derselben CCSID fahren, damit es nicht zu Darstellungsverlusten kommt.

[dschroeder]

Nochmals danke. Ist ein sehr komplexes Thema. Mich würde interessieren, was andere IBM i Anwender machen. Es ist ja oft so, dass man weiß, was theoretisch die beste Lösung ist, dass man aber in der Praxis doch eine einfachere (bzw. bekannte) Lösung wählt. Habt ihr zum großen Teil wirklich eure Tabellen auf DBCS umgestellt?

[BenderD]

... das mit dem View Layer, haben wir mal in einem BI Umfeld so gemacht. Ausgangslage waren:
- an die zehn Seperat Installationen der (fast) gleichen Software, für jede Auslandsgesellschaft eine.
- die komplette operative Software war klassisch mit Singlebyte, jeweils passende Codierung pro Installation
- die CCSIDs der Tabellen war teilweise falsch, funktioniert hat das nur nach dem MIMO Prinzip (sprich die Fehlcodierung der Eingabe war invers zur Fehlumsetzung bei der Ausgabe)
- im Datawarehaus sollten nun diese (auf den ersten Blick) inkompatiblen Bestände zusammengeführt werden.
- im Ladeprozess haben wir alles mit einem Mandantenkey (der letztlich auch die Codierung erkennen ließ) erweitert zusammengekippt

Dann haben wir im View Layer die Textfelder nach Unicode gecasted (technisch braucht es da Zwischencasts nach 65535, damit einem die automatischen Umsetzungen nicht dazwischen fuhrwerken)

Final war uns das dann für einige Tabellen zu langsam. Da haben wir dann zusätzliche Unicode Felder angehängt, die von Triggern gepflegt wurden.

Im View Layer haben wir dann Tabellen für alte Welt (single Byte korrekte CCSID) dargestellt und für neue Welt Unicode.

Da es sich um etliche Tabellen und Felder handelte, haben wir für alle erforderlichen SQL Skripte (create view, create trigger) 3 (oder waren es 4?) Generatoren geschrieben.

In der Summe nicht aufwandsfrei, aber signifikant weniger als Umstellung der vorhandenen Anwendung auf Unicode und wichtiger: Keinerlei Risiken für die vorhandene Anwendung (mit ihrem unbekannten Anteil an Varianten)

D*B

[Fuerchau]

Nachtrag:
Hier muss ich noch mal D*B recht geben.
Ich kann durchaus mehrere SBCS-CCSID's in einer Tabelle unterbringen (sowas schule ich auch), wenn man bestimmte Dinge berücksichtigt:
- zwischen DB und Job findet keine Umwandlung statt, wenn Job+DB-CCSID identisch ist oder der Job auf 65535 (*hex) steht
- Zwischen Job und DSPF/PRTF findet (ohne besondere Maßnahmen) keine Codewandlung statt
Also, Daten, die an einem 870-Terminal erfasst werden landen so binär auch in einer 273-DB.
Zu beachten ist lediglich, dass die Daten auch nur an einem 870-Terminal oder in einem 870-Spool korrekt wiedergegeben werden können.
Ich muss also ggf. zusätzliche Flags haben, um dies u.U. zu berücksichtigen (z.B. in einer View mit einem case-Verteiler für die Umwandlung in Unicode).
Wie Dieter schon sagte, solange ich die Daten nicht verändere werden sie binär betrachtet.
Beim Drucken muss ich dann berücksichtigen, dass ggf. beim Wechsel des Sprachflags eine andere PRTF (ggf. per OVRPRTF) mit anderer CHRID geöffnet werden muss.
Zu beachten ist dabei lediglich, dass auch die Drucker unterschiedliche Hardwarefonts unterstützen müssen.