Das Problem ist hier tatsächlich das alte QM-Query, das neue Tabellen nicht per SQL sondern intern via DDS erstellt. QMQRY kennt CCSID 1208 allerdings nicht! Daher könnte die Ausgabetabelle mit 65535 (Binär) erstellt worden sein. Das kannst du mal mit DSPFFD verifizieren.
Im Wesentlichen läuft das darauf hinaus, alle QMQRY in SQL mit "create table ... as (select ...)" umzubauen. Solche SQL's kann man sich per ACS-Script erstellen und dann auch per RUNSQL, ggf. lesen aus Datei, direkt ausführen.
Ich weiß auch nicht warum ihr euch für 1208 statt 1200 entschieden habt.
Bei der Erstellung von 1208-Feldern sollte man auch immer mindestens die doppelte Anzahl Zeichen vorsehen, da 1208 eben variabel 1-4 Zeichen breit ist. Häufig zwar mit 2 Zeichen auskommt aber eben mehr Platz braucht als vermutet. Spätestens im interationalen Bereich mit vielen Sonderzeichen Accent, Umlaute usw. brauchts Platz.
CCSID 1200 (UTF16) wäre die bessere Alternative gewesen, und zwar in allen Belangen (ILERPG, Java, ODBC) Bei Java/ODBC wäre da noch nicht mal eine Umwandlung nötigt, da 1200 dem Typ String entsprincht.
Ggf. könnte QM damit auch besser umgehen.