|
Michael, Welcome to the brain-bending world of NLS! Firstly, you should keep the system code page as US (037) if you are in the US. The AS/400 translates the characters according to the code page tables in QUSRSYS (for example Q857A7AA3S is Windows 857 to Turkish 1026). Sometimes you have to modify these tables to get the results you expect! (To do this you have to use crttbl and copy an existing one.) If you have no PCs involved, things normally work OKish - but most people have PCs with client access rather than twinax terminals these days. You need to know that not all the bits of software involved work the same way. For example what you see on a client access screen using DFU may not be what you see using PDM which may not be what you see using DSPPFM! Fun, isn't it? And many PC softwares don't know about code pages at all - for example FTP and ODBC. So you need to start with what you want to achieve - who needs to see what? If you have users in Germany passing through to your system, they may see the umlauts when you do not for example. Obviously you need to test the solution to make sure it works for them. not for you. And if you have third party developers, what code page are they developing and compiling under? There are different levels where you can specify code page - system, display and file for example. To be absolutely sure about what is going on, you need to look at the Hex representation of each character. In the NLS manuals (probably on the net these days) you should be able to find graphic representations of each code page. You will see that for example Hex C0 in the UK (285) code page is a left curly bracket. However, Hex C0 on the France (297) code page is lower-case e with an acute accent. So if a character is displayed as left curly bracket on a system in the UK, It should display as e acute in France, given that all the other variables are in agreement! (Don't forget printers too...) The German code page is 273, and upper case U Umlaut is Hex 5A, which in the US code page (037) is exclamation mark. But of course, it's not that simple, because you may be doing a 2-way double pass translation (code page to code page and EBCDIC to ASCII both from and to the AS/400), and that can really garble the results, just like the German Enigma machine did with codes in the war! It's quite tricky to work out then what the original needs to be to achieve the desired result. And keep in mind that different versions of Dos/Windows use different ASCII translation tables, and there are also some new ones in Europe since 'Eastern Europe' was welcomed back into the fold. The real problem is that neither EBCDIC nor ASCII (which has fewer characters available than EBCDIC even) are big enough to support all the possible characters. The only solution is Unicode, when each character will be a double byte instead of a single byte, and we will be able to have all the different ones on one code page. Good luck, Clare Clare Holtham Director, Small Blue Ltd - Archiving for BPCS IBM Certified AS/400 Systems Professional E-Mail: Clare.Holtham@btinternet.com Mobile: +44 (0)7960 665958 ----- Original Message ----- From: <Mlpolutta@aol.com> To: <midrange-l@midrange.com> Sent: Monday, July 15, 2002 6:38 PM Subject: How to display German "extra" characters Folks, What code page do I use to display umlauts and other fun German things? We are changing our system to use MSGF entries for all "literals" in our display files so we can "easily" have multiple-language support. We have our first round of data back from the translators. However, some characters did not map according to expecatations - the umlaut became the 3/4 symbol, for instance. Thanks for your help! Michael Polutta Atlanta, GA _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.
midrange.com
