More curiousity questions.

Discussion of the Co:Z Toolkit Dataset Pipes utilities
Post Reply
Posts: 39
Joined: Sat Nov 21, 2009 2:59 pm

More curiousity questions.

Post 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!
Site Admin
Posts: 2006
Joined: Thu Jul 29, 2004 12:12 pm

Post 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.
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

Post 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.
Post Reply