BIF %UCS2 give incorrect value for JDE WORLD kanji

[DavidB16]

AS400 at V5R2
JDE at 7.3 with Japanese Language Installed.
File with data is ccsid 37
Use java based Client Access at code page 937 to view kanji correctly

Assignment. Convert Japanese stored DBCS data to Unicode in IFS.

Problem: Incorrect UCS2 hex value returned most of the time. But sometimes it works. If I have the correct starting UCS2, the rest of my conversion
(my own Unicode custom function works.)

Example: characters
Those are Kanji parenthesis not single byte parenthesis
. Represented by JDE in DRDL01 10A ccsid as x'0e424d48ef425d0f'
. x'0e' and x'0f' Shift out/in

D myUCS2 10C

myUCS2=%UCS2(drdl) converts JDEFIELD(DRDL01) to u'FF08' + x'975E' + x'FF09)

Debug eval myUCS2:x or SQL select hex(:myUCS2) from QSYS2/QPTPTBL (guessing old name)
Returns

FF08 and FF09 is correct. but 975E is not. It should be 7AEF.

Makes no difference what I set my JOB CCSID to be. Supposed to convert to 13488 by default

%UCS2 must be using the wrong conversion table or else the JDE values are only understan

[Scott Klement]

I was going to suggest reporting this to IBM rather than posting it here (we can't fix bugs in the OS!) But, then I noticed that you said V5R2. Now I'm just in disbelief... your business is relying on a release that reached it's end-of-support (and end-of-life) TEN YEARS AGO?

[Barbara Morris]

David, I tried out your data with a 7.2 program (in 7.2, I can specify the CCSID of the 10A variable). When I say that the character data is CCSID 5035 (Japanese, also works for CCSID 5026), it says that the middle UCS-2 character is x'7aef as you expect. When I say that the character data is CCSID 937 (Chinese), it says that the middle UCS-2 character is x'975e', which you say you sometimes get.

In v5r2, the character data is always assumed to be in the job CCSID. I think your problem must be related to the job CCSID.

     D RDL01_5035      S             10A   inz(x'0e424d48ef425d0f')
     D                                     ccsid(5035)
     D RDL01_937       S             10A   inz(x'0e424d48ef425d0f')
     D                                     ccsid(937)
     D ucs2            S              3C   ccsid(13488)
         ucs2 = RDL01_5035;
         ucs2 = RDL01_937;
         return;

My debug session, after each assignment to the ucs2 variable:

> EVAL ucs2:x
     00000     FF087AEF FF09
> EVAL ucs2:x
     00000     FF08975E FF09

[Barbara Morris]

David, you said the problem wasn't related to the job CCSID, but maybe you're changing the job CCSID too late. RPG figures out the job CCSID when the program starts for the first time, or after LR was on for the previous call.

Here's a program you can run in v5r2 (at least, I think it will run in v5r2) to test out the job CCSID question.

     D RDL01           S             10A   inz(x'0e424d48ef425d0f')
     D ucs2            S              3C   ccsid(13488)
      /free
         ucs2 = RDL01;
         if %subst(ucs2:2:1) = u'975e';
            dsply '975e chinese';
         elseif %subst(ucs2:2:1) = u'7aef';
            dsply '7a3f, japanese';
         else;
            dsply 'something else';
         endif;
         dsply '*inlr?' '' *inlr;
         return;

1. Do CHGJOB CCSID(37) and call the program. RPG will assume your character data is 937 due to an "oddity" where it assumes character data is in the mixed-CCSID related to the job CCSID. See CCSID(*CHAR:*JOBRUN) in the manual, http://www.ibm.com/support/knowledge...hccsidchar.htm. It would behave the same if you explicitly change the job CCSID to CCSID 937.
2. Respond 0 to the *INLR question. RPG won't fetch the job CCSID for the next call because it ends with LR off.
3. Do CHGJOB CCSID(5035) and call the program. It will display the same "chinese" result as before, because it doesn't fetch the job CCSID again.
4. Respond 1 to the *INLR question.
5. Call the program again. This time it will display the "japanese" result, because it fetched the job CCSID again due to LR on, so it uses CCSID 5035 for the character data.