Design question for a UNIX facility similar to TSO SEND command
- From: joarmc@xxxxxxxxxx (John McKown)
- Date: 24 Oct 2010 16:03:16 -0700
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
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
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
- Prev by Date: Re: Abending TCB
- Next by Date: Re: How do I determine Enterprise COBOL for z/OS release level from outside COBOL or LE environment?
- Previous by thread: Horny Middle East babe *** fingered and***ing like cowgirl MMS
- Next by thread: Re: Design question for a UNIX facility similar to TSO SEND command