IBM Mainframe Forum

I have a client that is currently zipping up a set of files using the Unix zip command. When I try and unzip and load the files I get back some files that have AUTO CRLF=LF (as expected), but then some files have AUTO CRLF=N (not expected). When I look at the raw files with AUTO CRLF=N I can see the line feeds. Has anyone ever seen this before?

Hello and welcome to the forum,

Are these different files with different file transfer processes?

Suggest you look at the file transfer control statements.

Nope. This is just one zip file that contains 9 files. All but 2 of them have the correct AUTO CRLF. Could this be some unix zip flag that needs to be added? The party sending the file has asked if there is a way for them to identify the AUTO CRLF before sending using "standard unix" tools and I am not sure of the answer to this.

Hello,

The party sending the file has asked if there is a way for them to identify

Hopefully, they have a unix sysadmin that can answer this for their system. . .

Long ago (early/mid-90's), when i doubled between mainframe and unix (was a dba on the mainframe and dba/sysadmin on unix), we used the "compress" unix command (which was part of unix). There were other ways (i.e. pkzip) that were licensed products. I don't recall having a "zip" command available, but it may well have been added.

All but 2 of them have the correct AUTO CRLF.

This may be due to the way these files are created on the unix system rather than a compression or file transfer problem. We had an XD command that produced a hex dump of a file - if the output of the xd is piped to "more", it can be viewed on their screen. Possibly they can see the difference between a "good" file and one that is not working.