Re: Converting to upper case

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

-------------------------- Original Message --------------------------
Dan,

The problem is not so much A-Z and a-z but that there are a whole lot
more letters than just a-z.  Latin small letter a grave should, for
instance, become Latin capital letter A with grave; Greek small letter
sigma a Greek capital letter sigma; Cyrillic small letter fita a
Cyrillic capital letter fita, etc.  Users outside of the United States
might not care for a routine that only handled the basic a-z...  These
other characters do exist in various code pages and should be correctly
cased.

And, yes, there are also straight code page problems with a-z.  In Japan
code page 290 has lower case a-z at different code points than that
found in most languages.  A XLATE done in an "English" RPG program
would cause Katakana characters to become A-Z and leave the CP 290 a-z
untouched.  Perhaps carrying it to an extreme, but XLATE using ASCII
input won't fly too well either.  Note that when I say XLATE I am
refering to XLATE using a fixed conversion mapping approach.  Obviously
XLATE could use dozens of different mapping tables based on the code
page in use; but then why not just use the Convert Case API and not
have to build all those mapping tables?

Bruce

>
>David, thanks for the reply!
>
>It seems to me that you can't get much more centralized than just using the
>XLATE opcode.
>
>What problems with the code page?  Do not the letters A-Z & a-z all translate
>the same way regardless of code page?  And if not, XLATE can't handle that
 but
>an API can?  Scary thought.  If you need a procedure to correct problems
>associated with code pages, don't you still have a problem with constants
>defined in the application?
>
>I know you were just using the code page as an example, but I'm hard pressed
>to think of another example where a straight "upper" or "lower" procedure
>would offer more flexibility over XLATE.
>
>It just seems to me that you're trying to fix a problem before one actually
>exists.
>
>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
+---