Hi Steve, That's such a good point. It's true for IBM MLC, OTC pricing, and ISV pricing. Most OTC products allow sub-capacity pricing, but we see that most customers are still using full-capacity pricing. Also, the majority of ISVs, especially the larger ones, will provide sub-capacity pricing if you push them hard enough.
For more on these issues, you can see our presentations from the last SHARE on our website at http://watsonwalker.com/publications/presentations/. And if you're a Tuning Letter subscriber, look at our 2015 No 4 issue for both the article that Mike mentioned and another article on how HiperDispatch works. All my best, Cheryl Cheryl Watson Watson & Walker, Inc. 100 Central Ave, Suite 1013 Sarasota, FL 34236 P-941-924-6565, F-941-924-4892 www.watsonwalker.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Wednesday, September 28, 2016 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Would HiperDispatch likely delay heavy multitasking job? Cheryl's tuning letter fall 2015 described a case where they implemented MSU capping http://www-01.ibm.com/support/docview.wss?uid=isg1OA49201 and reconfigured their CPUs from 706 to 712 to 730. With LPAR cores consolidating onto one chip with cache shared among multiple z cores, they saw a huge decrease in MIPS and MSUs and delays. HOWEVER, you MUST be licensed for ALL CPUs with billing based on MSUs instead of cores. Otherwise your SOFTWARE BILL based on cores will EXPLODE. On Wed, Sep 28, 2016 at 11:29 AM, Peter Hunkeler <p...@gmx.ch> wrote: > Environment is: > - 6 * z13 model 712 > - some 10 z/OS LPARs on each CEC > - overall LCP to PCP ratio ~ 4- 12-way production sysplex has two 12 > LCP LPARs on each CEC > > - prod LPARs have a ~38% share based on their weight => 4 vertical > high and 1 vertical medium CPs > - Neither CEC nor prod LPARs re overly busy (RMF shows some 40% - 60%) > - CPU Activity Report shows > > Job in question is DB2 reorg utlility job which runs some 30 subtasks in > parallel runs for 2 hours. RMF III (60s intervals) shows that the job mostly > has a good workflow (80%+), is heavily using CP (often 80%-90%) and at the > same time is heavily delayed for CP (40%-60%). The job is seen to use up to > 230% CP. > > > Question I've been asked: Would the job run even faster, if it was moved to a > higher goal, higher importance service class. > > > > I understand that with HiperDispach=YES, WLM will assign work to the CP nodes > it bulids, so the tasks will be dispatched on the same small set of LCPs, > which (for the vertical high CPs) will always be dispatched on the same PCPs. > > > Question: Is the assignment to dispatcher nodes by address space? In other > words, would the 30+ subtasks of the reorg job all be assigned to the same > node? > > > Is so, the job would not be able to run more CPs in parallel at any point in > time than there are LCPs in the node (highds, mediums, and unparked lows), > right? > > > Any thoughts? > > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
