RE: Sending Hebrew data from RPG program to Java program

If you're running the java from an interactive job, run the DSPJOB command from the job and look at option 2. Scroll down a bit and you'll see the job CCSID and the default CCSID. If the job CCSID is 65535, the default CCSID will be used. Most likely it is this default CCSID that is being used to convert the RPG field from byte array to java string. If that conversion hits a character it doesn't recognize it will substitute x'40' (EBCDIC blank) for the value and then convert it. This may be erasing one or more of the bidi flags.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Geren White
Sent: Monday, July 01, 2013 10:58 AM
To: 'Java Programming on and around the IBM i'
Subject: RE: Sending Hebrew data from RPG program to Java program

Yes, I've read many warnings about how CCSID 65535 is most likely not what
you want to use. Unfortunately this is out of my control and if the CCSID
does turn out to be the problem this issue might be unsolvable. The company
that is using our application has their system CCSID set to 65535 and
changing it could potentially cause issues with other setups that they have.
I know it is possible to change the CCSID to something other than the system
default and has been one thing I've been looking into. At this point though
I'm unsure where the conversion is going wrong and I'm just guessing that
the issue is the CCSID. So I'm thinking my biggest concern should be
figuring out when this data is processed into an incorrect order. At some
point between getting the data from the spooled file and it being sent to
the Java program something is handling it incorrectly.

Thanks,