We have sufficient enough resources so "set share" isn't a big deal, however, I do have production set at "set share relative 150" and the test systems as "set share rel 50".
When they are competing, the production machines end up with 75% of the processor and the test machines with about 25%. That seems to be cool with me. You don't want certain machines to be cpu starved. We need CICS users, both test and production to be serviced and all IP stuff to be serviced. That includes DB2 when accessed via DRDA. So, in my minds eye (since we don't have any good performance monitors), I use the relative share to "pretty much" allow the test systems about 12% of the processor. This should take care of any CICS and IP traffic. A long time ago, I tried dropping the test machines in the basement, priority wise. CICS started abending AICA, IP would fail on timeouts and DB2 DRDA would faile on timeouts. Many times it was quicker to reipl the test system then to determine what failed and restart the task. Since then, test systems always get "some" cpu. Tom Duerbusch THD Consulting >>> "Hughes, Jim" <jim.hug...@doit.nh.gov> 2/7/2011 2:27 PM >>> Thanks for the reply Marty. Long time, no see. Our VSE systems are mainly interactive CICS or IDMS/DC systems during the day. Night time they become batch machines. The CICS and IDMS/DC systems are mainly accessed via VTAM. Our three production systems are each set to ABSOLUTE 20% with no defined target maximum. The sum of our ABSOLUTE SHARE users does total 100%. With that said, we've asked ourselves is ABSOLUTE 20% enough? The manual says once you have defined the minimum target ABSOLUTE SHARE to total 100%, the scheduler reserves 1% for the RELATIVE SHARE users. It goes on to say that once an ABSOLUTE SHARE user has reached its minimum target share it only gets more if system resources are available. What I am looking for is a way to keep the production systems behaving if a production vse system(absolute share), test vse system(relative share) or a cms user(relative share) begins to loop. The more I read about CP SET SHARE the more I suspect it isn't designed to be a panacea for smooth performance in time of trouble. Maybe I should be investigating the VM Performance Monitor to assist with dynamic performance adjustment in a time of trouble. Comments? ____________________ Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586 Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. ________________________________ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin Zimelis Sent: Monday, February 07, 2011 3:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SET SHARE ABSOLUTE/RELATIVE Catherine, I don't think your understanding of SHARE is backwards, but your expectation of what the performance manager will do might be. I suspect it's trying to keep heavy CPU users from hogging the processors. To get back to the original question, Jim, I think you need to describe what the z/VSE guests are doing. If they're supporting interactive users (e.g., CICS), you'd want one answer from the assembled masses. If they're true batch workloads, the answer should be quite different. Since your system's perceived responsiveness likely depends on how quickly TCPIP (and VTAM) gets serviced, a high share is called for. In your situation, is the same true for RSCS? Regardless, my experience with the conventional wisdom of whether to use relative or absolute shares is dated, so I'll leave detailed recommendations to those with more recent experience. Marty Zimelis On Mon, Feb 7, 2011 at 2:13 PM, McBride, Catherine <cmcbr...@kable.com> wrote: A while ago a very experienced VM person from IBM suggested that we not use ABSOLUTE unless you "absolutely" must cap off a guest to keep it from running away with your real processors. We used that setting on our test system only. Our VSE TOR and VM guest TCPIP both had high relative shares (10000 versus 3000 for regular production guests). Then we started using a performance manager feature of VM Toolkit, it managed share values for us. It set everything the same after VM IPL, but by the end of a normal production day our busiest guests had dropped to the lowest relative share, the ones seldom used had the highest. Meaning my understanding of how relative share worked was backwards or the gizmo in VM Toolkit was. Hopefully Alan or Kris will expound. -----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Hughes, Jim Sent: Monday, February 07, 2011 12:57 PM To: IBMVM@LISTSERV.UARK.EDU Subject: SET SHARE ABSOLUTE/RELATIVE I've read the CP COMMAND manual and the PERFORMANCE manual regarding the SET SHARE command and how it works. Would someone care to comment on how you have used them for your z/VSE production and guest machines? What would suggest for TCPIP/RSCS/VTAM SET SHARE values? Thanks in advance. ____________________ Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586 Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system.
