XML-Ausgabe in Cobol im Format UTF-8

[Günter]

Hallo,

wir möchten mit einem ILE-COBOL-Programm eine XML-Datei erstellen. Am liebsten wäre uns, wenn wir diese im Format UTF-8 erstellen könnten.
Wir verwenden dazu die Funktion XML GENERATE im Format 2 (Ausgabe als IFS-File).
Damit die XML-Datei im IFS als UTF-8 ausgegeben wird, setzen wir mit der PROCESS-Anweisung die entsprechende CCSID auf den Wert 1208 oder 1209.
"PROCESS CCSID(JOBRUN HOBRUN JOBRUN 1209)"

Beim Aufruf des XML-GENERATE gibt es dann aber einen XML-Fehlercode "UTF-8 Single Byte nicht unterstützt" (Zumindest so ähnlich. Den genauen Fehlercode habe ich gerade nicht parat.) Es erfolgt dann keine Ausgabe in die XML-Date bzw. diese ist leer.

Wenn wir eine andere CCSID, z.B: 819 verwenden, gibt es keinen XML-Fehlercode und es wird XML in die Datei ausgegeben.

Wir haben noch keine Erfahrung mit XML und COBOL auf der iSeries. Kennt sich evtl. jemand besser damit aus und kann weiterhelfen?

Viele Grüße
Günter

[Fuerchau]

Nun ja, wie der Fehler schon sagt, 1208 wird in Cobol nicht unterstützt.
Du kannst nur UCS2 (National) ausgeben, wobei dann die Ausgabe wieder in einer N-Variable steht.
Um diese dann in UTF-8 zu konvertieren, benötigst du dann folgendes API:
http://www-01.ibm.com/support/knowle...RT.htm?lang=en
Dieses API ist einfacher aufzurufen als C-Routinen wie iconv().

[Günter]

Hallo Fuerchau,

danke für die Infos. Klingt ganz schön aufwändig. Mit "National" haben wir auch noch nichts gemacht, also auch Neuland.
Eigentlich würde uns ja auch 8859-1 (CCSID819) ausreichen. Weil das aber auch nicht richtig funktioniert hat, hatten wir es mit UTF-8 versucht.

Vielleicht bekommen wir das aber dann doch mit 8859-1 irgendwie hin. Unser Problem ist, dass wir in diesem Fall mit "PROCESS CCSID(JOBRUN JOBRUN JOBRUN 819)" den Zeichensatz angeben aber die Umlaute nicht korrekt ausgegeben werden. So wird z.B. bei einem "ä" der Zeichencode 7b ausgegeben. Lt. Tabelle 8859-1 müsste es aber ein e4 sein.
Über die Eigenschaften im iSeries Navigator sieht man, dass die Datei die Zeichensatz-ID 819 hat. Wenn ich die Datei aber aus dem Navigator auf den PC kopiere und dort mit einem HEX-Editor öffne, sehe ich eben, dass die Umlaute falsch sind. Die Standardzeichen (normale Buchstaben und Ziffern) passen.
Reicht die Angabe der CCSID evtl. nicht aus, damit die Zeichen bei der Ausgabe gewandelt werden?

Viele Grüße
Günter

[Fuerchau]

819 ist veraltet, korrekt ist nun 1252.
Wie ist die CCSID der DB und des Job's zur Laufzeit?
Wenn wieder mal *HEX(65535) dann kann XML ggf. von der Basis 037 (Englisch USA) ausgehen und somit stimmt deine Basis (VON EBCDIC nach 1252) nicht.
Beachte, dass beim Lesen aus der DB keine Codewandlung passiert, wenn DB oder Job 65535 ist.
XML-Funktionen gehen ggf. bei fehlender CCSID von der "current locale" aus.

[Fuerchau]

Nachtrag:
Dies gilt i.Ü. auch bei Erstellung von UTF-8, da nun mal die JOB-CCSID für die Quellkodierung zuständig ist.

[Günter]

Die Tabellen in der Datenbank haben die CCSID 273. In unserem ersten Testprogramm war der Zugriff auf die Datenbank noch nicht enthalten, es wurde nur mit Variablen und Literalen gearbeitet.
Der Tipp mit der Basis-CCSID war aber dennoch ein Volltreffer. Wir haben nun für "non-locale single byte data" die CCSID 273 zugewiesen "PROCESS CCSID(JOBRUN 273 JOBRUN 819)" und neu umgewandelt. Damit kommen nun auch die Sonderzeichen korrekt im XML an. Das Problem ist also damit gelöst! Wir hatten es zuerst mit "locale single byte data" versucht, das hatte aber keine Wirkung.

PS: Die CCSID 1252 funktioniert nicht, damit bekommen wir wieder den XML-Fehler.

Übrig bleibt eine gewisse Unsicherheit, weil ich nicht genau weiß, warum es nun der CCSID-Parameter für "non-locale single byte data" ist, der eingestellt werden muss und nicht der "locale single byte data". Mir ist wohl nicht klar, wofür hier "locale" bzw. "non-locale" steht.
Sollte ich sicherheitshalber beide Parameter auf 273 einstellen?

Gruß
Günter

[Fuerchau]

Nun ja, da kann man mal sehen, welchen Mist sich die IBM da wieder überlegt hat.
Normalerweise sollte die CCSID immer auf JOBRUN stehen und dafür gesorgt werden, dass der Job die korrekte CCSID aufweist.
Immerhin findet (normalerweise) zwischen DB und Job eine Codewandlung statt.
Ist alles korrekt, klappte es auch (meistens) mit anderen Sprachumgebungen.
Ggf. ist das für euch ja nicht relevant.
Bei den Parametern für CCSID(a b c d) kann ich nur vermuten, das Handbuch gibt da nicht so viel her:
a) Locale-Single-Byte = CCSID für das lesen/schreiben von/zur Datenbank
b) Non-Locale-Singl-Byte = CCSID aller Zeichen-variablen des Programmes
c) Non-Locale-Double = CCSID eben für DBCS (auchtung, nicht UCS2/Unicode)
d) XML

Da nun das XML-Statement wohl die XML nur im Speicher erstellt und du das Ergebnis ja noch weitergeben willst, wirst du ja wohl die Daten ins IFS noch ausgeben.

Codepage 819 ist leider unvollständig, da die Codes zwischen x80 und x9F nicht definiert sind. Diese Hexcodes können also nicht korrekt umgewandelt werden.
Codepage 1252 ist vollständig, da ist z.B. auch das €-Zeichen dabei.
Warum nun kein 1252 erstellt werden kann weiß ich nicht, aber meine Empfehlung ist hier 273 in der Variablen zu erstellen und dann per Codewandlungs-API von 273 nach 1252 umzuwandeln.
Dann klappt es auch mit weiteren Sonderzeichen:
http://de.wikipedia.org/wiki/Codepage_819

[Günter]

Beim XML GENERATE im Format 2 wird das XML direkt aus der Varablenstruktur ins IFS geschrieben. Um die Ausgabe ins IFS-File muss man sich also nicht extra kümmern.

Damit, dass die Sonderzeichen des Bereichs x'80 bis x'9f nicht entsprechend der neueren Copdepage 1252 konvertiert werden, kann ich erstmal leben. In 8859-1 ist dieser Bereich ja auch gar nicht definiert.

Was nun als nächstes auffällt, ist, dass dabei im XML-File kein Header erstellt wird. Lt. Handbuch ist das auch so beschrieben. Evtl. hat ja aber doch noch jemand eine einfache Lösung?

Nun haben wir einen ersten Test mit der umgekehrten Richtung mit XML PARSE gemacht. Es sieht dabei so aus, als ob (anders als beim XML GENERATE) keine automatische Zeichenkonvertierung erfolgt. Zumindest sind die Einstellungen mit der PROCESS CCSID-Option hier scheinbar völlig wirkungslos.
Gibt es beim XML-PARSE tatsächlich keine automatische Zeichenkonvertierung oder muß ich noch andere Parameter setzen?
Falls es tatsächlich nicht automatisch geht, wie mache ich die Codeumwandlung, ggf. danach auf das IFS-File, selbst? Kann ich das direkt von Cobol oder CL machen?

[Fuerchau]

Fragen über Fragen.
Prüfe mal per DSPATR, ob die CCSID auch wirklich in die Datei eingetragen wird.
Ansonsten musst du per CHGATR die CCSID danach setzen.
Hat die Quelle die korrekte CCSID erkennt dies XML-PARSE automatisch.

Den XML-Header würde ich in eine separate IFS-File mit CCSID 819 schreiben.
Mit QSH CMD('cat xmlhdr xmlfile >xmlcomplete') kannst du das dann zusammenschustern.

[Günter]

Mal keine Fragen, sondern eine Erkenntnis:

Der XML-PARSE konvertiert nicht automatisch. IBM schreibt hierzu:

When you parse ASCII XML documents, the document fragments passed to the processing procedure in special register XML-TEXT are encoded in ASCII. Because ILE COBOL operations such as move and comparison rely on EBCDIC encoding or on national characters for proper operation, you must convert the document fragments before using them. To do this when the XML document is in a COBOL program, first convert from the ASCII CCSID of the XML document to national characters using the MOVE statement. Then, if necessary, convert the result from national characters to EBCDIC using the MOVE statement.

Man muss also intern immer erst für jedes gelesene XML-Statement eine Zeichenkonvertierung durchführen, bevor man die Informationen weiterverarbeiten kann.

[Fuerchau]

Nun ja, wenn es mit einem simplen Move erledigt werden kann.