Re: Slip Trap turning off GTF on different LPAR
To all who replied on this subject, giving me lots of food for thought and some good advice: THANK YOU!!! -- Regards - Grant - DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- 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: Slip Trap turning off GTF on different LPAR
I wrote: (somewhat facetiously) /RO the_system_you_wanted,the_command_you_wanted? And Ed said Are you suggesting enhancing SLIP to issue system commands? Not at all. I was responding (tongue in cheek) to Peter's comment that there was no system-provided means of driving SLIP on another system. -- snip -- Actually, I like the idea of enhancing SLIP to generate system commands. Then a SLIP trap match could not only stop GTF trace records from being generated, but also stop the GTF STC. Does this sound like a reasonable requirement? -- John -- 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: Slip Trap turning off GTF on different LPAR
On Tue, 2007-10-30 at 09:36 +0100, John Ticic wrote: Actually, I like the idea of enhancing SLIP to generate system commands. Then a SLIP trap match could not only stop GTF trace records from being generated, but also stop the GTF STC. Does this sound like a reasonable requirement? Yes. -- 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: Slip Trap turning off GTF on different LPAR
If the real problem here is shutting off GTF on every LPAR when a SLIP trap hits on one LPAR, I believe this problem has already been solved. Here's an actual SLIP trap we have been given to run on every LPAR in our sysplex, in conjunction with a GTF trace running on every LPAR. When the trap hits on any LPAR, it also shuts off GTF on every LPAR. I believe this is accomplished through the use of the IDGROUP parameter and the A=STOPGTF parameter. SLIP SET,IF,A=TRACE,NUCMOD=(IOSCACDR,1C76),TRDATA= (STD,REGS,6R?,+1F,4R?, +1F,13R?+23C?,+7),ID=SLP1,IDGROUP=CMDRGRP,END SLIP SET,COMP=C0D,N=(IOSVDSTF),A= (STOPGTF),ID=SLP2,IDGROUP=CMDRGRP,END Brian On Tue, 30 Oct 2007 19:13:14 +1000, Shane wrote: On Tue, 2007-10-30 at 09:36 +0100, John Ticic wrote: Actually, I like the idea of enhancing SLIP to generate system commands. Then a SLIP trap match could not only stop GTF trace records from being generated, but also stop the GTF STC. Does this sound like a reasonable requirement? Yes. -- 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: Slip Trap turning off GTF on different LPAR
---snip- Actually, I like the idea of enhancing SLIP to generate system commands. Then a SLIP trap match could not only stop GTF trace records from being generated, but also stop the GTF STC. Does this sound like a reasonable requirement? -unsnip--- It sounds like a wonderful idea, but I would require one limitation: no response to be expected. SLIP should NOT be required to handle ANY responses to any command it issues. Nor should there be any mechanism to make substitutions in the command before it's issued. Let's keep it real simple to start with; enhancement MIGHT follow, if the need and usefulness can be demonstrated. -- 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: Slip Trap turning off GTF on different LPAR
The STOPGTF operand of the SLIP trap applies only to the system where the SLIP trap is set, not to remote systems, even when the REMOTE keyword is used. There is no system-supplied mechanism for doing what has been asked for. Peter Relson z/OS Core Technology Design -- 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: Slip Trap turning off GTF on different LPAR
/RO the_system_you_wanted,the_command_you_wanted? CC The STOPGTF operand of the SLIP trap applies only to the system where the SLIP trap is set, not to remote systems, even when the REMOTE keyword is used. There is no system-supplied mechanism for doing what has been asked for. Peter Relson z/OS Core Technology Design -- 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: Slip Trap turning off GTF on different LPAR
Craddock, Chris wrote: /RO the_system_you_wanted,the_command_you_wanted? Are you suggesting enhancing SLIP to issue system commands? -- 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: Slip Trap turning off GTF on different LPAR
On Mon, 29 Oct 2007 09:54:27 -0700, Edward Jaffe wrote: Craddock, Chris wrote: /RO the_system_you_wanted,the_command_you_wanted? Are you suggesting enhancing SLIP to issue system commands? If so then it might also be a good idea to suggest that some single standard SAF UTOKEN value be used in order to anticipate/avoid potential confusion or documentation snafus that might otherwise result from that suggestion's initial implementation. (Just a thought; I liked the suggested enhancement but having the command trigger under any of a plethora of possible security environments may invite security failures.) -- Tom Schmidt Madison, WI -- 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: Slip Trap turning off GTF on different LPAR
I wrote: (somewhat facetiously) /RO the_system_you_wanted,the_command_you_wanted? And Ed said Are you suggesting enhancing SLIP to issue system commands? Not at all. I was responding (tongue in cheek) to Peter's comment that there was no system-provided means of driving SLIP on another system. The ROUTE command is the swiss-army knife that lets you issue commands directed to another system. I have used it pretty extensively and I assume you have too :-) I have never tried to mess with SLIP commands using /RO, but I don't see any obvious reason that it wouldn't just work. CC -- 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: Slip Trap turning off GTF on different LPAR
Craddock, Chris wrote: I have never tried to mess with SLIP commands using /RO, but I don't see any obvious reason that it wouldn't just work. Yes. That works for establishing a SLIP trap. But, in this case the poster was trying to make SLIP's STOPGTF functionality work on a remote 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: Slip Trap turning off GTF on different LPAR
On Mon, 29 Oct 2007 11:37:58 -0700 Edward Jaffe [EMAIL PROTECTED] wrote: :Craddock, Chris wrote: : I have never tried to mess with SLIP commands using /RO, but I don't see : any obvious reason that it wouldn't just work. :Yes. That works for establishing a SLIP trap. But, in this case the :poster was trying to make SLIP's STOPGTF functionality work on a :remote system. How about using automation software to trigger off of the SLIP MATCHED message? -- 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
Slip Trap turning off GTF on different LPAR
Hi Listers, we need to run GTF and have a slip trap set that when triggered will turn off the GTF trace. The problem is that both GTF and slip trap are on different LPAR's. Is there a way to achieve this? -- Regards - Grant - DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- 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: Slip Trap turning off GTF on different LPAR
we need to run GTF and have a slip trap set that when triggered will turn off the GTF trace. The problem is that both GTF and slip trap are on different LPAR's. Provided the 'other lpar' is in the same sysplex, check the action parm for the slip trap. Look at the remote parm, you can basically specify all actions (described by 'option') remotely, too. I won't even try to provide an example, as I always get the parenthesis wrong on the first 3 tries Regards, Barbara -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -- 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
