Thanx to Bill Godfrey, the tr -d did the trick. I am sorry about the confusion, I made a mistake in my initial analysis in that an ascii file with 0A0D that is FTP'd in ASCII mode is changed to a single x'15', thanx to Paul Gilmartin for pointing that out. I also said that after transferring I wanted to convert to ASCII, what I meant was I wanted to convert to EBCDIC. I tend to think of files as either being binary or text and when I said ASCII I was thinking text, and of course on USS text is EBCDIC. I can see how my internal confusion became manifest.
What I want and now seems to work is a way to package up an entire directory structure and its files on a PC, transmit them to uss via ftp, and then restore that structure at the desired mount point. Perhaps a better set of tools on the PC side would be of benefit. I am currently using ANT and ECLIPSE to construct a JAR file, which I FTP to USS in binary mode. I then use JAR -xf to unjar the ftp'd file, but all of the "text" files are still ascii. So I wanted to convert the ascii to EBCDIC. This ICONV did for me. What I did not realize is that FTP in ASCII mode converted the two character sequence to a one character sequence. So if anyone has some suggestions in how to move directory structures around. I have the same problem when downloading open source from the net. If it is in tar.gz format unix recognizes it fairly easily and the latest pkzip recognizes it (used to not to). It appears that providers, usually provide two formats for downloading, a tar.gz and a .zip file, sometimes a self extracting zip file, via .exe. Ideally I would like to produce just a single archive that any target system could just unpackage, without all of these conversion issues. Brad Taylor -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Godfrey Sent: Monday, June 26, 2006 11:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Character set conversoin headaches Text files in Unix System Services are supposed to have hex '15' as newline characters. If you want to translate an ASCII file with CRLF hex '0d0a' newlines to EBCDIC, you want the output file to have hex '15', not '0d0a' or '0d15', so you should delete the '0d' before or after the iconv. This command will delete ALL hex '0d' characters: tr -d '\015' <infile >outfile The \015 is octal notation, equivalent to hex '0d'. I don't understand why you would want an EBCDIC file with CRLF as newline, but if that's really what you want, you can translate the hex '0d15' back to '0d0a' with this command: tr '\025' '\012' <infile >outfile which translates ALL hex '15' to hex '0a'. Your description is confusing to me. You talk about converting to ASCII, but then you use a command that converts to EBCDIC. Where and how does converting to ASCII get involved here? Bill Godfrey ---------------------------------------------------------------------- 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
