XML-Ausgabe in Cobol im Format UTF-8

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