> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Shmuel Metz (Seymour J.) > Sent: Wednesday, February 06, 2008 9:44 PM > To: [email protected] > Subject: Re: CPU time differences for the same job > > In <[EMAIL PROTECTED]>, > on 02/05/2008 > at 05:23 PM, "Farley, Peter x23353" <[EMAIL PROTECTED]> said: > > >Based on this thread, the JES-reported TCB and SRB usage > > 1. They are not JES reported
They appear in JESMSGLG, therefore they are JES reported. I don't particularly give a feghoot what program actually generated the message because it isn't relevant how the message was generated. The TCB/SRB time message appears in a JES output dataset so it is, in fact, JES reported. Picking a nit like this one is neither helpful nor germane to the discussion at hand. > 2. Most of the variability should be in the SRB time. The bulk of the early posts in this thread were discussing TCB or both TCB and SRB time elongation due to the various factors cited. I would agree with you that in a "normal" environment, SRB time *should* be the most variable. What this thread has been about is that it *isn't* only SRB time that varies, and the environment *isn't* nearly as "normal" and predictable as we were taught to believe it was. > 3. You can run the same job multiple times to see what the > variability is for the particular job. Agreed, that seems to be the only sensible solution, though not an entirely satisfactory one. > >Those numbers and the Strobe product the > >only tools I have available to me. > > Strobe should be enough to find the hot spots. Not as easy as it looks. Sometimes the hottest spots aren't in your control (I/O subroutines for a data store owned by another application group are one such example). Priorities aren't always perfectly aligned in such cases. > >It's very discouraging to be told "the tools you > >depend on are unreliable and unpredictably variable". > > Who told you that? The details and discussions in this whole thread told me that. The fact that two runs of the same work on the same system at similar times may vary by 10%-20% in CPU time is what I would call completely unreliable. 1%-2% can be called variable, but 10%-20% is a major difference that cannot be simply accounted for, except by throwing out low and high values from multiple runs as was suggested earlier in the thread. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
