Re: Question on PER-SLIP and PRCNTLIM.
>When SLIP SLIH code is active for a SLIP, what happens if >another SLIP is triggered on another CP? Is the system >in a non-dispatchable state? Is SPIN SLIH code serialized? SLIP does not need to serialize against itself for the most part. Accumulation of time, for example, is what any multi-threaded application would use -- some sort of compare and swap. One of the few places where SLIP does serialize against itself is in taking an SVC Dump for a trap, where if two relatively concurrent matches of the same SLIP trap occur (on different processors, of course) one will win and one will lose (but that's not much more than what could be said about two relatively concurrent SDUMP requests -- one will win and one will find SDUMP busy). In no case does SLIP make the second processor spin or wait. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Peter Hunkeler > > Jim, Peter > Thanks a lot. I understand it is not some precise measurement. I understand > this as a means to keep a > badly written SLIP from negatively impacting the system. > > Out of curiosity: When SLIP SLIH code is active for a SLIP, what happens if > another SLIP is triggered > on another CP? Is the system in a non-dispatchable state? Is SPIN SLIH code > serialized? > --Peter Hunkeler Found this note in the doc for SLIP SET parameters: "Between the instant matchlim is reached and when the trap is actually disabled, a small amount of time elapses. It is possible for the trap to match on another CPU during this small time interval. If this occurs, matchlim will actually be exceeded, with unexpected results. Therefore, use caution in setting a trap in a heavily used module as, for example, the dispatcher." Not sure if this would apply generally, though. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Question on PER-SLIP and PRCNTLIM.
Jim, Peter Thanks a lot. I understand it is not some precise measurement. I understand this as a means to keep a badly written SLIP from negatively impacting the system. Out of curiosity: When SLIP SLIH code is active for a SLIP, what happens if another SLIP is triggered on another CP? Is the system in a non-dispatchable state? Is SPIN SLIH code serialized? --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
(I forgot to send this yesterday, and Jim Mulder beat me to it. The only thing he omitted was about space-switch interrupts). >What exactly does "x% of system time" mean? >Is it a pecentage of the LPAR CP capacity? You might say it doesn't mean anything "exactly", but it does mean something "approximately" :-) Approximately, total - CPU time spent processing PER interrupts - CPU time spent processing space-switch interrupts Divide by number of online CPUs Divide by total elapsed time since trap was enabled Multiply by 100 It is quite inaccurate when you consider CPUs coming online and/or going offline, or parked logical processors, or zAAPs/zIIPs on a business class machine, or not dedicated processors. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Question on PER-SLIP and PRCNTLIM.
> No answer? Interesting! I was thinking this is one of the easier > questions for the experienced debuggers on the list. You would need access to the SLIP code to answer this question. I did look into this around 4 years ago, it just took me a while to find the notes from that investigation. The calculation is (((Amount of CPU time spent in PER on all CPUs since trap was enabled) / (number of CPUs online right now)) * 100) / (Elapsed time since trap was enabled) And yes, I know of several reasons why this may not produce the results you might expect, including 1. CPU online/offline reconfiguration 2. Doesn't normalize CPU time for subcapacity CPUs vs full speed specialty engines 3. Dividing by elapsed time, not CPU busy time Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
Thanks, AL. I did read the manual, but unfortunately the description of PRCNTLIM is rather fuzzy (at least to me). It is NOT a percentage of capacity, it is a TIME based calculation, as in;not how much CP it is using, but how LONG it has been. It is a percentage value that is to be specified. "How LONG..." would be a time value. I imagine SLIP code somehow keeps track of how long it is active (processing PER events) and how long it is inactive (not processing PER events). This ratio is a percentage of time. I assume SLIP code runs disabled. So on an LPAR with only one CP, time is equally CPU time as well as wall clock time. (Can a logical CP running in disabled state become nondispatched by LPAR code?) If the LPAR has more than one CP, the HW might signal a PER event on more than one CP simultaneously. SLIP code would run on multiple CPs in parallel, probably serialized (true?). Either way, it would use CP capacity on each of the CPs. This is way I'm thinking PRCNTLIM is an LPAR capacity percentage. Since all of the above could be wrong (I'm only making assumptions, after all), it may well work completely different. I'm curious to understand this better. That's why I was asking. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on PER-SLIP and PRCNTLIM.
It is NOT a percentage of capacity, it is a TIME based calculation, as in; not how much CP it is using, but how LONG it has been. I will admit that it is not very clear as to what the calculation is, but my first recommendation is to note in the PMR that it hit this limit and ask Level 2 a new value, they may have a better idea on what to specify, otherwise I would recommend doing it in increments, such as; PRCNTLIM=20, then PRCNTLIM=30, ... The manual says to avoid =99 because then there will be no limit. >From the MVS Commands manual: PRCNTLIM=p For a PER trap, specifies a software limit for PER processing by indicating a maximum percentage of system time that can be devoted to processing caused by PER interruptions. At least 33.55 seconds must have elapsed since the first PER interruption before a trap will be disabled because of this limit. . . . The value computed to test PRCNTLIM is an approximation. SLIP makes this calculation only when a PER interrupt occurs, so the PRCNTLIM parameter does not cause the trap to be disabled until a PER interrupt occurs. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, October 07, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question on PER-SLIP and PRCNTLIM. We had to set an IF SLIP trap with JOBNAME= in support of a PMR. As I didn't specify PRCNTLIM, this was set to 10% by SLIP SET processing. The slip has been disabled due to PRCNTLIM before a dump was taken (DATA= wasn't fulfilled so far). I understand this to mean that the RANGE that is set produced that many PER interrupts, that slip processing was using more than the allowed 10% of "system time" and disabled the slip. What exactly does "x% of system time" mean? Is it a pecentage of the LPAR CP capacity? -- 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: Question on PER-SLIP and PRCNTLIM.
Peter, It would help if you replied and included the original posting. Sometimes people do not have time to find what was requested and it is helpful to include the posting. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Hunkeler > Sent: Tuesday, October 07, 2014 10:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Question on PER-SLIP and PRCNTLIM. > > No answer? Interesting! I was thinking this is one of the easier questions for the > experienced debuggers on the list. > -- > Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Question on PER-SLIP and PRCNTLIM.
No answer? Interesting! I was thinking this is one of the easier questions for the experienced debuggers on the list. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question on PER-SLIP and PRCNTLIM.
We had to set an IF SLIP trap with JOBNAME= in support of a PMR. As I didn't specify PRCNTLIM, this was set to 10% by SLIP SET processing. The slip has been disabled due to PRCNTLIM before a dump was taken (DATA= wasn't fulfilled so far). I understand this to mean that the RANGE that is set produced that many PER interrupts, that slip processing was using more than the allowed 10% of "system time" and disabled the slip. What exactly does "x% of system time" mean? Is it a pecentage of the LPAR CP capacity? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
