Re: Processing Multilanguage Data with YAJL, RPG and a PF

On 6/10/2016 3:48 PM, Bradley Stone wrote:

Ok, so I set up the field with CCSID 1208 in the DDS. I didn't specify the
*NORMALIZE option. From what I understand, this will fix any
non-corresponding hex values to the closest match available?
...
We shall see if this will help. But I'm wondering if there are any RPG
D-Spec keywords one can use so that when data is read in from this field it
is automatically converted to the JOB's CCSID? Or is iConv (or another
conversion API) required?

Brad, what is your job CCSID? My understanding (and experience) is that CCSID 1208 data (and all other alphanumeric data) is converted to the job CCSID automatically by database unless the job CCSID is 65535. When the job CCSID is 65535, no alphanumeric data is converted to the job CCSID.

At least, that's true when RPG opens the file prior to 7.2, and by default from 7.2 on. Starting in 7.2, you can code DATA(*NOCVT) in your F spec to cause the file to be opened with no conversion to the job CCSID. You could also code OPENOPT(*NOCVTDATA) to have that be the default for all database files.

Also in 7.2, you could code DATA(*CVT) on your F spec, and ensure the program field matching your 1208 field is in the job CCSID. Then RPG would do a runtime check, and if the job CCSID was 65535, it would convert the 1208 data in the buffer to your field's job CCSID.

DATA(*CVT) is the default, but RPG needs some indication in the code that you want this new support. The old support wasn't necessarily correct, but we know that people coded workarounds that we can't break.

As long as you code the the DATA keyword on your file, or CCSID(*EXACT) in your H spec, or OPENOPT(*(no)CVTDATA) in your H spec, or the CCSID keyword on that field or its externally-described data structure, RPG will handle any necessary CCSID conversions when the record is read.