We split our CICS regions into a separate CICSLPAR and saved $tons/yr. It was well worth the split.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Veilleux, Jon L Sent: Wednesday, February 17, 2010 2:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: LPARs: More or Less? Good point. Do you want to pay the per CPU charge for software on a 10-way where the software really runs on about 1 cpu's worth? We split out our WebSphere's to smaller LPARs for this reason. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Al Sherkow Sent: Wednesday, February 17, 2010 11:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: LPARs: More or Less? With z/OS and sub-capacity pricing the charges for many important and key products (and the more expensive) are tied to the "size" of the LPAR. A small amount of IMS in a large LPAR is charged a larger price than a small amount of IMS in a small LPAR. Some of IBM's current policies cause sites to jump through hoops to save money. This is one area, and another is parallel sysplex aggregation. When parallel sysplex was introduced the aggregation was a financial incentive to move sites to parallel sysplex. Most sites are there by now :) But sites are being forced to follow the rules initially set long ago. That is not a productive use of valuable system programmer time. Some sites spend a lot of effort managing this. They could be installing a new release of DB2 or IMS. They could be working with linux on z, or websphere or any number of other strategic initiatives for their organization. Instead they are jumping through hoops to follow rules that may lower their software charges, but do not enhance what mainframe if providing to their business. In general, and YMMV, more LPARs leads to lower software charges. The various LPARs do not all have their peak 4HRA during the same hour. The simultaneous 4HRA across all LPARs is lowered. In general I don't advise breaking apart LPARs just for SW charge savings, but in some cases the savings are significant. The IMS example in my first paragraph is a good example of that. I do recommend that sites stop combining LPARs for easier management. Rather leave them separate for lower SW charges, again YMMV. This has been a fairly standard practice after a merge to combine for example two separate production LPARs into one large Production LPAR. 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna ---------------------------------------------------------------------- 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
