Well, I don't have my "green card" with me at the moment, but IIRC 3F is the EBCDIC SUB character, which means mapping it to ASCII 1A is correct. EBCDIC 41 I think is "hard space" or something like that, and classic 7-bit ASCII does not support such a character, so there is no way for EBCDIC 41 to "round trip" through classic 7-bit ASCII (which is what I believe CCSID 1208 is, no?). Now if you are transferring through ISO8879 (Latin-1) or UTF-8 instead, there may be a code point in one of those CCSID's that maps to "hard space". I don't have time for the necessary code point research at the moment, but you may want to look into those CCSID's as an alternative to CCSID 1208.
HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Tuesday, June 12, 2012 1:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Anyone a Unicode Services expert? -- roundtrip conversion Thanks, Peter. Please understand I am not criticizing or faulting z/OS Unicode Services. I am just trying to explain to a customer the output they may expect to see when they use our product that in turn uses Unicode Services (USS? -- LOL -- never mind). Let's leave PCs out of it. If I were going z/OS to z/OS to z/OS, how could both 3F and 41 make the round trip successfully? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Farley, Peter x23353 Sent: Tuesday, June 12, 2012 9:04 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Anyone a Unicode Services expert? -- roundtrip conversion I believe that slide refers to "round trips" within the z/OS world only. There is no statement that CCSID conversion by a system other than z/OS (such as the PC ftp client in your example) will be covered in the 'round trip" guarantee. You have to be transmitting and receiving with the same or a very compatible iconv() instance to be able to make such a guarantee. It's remotely possible that transmission to a linux ftp client with an iconv() that is compatible with the z/OS iconv() *might* support such a guarantee (e.g., z/Linux), but I wouldn't bet on it. And Win systems are almost guaranteed NOT to support such a guarantee. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Tuesday, June 12, 2012 11:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Anyone a Unicode Services expert? -- roundtrip conversion Well, Peter, that's certainly consistent with what I see. I'm looking, however, at slide 11 of http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp?topic=/c om.ibm.iea.zos/zos/1.9/IntegratingNewAppOnzOS/zOSV1R9_Integrating_newAppl_LE UnicodeServices/player.html . (You may have to unfold that URL.) It says "R - Roundtrip conversion. Roundtrip conversions between two CCSIDs assure that all characters making the roundtrip arrive as they were originally." How is that going to be accomplished if both 3F and 41 translate to 1A? How will they make the round trip back to what they were? What does technique R mean? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
