How about submitting a requirement to IBM that would  add a control to WLM
This control would re-classify a ZIIP eligible  workload to a different
service class if it spills over to a GCP because you are running your ZIIPS
hot (or hit the "generosity factor" for DB2 work). This service class could
have a lower importance/goal than the original service class. You could
also restrict its CPU consumption using a resource group.

In other words, have a workload run at high priority on ZIIP, but limit it
if it crosses over to GCP.



Now, specifically for Db2 - note this from

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/perf/src/tpc/db2z_ibmziip.html

IIPHONORPRIORITY parameter

The IIPHONORPRIORITY parameter in the IEAOPTxx member of SYS1.PARMLIB
determines whether processes are routed from zIIP specialty engines to
general purpose processors when the zIIP specialty engines have no more
capacity. When IIPHONORPRIORITY is set to NO, general purpose processors
are not used to help with the workload, which can cause the system to hang
as it waits for zIIP resources. Furthermore, when IIPHONORPRIORITY is set
to NO, Db2 does not allow system tasks to become eligible for zIIP
processing. In most cases, IIPHONORPRIORITY should be set to YES.


This applies to Db2 11 and 12.

I would be very very careful about setting IIPHONORPRIORITY to No in a Db2
environment


Mike




On Tue, 18 Jun 2019 at 21:41, Brown, Duncan <dbro...@opers.org> wrote:

> I'm guessing by the responses that not too many shops are using this WLM
> feature.
>
> I'm not sure why you would use this approach and not just use the 'normal'
> controls that we have in WLM and let the dispatcher do its job.  I
> understand that reducing the R4HR is a good thing and preventing any
> softcapping is a good thing.   But it seems to me that the downside far
> outweighs the upside, unless you have a product like z/OS Spark.
>
> Drive the zIIP to a high utilization forcing other zIIP eligible workload
> to use the CP's.   Unless you can time the use to be when the zIIP is not
> busy it seems to me that the parameter will hurt more than it helps.
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Scott Chapman
> Sent: Tuesday, June 18, 2019 7:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: honorpriority=no in WLM
>
> ****************************************************************
> *** NOTE: This email is from an external source: Be cautious ***
> ****************************************************************
>
> ---------------------------------------------------------------------------------------------------------------------
> True, relative to the zIIP workload. But if that zIIP workload is
> relatively low importance and crossing over to the GCPs and raising your
> R4HA, it may make sense to restrict the low importance work instead of
> increasing the R4HA, depending on what your business requirements are. And
> keeping the low importance workload off from the GCP can be a good thing if
> the GCPs are being driven relatively busy by the zIIP-eligible work.
>
> Performance decisions are often dictated by financial concerns. More zIIP
> capacity is always good, but it costs money. And for some machines IBM
> won't sell you more on that generation of machine, making them even more
> difficult to obtain. (I.E. machine replacements are not quick and simple
> solutions.) Lowering software costs to make the platform more
> cost-competitive is good, but that can cost performance. Unfortunately the
> dollar increments that we deal with on the mainframe makes such decisions
> more difficult than just "add another CPU" or "spin up another instance".
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Disclaimer
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast Ltd, an innovator in Software as a
> Service (SaaS) for business. Providing a safer and more useful place for
> your human generated data. Specializing in; Security, archiving and
> compliance. To find out more visit the Mimecast website.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to