>Does that imply that the 750 specified for Period 1 duration >equated to approx. 0.44 clock seconds with the 2003 (1724.7 SU/sec); >exclusive of wait times, natch. And, by extension, does that mean >the period is now down to 0.11 clock seconds on our latest z/890 >(8084 SU/sec)?
The short answer is yes. This is exactly what it means. >My concerns centre 'round two cases in our local environment. 1) TSO >period 1 is 75% completion in 0.5 sec with a duration of 750 SU and >period 2 has Velocity>15. I'm worried that 750 SU is not really long >enough for half-a-second duration ie. that tasks are dropping >(almost) straight away into period 2. I'll be researching that in >the RMF report(s) later. Not likely, since 750 SU is an appreciable value for a "trivial" (1st period) transaction. A crude way of measuring this is to issue the TSO TIME command. You'll notice a service value displayed. When you issue the next time command the difference between the original and new values represents the approximate "cost" in service units of the TIME command. Doing a few other commands can give you some insight into what 750 Service Units actually means in terms of transactions. >2) I'm looking to split a service class into two periods because it's >exhibiting the classic 'valley' graph of response times ie. 90% of >transactions are roughly split between bottom (0.5) and top (>4.0) >buckets. Its current definition is 50% complete in 1 second and I've >got *one* 4hr sample of 65% at 0.5 sec and 27% at >4 sec. It was >suggested, during a course, that this implies multiple periods. My >direct problem is how to determine the duration value? I would agree that this represents two periods. However, I also don't think a percentile of 50% is a good idea, IMHO, because it suggests that one out of two units of work should have no goals enforced. There is a huge difference between using percentiles to remove statistical outliers so that they don't influence the goals, but 50% is no longer statistical but approaches "random". To ensure that work is managed according to YOUR objectives, tighter controls are necessary so that work flows into the performance periods so that similarly "behaving" work can be managed to goals that are reflective of their resource consumption. If you include too many items together into a performance period you'll simply have unpredictable behaviors and your goal achievement will be erratic. In any case, those are my opinions so hopefully it may help you get started. Adam ---------------------------------------------------------------------- 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
