Converting to upper case

Dan,

Well as Jon pointed out in an earlier note, you might be exposed on
casing even now as French (and the non a-z letters) may be part of
current customer/company names and the use of XLATE and just a-z mapping
would leave possibly unintended results (namely only partial casing).

You do have one advantage with your current environment; namely that
Canada, England, and the United States all use the same character set
(697) and so code page/CCSID conversions "at the door" wouldn't lose
any data assuming you normalize to CCSID 37 when data enters your local
system. And depending on the code pages being used on the various systems
you may even have the same code points for the "other letters" as CCSIDs
37 (USA/Canada), 285 (United Kingdom), and 500 (Multinational and the
default for the Canadian French National Language Version of OS/400) all
appear (disclaimer: I just did a brief scan of the CCSIDs) to assign
the "other letters" the same; so you could just expand your XLATE
constant to include the "other letters" and run the same code on all
of your current systems.

If however your management decided they would like to expand into say
Germany and code page/CCSID 273 then you may need to customize the
tables as, for example, 273 assigns the left curly bracket to x'43'
where 37, 285, and 500 assign latin small letter a with diaersis.  Using
the "enhanced" table would then cause the left curly bracket to be
"uppercased" to a left square bracket while leaving the 273 latin small
letter a with diaersis (x'C0) unchanged (as opposed to being converted to
x'4A' (latin capital letter A with diaersis)).  Expansion into a
non-Latin 1 based language (Greek, Cyrillic, Arabic, etc.) will just be
more changes being required.  (A minor note, my German example can
also be worked around by using CCSID 500 rather than 273; but the
non-Latin 1 examples do not have as easy of work arounds)

Is this important enough to worry about now?  I believe it is as I have
run into more situations than I care to recall where upper management
has decided to expand into another geography and expect to be able to
run their existing software in the new geography.  Building in
assumptions like only a-z as part of a users alphabet just makes such
a business change that more difficult (though I will be the first to
point out that there are a whole lot of other considerations above and
beyond proper casing -- but so long as we are discussing how to approach
casing I would just prefer to do it from a global perspective first time
out).

As for your program comparision/key, you are safe in that latin capital
letter A is invariant across all current (and most likely future)
EBCDIC code pages/CCSIDs.  Use small letter a and you run into the
290 Japanese problems I mentioned earlier.  Change the 'A' to a numeric
pound sign, a US dollar sign, a commercial at sign, a cent sign, or a
long list of other characters; and you can have problems due to the
variance across many code pages/CCSIDs.  This is one of the reasons
I hate seeing so many code examples use the dollar sign, numeric pound
sign, and commercial at sign in source and object names as this can
make things decidedly more difficult to use in some scenarios.

Hope this helps,
Bruce

>
>I know that we need to think "global" these days, but for those of us who work
>in "isolated" environments, is this really necessary?  By isolated, I mean...
>well, I'm not sure exactly what I intended to mean.  Our environment consists
>of several AS/400s spread across the U.S., one in Canada, and one in England.
>Our AS/400 "talks" to an IBM mainframe and a Unix-Oracle box.  To my (limited)
>knowledge, all the code page stuff is done at the "door", that is, at FTP
>time.  (We do not, for example, have any users in Japan [to use your example]
>providing data that enters our AS/400.)  We have not had any issues related to
>code page errors.  At what point do we need to consider them, in our
>environment?
>
>Also, the upper/lower translation API aside, how does the code page affect
>constants used in programs?  Or select/omit constants in logical files?  Does
>the following simplistic scenario present a problem?
>
>Pgm A snippet:
>     C                     MOVE 'A'       ODSTS
>     C                     UPDATORDDTL
>
>Pgm B snippet:
>     C           KEY       CHAINORDDTL               99
>     C           ODSTS     IFEQ 'A'
>
>If Pgm A is compiled on a system with a different code page than the system
>used to compile Pgm B, and the 'A' character has a different hexidecimal value
>(is that the essence of code page problems?), is this a situation where we get
>hosed?
>
>Dan Bale
>IT - AS/400
>Handleman Company
>248-362-4400  Ext. 4952
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---