Re: Globalization question -- MIDRANGE-L

Hey, thanks for the grand chuckle on a Friday morn!

Now just be glad you're not going along with me and some high-school friends to the S*p*a*m museum today!!

On 8/31/2012 7:55 AM, Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:

"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