Thank you I did not see that, but obviously you are correct and recognized the culprit. This is a major breakthrough now!
Actually, wc3270 (and my mainframe IND$FILE) deal with the situation correctly (I might have implied otherwise, but I've now conducted few more tests) and recognizes extended ASCII. It is the FTP configuration, whatever my user is using that deal with 7 bit ASCII only and thus causes the problem. So now that I know what have caused the issue, I can either guide the user (or users) to ask their administrator to configure the transfer for ISO 8859-1 rather than "ASCII". Or, if they do not have any influence on the administrator to try the other two methods. Ze'ev Atlas ________________________________ From: Paul Gilmartin <[email protected]> To: [email protected] Sent: Sunday, December 9, 2012 12:55 AM Subject: Re: How to load logical load x'ac' On Sat, 8 Dec 2012 20:31:40 -0800, Ze'ev Atlas wrote: >I'll qualify, x'ac' is an extended ascii for logical not > http://www.ascii-code.com > That page confirms what the ever-so-pedantic Shmuel asserts: ASCII is a 7-bit code, and, The extended ASCII codes (character code 128-255) There are several different variations of the 8-bit ASCII table. ... >In any case, I expect circumflex (x'5e') �to translate into logical not or >circumflex, not to the meaningless comma (x'6b'), which is unfortunately what >I get. �It seems that there are at least two flavors of the conversion while >ftping. �One translates logical not correctly to either circumflex or to >logical not (which I can deal with easily). �The other flavor of ftp >conversion, prefers to translate it to comma. >According to > http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/reference/html/hcp_reference27.htm The solution would to use that flavor of FTP which "... translates logical not correctly to either circumflex or to logical not ..." It appears that whatever process you're using takes the narrow 7-bit view of ASCII and ignores the high order bit of x'AC", regarding it as x'2C' and translates that value correctly to comma. I can't tell whether the problem is in your wc3270 server (would that be IND$FILE?), in which case you may need to have your administrator configure it for ISO 8859-1 rather than "ASCII" or in your desktop, in which case you need to perform a similar operation there. Alternatively, if wc3270 supports it, transfer the file in BINARY, then on z/OS use either "dd" or "iconv -f ISO8859-1 -t IBM-1047" to convert to EBCDIC. Yet another possibility if you have FTP on z/OS is to work entirely on z/OS with the binary file and do: FTP localhost user password BINARY QUOTE TYPE A PUT ascii.file EBCDIC.FILE QUIT -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
