Das ist ja genau das Problem mit den CCSID's.
Die Jobs müssen zur Laufzeit natürlich immer die passende CCSID des Systems aufweisen oder können allenfalls *HEX sein.
Die 1153 (Latin-2) ist nun mal leider nicht kompatibel zu 28709 (Chinesisch).
Ein Ändern der CCSID deines SQL-Serverjobs hat noch zusätzlich fatale folgen:
Nach Erstellung eines Result-Sets greift der ODBC/OLEDB/JDBC-Server wiederum auf die QSYS2-Objekte zu um die korrekten Felddefinitionen des Resultsets zu erfragen.
Hier scheitert der Server dann aber an der falschen CCSID.

M.a.W:
Mischungen von unterschiedlichen CCSID's auf einem System sind äußerst schwierig zu behandeln.
Die einzige Alternative ist wirklich Unicode oder entsprechende Casts in Unicode beim Select (View).
Bei Updates hast du dann ggf. schon wieder probleme, wenn du die Automatismen von .NET o.ä. verwendest, da du jeden Wert explizit in die korrekte CCSID casten musst:

select cast(My1153Field as nvarchar(nn) ...

update My1153File set My1153Field = cast(MyUnicodeValue as char(nn) ccsid 1153) ...