Don,

Then should I see that MVS % Busy in LPAR mode is "different" to the
accurate measure you get in Basic Mode or with Dedicated PIP :)

Useful, but still wrong - like Device Busy with PAV.

Ron

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Don Deese
> Sent: Wednesday, 15 February 2006 3:53 AM
> To: [email protected]
> Subject: Re: LPAR utilization more important than MVS utilization?
> 
> That depends on what your definition of "wrong" is.
> 
> MVS Busy is the time a logical processor was dispatched on a physical
> processor, plus the time that PR/SM intercepted the logical processor
> because it had exceeded its dispatch interval and it was on the PR/SM
> Logical Processor Ready Queue awaiting re-dispatch.  The difference
> between
> MVS Busy and CPU Busy is a result of over-commitment of logical processors
> to physical processors and a high processor demand relative to CPC share
> for the LPAR.
> 
> If a logical processor voluntary gives up the processor because it is
> waiting (e.g., wait for I/O), then  wait time is indeed accumulated (see
> SMF70WST, which is valid with z/OS V1R3 on z/Architecture).
> 
> With z/OS on z/Architecture (after z/OS V1R3 when the values were
> corrected), you can calculate (1) logical processor dispatched to physical
> processor, (2) logical processor in wait state, (3) logical processor on
> Logical Processor Ready Queue from Intercept, and (4) logical processor on
> Logical Processor Ready Queue recovering from wait.  All four values are
> useful in analyzing PR/SM activity, and analyzing LPAR busy and delays.
> 
> Cheers,
> 
> Don
> 
> ******
> Don Deese, Computer Management Sciences, Inc.
> Voice: (703) 922-7027  Fax: (703) 922-7305
> http://www.cpexpert.org
> ******
> 
> 

----------------------------------------------------------------------
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

Reply via email to