|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.