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

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.