RMFOD5 - Daily LPAR MSU Use and Capacity Limits
The RMFOD5 inquiry shows the average MSU usage of LPARs at the RMF interval level.
micsrm140
All LPARs are accounted for with the exception of LPARs that exclusively use specialty engines, such as Coupling Facility LPARs with ICF engines only or Linux LPARs with IFL engines only. If an LPAR uses at least one general-purpose CP engine, a chart is produced. The inquiry generates two separate charts. One for LPARs that have defined capacity limits, and the other for LPARs with no defined capacity limits. One of the uncapped LPARs for each CPC is the 'PHYSICAL' LPAR that captures PR/SM overhead.
The inquiry produces a vertical bar chart where each bar represents the average number of consumed MSUs.
The top example shows the average MSU usage chart for an LPAR (PRSMLPNM=’ZQ02’) running on an IBM z10 2097-712 CPC. The RMF record interval was 30 minutes and the LPAR has a defined capacity limit of 200 MSUs.
The second example shows the average MSU usage chart for another LPAR (PRSMLPNM=’ZQ02’) on the same CPC. The RMF record interval records were 30 minutes and the LPAR has no defined capacity limit.


Uses
The processing capacity of mainframe CPCs is expressed in MSUs (Millions of Service Units per Hour). One of the characteristics of a specific CPC model is its MSU capacity. This capacity is indicative of its workload processing capability and is directly related to the number of general-purpose CP engines configured. Each LPAR that is assigned logical CP processors uses some amount of the available CPC MSUs. The MSU capacity of a CPC and of individual LPARs can influence the cost of software licensed to run on LPARs. Some software licensing costs can be lowered by defining a capacity limit for an LPAR. The limit prevents the LPAR from using the full MSU capacity associated with the logical processors assigned to it.
These charts can be used to monitor the normal MSU consumption of LPARs that use general-purpose CP engines, and also to determine whether the values used as defined capacity limits are correctly set.
Charts
Daily MSU Use for Capped LPARs
All LPARs in these charts have defined capacity limits. If no LPARs in any CPCs have no charts are produced for capped LPARs.

Left Y-axis
LPCAVMSU
Avg Number of Consumed MSUs
Right Y-axis
LPCDEFLM
Partition Defined Capacity Limit
X-axis
HHMM
Hour : Minute
Data element HHMM is derived by concatenating the HOUR and MINUTE of each RMF interval together, separated by a colon, HH:MM (for example, 14:59 meaning hour 14, 59th minute).
Daily MSU Use for Uncapped LPARs
All LPARs in these charts have no defined capacity limits. There is always at least one LPAR in this data extract for each CPC - the ‘PHYSICAL’ LPAR which shows PR/SM overhead.

Left Y-axis
LPCAVMSU
Avg Number of Consumed MSUs
Right Y-axis
LPCDEFLM
Partition Defined Capacity Limit
X-axis
HHMM
Hour : Minute
Data element HHMM is derived by concatenating the HOUR and MINUTE of each RMF interval together, separated by a colon, HH:MM (for example, 14:59 meaning hour 14, 59th minute).
Inquiry Defaults
- HARLPC at the DETAIL timespan file: Cycles 01 - 02
- Filters: PRSMLPTP EQ ‘CP’ or PRSMLPTP EQ ‘PHY’ (select LPARs using CP engines)
- Previous Day is selected
- Derivations:
CPCID
%CPCID ;
DATE
DATEPART(ENDTS);
HHMM
PUT(HOUR(ENDTS),Z2.) || ':' || PUT(MINUTE(ENDTS),Z2.);
Modifications
Modification considerations:
- If you want to see hourly, rather than interval level MSU usage averages, you can change use the HARLPC DAYS timespan.
- You can increase the number of cycles to create charts for multiple days, but remove the step that selects only yesterday’s data.
- Using the following CPC Identification data elements you can filter on CPC:
- fffMOD - Processor Model Family (where fff is the file identifier -- for example., CPU, LPC, and so on.)
- CPCMODID - CPC Model Identifier
- CPCSEQNB - CPC Sequence Number