× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.