CCSID 1208 ist in der DB auch für Java kontroproduktiv.
In Java muss UTF8 erst in String konvertiert werden (UTF16 = CCSID 1200) um damit arbeiten zu können. Beim Schreiben muss wieder in UTF8 überführt werden.
Wenn die DB gleich UTF16 hat, wird sie auch vom JDBC-Treiber korrekt als String interpretiert.
Ein Automatismuss UTF8<=>String gibts da nicht.
Desweiteren muss man bedenken, dass man mindestens den doppelten bis 3-fachen Platz vorsehen muss, da UTF8 ein variabler Zeichensatz ist.
Bei UTF16 (n[var]char) ist die Längenangabe bereits in Zeichen und nicht in Bytes. Und zumindest lassen sich japanisch und chinesisch (1 Dialekt) in den ersten 32K-Zeichen unterbringen ohne auf 4-Bytes gehen zu müssen.
Ich hatte da mal ein Oracle-Problem, da auch dort mit UTF8 gearbeitet wird und die Länge dann in Bytes definiert wird. Daher wurde ein Feld "Lager" als nchar(2) definiert. Als dann auf dem Quellsystem ein Lager "Ü1" angelegt wurde, scheiterte die Schnittstelle, da nun 3 Bytes in 2 Bytes nicht passen.

Auch ist generell VARCHAR vorzuziehen und die Daten ggf. zu trimmen, da auch in Java Leerzeichen am Ende für Vergleiche relevant sind, für die DB allerdings nicht, wie für RPGLE und COBOL auch.

Da die DB zwar UTF8 mittlerweile selber unterstützt, passiert beim Lesen in RPG auch erst mal keine Umwandlung, da das Zielfeld ja ebenso mit CCSIID 1208 getagt sein sollte.
Nur bei der Weiterverarbeitung muss ich erst in CHAR oder UCS2 umwandeln, was der Einzelfeld-Eval ja tut. Ein Eval-Corr nimmt das Feld aber nicht mit, wenn die CCSID nicht identisch ist.

Der CPYF ist auf keinen Fall zu empfehlen.