Dies insgesamt zu erklären ist hier vielleicht etwas aufwändig.
Grundsätzlich gilt jedoch eigentlich:

Das System sollte eine QCCSID/QCHRID in den Systemwerten entsprechend der Primärsprache enthalten, da auch die Systemdateien in einer CCSID ausgeliefert werden.
Eigene DB's sollten in der vorzugsweisen CCSID erstellt werden.

In einer mehrsprachigen Umgebung (Deutsch, Englisch, Französich, ...) Latin1-Welt erfolgt eine korrekte Umsetzung zwischen den Sprachen. Insbesonders beim Austausch mit Fremdsystemen (IFS, ODBC) können Sonderzeichen korrekt übertragen werden.

Hast du in einer DB unterschiedlichste Sprachen mit CCSID 65535 erfasst, kannst du die Daten ausschließlich an Terminals mit der gleichen Konstellation darstellen an denen sie auch erzeugt wurden.
Erfasst also ein Franzose an einem franz. Terminal Sonderzeichen (éèáàê...) können diese an einem deutschen oder englischen Terminal nicht korrekt wiedergegeben werden.
Steht der Job aber auf der gleichen CCSID wie das Terminal (273 Deutsch, 297 Französisch) und die Datenbank ist auf 273, können die Daten an jedem Terminal mit Latin1-CCSID korrekt wiedergegeben werden.

Etwas anders siehts leider mit der Latin2-Welt (griechisch, polnisch, tchechisch,...) aus (nicht wenn sie in sich geschlossen bleibt), wenn Daten mit Latin1 ausgetauscht werden müssen. Hier gibt es beim Hin- und Rückkonvertieren ggf. Zeichenverluste was aber im einzelnen zu prüfen ist.

Der absolut korrekte Weg wäre die Verwendung von DBCS oder neu ab V5 die Verwendung von UNICODE (CCSID 13488) für eine neutrale mehsprachige Umgebung (ich kenne niemand der das macht).

Schau mal bei IBM zum Thema "Globalization".