Re: Hex translation

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hi Åke,

I agree with Vern.  The system doesn't really use tables anymore, it 
uses a CCSID translation.  Tables are still there, of course, for 
backward compatibility... (and I guess they might be used somewhere 
under the covers?)  But programmers doing translation (including those 
at IBM who write the database functionality) don't need work with 
tables, they just call the iconv() API and specify the from/to CCSID values.

The system automatically figures out how to get from one CCSID to 
another (even if there isn't a specific table) and makes the conversion...

On 2/21/2012 4:39 AM, Åke Olsson wrote:
> We have the following:
>
> A Physical file (customer file) which has CCSID = 37 A user (in
> Poland) which has CCSID = 870 and a client-access host code page also
> set as 870.
>
> What we see is that a specific character in a name field is stored as
> X'69' in the database but when the user program retrieves it is
> translated to X'72'. Same thing other way - when the user writes a
> X'72' character it is stored in the database as X'69'
>
> In many ways this makes sense the char the user sees and keys is a
> capital "E" with some accents underneath. What is slightly
> frustrating is that I cannot find a table that describes the rules
> for the translation. Is there one anywhere? I would need something
> along the lines:
>
> CCSID-37 hex code                    translated to CCSID-870 hex code