Hier muss man den Unterschied zwischen den Sprachräumen Latin1 (deutsch, englisch, franz., ital., span. ...) und Latin2 (poln. grich., kroat., serb., russ. ...) betrachten !
Zwischen diesen ist eine Konvertierung nicht definiert, da auch generell unterschiedliche Symbole in den Zeichensätzen vorkommen und es somit zu Darstellungsverlusten kommt.
Solange du die Daten sortenrein auseinanderhalten kannst, magst du mit 65535 gut fahren. Spätestens wenn du mit ODBC/FTP, IFS o.ä. auf die Daten zugreifen willst, werden die Probleme erst richtig anfangen.
Woher soll denn die AS/400 wissen, welche ASCII-Codepage gilt ?
Beim ODBC werden Zeichenfelder mit 65535 normalerweise NICHT umgesetzt, du erhältst auf dem PC dann den EBCDIC-Code.
Klickst du aber "Zeichenumsetzung für CCSID 65535" an, nimmt die AS/400 den Standardwert der installierten Primärsprache (e.g.273) an und wandelt dann in die ANSI-Codepage des PC's (Deutsch 1252, Polnisch ????).
Was das nun für die polnischen Daten bedeutet kannst du dir ja vorstellen.

Mehrsprachigkeit vor allem unterschiedlicher Sprachräume erfordert ggf. ein Redesign der DB !
D.h., Normalisierung bezüglich der Text- und Nicht-Text-Felder, wobei es Textschlüssel geben mag, die überall gleich sind, aber das weiß die AS/400 ja nicht.
Pro Sprachraum (Latin1, Latin2, ...) eine eigene Daten-Lib !
Wo gibt es tatsächlich den Zwang für Konsolidierung der Daten über Sprachgrenzen ?

Anwendung von DBCS, noch besser UNICODE so wie es die Windows-PC's schon länger machen.

Bei einem anderen Kunden von mir arbeiten die Polen halt in Englisch !