Re: Globalization question

[Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx]

"So replace all character literals with variables, then populate those 
variables from some external data thingy."

I now have a new technical term "external data thingy"!!! Thanks for 
sharing!!!


Thanks,
Tommy Holden



From:   Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>, 
Date:   08/30/2012 06:01 PM
Subject:        Re: Globalization question
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



Steve

Almost anything that is a literal in your code will NOT be converted. As 
David said, you need to pull these values in either from a CCSID-tagged 
physical file or a message file. Message descriptions can have a CCSID 
on them, that makes it all just work.

So replace all character literals with variables, then populate those 
variables from some external data thingy.

Now Unicode can get interesting - albeit still pretty well-managed if 
you follow the above guidelines.

IBM has handled globalization with messages files from the beginning - 
all that text on screens comes from message files a lot. And there is 
this OVRMSGF command that can help, or just have the library list do it 
- so there's a QSYS2927 (just making up a number) for some language 
other than US English, and that will precede QSYS on a dual language 
machine.

It's magical once you get away from character literals in your source.

One idea I have is to use a data structure with all the character values 
you need - then populate it from a message description or a physical 
file field.

So far as I know, there's no tagging by CCSID on user spaces or data 
areas.

HTH
Vern

On 8/30/2012 3:09 PM, sjl wrote:
> I have several RPG programs which are being deployed via Implementer to
> several different LPAR's being used by different world areas, one of 
which
> is for Europe.
>
> The source files are  all defined with CCSID(37), but the European
> environment is using CCSID(500).
>
> How do I deal with the variant character | (the pipe symbol) across 
these
> environments:
>
> In CCSID(37) , the pipe symbol is X'4F', but in CCSID(500) the pipe 
symbol
> is X'BB'
>
> for example, in a program I have:
>
> Delimiter = '|';
>
> which works fine in the CCSID(37) environments, but on the CCSID(500)
> environment it it appears as a ! (exclamation point) since X'4F' in
> CCSID(500) is the exclamation point.
>
> I know, for example, that in CL programs that the solution is to use 
*BCAT,
> *TCAT, or *CAT instead of the symbolic representations |<, |>, or || to 
get
> around the character translation issues having to do with variant
> characters, but I am stumped on how to handle this problem.
>
> - sjl