Hiperdispatch
Is there a cblock which contains an indicator for this? Roland -- 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
Hiperdispatch
>Is there a cblock which contains an indicator for this? SVTAFFON "X'80'" Affinity dispatching is active Regards, George Kozakos z/OS Function Test/Level 3 Supervisor -- 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
Re: Hiperdispatch
George, according to the macro changes this flag was introduced around 2005 $LN=AFFDISP HBB7730 050311 PD00GD: Affinity Dispatcher Well this flag is off on my z9. Roland >>Is there a cblock which contains an indicator for this? >SVTAFFON "X'80'" Affinity dispatching is active > >Regards, >George Kozakos >z/OS Function Test/Level 3 Supervisor > -- 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
Re: Hiperdispatch
Roland Schiradin wrote: George, according to the macro changes this flag was introduced around 2005 $LN=AFFDISP HBB7730 050311 PD00GD: Affinity Dispatcher Well this flag is off on my z9. You're saying the flag is OFF even when HiperDispatch is enabled? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Hiperdispatch
Ed, no I don't have HIPERDISPATCH=YES as it makes no sense on a z9. I just wonder why this flag was added in 2005 long before Hiperdispatch comes out and if it's the correct flag. Roland >Roland Schiradin wrote: >> George, >> >> according to the macro changes this flag was introduced around 2005 >> $LN=AFFDISP HBB7730 050311 PD00GD: Affinity Dispatcher >> Well this flag is off on my z9. >> > >You're saying the flag is OFF even when HiperDispatch is enabled? > >-- >Edward E Jaffe -- 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
Re: Hiperdispatch
Roland Schiradin wrote: Ed, no I don't have HIPERDISPATCH=YES as it makes no sense on a z9. Actually, it does not work on a z9 no matter what you specify in parmlib. A z10 is required for HiperDispatch. So, assuming this is the correct bit and that it's descriptively named (neither of which I know for sure), it should never be set on a z9. -- 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
Re: Hiperdispatch
So the support was there before the processor was available. You need a z10 for HIPERDISPATCH. My testing shows that it is the correct flag and it is set correctly. I guess I'll add that to IPLINFO. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Wed, 29 Oct 2008 00:39:37 -0500, Roland Schiradin <[EMAIL PROTECTED]> wrote: >George, > >according to the macro changes this flag was introduced around 2005 >$LN=AFFDISP HBB7730 050311 PD00GD: Affinity Dispatcher >Well this flag is off on my z9. > >Roland > >>>Is there a cblock which contains an indicator for this? >>SVTAFFON "X'80'" Affinity dispatching is active >> >>Regards, >>George Kozakos >>z/OS Function Test/Level 3 Supervisor >> > -- 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
Re: Hiperdispatch
WLMOPT tools shows the IEAOPT and the runtime HIPERDISPATCH. Is this the IEAOPT setting or the runtime? Thank you for the information and verification. Yep good idea to add this to IPLINFO. Will do the same for SHOWzOS. During my research I also made some other changes MCCAFCTH in IEAOPT was wrong, added display for BLWLTRPCT and BLWLINTHD Perhaps a display for all IEAOPT settings is good idea for IPLINFO Roland >So the support was there before the processor was available. You need >a z10 for HIPERDISPATCH. My testing shows that it is the correct flag >and it is set correctly. I guess I'll add that to IPLINFO. :-) > >Mark >-- -- 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
Re: Hiperdispatch
On Wed, 29 Oct 2008 15:35:58 -0500, Roland Schiradin <[EMAIL PROTECTED]> wrote: >WLMOPT tools shows the IEAOPT and the runtime HIPERDISPATCH. >Is this the IEAOPT setting or the runtime? >Thank you for the information and verification. It shows both. In your case if you turned it on for a z9 it would look like this: HIPERDISPATCH Yes, No Hiperdispatch value(inOPT, Running) > >Yep good idea to add this to IPLINFO. Already done, one my web site (with a few other updates) and sent to Sam for the CBT. Best Regards / Mit freundlichen Grüßen, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Hiperdispatch
At the current moment, IHASVT bit SVTAFFON does not necessarily match the IEAOPTxx Hiperdispatch setting, but does reflect whether at the current time the system is in hiperdispatch mode (there are transition states where the two might not match). We have no plans to change, but conversely no intention of committing to keep, this behavior. Peter Relson z/OS Core Technology Design -- 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
Re: Hiperdispatch
On Thu, 30 Oct 2008 07:19:32 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: >At the current moment, IHASVT bit SVTAFFON does not necessarily match the >IEAOPTxx Hiperdispatch setting, but does reflect whether at the current >time the system is in hiperdispatch mode (there are transition states where >the two might not match). > They will never match on a pre-z10 machine if you specify HIPERDISPATCH=YES in IEAOPTxx. But the WLMOPT tool which looks at the IEAOPTxx setting and SVTAFFON does report both values correctly AFAIK. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Hiperdispatch
For me the runtime setting is fine. I believe the OPT value comes from oco cblock IRARMCTY. Thanks Peter Roland >On Thu, 30 Oct 2008 07:19:32 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: > >>At the current moment, IHASVT bit SVTAFFON does not necessarily match the >>IEAOPTxx Hiperdispatch setting, but does reflect whether at the current >>time the system is in hiperdispatch mode (there are transition states where >>the two might not match). >> > >They will never match on a pre-z10 machine if you specify HIPERDISPATCH=YES >in IEAOPTxx. But the WLMOPT tool which looks at the IEAOPTxx setting and >SVTAFFON does report both values correctly AFAIK. > -- 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
ZAAPAWMT under Hiperdispatch
In our development environment, we have dozens of Websphere App servers running, and we only have one zAAP (on a z10-704). The aggravation is that we have significant overflow of zAAP eligible workload to GP engines, despite the zAAP being nowhere near 100% busy (whereas all the GPs are 100% busy, pretty much 24x7! with a slight respite at weekends.). With Hiperdispatch off, ZAAPAWMT is 12000, and with it turned on, it gets reduced to 3200 (I think these are standard values, rather than site specific). I am anticipating that increasing the ZAAPAWMT value would help raise the utilisation of the zAAP, thus reducing the impact on the GP engines. Does anyone have any experience of altering the ZAAPAWMT values with Hiperdispatch turned on? Or is conventional wisdom not to mess with the IBM defaults? Would be grateful for any insights/experience anyone may have on this subject. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Hiperdispatch and IRD
We are implementing Hiperdispatch, but we have IRD already setup and working fine for quite sometime. I have read that when both are on, the CPU VARY option is disabled. Besides this, are there any other functions that might cause some problems or not work? Which one is better or brings the largest benefits? Should we leave them both active? FYI, we have z/OS 1.9 with put level 0812 working on two z10's (703 and 702). Any inputs, would be really appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HiperDispatch OA27869 IRA863E HIPERDISPATCH MODE ALGORITHM DETECTED AN ERROR. RC=002F
http://www.ibm.com/support/docview.wss?uid=isg1OA27869 OA27869: IRA863E HIPERDISPATCH MODE ALGORITHM DETECTED AN ERROR. RC=002F We ran into this problem just once but it was the first time for someone in the field and IBM took APAR OA27869 which is now closed. Because we already had the fix for OA26540 is applied we were able to do a SET OPT=xx for our normal IPL time IEAOPTxx to turn HiperDispatch back on. You can review the documentation in the APAR now that it is closed using the link above. We picked up on the original problem right away because we had the Health Checker for z/OS configured to send exceptions to our team. This is an update to the HiperDispatch segment in Bit Bucket x'25' from SHARE in Austin. http://ew.share.org/client_files/callpapers/attach/SHARE_in_Austin/S2817SK213820.pdf http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=18797&conference_id=20 Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ZAAPAWMT under Hiperdispatch
Graham Harris wrote: In our development environment, we have dozens of Websphere App servers running, and we only have one zAAP (on a z10-704). The aggravation is that we have significant overflow of zAAP eligible workload to GP engines, despite the zAAP being nowhere near 100% busy (whereas all the GPs are 100% busy, pretty much 24x7! with a slight respite at weekends.). Do you have Honor Priority turned on (IFAHONORPRIORITY=YES) in IEAOPTxx, or off (IFAHONORPRIORITY=NO)? -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ZAAPAWMT under Hiperdispatch
See OA31072.. In our development environment, we have dozens of Websphere App servers running, and we only have one zAAP (on a z10-704). The aggravation is that we have significant overflow of zAAP eligible workload to GP engines, despite the zAAP being nowhere near 100% busy (whereas all the GPs are 100% busy, pretty much 24x7! with a slight respite at weekends.). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ZAAPAWMT under Hiperdispatch
Allan Staller said: >>See OA31072.. Thanks Allan, that looks like a relatively new one, although doesnt look like it applies in our environment. John Eels said: >>Do you have Honor Priority turned on (IFAHONORPRIORITY=YES) in IEAOPTxx, or off (IFAHONORPRIORITY=NO)? We have this set to YES, and thus expect to have the 'needs help' behaviour taking place, but our GPs are being just a little too 'helpful' I have had another off-list response, which confirms that upping the ZAAPAWMT value is potentially appropriate in our situation, and so I will look to getting this increased, and assessing the impact. Thanks. On 20 May 2010 13:40, Staller, Allan wrote: > See OA31072.. > > > In our development environment, we have dozens of Websphere App servers > running, and we only have one zAAP (on a z10-704). > > The aggravation is that we have significant overflow of zAAP eligible > workload to GP engines, despite the zAAP being nowhere near 100% busy > (whereas all the GPs are 100% busy, pretty much 24x7! with a slight > respite > at weekends.). > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z10 and HiperDispatch question.
Hello all, I would like to know if any of you have this feature turned on and what benefits have you noticed from it. We are switching to a z10BC U03 this weekend from a z/890 370 and I am interested in what experiences any of you have had. Our WLM policy is okay and I may need to tweak a few areas pending HiperDispatch. I am now reading the White Paper (Planning Considerations for HiperDispatch Mode) so I can get a feel for it. Any one have any comments good or bad on this? Thanks up front, Claude Claude Richbourg Florida Department of Corrections z Systems Programmer 850-921-1383 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HIPERDISPATCH=YES and z9
This was just posted on MXG-L by Chuck Hopf. I told him that I would post it here and he said go ahead. When he posts the APAR on MXG-L I'll post that here also. If you have a mix of z9 and z10 processors with a common IEAOPT and you are using HIPERDISPATCH=YES with CPUVARY=YES for IRD, this affects you. The two parameters are mutually exclusive but accepted with no obvious error except that the CPUVARY by IRD will be disabled on z9 processors. At IPL time, HIPERDISPATCH=YES disables CPUVARY but then when it can't use HIPERDISPATCH on a z9 does not turn it back on. When I have an APAR number I will post it. In the meantime, to fix it, a separate OPT for the z9 systems with HIPERDISPATCH=NO will solve the problem either at IPL time or by using the SETOPT command. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
HiperDispatch with mostly small LPARs
We are thinking about HiperDispatch implementation but I am not sure it is appropriate in our environment. We have a z196 Host = 2817-M66/700 with 12 CPs. There is one large LPAR with a share that allows access to 8.89 CPs. It is assigned 12 LPs. The rest of the LPARs on this box have very low shares. There are 8 additional LPARs and the highest physical processor share is 1.05. The rest of the PP shares vary from 0.16 to 0.53. I am not sure that there is any point to turning on Hiperdispatch for these LPARs. I read an article by Don Deese where he said HiperDispatch Management Mode cannot be effective in an LPAR unless the LPAR has a share of CPC capacity that results in at least 0.5 (the #CP value) equivalent physical processors. This was in a document about the z10 and I am wondering whether it is also true on a z196. If we enable HiperDispatch on the one LPAR will there be a negative effect on the other LPARs? In total now there are 37 LPs assigned for the box. I think this is a high number. Any comments would be appreciated. Mike Hall Millennium II Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
On Thu, 15 Jan 2009 08:52:21 -0500, Richbourg, Claude wrote: >Hello all, > >I would like to know if any of you have this feature turned on and what >benefits have you noticed from it. >We are switching to a z10BC U03 this weekend from a z/890 370 and I am >interested in what experiences any of you have had. Our WLM policy is >okay and I may need to tweak a few areas pending HiperDispatch. > >I am now reading the White Paper (Planning Considerations for >HiperDispatch Mode) so I can get a feel for it. >Any one have any comments good or bad on this? > We had it on but had to turn it off. We are waiting for APAR OA26789 to close. The description of the APAR says "PROCESSOR NOT UNPARKED WHEN LOW WEIGHT PARTITION RUNNING 100%". But I wouldn't call the LPARs we were having problems with "low weight". Basically, the algorithms are too aggressive in the parking of engines and we were not able to drive the CPCs to 100% busy. That is the way we run during peeks (a peek can be most of prime shift depending on the day of the week / month). We rely on "stealing" heavily... especially with sysplexes on the same CPCs in different time zones. The amount of overhead we would save by having it on (2-4% percent perhaps based on our configurations), didn't offset the problems we were seeing (engines parked with MVS busy 100% and spare capacity on the CPC). >From what I understand, OA26789 will be used to make more changes than just what the description says. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
Bernie Pierce from IBM PO'K indicated that a round of PTFs to fix the currently outstanding issues should be issued at the end of January. Wait until then. We've definitely have strange unexplainable things happen that went away when HD was turned off. On a side note, is anyone running, or planning to run HD on a machine with z/OS and z/VM? IBM doesn't mix their machines with z/OS and z/VM on it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Thursday, January 15, 2009 SYSN 06:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z10 and HiperDispatch question. On Thu, 15 Jan 2009 08:52:21 -0500, Richbourg, Claude wrote: >Hello all, > >I would like to know if any of you have this feature turned on and what >benefits have you noticed from it. >We are switching to a z10BC U03 this weekend from a z/890 370 and I am >interested in what experiences any of you have had. Our WLM policy is >okay and I may need to tweak a few areas pending HiperDispatch. > >I am now reading the White Paper (Planning Considerations for >HiperDispatch Mode) so I can get a feel for it. >Any one have any comments good or bad on this? > We had it on but had to turn it off. We are waiting for APAR OA26789 to close. The description of the APAR says "PROCESSOR NOT UNPARKED WHEN LOW WEIGHT PARTITION RUNNING 100%". But I wouldn't call the LPARs we were having problems with "low weight". Basically, the algorithms are too aggressive in the parking of engines and we were not able to drive the CPCs to 100% busy. That is the way we run during peeks (a peek can be most of prime shift depending on the day of the week / month). We rely on "stealing" heavily... especially with sysplexes on the same CPCs in different time zones. The amount of overhead we would save by having it on (2-4% percent perhaps based on our configurations), didn't offset the problems we were seeing (engines parked with MVS busy 100% and spare capacity on the CPC). >From what I understand, OA26789 will be used to make more changes than just what the description says. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
on a z10BC U03 you probably won't see a 'measurable' difference. All the LPARs are in a single book and all the physical engines of an LPAR will be close together already. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
We are running a Z10BC W03 and we did see some difference with Hyperdispatch on. When running a IO workload on one LPAR, the three CP's didn't balance out. One was running close to 100% and the others were around 20% or less. The LPAR was running around 50% utilization. When we turned off Hyperdispatch all three CP's ran at the same utilization. The IO/sec and LPAR utilization was the same with it on or off so the difference wasn't measurable from that standpoint. Thanks, Chris Burgess EMC² where information lives Phone: 1-800-445-2588 x42149 1-508-249-2149 Pager: 1-877-443-8447 Fax: 1-508-544-2076 Email: burgess_christop...@emc.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Al Sherkow Sent: Thursday, January 15, 2009 12:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z10 and HiperDispatch question. on a z10BC U03 you probably won't see a 'measurable' difference. All the LPARs are in a single book and all the physical engines of an LPAR will be close together already. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
That is how HyperDispatch should work. Engines will be pseudo dedicated to an LPAR. 3 LPARs on a W03 (or U03 of the orig question) with 3 logicals each would tend to have one engine at 100% and the other two close to zero (if all have equal demand) and weights of 33%. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
If you're curious about how things are being distributed, and have RMF, the RMF post-processor CPU report will show you the processor share from an LPAR point of view. Note that Al isn't completely correct, in that sometimes HiperDispatch may decide to give you two medium CPs (CPs that have a logical processor share between 1 and 99%) instead of 1 high CP (a CP with a 100% logical processor share). --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 Al Sherkow Sent by: IBM Mainframe Discussion List 01/16/2009 09:50 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@bama.ua.edu cc Subject Re: z10 and HiperDispatch question. That is how HyperDispatch should work. Engines will be pseudo dedicated to an LPAR. 3 LPARs on a W03 (or U03 of the orig question) with 3 logicals each would tend to have one engine at 100% and the other two close to zero (if all have equal demand) and weights of 33%. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
I believe Al is correct on the small processor that was indicated. You'd need to have more than 3 processors to see a 100%, some in the middle, and some parked. Actually on larger n-way images, you could see several virtually dedicated, several being shared somewhere in the middle range, and several parked. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kevin Mckenzie Sent: Friday, January 16, 2009 SYSN 03:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z10 and HiperDispatch question. If you're curious about how things are being distributed, and have RMF, the RMF post-processor CPU report will show you the processor share from an LPAR point of view. Note that Al isn't completely correct, in that sometimes HiperDispatch may decide to give you two medium CPs (CPs that have a logical processor share between 1 and 99%) instead of 1 high CP (a CP with a 100% logical processor share). --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 Al Sherkow Sent by: IBM Mainframe Discussion List 01/16/2009 09:50 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@bama.ua.edu cc Subject Re: z10 and HiperDispatch question. That is how HyperDispatch should work. Engines will be pseudo dedicated to an LPAR. 3 LPARs on a W03 (or U03 of the orig question) with 3 logicals each would tend to have one engine at 100% and the other two close to zero (if all have equal demand) and weights of 33%. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 and HiperDispatch question.
The algorithms for distribution of logical processors among high/medium/low polarity have been documented in several recent IBM presentations. See SHARE proceedings and CMG proceedings for a description. The distribution is based on the LPAR's share of physical engine capacity. In summary: - Always have at least one medium polarity - If physical share is GT 1.5, assign high polarity processors subject to above rule (e.g., physical share GT 1.5, assign 1 high polarity; if share GT 2.5, assign 2 high polarity, etc.). - If remaining share after assigning high polarity is LE 1.5 and remaining share is GT 1, assign 2 mediums (if at least two logical processors have been assigned to LPAR). - If at least two logical processors are assigned, always have at least 2 unparked logical processors - Park all logical processors not explicitly assigned high polarity or medium polarity. The algorithms change somewhat, depending on which APARs have been applied (for example, the "always have two logical processors unparked" rule is applicable with APAR OW24272). The above algorithms are static (that is, the high and medium polarity processor are formed based on weight/share and do not change unless the weight/share change). Consequently, the result of the algorithms can be computed easily using a spreadsheet. IRD LPAR Weight Management algorithms can change the weight/share associated with an LPAR, so the distribution of high/medium polarity can dynamically change based on IRD actions. - If low polarity processors are parked, they can be unparked based on the utilization of existing unparked logical processors, the demand for more CPU capacity in the LPAR, the unused capacity share available from other LPARs, etc. Unparked low polarity logical processors will be parked if the computer capacity conditions are no longer applicable. Unparked low polarity logical processors will share equally with the medium processor(s) in the medium share. The algorithms that decide to park/unpark low polarity logical processors are executed every 2 seconds. These algorithms are being revised because the current algorithms are not sufficiently responsive. For example, the current algorithms require that all unparked logical processors must be at least 94% busy before another low polarity logical processor will be unparked. According to Bernie Pierce (WLM Developer) at his CMG presentation last month, the revised algorithms should be available by end of January. As mentioned, you can put the above algorithms into a spreadsheet and experiment with various combinations of weight/share among the 3 LPARs each having 3 logical processors as described by the OP. That will answer any questions about the distribution of logical processors into high/medium/low polarity depending on LPAR share of physical capacity. You will notice, for example, that it is not possible to have TWO medium logical processors each with a share of 99%. A single medium can have 99%, but if the combined share of two mediums was more than 150%, then the algorithms would form one high and one medium. Regards, Don ** Don Deese, Computer Management Sciences, Inc. Voice: (804) 776-7109 Fax: (8043) 776-7139 http://www.cpexpert.org ** At 06:26 PM 1/16/2009, you wrote: If you're curious about how things are being distributed, and have RMF, the RMF post-processor CPU report will show you the processor share from an LPAR point of view. Note that Al isn't completely correct, in that sometimes HiperDispatch may decide to give you two medium CPs (CPs that have a logical processor share between 1 and 99%) instead of 1 high CP (a CP with a 100% logical processor share). --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 Al Sherkow Sent by: IBM Mainframe Discussion List 01/16/2009 09:50 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@bama.ua.edu cc Subject Re: z10 and HiperDispatch question. That is how HyperDispatch should work. Engines will be pseudo dedicated to an LPAR. 3 LPARs on a W03 (or U03 of the orig question) with 3 logicals each would tend to have one engine at 100% and the other two close to zero (if all have equal demand) and weights of 33%. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.8/1898 - Release Date: 1/16/2009 3:09 PM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Se
Re: HIPERDISPATCH=YES and z9
APAR Identifier .. OA26225 Last Changed 08/08/21 VARYCPU MANAGEMENT DISABLED WHEN RUNNING ON A Z9 AND SPECIFYING HIPERDISPATCH=YES Symptom .. IN INCORROUT Status ... INTRAN Severity ... 2 Date Closed . Component .. 5752SC1CX Duplicate of Reported Release . 730 Fixed Release Component Name 5752 SYS RSRCE Special Notice Current Target Date .. Flags SCP ... Platform Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: When running on a z9 and specifying in the IEAOPTxx parmlib member HIPERDISPATCH=YES and VARYCPU=YES (or the default of VARYCPU=YES is taken), vary cpu management is disabled. When running on z9 hardware Hiperdispatch is not possible, so IRABAINI will not enable Hiperdispatch, but it also does not re-enable vary cpu management. LOCAL FIX: When running on a z9, do not specifiy HIPERDISPATCH=YES in the IEAOPTxx parmlib member -- 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
Re: HiperDispatch with mostly small LPARs
The "OLD" ROT for LP:CP was 2:1. More recent hardware (e.g. 2817) have increased this limit to about 3:1 The exact value between 2:1 and 3:1 depends on the level of pain you can endure. YMMV. The amount of overhead due to context switching when another LP is dispatched varies with the activity and quantity of the LPs. DANGER! Will Robinson DANGER! This IS NOT a linear equation. IMO it tends towards cubic once the 3:1 ratio is exceeded! HTH, We are thinking about HiperDispatch implementation but I am not sure it is appropriate in our environment. We have a z196 Host = 2817-M66/700 with 12 CPs. There is one large LPAR with a share that allows access to 8.89 CPs. It is assigned 12 LPs. The rest of the LPARs on this box have very low shares. There are 8 additional LPARs and the highest physical processor share is 1.05. The rest of the PP shares vary from 0.16 to 0.53. I am not sure that there is any point to turning on Hiperdispatch for these LPARs. I read an article by Don Deese where he said "HiperDispatch Management Mode cannot be effective in an LPAR unless the LPAR has a share of CPC capacity that results in at least 0.5 (the "#CP" value) equivalent physical processors." This was in a document about the z10 and I am wondering whether it is also true on a z196. If we enable HiperDispatch on the one LPAR will there be a negative effect on the other LPARs? In total now there are 37 LPs assigned for the box. I think this is a high number. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HiperDispatch with mostly small LPARs
I think it will depend on how many books you have. HD will likely help your largest LPAR because HD will give exclusive access to 8 physical CPs across 2 chips which will result in better cache utilization. We have 2 LPARS across 8 Physicals with 45%/55% weight distribution and are seeing about 5% benefit from HD. Turn on SMF113s before you turn on HD so that you can measure the uplift. I just gave a pitch at SHARE and you can see some of SMF 113 metrics: http://share.confex.com/share/117/webprogram/Session9689.html Of course it also depends on your workload. Regards, Santosh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HiperDispatch isn't working on a z10
Here is a problem we opened with IBM and are wondering if anyone else has observed this as well. We have currently turned off HiperDispatch because IBM wants the CE to gather data and because of other issues, we are very uncomfortable with that. We're running z/OS 1.10 in a parallell sysplex. One of our CEC's is a 2097-717 with 4 LPARs defined. One of the LPARs is not active. The weights of the LPARs is as follows: LPAR1 - 66% LPAR2 - 20% LPAR3 - 10% The LPAR that is down is LPAR4 and is weighted at 4%. During the online day, our CPU is busy but at night there is excess capacity. The LPAR LPAR3 during the day has two CPs configured online. At 19:00 when the demand drops, we configure four more engines online. As the applications throw more work to LPAR3, the utilization gets to about 11.5% but that's it. It won't take any more even though the entire CEC is about 70-80% busy. I thought that as long as the CEC had capacity, the LPAR could take more than it's weight. When I look at the engines through our monitor, the four engines that I configured online are in a PARKED state. Is this working correctly or is there something else I should do to allow more work to flow to LPAR3 during off peak times? ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email:jim_peter...@homedepot.com 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell phone The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment. - The information contained in this e-mail and any attached documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been sent to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HiperDispatch isn't working on a z10
Have you done anything with your WLM Service Policy to support HD? Do you have much Web work? If you use HD, I would not suggest playing manual IRD. Configure each LPAR with the number of engines need to handle the peak work; the HD will park the excess as needed. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Petersen, Jim Sent: Wednesday, July 14, 2010 Wednesday 11:51 AM To: IBM-MAIN@bama.ua.edu Subject: HiperDispatch isn't working on a z10 Here is a problem we opened with IBM and are wondering if anyone else has observed this as well. We have currently turned off HiperDispatch because IBM wants the CE to gather data and because of other issues, we are very uncomfortable with that. We're running z/OS 1.10 in a parallell sysplex. One of our CEC's is a 2097-717 with 4 LPARs defined. One of the LPARs is not active. The weights of the LPARs is as follows: LPAR1 - 66% LPAR2 - 20% LPAR3 - 10% The LPAR that is down is LPAR4 and is weighted at 4%. During the online day, our CPU is busy but at night there is excess capacity. The LPAR LPAR3 during the day has two CPs configured online. At 19:00 when the demand drops, we configure four more engines online. As the applications throw more work to LPAR3, the utilization gets to about 11.5% but that's it. It won't take any more even though the entire CEC is about 70-80% busy. I thought that as long as the CEC had capacity, the LPAR could take more than it's weight. When I look at the engines through our monitor, the four engines that I configured online are in a PARKED state. Is this working correctly or is there something else I should do to allow more work to flow to LPAR3 during off peak times? ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email:jim_peter...@homedepot.com 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell phone The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment. - The information contained in this e-mail and any attached documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been sent to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HIPERDISPATCH (was Re: First z10 BC on West Coast)
> >> 2) The majority of installations that bring in a z10 are not turning on >> > >I did not know that. Where did you hear that? Cheryl's newsletter? >Another source? > The LSPR numbers are with HIPERDISPATCH=ON. We already have trouble getting out of the box what zPCR tells us to expect (no surprise, we've had that problem since z990). There is no way we could have put one of these puppies in without starting off with HIPERDISPATCH=ON unless we wanted to purchase some (very expensive!) extra engines.I suspect the same is true with most if not all medium to large shops. We weren't the first kids on our block to get a upgrade this time. I wonder if IBM let customers turn on extra engines for free while some of the bugs with HIPERDISPATCH were being worked out (still ISV issues with this approach). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: HIPERDISPATCH (was Re: First z10 BC on West Coast)
On Mon, 8 Dec 2008 16:46:15 -0600, Mark Zelden <[EMAIL PROTECTED]> wrote: >>> 2) The majority of installations that bring in a z10 are not turning on >>> >> >>I did not know that. Where did you hear that? Cheryl's newsletter? >>Another source? > >The LSPR numbers are with HIPERDISPATCH=ON. We already have trouble >getting out of the box what zPCR tells us to expect (no surprise, we've had >that problem since z990). There is no way we could have put one of these >puppies in without starting off with HIPERDISPATCH=ON unless we wanted >to purchase some (very expensive!) extra engines.I suspect the same >is true with most if not all medium to large shops. > >We weren't the first kids on our block to get a upgrade this time. I wonder if >IBM let customers turn on extra engines for free while some of the bugs with >HIPERDISPATCH were being worked out (still ISV issues with this approach). > Of course I meant HIPERDISPATCH=YES as far as the correct setting in IEAOPTxx, but you get the idea... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
HiperDispatch OA26789 PROCESSOR NOT UNPARKED WHEN PARTITION RUNNING 100% EVEN THOUGH THERE IS AVAILABLE CAPACITY ON THE CEC
http://www.ibm.com/support/docview.wss?uid=isg1OA26789 OA26789: PROCESSOR NOT UNPARKED WHEN PARTITION RUNNING 100% EVEN THOUGH THERE IS AVAILABLE CAPACITY ON THE CEC We have been running the APAR fix since the beginning of March and just this morning promoted it to the rest of our LPARs on a larger z10. You can review the documentation in the APAR now that it is closed using the link above. The original HiperDispatch implementation had no consideration for MVS Busy at all. The revised processing which considers both MVS Busy and CEC Utilization suits us better allowing us to better utilize available CEC capacity. I continue to see HiperDispatch as a "very good thing" that has definitely provided relief on N-WAY overhead while moving us back to letting z/OS and the hardware manage itself. Kudo's to the wizards in Poughkeepsie. Now if only all the systems management and reporting tools would catch up:-( That is still a bit of a patchwork with support here (RMF data portal) but not there (RMF III 3270 and some OEMs). # of processors on-line is now useless if not displayed in with counts of high/med/low processors when running with HiperDispatch. This is an update to the HiperDispatch segment in Bit Bucket x'25' from SHARE in Austin. http://ew.share.org/client_files/callpapers/attach/SHARE_in_Austin/S2817SK213820.pdf http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=18797&conference_id=20 Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
