Nun ja, da UTF-8 eine variable Speicherung ist, muss man beim Lesen andere Felder als beim Schreiben verwenden, was so bei RPGLE nun mal nicht geht.
Erklärung:
Ein Zeichen < x'7f' belegt in beide Richtungen nur 1 Byte, daher kann das Zielfeld genauso lang wie wie das Quellfeld sein. Für alle anderen Zeichen kommt es zur Verkürzung.
Umgedreht muss das Quellfeld aber 4x kürzer sein, da ja im Zweifel eine Vervierfachung auftreten kann.
Ausserdem muss man berücksichtigen, dass das PGM-Feld ggf. immer mit Leerzeichen aufgefüllt ist.
Also kann ein Unicode-Feld nach UTF-8 bis zu 4x größer werden. Ein UTF-8-Feld von gleichgroß bis zu einem viertel.
Die Lösung könnte ggf. ein VARLEN-Feld sein, wenn die aktuelle Länge beim Schreiben eben max. 1/4tel der verfügbaren Länge beträgt.

Die Speicherung im UTF-8 macht also insoweit keinen Sinn, da Unicode hier sowieso die konsistentere Wahl ist.
UTF-8 wird eher im Datenaustausch (Streamfiles) verwendet, die Speicherung immer in UNICODE.

Nun zu deinem Konvertierungsproblem:
Hexcodes im Programm werden in der Codepage des Job's interpretiert, dies gilt auch beim SQL/STRSQL. Wenn du also ein normales Zeichenfeld dem SQL übergibst dann ist das immer der Hexwert der JOB-CCSID (im Zweifel falls 65535 eben Deutsch 273, siehe auch QCCSID).
Die Konvertierung in UTF-8 macht eben eine Konvertierung des aktuellen Hex-Wertes in UTF-8.
UTF-16 oder auch Unicode sind per Definition aber weltweit gleich. Sprich dein 'Ä' ist bereits im korrekten Hexcode verwendet und kann daher auch korrekt in UTF-8 übersetzt werden.