Re: FCXPER315A
On Wed, 4 Jun 2008 22:34:06 -0500, Alan Ackerman <[EMAIL PROTECTED] ERICA.COM> wrote: >We don't run PTK, we run ESAMON. But we have seen similar messages. > >I'm guessing that either your monitor shared segments are too small or t he user connecting to the >monitor segment needs a greater SHARE and/or QUICKDISP. > >In my case we are running in a small deliberately paging constrained VM. Nothing we can do >avoids these errors. > >Alan Ackerman >Alan (dot) Ackerman (at) Bank of America (dot) com > = == = Man! I was batting 0 for 2 on Wednesday night. Sorry about that! Better g et some more sleep! Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: FCXPER315A
We recently began, under unknown circumstances, receiving this exception from PTK on one VM LPAR (z800, V5R3): FCXPER315A Cl1 time slice 1.444 exceeds limit 1.000 (Q1=21 Qx=24) ... We don't run PTK, we run ESAMON. But we have seen similar messages. I'm guessing that either your monitor shared segments are too small or the user connecting to the monitor segment needs a greater SHARE and/or QUICKDISP. No, definitely nothing to do with monitor data collection. Please see my reply to Raymond Stricklins original append. In my case we are running in a small deliberately paging constrained VM. Nothing we can do avoids these errors. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com If you get similar messages then ESAMON must also have a built-in threshold monitoring function, and you may want to adapt that threshold or just disable it if you're not interested in the messages. Eginhard Jaeger
Re: FCXPER315A
Original Message - From: "Stricklin, Raymond J" <[EMAIL PROTECTED]> To: Sent: Tuesday, June 03, 2008 11:12 PM Subject: FCXPER315A We recently began, under unknown circumstances, receiving this exception from PTK on one VM LPAR (z800, V5R3): FCXPER315A Cl1 time slice 1.444 exceeds limit 1.000 (Q1=21 Qx=24) We received it (with slightly different numbers) once every ten minutes for about a month, when it stopped under circumstances equally unknown as those surrounding its beginning. Only one LPAR of the four on the machine reports this exception. I don't really know what it's referring to (apart from the dispatcher, generally), or what its significance might be. Is it of any significance? Where might I begin looking to determine the ultimate cause? Selecting context help for the '85% elapsed time' field on the CPU screen explains meaning and use of the class 1 elapsed time slice: 'Elapsed time slice which determines the maximum time a VMDBK may remain in the dispatch list before it is dropped. This value is continuously adapted for class 1 transactions so that 85% of them can complete within a single class 1 elapsed time slice, i.e. the value reflects both the system responsiveness to user demand and workload characteristics. You should bear this in mind when comparing the values from different systems. ...' The messages you saw were probably generated by the initial threshold setting provided with the sample FCONX $PROFILE: a value exceeding 1 second would have meant bad response times on a system with mainly interactive CMS (e.g. PROFS) users. However, as the text says, the value depends not only on system responsiveness but also on your workload, and the sample threshold may be far off the target for your system. You should check the actual values for the class 1 elapsed time slice on your system (see C1ES values on REDISP screen) and relate them to good/bad performance felt by your users. Then adapt the threshold value in the 'FC LIMIT C1ES ..' command in the FCONX $PROFILE to a value where experience has shown that system performance is getting worse. Or simply disable threshold checking for C1ES if you cannot determine a good threshold value .. Eginhard
Re: FCXPER315A
On Tue, 3 Jun 2008 14:12:00 -0700, Stricklin, Raymond J wrote: >We recently began, under unknown circumstances, receiving this exception >from PTK on one VM LPAR (z800, V5R3): > >FCXPER315A Cl1 time slice 1.444 exceeds limit 1.000 (Q1=21 Qx=24) > >We received it (with slightly different numbers) once every ten minutes >for about a month, when it stopped under circumstances equally unknown >as those surrounding its beginning. Only one LPAR of the four on the >machine reports this exception. > >I don't really know what it's referring to (apart from the dispatcher, >generally), or what its significance might be. Is it of any >significance? Where might I begin looking to determine the ultimate >cause? > >Thanks; > >ok >r. > = == = We don't run PTK, we run ESAMON. But we have seen similar messages. I'm guessing that either your monitor shared segments are too small or th e user connecting to the monitor segment needs a greater SHARE and/or QUICKDISP. In my case we are running in a small deliberately paging constrained VM. Nothing we can do avoids these errors. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
FCXPER315A
We recently began, under unknown circumstances, receiving this exception from PTK on one VM LPAR (z800, V5R3): FCXPER315A Cl1 time slice 1.444 exceeds limit 1.000 (Q1=21 Qx=24) We received it (with slightly different numbers) once every ten minutes for about a month, when it stopped under circumstances equally unknown as those surrounding its beginning. Only one LPAR of the four on the machine reports this exception. I don't really know what it's referring to (apart from the dispatcher, generally), or what its significance might be. Is it of any significance? Where might I begin looking to determine the ultimate cause? Thanks; ok r.
