Re: RPG CCSID conversion - help needed

Gad,

If you're still having a problem can you email me (directly):

1. The hex contents of the UTF-8 field containing Hebrew, English, German,
whatever
2. The definition (DDS or SQL) of the field the RPG program is reading from
(and containing the UTF-8 data)
3. The definition (DDS or SQL) of the field the RPG program is writing to

As to your questions, any character encoded in UTF-8 and not in 7-bit ASCII
requires two or more bytes. So your German Bibliothek would only require
one byte per character but your German Mädchen would require an extra byte
(two bytes for the small Latin letter a with diaeresis -- x'C3A4'). So some
Latin characters used by the German language will require two bytes, some
won't. Korean "characters" may need three or four bytes.

Bruce


On Wed, Apr 9, 2014 at 3:09 AM, Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hello Bruce

Job CCSID of RPG program is 424
Job CCSID of CPYF is 424 as well

CPYF does seem to work, i.e after CPYFing the (CCSID 1208) input file to a
all-424 file, English & Hebrew are displayed OK and other languages do not.
When doing the same with a RPG program and using debug to look at those
fields, English and Hebrew data looks garbeld meaning an intelligible
string of displayable characters and not just reverse image blocks.

RPG job CCSID is 424 so naturally I expected all Heb & Eng data to be
converted succsesfuly.

Oh, and another issue if I may, it looks like German takes 2 byte for each
character
and Korean 3 bytes per character, is it OK? should I use a different CCSID
(not 1208) ?


Thanks
Gad

date: Mon, 7 Apr 2014 16:39:30 -0500
from: Bruce Vining <bvining@xxxxxxxxxxxxxxx>
subject: Re: RPG CCSID conversion - help needed

Using RPG file IO data management will be converting the 1208 data to

your

job CCSID on input and from the job CCSID to 424 on output. If the job
CCSID is 65535 data management will be leaving the data as 1208 on input
and output. What is your job CCSID when running the RPG program?

Hopefully

some variant of 424.

By "gibberish" when using CPYF do you mean seeing totally different
characters? I would have expected (though have not used CPYF) to just get
subs (x'3F') for all the non-424 data (most likely just a lot of reverse
image blobs, not random characters/gibberish) -- but then my expectations
and reality do, at times, not line up and become learning opportunities

:)

Bruce Vining



On Mon, Apr 7, 2014 at 2:02 AM, Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hello pundits

We are using a home grown Java utility to upload (to the IBM i)

external

csv transactions report files where some of the fields are variable

length

multi multi lingual (English, German, Arabic, Korian, Hebrew, Japanese
etc..)
These fields (Name, Title..) are defined in the DDS with CCSID(1208).

the

file itself is
CCSID 424

Browsing the file using Access for Web the data look fine.

I CPYFed data from this file to another same-structure standard (CCSID

424)

file and it looks as if conversion to CCSID 424 works OK.
i.e English and Hebrew displays correctly on a green screen emulation
terminal and other languages looks "Gibberish"

Now, when using RPG to do the same, i.e reading the file and writing

to

another standard 424 file, conversion does not seems to work and all

data

looks garbled.

What am I missing? RPG compiler paramaters perhaps?

Being a code page illiterate I do need your help

Gad
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Regards,
Bruce
www.brucevining.com
www.powercl.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.