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

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


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

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


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
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

In CCSID(37) , the pipe symbol is X'4F', but in CCSID(500) the pipe
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
*TCAT, or *CAT instead of the symbolic representations |<, |>, or || to
around the character translation issues having to do with variant
characters, but I am stumped on how to handle this problem.

- sjl

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page