Possible new use or ability

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

Possible new use or ability

Post by JohnMcKown »

I really like dspipes to get z/OS data to my Linux desktop. Makes things much easier. But I guess I have too much time on my hands right now. I like the fromdsn and todsn commands. What might be nice would be a C API in the form of a DLL or Shared Object so that I could write C (or Perl or Python or ...) code which could directly use the API to get data from or send data to z/OS. Yes, I do know how to do this in a general way using piping in those languages. Perhaps cozclient could be made into a dynamic library and that would then enable the fromdsn and todsn functionality in a more general way.

I was also wondering if dspipes itself could be extended to allow user written functionality for ssh communications. I don't have a good idea on this yet, but I was thinking that I need to transfer binary data between my desktop and z/OS via ssh. It might be nice to be able to write desktop code which uses the API to send requests to dspipes which would then invoke user code on z/OS, setting up a binary (or ascii) channel between the desktop app and the z/OS app.

Again, the above I __might__ be able to do myself. But I'm a tad lazy. <grin>
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Post by dovetail »

It seems like an interesting idea, but what functionality would you gain over invoking cozclient using spawn() or popen() ?
JohnMcKown
Posts: 39
Joined: Sat Nov 21, 2009 2:59 pm

Post by JohnMcKown »

I cannot really think of any enhanced functionality. Basically, it would just be a matter of efficiency. I wouldn't need to have another process and IPC to transfer data. It is not really a big deal. It was just an idle thought.

The dynamic call would save one process. From what I can tell, the cozclient actually forks() and does an "ssh -s dspipes" type command to do its communications. My background is from long ago where every machine cycle was precious and memory was a big issue. So I still have that extreme machine efficiency mindset in a day where programmers efficiency and productivity is more cost effective.

So, in reality, it would likely be better to think of new functionality than a bit more machine efficiency. And I can't think of anything missing in your product other than a way to cancel a job on the input queue or while in execution, and to purge the sysout. But that would be easy with a simple REXX program invoked via ssh itself.

If you like, feel free to distribute this code if you think it is worth while. No copyright on it. It's only three lines of obvious code, who would try to copyright that?

/* rexx */
parse arg parms
address tso "cancel "parms

put this in /bin (for ease of use) and issue the command:

ssh user@zos -c cancel "'jobname(jobid) purge'"

Note that I had to use both a " and a ' in order to escape the ( and ) from the ssh command on the desktop with the " and the z/OS shell. Otherwise you get a weird message (on Linux, I don't use Windows):

bash: syntax error near unexpected token `('

if you have neither or:

FSUM7332 syntax error: got (, expecting Newline

if you only use one set.
Post Reply