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
