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 durin
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
>mo
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 i
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
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
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" decide
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
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 ..
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 Suglian
From: "Gil Peleg"
> Question is how will IBM regard this in terms of licensing charges?
Depends on what was signed I guess - I don't get involved at that level.
One would have to think it outside the spirit of the license - especially if
the CF LPAR was being actively used.
> Another thing is im
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
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 ...
From: "Gil Peleg"
> After a lot of consideration, I dec
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
13 matches
Mail list logo
