Page 1 of 1

More curiousity questions.

Posted: Sun Dec 12, 2010 8:03 pm
by JohnMcKown
I am now curious about why the "fromdsn" and "todsn" commands for non-z/OS exist (along with the dspipes subsystem). They are not really needed. I have found that I can run the z/OS versions and get the results back to my Linux desktop via:

ssh userid@zos fromdsn ...

instead of:

fromdsn ...

Likewise with todsn. Well, I do need to include the entire path to the executable unless there is a symlink in /bin.

Now, I will grant that having fromdsn and todsn as local commands is convenient. So if that is the reason, how about an enhancement so that I can also have catscan, pdsdir, and the other commands as local so that they are also easier to use? Just a thought. I have a Linux shell script which I wrote which makes things easier for me, so I don't really need them.

And I am grateful to Dovetailed Technologies for developing these and making them freely available. And especially the enhanced sftp server!

Posted: Mon Dec 13, 2010 10:01 am
by dovetail
If you use:

ssh userid@zos fromdsn

The IBM Ported Tools sshd server with *always* translate the input and output of your commands ISO8859-1<->IBM1047. So for simple things it will work, but fail when you need a clean binary channel. The dspipe subsystem is the solution to this problem, since ssh subsystems are left alone by the IBM sshd server.

BTW: when you use an ssh subsystem, even though the channels are binary, you don't get a stderr channel. So, the dspipes subsystem muxes stdout/stderr.

The fromdsn/todsn client commands are just special versions of the cozclient client command, which is the client part of the dspipes subsystem.

Posted: Mon Dec 13, 2010 4:11 pm
by john.mckown
Ah. So if I ever had a need to pipe binary type data from a z/OS UNIX command back to Linux, then I'd need a ssh subsystem of some type. I don't like piping binary data. I prefer only using "printable" data. But I can see where it is needed in some cases, such as for SMF data or other data that the user doesn't want to "post process" on the z to something transportable via printable characters. In my case, I might decide to UUENCODE my data for transport. Or "escape" it in some manner.