Re: SLIP trap on High CPU usage
I was responding to this part of the OP question > My problem is a vendor product where a user exit is being repetitively > called, issuing unnecessary GETMAIN/FREEMAIN Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter Hunkeler > Sent: Wednesday, May 30, 2018 10:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Re: SLIP trap on High CPU usage > > >But a GTF Trace probably can. I would look at GTF TRACE or VSM Traces. > > > But this will monitor VSM calls, not CPU usage. I understand the > GETMAIN/FREEMAIN are expected, but only every now and then, they go wild. I > don't see how GTF can help here. > > > I don't know the details, but I know we have some automation in place to > detect high CPU users (jobs). AFAIK, it is based on MainView z/OS detecting > such a job and then writting (WTO) a message, which in turn triggers > automation. > > > Do you have some tool like MainView or Omegamon? > > > -- > Peter Hunkeler > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP trap on High CPU usage
I would suggest that you figure out how much CPU your STC typically takes and specify a TIME= at about that level. Then you can SLIP on 322 to take an abend. Of course, depending on the criticality of the STC, you should consider making it automatically restart. On Wed, 30 May 2018 22:00:01 -0500 Munif Sadek wrote: :>Is there a way to slip trap on a module/STC if it starts consuming higher MSU in zOS 2.3. :>My problem is a vendor product where a user exit is being repetitively called, issuing unnecessary GETMAIN/FREEMAIN. Vendor has asked us to dummy out user exit and fix will come in the next release. This problem is intermittent, generally happens once every couple of hours during online window. :>Dummied out User exit has provided relief, still management perceived notion that Mainframe is expansive and Vendor reluctance to disclose what process is initiating call to this exit, is there a way I can set a slip trap whenever CPU usage is spiked so that I can go back to vendor with SVC DUMP/ Systrace (Mod names) of the exact problem. :>We do have Strobe but strobe can not automate this request without integration with iStrobe and BMC Caze. :>Did look at SLIP documentation but can not find relevant information. -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SLIP trap on High CPU usage
>But a GTF Trace probably can. I would look at GTF TRACE or VSM Traces. But this will monitor VSM calls, not CPU usage. I understand the GETMAIN/FREEMAIN are expected, but only every now and then, they go wild. I don't see how GTF can help here. I don't know the details, but I know we have some automation in place to detect high CPU users (jobs). AFAIK, it is based on MainView z/OS detecting such a job and then writting (WTO) a message, which in turn triggers automation. Do you have some tool like MainView or Omegamon? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP trap on High CPU usage
I do not think a SLIP trap will work. But a GTF Trace probably can. I would look at GTF TRACE or VSM Traces. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/gfs.htm GFS trace is a diagnostic tool that collects information about the use of the GETMAIN, FREEMAIN, or STORAGE macro. You can use GFS trace to analyze the allocation of virtual storage and identify users of large amounts of virtual storage. You must use the generalized trace facility (GTF) to get the GFS trace data output. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Munif Sadek > Sent: Wednesday, May 30, 2018 8:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SLIP trap on High CPU usage > > Dear listers > > Is there a way to slip trap on a module/STC if it starts consuming higher MSU > in zOS 2.3. > > My problem is a vendor product where a user exit is being repetitively > called, issuing unnecessary GETMAIN/FREEMAIN. Vendor has asked us to dummy > out user exit and fix will come in the next release. This problem is > intermittent, generally happens once every couple of hours during online > window. > > Dummied out User exit has provided relief, still management perceived notion > that Mainframe is expansive and Vendor reluctance to disclose what process is > initiating call to this exit, is there a way I can set a slip trap whenever > CPU usage is spiked so that I can go back to vendor with SVC DUMP/ Systrace > (Mod names) of the exact problem. > > We do have Strobe but strobe can not automate this request without > integration with iStrobe and BMC Caze. > > Did look at SLIP documentation but can not find relevant information. > > kind regards, > Munif. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SLIP trap on High CPU usage
Dear listers Is there a way to slip trap on a module/STC if it starts consuming higher MSU in zOS 2.3. My problem is a vendor product where a user exit is being repetitively called, issuing unnecessary GETMAIN/FREEMAIN. Vendor has asked us to dummy out user exit and fix will come in the next release. This problem is intermittent, generally happens once every couple of hours during online window. Dummied out User exit has provided relief, still management perceived notion that Mainframe is expansive and Vendor reluctance to disclose what process is initiating call to this exit, is there a way I can set a slip trap whenever CPU usage is spiked so that I can go back to vendor with SVC DUMP/ Systrace (Mod names) of the exact problem. We do have Strobe but strobe can not automate this request without integration with iStrobe and BMC Caze. Did look at SLIP documentation but can not find relevant information. kind regards, Munif. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
