Idea: DLL for Dataset Pipes, invoking from a user program.
Posted: Thu Jun 28, 2012 9:46 am
I am wonder what ya'll might think of this idea. Taking the functionality of the todsn and fromdsn and wrapping it in a DLL. I think this would make it easier to write an application which could use the functionality of todsn and fromdsn more easily than using a language facility to fork/spawn a new process to perform a like function. And, thinking about it, a DLL wrapping the lsjes functionality might be very helpful too. This might not be needed on z/OS itself. But I am thinking more of on a remote system.
As an example. I run Fedora (FC-17) on my desktop. It would be nice to set up an SSH connection to the z/OS UNIX environment (which I do using the ControlMaster, ControlPath, and ControlPersist parameters in the ~/.ssh/config file). I could then have a "full screen" application (QT or GTK+ or ???) on my Linux/Intel box which could do things such use the lsjes capability to display entries in the JES SPOOL. The user could then direct the application to "select" a particular job. This would cause the application to use the fromdsn DLL to read the SPOOL data down to the Linux system (perhaps storing it in a temp file, or maybe just memory) and then displaying it (perhaps using "less") or maybe even putting the data into an editor's (vim/gvim/emacs/...) buffer. This would be basically like doing an SE on the job in SDSF. The only thing missing from this scenario is a simple way for the user to cancel or purge the job's output (which I can envision a rather complicated way of doing, using my own code to run a REXX program on z/OS).
Another application might be to write an equivalent of ISPF option 3.4 on Linux which somehow does a catsearch on z/OS to get a list of datasets. Once it has this, it displays it. The could could then, like with ISPF 3.4, do a member list. From there use the fromdsn DLL to copy the member to do the equivalent of browse, view, or edit. If edit, then it would even be possible to use the todsn DLL to write the changed data back to the member, or dataset (if it was sequential). Thinking about it, perhaps even a DLL to delete a member. I do recognize the issue of dataset / member integrity due to lack of the ENQs used by ISPF so that two people don't edit the same dataset / member concurrently. Perhaps this could be handled similar to how vim does, perhaps by reading the current data, comparing it to the original (or checking an MD5 hash), and warning the use if it has changed.
I will grant that all of this can be done by using the host language's functions such as system() or fork() or spawn() to run the commands just as they would be on the command line. I guess that I consider using a DLL to be more "elegant". I'm not sure, but perhaps the "run the external" command would even be more general because not all languages (especially scripting languages like awk and Perl) can use a DLL. Hum.
If this is considered, then possible enhancements on the z/OS side would be a way to run arbitrary z/OS UNIX commands. As in the example thoughts above, in order to run the "catsearch" program and the REXX UNIX program to purge job output.
Having been educated a bit by what you've accomplished with your sftp server (which might be a way to purge that job now that I think of it), I might even try to write my own z/OS ssh subsystem code to do some of these things. Would be interesting just to try, even if I don't succeed.
Well, that's it for now for me. See ya'll on MVS-OE or IBM-MAIN perhaps.
As an example. I run Fedora (FC-17) on my desktop. It would be nice to set up an SSH connection to the z/OS UNIX environment (which I do using the ControlMaster, ControlPath, and ControlPersist parameters in the ~/.ssh/config file). I could then have a "full screen" application (QT or GTK+ or ???) on my Linux/Intel box which could do things such use the lsjes capability to display entries in the JES SPOOL. The user could then direct the application to "select" a particular job. This would cause the application to use the fromdsn DLL to read the SPOOL data down to the Linux system (perhaps storing it in a temp file, or maybe just memory) and then displaying it (perhaps using "less") or maybe even putting the data into an editor's (vim/gvim/emacs/...) buffer. This would be basically like doing an SE on the job in SDSF. The only thing missing from this scenario is a simple way for the user to cancel or purge the job's output (which I can envision a rather complicated way of doing, using my own code to run a REXX program on z/OS).
Another application might be to write an equivalent of ISPF option 3.4 on Linux which somehow does a catsearch on z/OS to get a list of datasets. Once it has this, it displays it. The could could then, like with ISPF 3.4, do a member list. From there use the fromdsn DLL to copy the member to do the equivalent of browse, view, or edit. If edit, then it would even be possible to use the todsn DLL to write the changed data back to the member, or dataset (if it was sequential). Thinking about it, perhaps even a DLL to delete a member. I do recognize the issue of dataset / member integrity due to lack of the ENQs used by ISPF so that two people don't edit the same dataset / member concurrently. Perhaps this could be handled similar to how vim does, perhaps by reading the current data, comparing it to the original (or checking an MD5 hash), and warning the use if it has changed.
I will grant that all of this can be done by using the host language's functions such as system() or fork() or spawn() to run the commands just as they would be on the command line. I guess that I consider using a DLL to be more "elegant". I'm not sure, but perhaps the "run the external" command would even be more general because not all languages (especially scripting languages like awk and Perl) can use a DLL. Hum.
If this is considered, then possible enhancements on the z/OS side would be a way to run arbitrary z/OS UNIX commands. As in the example thoughts above, in order to run the "catsearch" program and the REXX UNIX program to purge job output.
Having been educated a bit by what you've accomplished with your sftp server (which might be a way to purge that job now that I think of it), I might even try to write my own z/OS ssh subsystem code to do some of these things. Would be interesting just to try, even if I don't succeed.
Well, that's it for now for me. See ya'll on MVS-OE or IBM-MAIN perhaps.