RMF Special Purpose LPARs

The following types of logical partitions are included in the special purpose category:
micsrm140
  • Coupling Facility LPARs using Integrated Coupling Facilities (ICF)
  • Linux Only LPARs using Integrated Facilities for Linux (IFL)
Special purpose logical partitions do not run RMF, and therefore, as for non-z/OS general-purpose LPARs, the amount of information available to track their activity is limited to the contents of the HARVPA and HARLPC files, that is, to the high-level PR/SM perspective.

Internal Coupling Facilities

The Internal Coupling Facility (ICF) is a specialized processor unit configured as a coupling facility engine. It can only run Coupling Facility Control Code (CFCC or ICMF) in an LPAR operating in Coupling Facility (CF) mode.
As already stated, these LPARs do not run RMF, and therefore the PR/SM related
MICS
files contain very little information about the actual utilization of coupling facility functions. Therefore, just as for z/OS dedicated LPARs for which you had to acquire the actual utilization from an operating-system-oriented file such as HARCPU, tracking coupling facility LPARs must be performed from an inside perspective. The file you can use for this purpose is the CF Configuration and Activity (HARCFP) file. At the end of this section is a list of the
MICS data element
s that are commonly used to report on coupling facility LPARs' activity.
Depending on your data center's requirements for availability, connectivity, cost, and performance, CF logical partitions may be configured with ICFs in four different ways. Each of these options is briefly described below:
Dedicated ICFs only
The performance of a logical partition configured with dedicated ICFs is similar to that of a standalone Coupling Facility, because a dedicated LPAR requires only a little PR/SM dispatching overhead. Furthermore, while ensuring high coupling efficiency, this configuration does not remove any processing capacity from the operating system partitions.
From a reporting standpoint, it is not possible to determine the actual utilization of such a coupling facility LPAR using the HARLPC file because the Coupling Facility Control Code (the "CF operating system") is always running, either processing or searching for service, and hence never enters into a wait state. This results in an LPAR utilization percentage being always close to 100%.
Dedicated ICFs and shared standard CPs
The Dynamic ICF Expansion function, available for any logical partition defined with ICF processors, gives the ability to define shared and dedicated processors to support CF activity. When using Dynamic ICF Expansion, a CF partition running on servers with dedicated ICFs, can acquire, if needed, extra resources from the shared standard CP processors' pool typically used to execute z/OS applications on the same server. Most CF requests are handled by dedicated ICFs; however dynamic expansion takes place, and the standard CP processors help to handle CF activity when the ICFs are very busy. There is a performance trade-off when using this function. If expansion should take place and the standard CP processors start to handle CF requests, the amount of capacity available to the other LPARs using these shared processors is reduced. In this case, lower priority work may start to see throughput reductions as capacity is used by the CF expansion.
As in the previous case, actual utilization of the dedicated ICFs cannot be tracked from the HARLPC file, but you can monitor the capacity of shared standard CP processing "stolen" to the other LPARs.
Shared ICF processors only
It is possible for multiple coupling facility LPARs to share ICFs. Generally some of these LPARs have very low activity rates, but as each coupling facility is continuously polling, even the ones with little activity show up as 100% busy and take their full share of ICF resources. However, if dynamic CF dispatching is enabled for an LPAR, it enters into a wait state as soon as there is no more request in the CF Receiver buffer, hence saving processor cycles. It may be a good option to be used by a production backup coupling facility, or a testing environment coupling facility.
When dynamic CF dispatching is turned on, the LPAR should not appear as being 100% busy anymore in the HARLPC file, but should be closer to what could provide an in-depth coupling facility analysis performed from the HARCFP file.
Dedicated ICFs and shared ICFs
With an enhancement to the Dynamic ICF Expansion function, a CF partition running with dedicated ICFs, can acquire, if needed, extra resources from the pool of shared ICF processors. Again, most CF requests are handled by dedicated ICFs, and expansion only takes place when the CF activity exceeds the dedicated ICFs capacity.
Data elements related to ICF activity
The following data elements help you to identify and report on ICFs. Refer to their data dictionary entries for more detailed information, such as how they are used in the computation of derived data elements.
  • From the HARVPA file:
PRSMPRTP
Logical Processor Type
This element identifies the pool of processors to which a logical processor belongs. For zSeries and earlier models, a value of ICF in this data element does not imply the processor is an internal coupling facility. It could be an IFL or a zAAP as well. Use CPUTYPE described below to accurately identify true ICFs.
CPUTYPE
Physical Engine Type
Internal coupling facilities are identified by a value of ICF in this element (other possible values are CP, IFL, IFA, and IIP). Subsetting or summarizing the HARVPA information by this data element allows you to isolate statistics only pertaining to ICFs. Note that, for System z9 and later models, CPUTYPE contains the same value as PRSMPRTP.
  • From the HARLPC file:
PRSMLPTP
Logical Partition Type
CF partitions using ICF processors are identified by the value of ICF in this data element. However, they are not the only type of LPAR in this category, which also includes Linux-only LPARs configured with IFLs. Therefore, when using PRSMLPTP for subsetting or summarizing HARLPC data, be careful to use your configuration knowledge to select only coupling facility LPARs.
LPCTIDTM
Total ICF Processors Dispatch Time
For a CF partition using dedicated ICF processors, this element will be very close to the interval duration (DURATION). If the LPAR uses shared ICF processors, LPCTIDTM will vary according to the LPAR's weight, and the status of dynamic CF dispatching.
LPCTODTM
Total CP Processors Dispatch Time
For a CF partition using ICF processors, this element will always be equal to zero, unless the LPAR used some resources from the standard CP processors' pool using the dynamic ICF expansion feature.
LPCSIDTM
Total Shared ICF Proc. Dispatch Time
For a CF partition using dedicated ICF processors only, this element will be equal to zero.
For a CF partition using shared ICF processors only, this element will be equal to LPCTIDTM, as all resources used by the LPAR are from the shared pool.
For a CF partition using a mix of dedicated and shared ICF processors, it will be a subset of LPCTIDTM, and it will represent the capacity of the shared ICF processors' pool used by the LPAR while using the enhanced dynamic ICF expansion function.
  • From the HARCFP file:
CFPPCEBS
Effective Processors Utilization
This data element represents the logical utilization of the logical processors in the coupling facility, that is, only the utilization of the effective processors. This is the actual load of the coupling facility.
CFPEFCPU
Effective Processors
This data element contains the number of effective logical processors available to the coupling facility. It will differ from the number of processors defined to the LPAR if the ICF processors are shared.

Integrated Facilities for Linux

The Integrated Facility for Linux (IFL) is a specialized processor unit devoted exclusively to Linux workloads. It can run either a single Linux image under the Linux operating system, or multiple Linux images under the control of z/VM Version 4 and higher, in an LPAR operating in Linux-Only mode.
As for internal coupling facilities, LPARs configured with IFLs do not run RMF; therefore, their utilization statistics are limited. The SMF records created by RMF do not provide any information from inside Linux, and PR/SM is only aware of the total amount of time the special purpose processors assigned to these LPARs were dispatched.
Depending on your data center's requirements, IFLs can be configured as either dedicated or shared:
Dedicated IFLs
Dedicated IFLs are considered by PR/SM as always dispatched. Therefore, the dispatch time is equal to the measurement interval time, regardless of actual processor utilization; and the LPAR appears as being used 100% of the time in the HARLPC file.
Shared IFLs Only
When an LPAR is configured with shared IFLs, that LPAR should not appear as being 100% busy anymore in the HARLPC file. It should report the actual amount of time PR/SM allocated to its operating system.
Data Elements Related to IFL Activity
The following data elements help you to identify and report on IFLs. Please refer to their data dictionary entries for more detailed information, such as how they are used in the computation of derived data elements.
  • From the HARVPA file:
PRSMPRTP
Logical Processor Type
This element identifies the pool of processors to which a logical processor belongs. For zSeries and earlier models, IFLs belong to the generic ICF processors' pool, thus they have a value of ICF in PRSMPRTP. Use CPUTYPE described below to accurately identify IFLs. For System z9 and later models, the value of PRSMPRTP is IFL.
CPUTYPE
Physical Engine Type
Integrated facilities for Linux are identified by a value of IFL in this element (other possible values are CP, ICF, IFA, and IIP). Subsetting or summarizing the HARVPA information by this data element allows you to isolate statistics only pertaining to IFLs. Note that, for System z9 and later models, CPUTYPE contains the same value as PRSMPRTP.
  • From the HARLPC file:
PRSMLPTP
Logical Partition Type
Linux-only logical partitions using IFLs are identified by the value of ICF in this data element. However, they are not the only type of LPAR in this category, which also includes CF LPARs configured with ICFs. Therefore, when using PRSMLPTP for subsetting or summarizing HARLPC data, be careful to use your configuration knowledge to select only Linux LPARs.
LPCTIDTM
Total ICF Processors Dispatch Time (zSeries)
LPCTNDTM
Total IFL Processors Dispatch Time (z9)
For an LPAR using dedicated IFLs, this element will be very close to the interval duration (DURATION). If the LPAR uses shared IFLs, it will vary according to the LPAR's weight, and the actual system load.
LPCTODTM
Total CP Processors Dispatch Time
For an LPAR using IFLs, this element will always be equal to zero.
LPCSIDTM
Total Shared ICF Proc. Dispatch Time (zSeries)
LPCSNDTM
Total Shared IFL Proc. Dispatch Time (z9)
For an LPAR using dedicated IFLs, this element will be equal to zero.
For an LPAR using shared IFLs, this element will be equal to LPCTIDTM (or LPCTNDTM for z9 and later models), as all resources used by the LPAR are from the shared pool.