====================================================================
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).
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).
