Re: Need to cap my software costs

2008-12-30 Thread John McKown
On Tue, 30 Dec 2008 09:33:44 -0600, Hal Merritt  wrote:

>We have a temporary need to cap our overall rolling four hour average
>until the new box arrives.  We are running z/os 1.7 on a z/9 and, as far
>as I know, don't have the ability to do that. Our particular mission has
>one most loved LPAR that we'd prefer to run at the expense of all else.

Assign the LPAR weights appropriately on the HMC.
 
>
>
>We have enough power so that we are worried only about some occasional
>spikes that the normal soft capping won't handle to suit us. 

Hard cap the LPAR weights on the HMC for the "unloved" LPARs. That way, they
get __at most__ their weight, regardless of what any other LPAR is doing.
This does introduce more PR/SM overhead to manage the "unloved" LPARs.


>
>I know this has been discussed before,  but I'm wondering what the
>current consensus might be for our situation.  
>
> 
>
>For example, what if I really skew the weights such that the unloved
>LPAR's are starved if the most loved needs the cycles. If the unloved
>LPARS are starved, then they should not be able to rack up MSU's and
>thus lower my total. 
>
> 
>
>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


Re: Need to cap my software costs

2008-12-30 Thread Marsan, Tammi
 We also use the HMC to hard cap test lpars during certain day hours.
They are not able to spike above their allocated weights and use
production resources during these times.

Tammi Marsan
MF Performance & Tuning
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John McKown
Sent: Tuesday, December 30, 2008 10:41 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to cap my software costs

On Tue, 30 Dec 2008 09:33:44 -0600, Hal Merritt 
wrote:

>We have a temporary need to cap our overall rolling four hour average 
>until the new box arrives.  We are running z/os 1.7 on a z/9 and, as 
>far as I know, don't have the ability to do that. Our particular 
>mission has one most loved LPAR that we'd prefer to run at the expense
of all else.

Assign the LPAR weights appropriately on the HMC.
 
>
>
>We have enough power so that we are worried only about some occasional 
>spikes that the normal soft capping won't handle to suit us.

Hard cap the LPAR weights on the HMC for the "unloved" LPARs. That way,
they get __at most__ their weight, regardless of what any other LPAR is
doing.
This does introduce more PR/SM overhead to manage the "unloved" LPARs.


>
>I know this has been discussed before,  but I'm wondering what the 
>current consensus might be for our situation.
>
> 
>
>For example, what if I really skew the weights such that the unloved 
>LPAR's are starved if the most loved needs the cycles. If the unloved 
>LPARS are starved, then they should not be able to rack up MSU's and 
>thus lower my total.
>
> 
>
>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

--
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: Need to cap my software costs

2008-12-30 Thread Al Sherkow
You are correct that you do not have LPAR Group Capacity limits with z/OS 1.7.

You can cap those small LPARs but you must use a soft cap on the 'most loved
LPAR' also. Otherwise that will drive the box to 100% (if there is workload
that wants that capacity). 

The max 4HRA for invoicing is simultaneous across the LPARs within any hour.
The limit of this number is the sum of the defined capacities. You might
want to both hard cap and soft cap the small LPARs.

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: Need to cap my software costs

2008-12-30 Thread Hal Merritt
I believe that I have seen an 'under load' effect when trying to manage
low use LPARs.  Consider an LPAR that loafs along slurping a mere 3
MUS's and that is quite enough for its mission. But if I soft cap that
LPAR at, say, 4, and it spikes to, say 10, then the cap is hit within an
interval or two.  

Compare to an LPAR gulping 20 or so and then spiking to 100. It takes
that LPAR a considerable time for the rolling average to climb to a cap
of, say, 80. 

Now this is just a perception and I have not done any measurements but
it is something I think about as I evaluate candidate hard capping and
soft capping values. 

Perhaps one of the math whizzes on the forum could comment.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Al Sherkow
Sent: Tuesday, December 30, 2008 10:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to cap my software costs

You are correct that you do not have LPAR Group Capacity limits with
z/OS 1.7.

You can cap those small LPARs but you must use a soft cap on the 'most
loved
LPAR' also. Otherwise that will drive the box to 100% (if there is
workload
that wants that capacity). 

The max 4HRA for invoicing is simultaneous across the LPARs within any
hour.
The limit of this number is the sum of the defined capacities. You might
want to both hard cap and soft cap the small LPARs.

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
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
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: Need to cap my software costs

2008-12-30 Thread Mark Zelden
On Tue, 30 Dec 2008 09:41:23 -0600, John McKown  wrote:
>
>Hard cap the LPAR weights on the HMC for the "unloved" LPARs. That way, they
>get __at most__ their weight, regardless of what any other LPAR is doing.
>This does introduce more PR/SM overhead to manage the "unloved" LPARs.

That's the first time I've ever heard that (hard capping has more PR/SM
overhead).  Do you have any documentation or numbers to back that
statement up? 

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: Need to cap my software costs

2008-12-30 Thread Ted MacNEIL
>That's the first time I've ever heard that (hard capping has more PR/SM 
>overhead).  Do you have any documentation or numbers to back that statement 
>up? 

I've used hard capping in the past, and I found no difference in overhead.
(Total Dispatch less Effective Dispatch vs Effective on an LPAR basis)
(Total less Effective plus PHYSICAL vs All LPARs Effective)
(Above expressed as a percentage)

Mind you, the last time I measured it was on a z/900 running 2.10 in 64-bit.

And, PR/SM has improved since then.
-
Too busy driving to stop for gas!

--
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: Need to cap my software costs

2008-12-30 Thread Brian Westerman
I'm not sure that the overhead for the hard caps would be a measurable
difference.  I tried to measure it as a test on the z9 here, and I can't see
any real difference.  Maybe I just need a much higher test load, but it
doesn't appear to be a significant hit, (if any at all). 

Brian

--
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: Need to cap my software costs

2008-12-31 Thread Jacky Hofbauer
Some people activate  a Coupling Facility LPAR with a z/OS CP in dyndisp=no
mode: its weight represents the number MSU which you want consume without
billing because these MSUs doesn't enter in the SW bill.

As all functions of capping, it's a technical way. You need to search for a
financial way.

Jacky Hofbauer
zCost Management  

"There are risks and costs to a program of action, but they are far less
than the long-range risks and costs of comfortable inaction".
John F. Kennedy

--
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