In die Datenbank bekommst du die Daten nur dann vernünftig, wenn die Felder ebenso UCS2 sind:
DDS Typ G, CCSID 13488
SQL N[VAR]CHAR(xx)

Im Programm sind die Variablen dann vom Typ "C".
Beim Drucken allerdings hört der Spaß fast wieder auf:
AFPDS = Dies geht, wenn du z.B. PDF-Ausgabe wählst, kann in der PRTF ein Typ-G-Feld mit einem TrueTypeFont verwendet werden.
Bei anderen Ausdrucken (SCS, lokalen Druckern) müssen die Daten in die korrekte CHRID für die PRTF ausgegeben werden. Die CHRID wird beim CRTPRTF/OVRPRTF angegeben.
Die Daten zum Drucker unterliegen, ebenso wie beim Display, keiner Codewandlung.
D.h., auf Grund der CHRID wird im Drucker die Codepage (850=Deutsch, 852=Osteuropa, ...) ausgewählt. Ist diese nicht vorhanden, wird Schrott gedruckt.

Wenn du z.B. einen Zebra-Drucker einsetzt, musst du die ZPL-Codes der Codepage kennen und die Daten passend in der EBCDIC-CCSID an den Drucker geben.

Im Programm kann man per API (dynmischer) oder auch per SQL (leider nur statisch) Codewandlungen durchführen, dazu sollte die Daten in einer "C"-Variablen vorliegen:
SQL: exec sql set : MyChar870 = cast(: MyCVar as char(nn) ccsid 870);
Leider lässt sich das so nicht per dynamischem SQL ausführen.

Oder du liest die Daten mittels dynamischem Cursor direkt in der passenden CCSID ein.

Wie du siehst, leider nicht ganz so einfach, da du im Vorhinein wissen musst, welche CCSID deine Daten haben um dann entsprechend für die Ausgabe reagieren zu können.
D.h., dass du am besten deine Daten mit einem eigenen Zusatzfeld und der Quell-CCSID speicherst.