View previous topic :: View next topic
|
Author |
Message |
r.ravikumar
New User
Joined: 05 Jan 2007 Posts: 18 Location: chennai
|
|
|
|
How to convert a file in ASCII format to Binary Format.
My input is an HFS file in ASCII format. To copy the HFS file to an flat file in binary format, I used the IKJEFT01 with the below control cards, but the records are appending in the output file.
OCOPY INDD(DSNHFS) OUTDD(DSNMVS) BINARY
DSNHFS - Input HFS file
DSNMVS - Target flat file |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Terminology is a continuing problem on this forum ... your statement
Quote: |
How to convert a file in ASCII format to Binary Format. |
is absolute garbage. ALL files are binary -- there's nothing but ones and zeroes if you go down far enough.
OCOPY may work in text mode or binary mode -- but mode has nothing to do with file format; it controls whether or not newline characters are considered record delimiters or not.
Usage note 4 of the OCOPY command in the Unix System Services Command Reference manual states
Quote: |
When you are copying into an existing file, data is appended to the end of the file if OAPPEND is specified in PATHOPTS. Otherwise, the existing file is overwritten. |
so fix your DD statement and the appending problem will go away. |
|
Back to top |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007 Posts: 562 Location: Iowa, USA
|
|
|
|
My understanding is that data in an MVS HFS file is EBCDIC format, not ASCII. No conversion needed. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Bill, you raise a good point.
Ravi kumar.R: where did the file come from? How do you know it is ASCII? Why are you placing an ASCII file on the system when it will not make sense to edit, browse, or even read it? I think we need some details about your process and what you're trying to accomplish. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Also, this is the second topic from the same OP that mentions the dataset being "appended" without really qualifying what that means. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
And Ravi has not answered the questions asked in the other topic. . .
It sounds like the requirement is not understood and the tools available to do what is needed are not understood.
It is very difficult for us to help when the poster does not properly post the requirement or the actual problem(s) encountered. . . |
|
Back to top |
|
|
r.ravikumar
New User
Joined: 05 Jan 2007 Posts: 18 Location: chennai
|
|
|
|
My requirement is to perform SFTP from client server to MVS. The records in Client server are in EBCDIC format. So I performed SFTP to copy the records in file to HFS file in ASCII format.Then i copied the records from HFS file to flat file with records format as binary by using below OCOPY option.
OCOPY INDD(DSNHFS) OUTDD(DSNMVS) BINARY |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
The records in Client server are in EBCDIC format. |
What client/server is being used that has ebcdic data?
Quote: |
copy the records in file to HFS file in ASCII format |
What reason was there for doing this?
We send and receive files multiple times a day and do not have a need to jump thru hoops like this.
Why can you not simply send the data to the mainframe? Why is there this flip/flopping between ebcdic/ascii? I realize that my experience is limited to only several thousand files of a variety of style and content and have NEVER needed to do anything like this. . . |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Your process seems pretty flawed from the start. If you're sure the file on the client server is EBCDIC (and the only machines I know of that put out EBCDIC by default are z/Architecture boxes -- Unix and Windows boxes put out ASCII by default), transfer the file in binary to the mainframe and you don't have a single EBCDIC/ASCII conversion to worry about.
Further, converting to ASCII is a wasted step -- z/OS will require the file to be in EBCDIC for pretty much anything you want to do with it, so why bother converting it?
Third, if you're transferring to a Unix System Services file, use the iconv command in USS to convert the file (if you absolutely have to convert it), so you're not having to worry about transfers AND conversions at the same time. Simplify the process by doing one thing at a time -- it might take more steps but usually runs quicker that way. |
|
Back to top |
|
|
|