🚀 go-pugleaf

User1001 wrote:
> I don't have a precise technical answer for you but here are some
> observations that I can offer:

>
> 1) If the OS/390 SSH is "OpenSSH", it should be the IBM implementation
> that they fully support and not the "hacked research version" before it,
> which croaked on null (0x00) bytes

Is there a way I can verify this?  I am not too familiar with z/OS but
some familiar Unix commands seem to work:

$ uname -a
OS/390 DDC1 14.00 03 9672

$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

(Right off the bat I can see they are behind on SSH, I am using
OpenSSH_4.2p1 but I dont know if the same holds true for z/OS)

>
> 2) OS/390 (and z/OS, its successor) use EBCDIC not ASCII, so there is
> often a character set translation problem; from experience, I have found
> that files compressed in one character set don't always decompress
> (well) under another; I have to ungzip gzip'ed files in z/OS USS (Unix
> System Services) before I can download them with SCP or the target file
> winds up a soup of binary goulash
>

This looks interesting.  I have no control over what the z/OS system is
doing as far as unzipping.   What is this USS you mention?  I am told
they use something called InfoZip to uncompress our files (which are
created using Solaris zip.)


> Workaround: uncompress the file(s) before SCP'ing them to OS/390.
>
>
> On Fri, 24 Feb 2006 15:02:20 -0800, tonij67 wrote:
> [snip]
> > been having problems in that every time we send a ZIP file to this z/os
> > system, they are unable to decompress it.  i.e. its corrupted.
> [snip]
> > verison of SSH they are running and they told me that scp expects all
> > files to be text, so the only way for this to work is for us to use
> > sftp instead of scp.
> [snip]