There shouldn’t be any problem with the files between the two systems — assuming the systems are configured appropriatly. For example, if you’re going to be storing and retrieving Unicode data in SQL tables (DB2 physical files) and especially if you’re expecting networking protocols such as DDM/DRDA to transfer data between multiple systems, you will want system attributes such as QCCSID to be set appropriately.
I don’t know a good reason for an improper QCCSID value, but I know that it’s common. If one or both of your systems is set to 65535, for example, you will want to keep specific control over individual jobs and/or profiles. The system will try to follow your instructions — 65535 is somewhat like instructing the system <i>not</i> to perform conversions during transfers.
You might issue CHGJOB CCSID( 37 ) on the source system before connecting to the remote Unicode system. (Assuming 37 is appropriate for you.) A remote query should then present the Unicode data in a readable fashion within that job.
It’s usually far easier simply to set the systems appropriately than to try to keep up with every connection.
We have Unicode data in a number of our files and have no problem with accesses from other systems in our network.
If you have specific problems, post the source and target environments, the data descriptions, the access methods and the results. Suggestions are probably available.