John, I know, this one is probably buried, I have to cleanup my mailbox so I have to read all these... I just want to test my thinking a bit here... As you know I got confused in the past, so no surprises there...
If the money is not forthcoming, and no real data-sharing is taking place, it should be possible to get the utilization of the 2 CF's, adjust all the non production LPARS to compensate for it, leaving the prod LPAR with the rest. I have never worked in an Outsourcing-type environment where prod LPARS probably need capping, but even so, if the prod is capped at 400, then regular reports should show the un-used CPU, and changes can be made according, but if the PROD is not capped... not problem? Herbie -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: 08 Oktober 2007 08:18 nm To: [email protected] Subject: Re: Logical PRocessor assignment - Processor Weight > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Jacky Bright > Sent: Monday, October 08, 2007 1:58 PM > To: [email protected] > Subject: Logical PRocessor assignment - Processor Weight > > > Hi, > > I have 823 MIPS processor Y02-2096 z9BC > > I have 4 LPARS and 2 CF > > PRODA > DEVEA > TESTA > MAINA > HSCF1 > HSCF2 > > > My requirement is to allocate > 400 MIPS to PRODA > 200 MIPS to DEVEA > 200 MIPS to TESTA > 23 MIPS to MAINA > > It should be capped so that LPARS can not use more than > allocated MIPS. I am > not sure what weight to be assigned to HSCF1 and HSCF2 ? > > What should be my Change LPAR Control Panel settings so that > this can be > achived ? >From what you stated, I think you have a problem. I __assume__ that HSCF1 and HSCF2 are the LPARs running the Coupling Facility code. Do you have ICF or IFL processors? If not, then you must account for those LPARs in your CP allocations, but you have not done so. It takes CPU power to run the Coupling Facilities. You have a total of 823 MIPS to allocate, and you have allocated all 823 MIPS to your z/OS LPARs. Where are you getting the CPU to run the CF LPARs? IBM strongly recommends that a CF LPAR run on a dedicated ICF processor. If you don't do this, the z/OS systems which need the Coupling Facilities will be impacted. So, my first strong recommendation is that you convince management to order two ICF engines and dedicate them, one to each CF LPAR. Once you have done that, then you can simply make the z/OS LPAR weights equal to the MIPS to be allocated and CAP them. If you simply cannot do that, then you'll need to __somehow__ figure out the minimal percentage to give to the CF LPARS and do so. Those MIPS simply must come "off the top" and cannot be used for z/OS. If you don't do this, then z/OS will suffer because it will wait for the CF LPAR to "do its thing". The z/OS LPARs will simply not be able to be guaranteed the CPU MIPS that you have specified. Can't be done. Don't even try. Forget it. Another thing to remember about the CF code is that it is designed as "active wait". That is, it does not normally issue a PSW wait. It loops, testing for interrupts. This means that it runs at 100% of the CPU given it. One thing that IBM has done to "help" in this situation is that you can set the CF LPARs to not do "active wait" by issuing the the command "SET DYNDISP ON" using the HMC. You do this by selecting the CF LPAR in the "CPC Images". You then double click on the "Operating System Message" ICON on the right. In the "Command:" area at the bottom of the page, you type in "set dyndisp on" (withouth the quotes, of course), then click on Send. Again IBM does __NOT__ recommend using this in a production environment. If you do, then z/OS responsiveness can be seriously impacted. It is akin to running DB2 or CICS at too low a priority and it becoming "CPU starved". -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- 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 Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator ---------------------------------------------------------------------- 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
