Re: Squeezing defined capacity
Bruno, After a lot of consideration, I decided to adopt your CF idea. We already have a sandbox plex here with 10% ICF defined, we will simply change it to 40% CPs. Its an easy change for us since we dont have to touch anything in the production or developement plexes (only reactivate the sandbox CF). Thanks for the great idea! Gil. On 10/1/05, Bruno Sugliani [EMAIL PROTECTED] wrote: On Sat, 1 Oct 2005 15:03:40 +1000, ibm-main [EMAIL PROTECTED] wrote: The only common sense reaction idea i had as i faced the same problem was to create one extra lpar , without operating system , just put either a CF -- 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: Squeezing defined capacity
We met with IBM this morning and explained the situation. Now waiting for their response on this. We are hoping to start with this today, as the SCRT reports are from the 2nd to the 1st of next month, and today is the 2nd.. Gil. On 10/2/05, ibm-main [EMAIL PROTECTED] wrote: Given that you are on a zSeries processor (presumably) running a current z/OS release, I suspect you will be disappointed with the result of this little bit of skullduggery. Have you asked an opinion of your legal department ???. Shane ... -- 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: Squeezing defined capacity
I've always thought that the restrictions IBM puts on sites and the hoops you have to go through to save money really suck. I've never had to do any of that, as our last 2 machines were an MP2003 and our current MP3000, and the pricing IBM gives you is pretty good without going through all of the gyrations. I've sat through several sessions explaining how to save money at Share and MCMG. Every time I sit through a session, my overriding thought is WHY? Why not just cut the price for everyone! The first time I heard IBM talk about the 4 hour rolling average that pricing is based on, I though there is no way we could utilize this. Since pricing is based on the highest rolling 4 hour average (I hope my understanding of this is right - if not I'm sure someone will correct my thinking), I knew it wouldn't give us any relief, even if we could use it. Every month we get periods of 8 hours or longer where the CPU is pegged out. Why doesn't IBM just take an average for the month in billing, and give us a user friendly way to cap it? Eric Bielefeld PH Mining Equipment ibm-main wrote: Capping LPARs anytime is bad - in the case of defined capacity, probably BAD (broken as designed). Just a monumental example of marketing apparently over-riding the techos. The contortions customers have to perform to use the machinery they paid for is mind-numbingly stupid. The perfect solution Gil mentions, is surely the only common-sense design - *from day 1*. I too have a customer that moves MSUs around - although with less regularity; end of month/quarter, that sort of thing. Shane ... -- 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: Squeezing defined capacity
In a message dated 10/1/2005 9:33:16 A.M. Central Standard Time, [EMAIL PROTECTED] writes: through all of the gyrations. I've sat through several sessions explaining how to save money at Share and MCMG. Every time I sit through a session, my overriding thought is WHY? Why not just cut the price for everyone! Guess it's sorta like the New car sales force. Detroit stamps 'em out, then the sales force haggles with the customer for most markup per unit. They're on commission, more you sell more you make. End of month or end of season deals are common place. Pretty much the same with sub-capacity licensing, you get the privilege of haggling the numbers monthly-can you say gopher guts? Guess what we're pushing for is simplified pricing and accounting like the online car brokers- _www.carsdirect.com_ (http://www.carsdirect.com) or the new _www.vehix.com_ (http://www.vehix.com) maybe the Platform solutions folks will lead the way in this area too. -- 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: Squeezing defined capacity
Actually it's not really IBM that's the majority of the problem price-wise, I could name a few vendors that decided to just recently quadruple their price. Once we made it clear we'd look at alternatives, and brought them in-house for a trial, all of a sudden, the old vendor magically decided they'd rather have the business at the old price than no business at all. -- 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: Squeezing defined capacity
In a message dated 10/1/2005 10:02:29 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Actually it's not really IBM that's the majority of the problem price-wise, Other vendors may be in on the conspiracy, but IBM is the ring leader. Same old FUD and chaotic accounting spun off to the ISVs. Guess I'm still mad about SE's and PSRs. I have to do their job and they want to charge me for the privilege. -- 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: Squeezing defined capacity
On Sat, 1 Oct 2005 15:03:40 +1000, ibm-main [EMAIL PROTECTED] wrote: The perfect solution Gil mentions, is surely the only common-sense design - *from day 1*. I too have a customer that moves MSUs around - although with less regularity; end of month/quarter, that sort of thing. Shane ... The only common sense reaction idea i had as i faced the same problem was to create one extra lpar , without operating system , just put either a CF .. or a machine language loop inside and limit this lpar to the amount of MIPS/MSU you do NOT want to use ... ( hardware weight ) and the other lpars eat the rest intelligently between them Crazy is it not ? Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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: Squeezing defined capacity
Bruno, I heard about this from a colleague. Question is how will IBM regard this in terms of licensing charges? Another thing is im not totally convinced that this will not hurt performance. Not sure PR/SM was designed to handle such a workload -- 100%cpu 24/7... Gil. On 10/1/05, Bruno Sugliani [EMAIL PROTECTED] wrote: The only common sense reaction idea i had as i faced the same problem was to create one extra lpar , without operating system , just put either a CF .. or a machine language loop inside and limit this lpar to the amount of MIPS/MSU you do NOT want to use ... ( hardware weight ) and the other lpars eat the rest intelligently between them Crazy is it not ? Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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
Squeezing defined capacity
Hello all, We are running 2084-303 which provides us 191 MSUs. We have 4 LPARs. Only in a couple of months new workload will start running in production on this machine that will actually require all 191 MSUs, so meanwhile each LPAR has its own Defined Capacity defined. The defined capacity during the day is curretly: PROD - 30 TEST - 15 DEV - 50 SANDBOX - 5 Which adds up to 100 MSUs -- so we are actually using a little over half the machine. Before the night shift, we change the MSUs to: PROD - 55 TEST - 10 DEV - 30 SANDBOX - 5 Which still adds up to 100 MSUs. Currently, the change is done manually by the operators. From time to time we notice that one LPAR is using 100% cpu for long periods of time and is WLM Capped 100%, while other LPARs arent using a lot of cpu. What we would like to do is to detect this situation and automatically change the MSUs in favour of the LPAR running at 100% cpu. For example - if the PROD is at 100% during the night, we would like to take 20 more MSUs from the DEV LPAR and add them to the PROD. We dont want to breach the 100 MSUs limit, it is more than enough, we just need to change MSU weight within these 100 MSUs. The perfect solution would have been to define a Defined Capacity to the entire machine and then define weights and no capping as usual, within this defined capacity (I heard something about being able to do this on System z9 running z/OS 1.8 ??). While writing these lines i'm thinking we just shouldnt have enabled that 3rd CP yet.. but thats the situation now. We dont use System Automation, so what would you recommend as the best solution to dynamically change the Defined Capacity in that case? Currently, the best idea I got is to write a program which uses the HMC API to change the Defined Capacity according to some simple predefined rules. Thanks, Gil. -- 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: Squeezing defined capacity
On Fri, 30 Sep 2005 18:58:38 +0200, Gil Peleg [EMAIL PROTECTED] wrote: of cpu. What we would like to do is to detect this situation and automatically change the MSUs in favour of the LPAR running at 100% cpu. For example - if the PROD is at 100% during the night, we would like to take 20 more MSUs from the DEV LPAR and add them to the PROD. We dont want to breach e 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 Hi In order to detect , use RMFM3B ( ERBR3CPC) that is what we do and it works In order to change without SAO i don't know ... i guess API to HMC is the solution Bruno -- 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: Squeezing defined capacity
From: Gil Peleg : The perfect solution would have been to define a Defined Capacity to the : entire machine and then define weights and no capping as usual, within this : defined capacity (I heard something about being able to do this on System z9 : running z/OS 1.8 ??). Capping LPARs anytime is bad - in the case of defined capacity, probably BAD (broken as designed). Just a monumental example of marketing apparently over-riding the techos. The contortions customers have to perform to use the machinery they paid for is mind-numbingly stupid. The perfect solution Gil mentions, is surely the only common-sense design - *from day 1*. I too have a customer that moves MSUs around - although with less regularity; end of month/quarter, that sort of thing. Shane ... -- 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
