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!
More curiousity questions.
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.
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.
-
john.mckown
- Posts: 48
- Joined: Tue Jun 12, 2007 2:46 pm
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.