RE: Character set conversoin headaches
- From: Clarence.Taylor@xxxxxxxxxxxx (Taylor, Clarence B)
- Date: 27 Jun 2006 09:07:35 -0700
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:IBM-MAIN@xxxxxxxxxxxx
Behalf Of Bill Godfrey
Sent: Monday, June 26, 2006 11:09 PM
To: IBM-MAIN@xxxxxxxxxxx
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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: Character set conversoin headaches
- From: Kirk Wolf
- Re: Character set conversoin headaches
- References:
- Re: Character set conversoin headaches
- From: Bill Godfrey
- Re: Character set conversoin headaches
- Prev by Date: Re: Cutting bloated VSAMs down to size...
- Next by Date: 9037 Syspex timer withdrawn 31 Dec. 2006
- Previous by thread: Re: Character set conversoin headaches
- Next by thread: Re: Character set conversoin headaches
- Index(es):
Relevant Pages
|
