Re: Dummy LPAR to store excess MIPS
Hi Timothy I haven't heard of that either. I was thinking of vendors that license for less than full capacity for a specific number of MSUS or MIPS. 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: Dummy LPAR to store excess MIPS
I haven't heard of vendors that both have sub-capacity licensing and then proceed to define sub-capacity differently than the four hour rolling average. But I suppose anything is possible. (A 3.28 hour rolling average?) I'm still not sure what the use case is for a dummy LPAR, though, at least nowadays. If the purpose is to keep tight control over a particular non-IBM software product's CPU consumption for licensing reasons, then presumably that's always true every minute, every day. So then why would you want to pay for the dummy LPAR's z/OS MSUs? What about a hard cap? I guess you could also vary engines off, but that's a rather coarse adjustment on most machines. Or what about creating a coupling facility LPAR? - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.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: Dummy LPAR to store excess MIPS
LPAR Group Capacity Limits came with z/OS 1.8, so that should be available to most sites. Requires z hardware. What some customers have not understood is you are allowed to have multiple LPAR Groups on a single machine and they are able to work across sysplex boundaries. So some sites use one group to limit a whole machine to 80% of installed capacity regardless of the number of LPARs. I have other sites that have one group for Production LPARs, a second for Development LPARs and a third group just for QA 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: Dummy LPAR to store excess MIPS
Timothy -- Yes, Defined Capacity and Group Capacity Limits can do this, but not *all* vendors. For many vendors, but not for all. Hence some sites are using these other techniques. Al 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: Dummy LPAR to store excess MIPS
OOPS - make that SCRT not SCLM. stupid fingers. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John > Sent: Friday, March 11, 2011 7:20 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Dummy LPAR to store excess MIPS > > We use Group Capacity to group our two LPARs together in a > single "capacity group". We then tell PR/SM how many MSUs > these two LPARs together may use. PR/SM works with WLM on > z/OS to "cap" the two LPARs such that they do not exceed this > group MSU capacity. SCLM works with this so that our software > bill is capped by this group capacity cap. > > Oh, this only works for z/OS release 1.10 and above on a z > series machine. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain > confidential or proprietary information. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten > and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West > National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bond, Dick (DIS) > > Sent: Thursday, March 10, 2011 4:58 PM > > To: IBM-MAIN@bama.ua.edu > > Subject: Dummy LPAR to store excess MIPS > > > > Does anyone use the concept of a "dummy" LPAR to store excess > > "MIPS" to avoid software costs? > > > > Suggest other methods of storing unused capacity? > > > > Thanks. > > > > Dick Bond > > Department of Information Services > > CSD Production Support > > di...@dis.wa.gov > > > > > -- > > 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 > > -- 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: Dummy LPAR to store excess MIPS
"Capping" works fine for us -jc- > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Field, Alan C. > Sent: Thursday, March 10, 2011 10:35 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Dummy LPAR to store excess MIPS > > Dick, > > We've been doing this for a number of months. We have a 2094-704 that we > dedicated one CPU to our sysprog lpar (so we didn't need to create a > parking lpar). It seems to be working to hold down the costs on the > other production lpars. > > Alan > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Bond, Dick (DIS) > Sent: Thursday, March 10, 2011 16:58 > To: IBM-MAIN@bama.ua.edu > Subject: Dummy LPAR to store excess MIPS > > Does anyone use the concept of a "dummy" LPAR to store excess "MIPS" to > avoid software costs? > > Suggest other methods of storing unused capacity? > > Thanks. > > Dick Bond > Department of Information Services > CSD Production Support > di...@dis.wa.gov > > -- > 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 -- 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: Dummy LPAR to store excess MIPS
We use Group Capacity to group our two LPARs together in a single "capacity group". We then tell PR/SM how many MSUs these two LPARs together may use. PR/SM works with WLM on z/OS to "cap" the two LPARs such that they do not exceed this group MSU capacity. SCLM works with this so that our software bill is capped by this group capacity cap. Oh, this only works for z/OS release 1.10 and above on a z series machine. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bond, Dick (DIS) > Sent: Thursday, March 10, 2011 4:58 PM > To: IBM-MAIN@bama.ua.edu > Subject: Dummy LPAR to store excess MIPS > > Does anyone use the concept of a "dummy" LPAR to store excess > "MIPS" to avoid software costs? > > Suggest other methods of storing unused capacity? > > Thanks. > > Dick Bond > Department of Information Services > CSD Production Support > di...@dis.wa.gov > > -- > 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: Dummy LPAR to store excess MIPS
I am assuming that you are on a z9. It is my understanding that under z10 such machinations are not needed. Rob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Walter Medenbach Sent: Friday, March 11, 2011 5:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Dummy LPAR to store excess MIPS Defined capacity capping uses a rolling 4 hour average. Usage before the cap kicks in can therefore exceed some license agreements. We have successfully use a dummy coupling facility soaker LPAR. The ICF must have dynamic dispatch set to OFF to ensure that it goes into a cpu loop. The amount of soak is controlled by capping the ICF LPAR and adjusting the weight as required. Walter Medenbach -- 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: Dummy LPAR to store excess MIPS
Yes, but it wouldn't get the sysprogs a nice comfy fast playpen. :-) Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker From: Timothy Sipples To: IBM-MAIN@bama.ua.edu Date: 11/03/2011 06:07 Subject: Re: Dummy LPAR to store excess MIPS Sent by: IBM Mainframe Discussion List Wouldn't a defined capacity setting (a.k.a. "softcap"), group and/or individually, be a lot less complicated and work at least as well? - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Dummy LPAR to store excess MIPS
Defined capacity capping uses a rolling 4 hour average. Usage before the cap kicks in can therefore exceed some license agreements. We have successfully use a dummy coupling facility soaker LPAR. The ICF must have dynamic dispatch set to OFF to ensure that it goes into a cpu loop. The amount of soak is controlled by capping the ICF LPAR and adjusting the weight as required. Walter Medenbach -- 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: Dummy LPAR to store excess MIPS
Wouldn't a defined capacity setting (a.k.a. "softcap"), group and/or individually, be a lot less complicated and work at least as well? - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.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: Dummy LPAR to store excess MIPS
Dick, We've been doing this for a number of months. We have a 2094-704 that we dedicated one CPU to our sysprog lpar (so we didn't need to create a parking lpar). It seems to be working to hold down the costs on the other production lpars. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bond, Dick (DIS) Sent: Thursday, March 10, 2011 16:58 To: IBM-MAIN@bama.ua.edu Subject: Dummy LPAR to store excess MIPS Does anyone use the concept of a "dummy" LPAR to store excess "MIPS" to avoid software costs? Suggest other methods of storing unused capacity? Thanks. Dick Bond Department of Information Services CSD Production Support di...@dis.wa.gov -- 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
Dummy LPAR to store excess MIPS
Does anyone use the concept of a "dummy" LPAR to store excess "MIPS" to avoid software costs? Suggest other methods of storing unused capacity? Thanks. Dick Bond Department of Information Services CSD Production Support di...@dis.wa.gov -- 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
