Nein, wie willst du denn konvertieren?
Da du ja alles über Prozeduren regelst, hast du dich von den Möglichkeiten in SQL quasi entkoppelt.

Auf Resultsets von Prozeduren kannst du nicht mehr mit SQL einwirken!

Wenn du mit ODBC zugreifst, musst du folgendes Bedenken:
Windowsanwendungen arbeiten schon mal per se in Unicode. Übergibst du einen Unicodewert an einen SBCS-Parameter, wird hier schon mal von Unicode in SBCS übersetzt. Ist das Windows polnisch, bleibt ja erst mal alles beim Alten, ist das Windows deutsch, geht die polnische Darstellung verloren.
Nun ist der Parameter in ANSI und wird bei der Übergabe an deine Prozedur in die EBCDIC-CCSID des QZDA-Job's gewandelt. Spätestens hier geht dein polnisch aber verloren.

Du kannst versuchen, den QZDA-Job in CCSID 870 zu versetzen (entweder per Prozedur (eigene oder QCMDEXC) mit "CHGJOB CCSID(870)".

Zusätzlich musst du deine Selects in den Prozeduren aber casten "cast(mychar as char(nn) ccsid 65535)", dann betrachtet das System die Daten als "neutral" und wandelt nicht in die JOB-CCSID.
Ebenso ist beim Insert natürlich ein cast auf CCSID 65535 erforderlich.

Nun kann der QZDA-Job (bzw. der Treiber) von der Job-CCSID nach ANSI konvertieren.

Ein Aufruf von iConv hilft dir hier nicht, da der bereits zu spät ansetzt, deine Daten werden ja bereits beim Lesen konvertiert.

Prozeduren sollten keine Resultsets zurückgeben sondern nur gezielt einzelne (oder mehrere) Werte (OUT/INOUT-Parameter).
Sollte mehr Anwendungslogik nötig sein (ins besonders beim Insert) sind hier Trigger bzw. Constraints der richtige Ansatz.

Und zu guter letzt:
Sollte von polnischen Clients auf deutsche Daten zugegriffen werden, verlierst du halt die deutsche Darstellung, was spätestens bei einem Update deine Daten zerstört.

Am besten überarbeitest du deine Prozeduren und stellst diese auf Unicode um.

PS:
Ein CHGJOB CCSID(65535) hat auf SQL keine Auswirkung, im Zweifel nimmt SQL nämlich die Default-CCSID des Jobs und die bezieht sich auf die Primärsprache des Systems.