SEO

Hey all,

I am working on a project that involves zipping up text files on
Solaris 9 using Zip 2.3 and sending them over to an OS/390. I don't
work on the 390 so all the information I get is from a third party.

Anyway they are telling me that once they get the file we zip up they
cannot open it. They are using a utility called InfoZip and it claims
it is not a valid zip file. My first response was to ask them to try
another unzip, so they took the file off their 390 and tried Winzip;
same errors.

I wondered if maybe there was a problem with the transfer, so I copied
a zip over to the 390 then back to the Solaris box. I was able to
unzip it with no problems. Then I pulled it down to a Win desktop and
used Winzip; still all good. But if they email me back the same zip
file that I was able to unzip before they got a hold of it, I can't
unzip it either.

Am I missing something simple here? I ran a chksum on the file before
I transferred it and after and the numbers are identical.

Anyone have experience with Solaris - 390 and how each handles zip
files?

tonij67@hotmail.com wrote:
> Hey all,
>
> I am working on a project that involves zipping up text files on
> Solaris 9 using Zip 2.3 and sending them over to an OS/390. I don't
> work on the 390 so all the information I get is from a third party.
>
> Anyway they are telling me that once they get the file we zip up they
> cannot open it. They are using a utility called InfoZip and it claims
> it is not a valid zip file. My first response was to ask them to try
> another unzip, so they took the file off their 390 and tried Winzip;
> same errors.
>
> I wondered if maybe there was a problem with the transfer, so I copied
> a zip over to the 390 then back to the Solaris box. I was able to
> unzip it with no problems. Then I pulled it down to a Win desktop and
> used Winzip; still all good. But if they email me back the same zip
> file that I was able to unzip before they got a hold of it, I can't
> unzip it either.
>
> Am I missing something simple here? I ran a chksum on the file before
> I transferred it and after and the numbers are identical.
>
> Anyone have experience with Solaris - 390 and how each handles zip
> files?
>
Although I have no direct experience with the setup you describe I do
have a suggestion. Since you've tested copying to the 390 and back, but
the problem files were emailed, I'd suggested looking into the
possibility of your mail exchanger and/or antivirus program mangling the
files.

Can you zip and copy, not email, to a location the 3rd party can test?
Also, if they are using Outlook to receive mail be aware that Outlook
often blocks or otherwise interferes with .zip files.

<tonij67@hotmail.com> wrote in message
news:1132671066.320102.227520@g43g2000cwa.googlegr oups.com...

> I wondered if maybe there was a problem with the transfer, so I copied
> a zip over to the 390 then back to the Solaris box. I was able to
> unzip it with no problems.

If you were using something like FTP, but in ASCII mode, it could easily
corrupt the file on the way to the 390, and fix it on the way back.

What FTP might do is change all of the LF characters (ascii 10) to CR/LF,
which would ruin the file. But on the way back, it could easily change CR/LF
to simply CR and things would be just fine.

I suggest you compare file sizes and if possible get a MD5 checksum on both
sides of the transfer to see if they do indeed match or not.

Regards,

Will Hartung

Thanks all,

KJ:

The file is unusable to the recieving end after they transfer it using
ftp, not email. The email example was just to see what the file looks
like after we send it to them. i.e., we send file, they download it,
cant open it, then email it to us and we can't open it either.
I told them to make sure they are using binary to FTP it so I have to
trust that they are. I dont have any control over the file once it
hits their system.

Will Hartung:

I did do a checksum; while the file was on the Sun box and after it was
transfered over to the 390. The numbers are identical.

I guarantee you they are not using binary mode


tonij67@hotmail.com wrote:
> Thanks all,
>
> KJ:
>
> The file is unusable to the recieving end after they transfer it using
> ftp, not email. The email example was just to see what the file looks
> like after we send it to them. i.e., we send file, they download it,
> cant open it, then email it to us and we can't open it either.
> I told them to make sure they are using binary to FTP it so I have to
> trust that they are. I dont have any control over the file once it
> hits their system.
>
> Will Hartung:
>
> I did do a checksum; while the file was on the Sun box and after it was
> transfered over to the 390. The numbers are identical.

You are pretty sure they are using ASCII? I have suspected this as
well but I can't prove it

Something else I just thought of...we are using scp to copy the file
from Solaris to 390.

I checked the scp man page but couldnt determine; does scp default to
binary or ASCII mode? Using OpenSSH_3.9p1

tonij67@hotmail.com wrote:
> Something else I just thought of...we are using scp to copy the file
> from Solaris to 390.
>
> I checked the scp man page but couldnt determine; does scp default to
> binary or ASCII mode? Using OpenSSH_3.9p1

As far as I know, scp doesn't even *have* an ASCII mode. Which is nice,
since it avoids the mistake of being in the wrong mode. :-)

- Logan