6. DATA SOURCES › 6.8 PR/SM LPAR Concepts › 6.8.5 Data Analysis › 6.8.5.2 LPAR Level Analysis › 6.8.5.2.2 Special Purpose LPARs › 6.8.5.2.2.1 Internal Coupling Facilities
6.8.5.2.2.1 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 CA 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 CA MICS data elements 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 normally 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 since 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. Please refer to their data dictionary entries for
more detailed information, such as how they are used in the
computation of derived data elements.
o 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.
o 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,
since 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.
o 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.