Below, Tom posted the book's description of the original
implementation of IFAHONORPRIORITY. But customers told us that
they would much prefer that we "filled up the zAAPs" before using
CP resource for Java workload. So in z/OS R8, and also with
APARs OA14131 and OA13953 for z/OS R6 and R7, we changed it to do
that (more or less):
*YES*
Specifies that standard processors run both zAAP processor
eligible and non-zAAP processor eligible work in priority order
when the zAAP processors indicate the need for help from standard
processors. The need for help is determined by the alternate wait
management (AWM) function of SRM for both standard and zAAP
processors. Standard processors help each other and standard
processors can also help zAAP processors if YES is in effect.
Specifying yes does not mean the priorities will always be
honored because the system manages dispatching priorities based
on the goals provided in the WLM service definition. AWM should
not be disabled when IFAHONORPRIORITY=YES is in effect. See the
description for parameter CCCAWMT for a description of AWM.
If zAAP processors are defined to the LPAR but are not online,
the zAAP processor eligible work units are processed by standard
processors in priority order. The system ignores the
IFAHONORPRIORITY parameter in this case and handles the work as
if it had no eligibility to zAAP processors. The zAAP processor
eligible processor times are reported in RMF and SMF for planning
purposes. Standard processors can also run zAAP processor
eligible work (even if IFAHONORPRIORITY is set to NO), if
necessary to resolve contention for resources with non-zAAP
processor eligible work.
IBM suggests that you specify or default to IFAHONORPRIORITY=YES.
*NO*
Specifies that standard processors will not examine zAAP
processor eligible work regardless of the demand for zAAP
processors as long as there is standard processor eligible work
available.
Tom Moulder wrote:
Something else to consider are two IEAOPTxx parameters for WLM control of
zAAP eligible workloads.
IFACROSSOVER controls whether standard CPs will be used for zAAP eligible
work. If YES (the default), then standard CPs will be used along with zAAP
CPs. zAAP CPs will be preferred, but standard CPs are not excluded from
consideration based on workload. If NO, then standard CPs are not
considered for zAAP eligible work unless there are no zAAP CPs present.
IFAHONORPRIORITY controls the workload priority settings for zAAP eligible
work that is executed on standard CPs. If YES (the default), then all work
on a standard CP will execute based on WLM assigned priority. If NO, then
all zAAP eligible work that is assigned for execution on a standard CP will
be scheduled at a lower priority than non-zAAP eligible workloads.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
