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