I could change it to say that "The current problem with z/OS pricing is that most software is charged on the size of the machine OR LPAR, not the amount of usage of the software." But I still think it's a current problem. There have been improvements in MVS releases to address this situation, such as the latest pricing improvement for z196 machines, Integrated Workload Pricing. But the basic problem still exists. When you add work to a z machine or LPAR, the cost of most of the other IBM and ISV software will increase.
Referring back to the other discussion of 'Dummy LPARs', yes, you could put the new software in another LPAR and not increase the software prices of the major software on the machine. But the z/OS usage is still increased. Many of the ISVs use sub-capacity pricing based on the MIPS or MSUs of the LPARs running z/OS. So an added LPAR for a new workload still causes an increase. In 2009, I quoted Al Sherkow in my newsletter when he said "about half of IBM's customers use sub-capacity pricing." I assume (and hope) that a greater percentage are now using sub-capacity pricing, but it's been a long haul. When I ask people why they don't use it, I get a variety of answers, but it's usually something in the form of "well we have this special full-site license that covers everything." That might work fine for IBM products, but it doesn't work for all products. Every installation should be pushing their ISVs to do sub-capacity pricing. When I talk about 'usage-based' pricing, I'm talking about a product that uses 30 MIPS during its peak, not about one that runs in a 30 MIPS LPAR. Because the tooling for that type of chargeback is fairly expensive, I can't see it happening except for new products arriving in the marketplace. I hope that explains my statements. Best regards, Cheryl ====================== Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com 941-266-6609 ====================== On Mar 12, 2011, at 1:58 AM, Timothy Sipples wrote: I didn't understand this comment: > The current problem with z/OS pricing is that most > software is charged on the size of the machine, not > the amount of usage of the software. The newsletter mentions VWLC later, but I disagree with this sentence with respect to IBM software. (It's not a "current problem.") Most customers now pay for all or at least the vast majority of IBM software based on monthly peak four hour rolling averages on an LPAR basis and in very granular MSU increments. The size of the machine is irrelevant except as an overall limit, not as a floor. Even some sub-LPAR sub-capacity pricing is now available. I could change just one word to make that sentence correct, though: "The current problem with non-mainframe pricing is that most software is charged on the size of the machine, not the amount of usage of the software." IBM and a few other vendors allow you to license their non-mainframe software on the number of CPUs that it runs (at maximum) rather than the total number of processors in the machine, with (much coarser) core granularity, but that practice is hardly universal. - - - - - 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 ---------------------------------------------------------------------- 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
