Voraussetzung ist natürlich, dass die Jobumgebung zum User passt.
Da kann man über die Spracheinstellung im USRPRF und Systemwerte entsprechende Einstellungen für die automatische Anpassung der Job-CCSID machen.
Die 5250-Sitzung des Users muss dann ebenso der Sprache zugeordnet sein.
Beispiel:
User Deutsch = Job 273 = Codepage 1141
User Französisch = Job 297 = Codepage 1147
User Polnisch = Job 870 = Codepage 1153

Alleine durch die Möglichkeit, dass der Job mal in 273/297 (Westeuropa) oder in 870 (Osteuropa) sein kann, darf die DB nicht mit 273 erstellt sein.
Neutrale Zeichenfelder, also invariante Zeichen, sollten in 65535 erstellt werden (hier gibts aber ODBC-Probleme), alle anderen Zeichenfelder müssen in Unicode (UCS2/UTF16) erstellt werden.
Dann kann man durchaus zwischen Unicode und DSPF (nicht Unicode) Daten austauschen.
Wichtig ist natürlich, dass bei der falschen CCSID-Quelle (also deutschen Daten auf polnischen Sitzungen und umgekehrt) Verfälschungen passieren.
Wenn du die Sprache in der PF hast, kannst du ja eine Änderung der Daten ablehnen, eine Anzeige wäre da unschädlich.

Ein generelles Problem hast du natürlich mit dem Rest der Anwendung.
Schließlich müssen sich alle Programme wärend der Sitzung so verhalten. Du kannst es nicht auf eine Datei beschränken.
Sobald ein Programm in einer Umgebung (Job 870, Datei 273) aufgerufen wird, fällt der Open schon auf die Nase.