Fremdsprachen einführen

[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

[Rainer Ross]

Ich habe einen Webservice zum Klicken gebaut, der Daten in Tschechisch, Russisch und Chinesisch als Webservice ausgibt. Als Frontend kann man jedes beliebige Webframework benutzen www.myhofi.com/muscgip/mymustst.pgm

Die Datei ist wie folgt aufgebaut:

create or replace table mylib.myfile (                                                                            
         id       int generated always as identity (start with 1 increment by 1),                                               
         artist1  char(50)    ccsid 1208,                                                                         
         artist2  graphic(50) ccsid 1200,                                                                         
         artist3  graphic(50) ccsid 13488,                                                                        
         primary  key(id)                                                                                       
        )

Mit wenigen JavaScript Statements ist es z.B. mit www.webix.com möglich, eine Weboberfläche für einen Webservice zu bauen
www.myhofi.com/devhtm/Websrv04.html

//--------------------------------------------------------------------------//
// Main                                                                     //
//--------------------------------------------------------------------------//

webix.ready(function(){
    webix.ui({
        view: "datatable",
        id: "myTable",
        autoConfig: true
    });
    webix.extend($$("myTable"), webix.ProgressBar);
    readData("myTable");
});

//--------------------------------------------------------------------------//
// Read Data                                                                //
//--------------------------------------------------------------------------//

function readData(tableId) {
    $$(tableId).showProgress({hide:true});
    webix.ajax().post("/myapp/websrv01.pgm", {id:0},
        function(text, data) {
            $$(tableId).clearAll();
            $$(tableId).parse(data.json().items);
            $$(tableId).setPage(0);
            $$(tableId).hideProgress();
        }
    );
}

Den Sourcecode für die Webservices findet ihr hier https://github.com/rainerross/websrvutl

Viele Grüße
Rainer

[dschroeder]

Auch an dich vielen Dank, Rainer. Noch mal eine vielleicht naive Frage: Wir haben bisher ja alle Felder in unseren Tabellen im SBCS (Also Single Byte Character Set) definiert. Gibt es einen "globalen Schalter", mit dem man alles (also alle Felder in allen Tabellen) auf Unicode umstellen könnte? Das System müsste dann, vereinfacht gesagt, ja nur alle Speicherplätze verdoppeln.

[Fuerchau]

Also ja und nein:
Wenn du alle Dateien mit DDS erstellt hast und diese grundsätzlich mit einer REFF definierst, musst du nur die REFF anpassen.
Hast du keine REFF must du die Felder anpassen. Anschließend alle Dateien mit CHGPF umsetzen. Die Daten bleiben dabei erhalten.

In SQL gibt es das leider so nicht. Hier gibts es nur einen "Create or Replace", wobei dann eben alle Daten weg sind. Du musst dann halt Sripte erstellen, die statt dessen einen "Alter Table ... Alter Column set data-type ..." generieren.

[dschroeder]

OK, habe ich verstanden. Letztlich müssen also die Felder in den Tabellen auf graphic oder ähnlichem stehen. Wenn wir Unicode wollen, müssten wir (in einer SQL-Tabellendefinition) also "graphic(xx) ccsid 13488" stehen haben.
Wenn wir das hätten, könnten unsere RPG-Programme dann damit einfach so arbeiten, wenn alle Zugriffe auf diese Felder mittels embedded SQL laufen? Müsste man die Hostvariablen im RPG dann auch mit dem Datentyp graph deklarieren?

[Fuerchau]

Um ggf. keine Fehler zu erhalten sollte dies gemacht werden.
Wie Dieter schon sagte:
Wenn es ein Umsetzungsproblem UCS2 => SBCS gibt, setzt SQL ein Warningsflag in der Anzeiger-Variablen (NULL-Flag = -2). Arbeitest du ohne NULL-Anzeiger gibts einen negativen SQL-Code.
Jetzt kannst du dir ja selber ausrechnen, was beim Lesen und Update dann so alles passieren kann.
Wobei bei einer Where-Klausel ggf. keine Daten gefunden werden, da die Umsetzung beim Lesen zu Ersatzzeichen geführt hat.

Auch hier sollte man dann mit externen Template-DS der Tabellen arbeiten (Copy, Include) und alle abgeleiteten per LIKE definieren.

[andreaspr@aon.at]

Müsste man die Hostvariablen im RPG dann auch mit dem Datentyp graph deklarieren?

Genau, du kannst aber auch ganz einfach eine extern beschriebene DS definieren. Dann brauchst du dir da keine Gedanken zu machen wie das genau definiert werden muss.
Nur wenn du die Unicode-Daten mit Chars kombinieren willst (EVAL oder IF) dann musst du halt Konvertierungen vornehmen (so wie in dem Beispiel was ich anfangs gepostet habe):