This is just something that I've been batting around in my head. I doubt that I'll ever actually do anything with it due to lack of time. But I really like my Linux desktop. And I no longer have a great love for TSO. So I've been considering how I might do more z/OS related work on my Linux desktop. And do it easily from a command prompt. I'm a command prompt type person in many ways. So I was thinking of writing a "server" type program on z/OS which can do "many things" (yet to be decided). This "server" would be akin to the ftp server, or actually more like the telnetd server. That is, it would communicate to the desktop via TCPIP and it would be started on z/OS via inetd (unlike the ftp server). The first Linux command would be something like "zlogin z/OS_system userid password". z/OS_system would be the DNS name or IP of the z/OS system. userid would be the user's z/OS userid and password would be the password. The "zlogin" command would fork() and daemonize itself so that the parent would exit (freeing up the terminal) whereas the child would daemonize itself. The other commands in this "package" would talk to the child. The child would do an IP connection to the z/OS system's inetd server. inetd would start (fork()) the "server" which would ask the Linux child for the given userid and password in order to logon to the z/OS system. This would make the "server" assume the z/OS and UNIX identity of the user, like ftp and telnet do. All the other commands would talk to the child, telling it to "do something" (exactly what is yet to be completely determined).
My idea is to be able to do z/OS work from the Linux command line. Some example commands would be "zcp" to copy (ftp-like) data to/from a z/OS legacy dataset or UNIX file to a local file, similar to what "scp" does. Eg: zcp -s local.file "//'HLQ.SEQ.FILE'" would send (-s) "local.file" to z/OS dataset 'HLQ.SEQ.FILE' or the other way: zcp -r "//'HLQ.SEQ.FILE'" local.file . zsubmit myjob.jcl would send the contents of "myjob.jcl" to the z/OS "server" which would write them to an INTRDR and thus submit the job. zsubmit would also have some sort of option to submit JCL which already resides on the z/OS system as well. zjobls would give output similar to doing an "ls" command in ftp when you have done a QUOTE SITE FILETYPE=JES. zgetjob would download SYSOUT from z/OS, similar to an ftp "get" with QUOTE SITE FILETYPE=JES active. zpurgejob would purge a job. That is cancel it and purge its output if it is running. Purge it if it is in the input queue, hold, or output queue. I.e. do a $PJ on it. zcanjob would cancel a running job or one on the input queue. I.e. do a $CJ on it. zlogoff would cause the z/OS task to terminate along with the Linux daemonized child. Other "z" commands might do other things, as I think of stuff I want to do. Now, the way that I planned this was the zlogin creates the "daemon child" which is what actually talks to the z/OS system. This allows every every shell for a given user to issue "z" commands once a single zlogin has been done. They do this by talking to the "child" using UNIX "Message Queues". Of course, the problem with this is that the "z" commands all go to a single z/OS system. I don't plan on a way to have connectivity to multiple z/OS systems concurrently. The plus is that it makes it easy to talk to the child so a program could to so. Or I could create an API so that developers could avoid the overhead of fork()'ing a "z" command. Well, I just wanted to blue sky with everybody. Feel free to ignore this. Or tell me that I'm an id10t (like I don't already know). Or even implement it yourself and sell it as a product. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
