Re: Java - EBCDIC - Unicode - RPG - all wrapped into one...

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Mike Cunningham wrote:

> An article in the October issue of SystemiNetwork said that when a
> java app accesses a DB2 character field the string must be converted
> from single-byte EBCDIC to double-byte Unicode.

Someone will correct me if I'm wrong, but...   I believe that Java uses 
UTF-8 (mixed-byte Unicode) natively.   That means that anytime it reads 
a database, the data must be converted from whatever's in the database 
to UTF-8.

This seems like common-sense to me.  If you didn't do this, your data 
would appear as garbage in the Java program.

> prevent the overhead associated with this conversion is to define
> character fields as GRAPHIC/VARGRAPHIC using a CCSID for
> UTF-16/UTF-8/UCS-2.  

It'd make sense that no conversion would be necessary for UTF-8.  But I 
don't know if I follow the bit about UTF-16/UCS-2.  I suppose the 
conversion would be EASIER when going from UTF-16 to UTF-8, but it still 
has to be done...


> It did not mention anything about RPG accessing
> DB2 fields defined as GRAPHIC and if it needed to convert it from
> double byte to single byte. Does any know if RPG needs to do this?

Depends. ILE RPG natively supports both EBCDIC and double-byte Unicode 
(UCS-2 and UTF-16). But does not natively support UTF-8 (which is 
mixed-byte).

HOWEVER...   most likely your RPG program is accessing other devices 
(such as 5250 displays or spooled files) that require EBCDIC and will 
not work with Unicode.  Therefore, the RPG program will ultimately have 
to convert the data to EBCDIC.

If the majority of your processing will require EBCDIC (which is what it 
sounds like) then you'll see a performance decrease by converting your 
databases to Unicode.

Keep in mind that this isn't really about the language you write your 
code in.  It's very simple.... does the data need to be translated?  Or 
not?   Not translating is obviously faster, because no work has to be done.