: Thursday, March 19, 2015 12:26 PM
Subject: Re: CR on records using OCOPY converting from ASCII to EBCDIC
On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin wrote:
We FTP a zip file from a vendor as binary to a z/OS Unix file. ...
...
Besides editing the file and removing the CR, is there a way
[mailto:paulgboul...@aim.com]
Sent: Thursday, March 19, 2015 12:26 PM
Subject: Re: CR on records using OCOPY converting from ASCII to EBCDIC
On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin wrote:
We FTP a zip file from a vendor as binary to a z/OS Unix file. ...
...
Besides editing the file
We FTP a zip file from a vendor as binary to a z/OS Unix file. We then expand
the zip file using the JAR command:
jar xf input.zip
Since the members were zipped as ASCII, the unzipped members in the z/OS Unix
file are also ASCII. Reviewing the unzipped members shows that each record ends
On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin wrote:
We FTP a zip file from a vendor as binary to a z/OS Unix file. ...
...
Besides editing the file and removing the CR, is there a way to prevent the CR
from being written to the z/OS data set during the translation?
From the man page of
On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin wrote:
We FTP a zip file from a vendor as binary to a z/OS Unix file. We then expand
the zip file using the JAR command:
jar xf input.zip
Since the members were zipped as ASCII, the unzipped members in the z/OS Unix
file are also ASCII.
Look at the OCOPY in Z/Os Unix services there is a parameter to fix CRLF
On Thursday, March 19, 2015, Kevin Landin klan...@central-insurance.com
wrote:
We FTP a zip file from a vendor as binary to a z/OS Unix file. We then
expand the zip file using the JAR command:
jar xf input.zip
