SQL hat da bestimmt die selben Probleme wie alle anderen auch, wenn man mit falschen CCSID's umgeht:
Es gilt nämlich immer noch die Aussage, dass Programmkonstanten und Felder selber keiner Codewandlung mehr unterliegen, da beim Laden eines Programmes dies eben nicht passiert.
Codewandlungen finden generell nur bei Zugriffen auf/von Objekten mit CCSID-Unterstützung statt.
Was im Jobspeicher liegt muss also der Job-CCSID entsprechen.

Also Quelle umgewandelt mit CCSID 273 => Hexwerte von Programmkonstanten in 273.
Solange der Job nun in 273 läuft ist auch alles gut.
Änderst du nun den Job auf z.B. 280 (Italien), nimmt auch SQL an, dass deine Hexwerte in 280 sind, was nun mal definitiv nicht stimmt.
Greifst du nun per SQL auf die Tabelle in 273 funktionierts nun nicht mehr.
Das hat auch nichts mit SQL zu tun, da die Codewandlung zwischen Job und DB auf der Schicht hinter SQL, nämlich auf der nativen Zugriffsschicht der PF, durchgeführt wird.

Deine Konvertierung erfolgt auf Basis der Job-CCSID zur Laufzeit und nicht auf Basis der Quell-CCSID zur Compilezeit. Die kann bei abweichender CCSID daher nicht korrekt sein.
Daher sollte man Konstanten generell nicht mit varianten Zeichen definieren (Umlaute, @, #, ...).

Wenn man allerdings sein System sowieso nur in einer Sprache und die Jobs in *HEX führt dem kann das letztlich egal sein. Sollte das System aber mal aus irgendwelchen Gründen mal mehrsprachig werden sollen darf man sich über die auftretenden Probleme dann nicht wundern.
Und da kenne ich nun genug, denen das dann passiert ist.