Dave, We are exactly on the same page here. I know this is difficult. To summarize:
- In data it matters what the character looks like. If I write Jäätelötötterö into a field then it needs to be the correct letters with matching hex values depending on the code page. (As John M. pointed out) - When it comes to, say, ISPF, it is the hex character that matters. For example if a member name needs a $-sign then doesn't matter what the character looks like, it must be x'5B'. - The exception to the above rule is in come compilers. They know which language they are in and so use the appropriate hex value so that the characters are correct. The hex value would change from language to language. Question: Which of the above is true and in what way (or, what changed and in what way) when we finally got ISPF to learn the code page from the emulator? (Which is stored in ZTERMCID). Here's what I think now. Absolutely nothing changed. Points 1 and 2 are still in effect. The _ONLY_ thing that changed is that ISPF knows the code page and ZTERMCID is filled in. ISPF itself doesn't do anything with that info. Sorry to beat this almost dead horse, but I'm so close now I really want to understand. Lindy -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Salt Sent: 11. heinäkuuta 2008 21:38 To: [email protected] Subject: Re: How to change the ISPF code page? > From: [EMAIL PROTECTED] > All this to say that I expect that when my emulator and ISPF are in sync that > with my emulator set to CP-278 Finnish that I could type $ (aka x'67') and it > would treat it as a $-sign even though the hex value is different from CP-37. Code pages give me a headache, but I think I know what's going on in the situation you describe and I'll try to explain it. In most cases, it is the 'appearance' of a character that's important and not what the underlying hex value is. For example, if a dollar amount is to be displayed on an ISPF panel the amount should be prefixed with a dollar sign. It should *not* be prefixed with an umlaut or square bracket or any other 'weird' character. Because the dollar sign might display differently on different code pages, the developer of the application has to make sure he doesn't simply hard-code a dollar sign to be displayed. Instead, he has to make sure the dollar sign is translated to whichever hex value causes a dollar sign to be displayed in different countries. In contrast to the above, it's the underlying hex value and *not* the appearance of characters that's important when it comes to 'national characters' that are used in data set and member names. For example, North America uses '@#$' as characters in data set and member names, but the appearance of these characters is not what's important. Instead, it's the underlying hex value that matters. For example, in code page 37 (North America), a dollar sign is hex '5B'. In code page 278 (Finland), a dollar sign is hex '67'. ISPF accepts hex '5B' as a character in a data set or member name, but does NOT accept hex '67'. Instead, if you want to create a member in Finland that uses hex '5B' you would have to enter the 'Å' character instead of the '$' character. In summary, your statement above is correct. When ISPF and your emulator are both using CP-278, the dollar sign is indeed treated as a dollar sign. But it just so happens that a dollar sign isn't a valid character to use in a member name if you're in Finland. I hope this helps? Dave Salt See the new SimpList(tm) rollover image at: http://www.mackinney.com/products/SIM/simplist.htm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
