The TSO SEND command can send a message from one TSO user to another TSO user. This works even if the two users are on different z/OS images, so long as they are in the same JESPLEX. This also appears to work for the z/OS SEND operator command. The closest equivalent to this that I can find for this is the UNIX "write" command. But this only works within a single z/OS image.
Now, this TSO facility (the SEND operator command) appears to be what is used to implement the NOTIFY= on a job so that a person knows when their job ends. I'm trying to think of a way to extend this to UNIX shell users (not under TSO OMVS). What I have done is use CA-OPS/MVS to trap the SEND operator command. I use the CA-OPS/MVS ADDRESS USS USSCMD function to run a UNIX command, passing in the entire SEND command. I have done this already, to the extent that I can get the UNIX command to run and see the SEND command as input. I'm still working on parsing it up. That is not my question. This has all been background. First question: Any ideas how to make my UNIX script, running on the same system as the ending job, send a message to a UNIX shell user running on another system? The only thing that I can think of is a daemon on every z/OS UNIX system. All of which talk to each other. The UNIX command I'm writing would send the SEND text to the local daemon, which would propagate it to all the connected daemons. Each daemon would then use a facility similar to the UNIX write command to send the text on to the local users. This implementation would do two things. First, it would allow the cross-system notification. Second, it would send the message to __every__ TTY onto which the user was logged. What I've found is that, when you logon to z/OS UNIX via telnet or SSH, a character device is created called /dev/ttyp.... where .... is a number. This device is owned by the logged on user in RW mode. The group on the device is TTY in W mode. That is how "write" appears to work - it is setgid TTY. I can do the same with the daemon so that it does not need to be UID 0, just setgid TTY or run by a UNIX id which has TTY as its default group or even just connected to the TTY group. I'd find the logged on user simply by scanning the /dev subdirectory for ttyp* files which are owned by the "send to" user. I am assuming that all non-zero UIDs are unique. If not, there will be you-know-what to pay. And that every system in this "daemon distribution" group uniquely maps UIDs to the same user on all systems, with no conflicts. Again, if this is violated, *POOF* goes my methodology. Second question: Should distribution be restricted to users who have an assigned UID on the generating system? This would cut down on the number of messages going around the systems for jobs run by TSO users who are not also UNIX users. Secondary question: distribute by user or UID? Third question: Is this even a good idea? UNIX TTYs are "full duplex". Unlike TSO, which will not interrupt the user with the SEND message until the user presses the ENTER key, writing to /dev/ttyp.... writes those characters directly to the user's terminal(s) immediately. So, what is a better method? What occurred to me was to use the "mail" command on each system to "mail" the SEND message text. What I've noticed is that most UNIX shell check to see if a new mail message has arrived just before writing the shell prompt. This makes it far less intrusive. And if the user is logged on to multiple TTY on a single system, he doesn't get the SEND text on every TTY. Much "kinder". Also, this method implements the "LOGON" function so that the message is not lost if the user is not logged on at the time. Unfortunately, this means that the message is on every system separately. Unless it is possible to share a single UNIX mailbox on multiple systems. If it is possible, then the daemon distribution might not even be needed. Fourth question: Can a single UNIX mailbox be shared between multiple UNIX systems using z/OS UNIX multi-system filesystem sharing? I just don't know how this works at all. Even if the filesystem can be shared, does the "mail" command implement concurrent use functionality which will work in this environment? Observation: Use of the daemon distribution method might make it possible for a non-z/OS UNIX user to submit a z/OS job for execution and be notified when it ends. I think Paul Gilmartin does something like this, if I understood him correctly. This might make it nice for people who use WDz (or whatever it is now called) on their desktop. If I do such a thing, I plan to GPL the code and, if permitted, put it on the CBT. I don't remember the license restrictions which are allowed by the CBT people. They may only allow BSD type licenses. My personal liking is for GPL so that somebody can't take my code, enhance it, then refuse to tell me (and others) what they did, while distributing it. I don't mind people using my code for free. I don't mind people charging to support my code. I do mind people taking my code, for free, and not giving back. But other good people can and do disagree with me. Thank you for your thoughts. Even to the people who will say "You're a nut!" <grin> -- John McKown Maranatha! <>< ---------------------------------------------------------------------- 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
