RMF Workload Activity and CPC activity report

====================================================================
      RMF WORKLOAD REPORT:                                            
====================================================================

      REPORT BY: POLICY=OWL        WORKLOAD=CSSDDF                    
      TRANSACTIONS    ---SERVICE----  SERVICE TIMES  ---APPL %---     
      AVG      0.23   IOC         0   CPU    392.9   CP      4.98     
      MPL      0.23   CPU      3931K  SRB      0.0   AAPCP   0.00     
      ENDED      51   MSO         0   RCT      0.0   IIPCP   0.07     
      END/S    0.01   SRB         0   IIT      0.0                    
      #SWAPS      0   TOT      3931K  HST      0.0   AAP      N/A     
      EXCTD       0   /SEC      1092  AAP      N/A   IIP     2.67     
      AVG ENC  0.23                   IIP     96.1                    
====================================================================

Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the total of the real CPU time on CP engines, plus the NORMALIZED CPU time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.  
But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1 seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine. And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.
And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL SERVICE units from CPs, zIIPs, and zAAPs.                         

In the RMF WLMGL Report, the field APPL% CP is the sum of the cpu times (tcb, srb, rct, iit, hst) divided by the reporting interval. An engine can theoretically be dispatched for the entire interval, so this is like saying the percentage of an engine.  For example, if APPL% CP is 324.9,  that's like saying 3 and a quarter of engine's
worth of cpu resource.



                 C P U  A C T I V I T Y 
                                                                              
            z/OS V2R1                SYSTEM ID TRX1             DATE 09/28/2013            INTERVAL 15.00.037
                                     RPT VERSION V2R1 RMF       TIME 16.45.00              CYCLE 1.000 SECONDS
  
CPU        2827   CPC CAPACITY   869        SEQUENCE CODE 0000000000089F25               
MODEL      609    CHANGE REASON=NONE        HIPERDISPATCH=YES                               
H/W MODEL  H66                                                                            

---CPU---    ---------------- TIME % ----------------   --- MT % ----   LOG PROC      --I/O INTERRUPTS--
NUM  TYPE    ONLINE    LPAR BUSY    MVS BUSY   PARKED   PROD   UTIL     SHARE %       RATE     % VIA TPI 
 0    CP     100.00     4.46         4.41        0.00   ------ ------    13.6  MED    30.65     0.20
 1    CP     100.00     0.00        -----      100.00   ------ ------     0.0  LOW     0.00     0.00
 2    CP     100.00     0.19         0.19        0.00   ------ ------     0.0  LOW     0.00     0.00
 3    CP      30.27     0.00        -----      100.00   ------ ------     0.0  LOW     0.08     0.00


MVS BUSY is a totally different view of cpu utilization from LPAR BUSY (and it can be a little confusing at first), so LPAR BUSY and MVS BUSY values won't necessarily match. The MVS BUSY is the percentage of time this z/OS did not go into a wait state.  So MVS BUSY represents how busy the LPAR was, but it doesn't show how much the LPAR has consumed its online logical engines.  You would look at the LPAR BUSY to determine this. The LPAR BUSY is the percentage of this LPAR's online logical CPs that the LPAR actually consumed.  If the number of logical CPs for an LPAR is equal to the number of physical CPs for the box,  
then LPAR BUSY is like saying what percentage of the box the LPAR
is using.                                                        
                                                                      
LPAR BUSY being less than MVS BUSY means that MVS dispatched work onto one of its logical CPs, but PR/SM took away that physical engine away from the logical engine to give to another LPAR.  Therefore MVS still thinks it has a logical engine (MVS BUSY clock keeps ticking) but PR/SM knows that LPAR is no longer
running on a physical engine (LPAR BUSY clock is no longer ticking).