Re: Dataset-held message to TSO user
In [EMAIL PROTECTED], on 11/21/2007 at 11:22 AM, McKown, John [EMAIL PROTECTED] said: Shmuel tends to not explain his answers. That depends on the question, and on the resources I have available at the time. For a suggested code/design change, I do tend to give yes-or-no answers, but for a How do I? question I'm likely to give some detail[1], sometimes sample code, and when I've had copies of manuals[3] on my local disks I've been known to CP the relevant text. [1] But try not to give more than needed[2] to steer the reader in the right direction. [2] If I know that the manual is incorrect or incomplete then I try to include that in my response. [3] Not alwasy the right release levels :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, November 21, 2007 4:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dataset-held message to TSO user In [EMAIL PROTECTED], on 11/16/2007 at 06:49 PM, Ed Gould [EMAIL PROTECTED] said: Point of curiosity here. Why not just change it to PUTLINE ? Because then it would no longer work. That should fix the problem, no? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT I will add that it won't work due to the fact that PUTLINE only writes to the local TSO user. That is, the PUTLINE must run in the address space of the TSO user. The message under consideration comes from a different address space. TPUT with the ASID=, ASIDLOC=, or USERIDL= will send the message from the originating address space to the specified address space (on the same z/OS image). Shmuel tends to not explain his answers. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
On Nov 21, 2007, at 11:22 AM, McKown, John wrote: --SNIP--- In [EMAIL PROTECTED], on 11/16/2007 at 06:49 PM, Ed Gould [EMAIL PROTECTED] said: Point of curiosity here. Why not just change it to PUTLINE ? Because then it would no longer work. That should fix the problem, no? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT I will add that it won't work due to the fact that PUTLINE only writes to the local TSO user. That is, the PUTLINE must run in the address space of the TSO user. The message under consideration comes from a different address space. TPUT with the ASID=, ASIDLOC=, or USERIDL= will send the message from the originating address space to the specified address space (on the same z/OS image). Shmuel tends to not explain his answers. -- Thanks... I was under the misunderstanding that TPUT would not work in batch. They have apparently fixed it. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Ed Gould wrote: Thanks... I was under the misunderstanding that TPUT would not work in batch. They have apparently fixed it. That was *never* the issue. The problem was that the TPUT was being issued from an MPF on the system where the contention message was issued ... not necessarily the system where the user was logged on! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
On Wed, 21 Nov 2007 13:55:07 -0600 Ed Gould [EMAIL PROTECTED] wrote: :Thanks... I was under the misunderstanding that TPUT would not work :in batch. They have apparently fixed it. TPUT works in batch, in that you can send a message to a logged on TSO user. TPUT does not go to SYSTSPRT. PUTLINE goes to the current stack, which typically is SYSTSPRT in batch or the terminal in real TSO, but it can be redirected (REXX OUTTRAP, for one). PUTLINE does not go to another TSO session. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
On Fri, 2007-11-16 at 14:09 -0800, Skip Robinson wrote: In a sysplex we need to send the message to the user wherever he's logged on in the GRSplex. Does anyone have a more modern mechanism to accomplish this goal? RO *ALL,C U=?? should do the job. May even SEND ... Sounds perfect for a rewrite in SYSREXX. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Skip Robinson wrote: For many years we have run an MPF exit called DSNHELD, apparently contributed to the CBT by INTEL (!) in the distant past. The exit sends a message to a user who owns a data set needed by a batch job. The program, last modified by us in the early 90's, does a fine job except for one glaring deficiency: it uses TPUT and can therefore send its message only to a user logged on to the same system that's running the job. In a sysplex we need to send the message to the user wherever he's logged on in the GRSplex. Does anyone have a more modern mechanism to accomplish this goal? I don't find anything on the current CBT. SYS1.SAMPLIB(ISGECMON) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Too bad that SYS1.SAMPLIB(ISGECMON) also uses TPUT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Maybe you're supposed to run ISGECMON on each LPAR where TSO users might be? Otherwise, I would imagine it would be relatively simple to convert to issuing a z/OS console SEND command to communicate with users wherever they may be Brian On Fri, 16 Nov 2007 17:12:44 -0600, Lucymarie Ruth wrote: Too bad that SYS1.SAMPLIB(ISGECMON) also uses TPUT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Shane wrote: RO *ALL,C U=?? should do the job. If only ... :-D -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
ISGECMON appears to work as self-advertized. A quick test on our sandbox gives good results: the owning user is notified regardless of where the job is running. Note that this program works altogether differently from DSNHELD, which is an MPF exit kicked off by message IEF863I on the batch job's system. ISGECMON, running on every system with an interval pop, eventually detects the conflict wherever the user is logged on, so TPUT gets issued on the 'right' system. Thanks to all for the quick help. We're venturing into our first bronze-plex this weekend, so users will likely see some GRS false contentions. Having sysplex-wide notification will help. Edward Jaffe [EMAIL PROTECTED] OFTWARE.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Dataset-held message to TSO user 11/16/2007 03:49 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Brian Peterson wrote: Maybe you're supposed to run ISGECMON on each LPAR where TSO users might be? Otherwise, I would imagine it would be relatively simple to convert to issuing a z/OS console SEND command to communicate with users wherever they may be You are definitely supposed to run it everywhere. The logic consciously ignores so-called data set owners running on other systems. The program notes say: |This program will not notify users on |other systems of contention. However, the |same effect may be achieved by running a |a copy of this program on every system. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Brian Peterson wrote: Maybe you're supposed to run ISGECMON on each LPAR where TSO users might be? Otherwise, I would imagine it would be relatively simple to convert to issuing a z/OS console SEND command to communicate with users wherever they may be You are definitely supposed to run it everywhere. The logic consciously ignores so-called data set owners running on other systems. The program notes say: |This program will not notify users on |other systems of contention. However, the |same effect may be achieved by running a |a copy of this program on every system. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Maybe you're supposed to run ISGECMON on each LPAR where TSO users might be? Otherwise, I would imagine it would be relatively simple to convert to issuing a z/OS console SEND command to communicate with users wherever they may be Yes, that's the idea. Run ISGECMON on each system in the GRSPLEX (SYSPLEX). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
Thanks as well to Mr Jaffe for pointing to the thing right under my nose. It looks as if running the task on every sysplex member may do the trick because contention is visible to all around. I'll play with it. I could be wrong, but if memory serves me correctly, ISGECMON reports contention on resources only between TSO users, and does not report BATCH vs. TSO contention. You'll have to try it to find out. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
My tests involved one TSO user editing a PS file and one batch job (IERFR14) trying to allocate the same file DISP=SHR .The user gets the message wherever the job runs. Lucymarie Ruth [EMAIL PROTECTED] AFEWAY.COMTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Dataset-held message to TSO user 11/16/2007 04:36 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Thanks as well to Mr Jaffe for pointing to the thing right under my nose. It looks as if running the task on every sysplex member may do the trick because contention is visible to all around. I'll play with it. I could be wrong, but if memory serves me correctly, ISGECMON reports contention on resources only between TSO users, and does not report BATCH vs. TSO contention. You'll have to try it to find out. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
On Nov 16, 2007, at 5:12 PM, Lucymarie Ruth wrote: Too bad that SYS1.SAMPLIB(ISGECMON) also uses TPUT. Point of curiosity here. Why not just change it to PUTLINE ? That should fix the problem, no? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dataset-held message to TSO user
The need here is for an interactive user to get notified of contention. For batch vs. batch, there's nobody home to answer the phone. Something may need to be done, but hollering at the resource owner is hoarse abuse. Lucymarie Ruth [EMAIL PROTECTED] AFEWAY.COMTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Dataset-held message to TSO user 11/16/2007 04:54 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Oops. Brain is a little foggy today. Check out BATCH vs. BATCH. It think that's the combination that doesn't get reported. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
