Posts Tagged ‘MSU’

New Software Pricing for IBM z13

February 6, 2015

Every new mainframe causes IBM to rethink its pricing. This makes sense because mainframe software licensing is complex. The z13 enables different workloads and combinations of uses that merit reexamining the software licensing. But overall, IBM is continuing its strategy to enhance software price/performance with each generation of hardware. This has been the case for as long as DancingDinosaur has been covering the mainframe. (click graphic below to enlarge)

 IBM z13 technology update pricing

DancingDinsosaur along with other mainframe analysts recently listened to Ray Jones, IBM Vice President, z Systems Sales go through the new z13 software pricing. In short, expect major new structural enhancements coming in the first half of 2015. Of particular interest will be two changes IBM is instituting:

  1. IBM Collocated Application Pricing (ICAP), which lets you run your systems the way that make sense in your organization
  2. Country Multiplex Pricing, an evolution of Sysplex pricing that allows for greater flexibility and simplicity which treats all your mainframes in one country as a single sysplex.

Overall, organizations running the z under AWLC should see a 5% discount on average.

But first let’s take a moment to review AWLC (Advanced Workload License Charge). This monthly program from the start has been intended to allow you to grow hardware capacity without necessarily increasing software charges. Most organizations under AWLC can grow hardware capacity without necessarily increasing software charges. In general you’ll experience a low cost of incremental growth and you can manage software cost by managing workload utilization and deployment across LPARs and peak hours.

A brief word about MSU. DancingDinosaur thinks of MSU as mainframe service unit. It is the measurement of the amount of processing or capacity of your mainframe. IBM determines the MSU rating of a particular mainframe configuration by some arcane process invisible to most of us. The table above starts with MSU; just use the number IBM has assigned your z configuration.

OK, now we’re ready to look at ICAP pricing. IBM describes ICAP as the next evolution of z Systems sub-capacity software pricing. ICAP allows workloads to be priced as if in a dedicated environment although technically you have integrated them with other workloads. In short, you can run your systems and deploy your ICAP workloads the way you want to run them. For example, you might want to run a new anti-fraud app or a new instance of MQ and do it on the same LPAR you’re running some other workload.

ICAP is for new workloads you’re bringing onto the z. You have to define the workloads and are responsible for collecting and reporting the CPU time. It can be as simple as creating a text file to report it. However, don’t rush to do this; IBM suggested an ICAP enhancement to the MWRT sub-capacity reporting tool will be coming.

In terms of ICAP impact on pricing, IBM reports no effect on the reported MSUs for other sub-capacity middleware programs (adjusts MSUs like an offload engine, similar to Mobile Workload Pricing for z/OS). z/OS shops could see 50% of the ICAP-defining program MSUs will be removed, which can result in real savings. IBM reports that ICAP provides a price benefit similar to zNALC for z/OS, but without the requirement for a separate LPAR. Remember, with ICAP you can deploy your workloads where you see fit.

For Country Multiplex Pricing a country multiplex to IBM is the collection of all zEnterprise and later machines in a country, and they are measured like one machine for sub-capacity reporting (applicable to all z196, z114, zEC12, zBC12, and z13 machines). It amounts to a new way of measuring and pricing MSUs, as opposed to aggregating under current rules. The result should be flexibility to move and run work anywhere, the elimination of Sysplex pricing rules, and the elimination of duplicate peaks when workloads move between machines.

In the end, the cost of growth is reduced with one price per product based on growth anywhere in the country. Hardware and software migrations also become greatly simplified because Single Version Charging (SVC) and Cross Systems Waivers (CSW) will no longer be relevant.  And as with ICAP, a new Multiplex sub-capacity reporting tool is coming.

Other savings also remain in play, especially the z/OS mobile pricing discounts, which significantly reduces the level at which mobile activity is calculated for peak load pricing. With the expectation that mobile activity will only grow substantially going forward, these savings could become quite large.

DancingDinosaur is Alan Radding, a veteran mainframe and IT writer and analyst. Follow DancingDinosaur on Twitter, @mainframeblog. See more of my writing at Technologywriter.com and here.

Software Licensing for IBM System z Distributed Linux Middleware

October 10, 2014

DancingDinosaur can’t attend a mainframe conference without checking out at least one session on mainframe software pricing by David Chase, IBM’s mainframe pricing guru. At IBM Enterprise2014, which wraps up today, the topic of choice was software licensing for Linux middleware. It’s sufficiently complicated to merit an entire session.

In case you think Linux on z is not in your future, maybe you should think again.  Linux is gaining momentum in even the largest z data centers. Start with IBM bringing new apps like InfoSphere, BigInsights (Hadoop), and OpenStack to z. Then there are apps from ISVs that just weren’t going to get their offerings to z/OS. Together it points to a telltale sign something is happening with Linux on z. And, the queasiness managers used to have about the open source nature of Linux has long been put to rest.

At some point, you will need to think about IBM’s software pricing for Linux middleware. Should you find yourself getting too lost in the topic, check out these links recommended by Chase:

To begin, software for Linux on z is treated differently than traditional mainframe software in terms of pricing. With Linux on z you think in terms of IFLs.  The quantity of IFLs represent the number of Linux engines subjected to IBM’s IPLA-based pricing.

Also think in terms of Processor Value Units (PVUs) rather than MSUs. For a pricing purposes, PVUs are analogous to MSUs although the values are different. A key point to keep in mind: distributed PVUs for Linux are not related to System z IPLA value units used for z/VM products. As is typical of IBM, those two different kinds of value units are NOT interchangeable.

Chase, however, provides a few ground rules:

  • Dedicated partition
    • Processors are always allocated in whole increments
    • Resources are only moved between partitions “explicitly” (e.g. by an operator or a scheduled job)
  • Shared pool:
    • Pool of processors shared by partitions (including virtual machines)
    • System automatically dispatches processor resources between partitions as needed
  • Maximum license requirements
  • Customer does not have to purchase more licenses for a product than the number of processors on the machine (e.g. maximum DB2 UDB licenses on a 12-way machine is 12)
    • Customer does not have to purchase more “shared pool” licenses for a product than the number of processors assigned to the shared pool (e.g. maximum of 7 MQSeries licenses for a shared pool with 7 processors). Note: This limit does not affect the additional licenses that might be required for dedicated partitions.

With that, as Chase explains it, Linux middleware pricing turns out to be relatively straightforward, determined by:

  • Processor Value Unit (PVU) rating for each kind of core
  • Any difference for different processor technologies (p, i, x, z, Sun, HP, AMD, etc—notice that the z is just one of many choices, not handled differently from the others
  • Number of processor cores which must be licensed (z calls them IFLs)
  • Price per PVU (constant per product, not different based upon technology)

Then it becomes a case of doing the basic arithmetic. The formula: # of PVUs x the # of cores required x the value ($) per core = your total cost.  Given this formula it is to your advantage to plan your Linux use to minimize IFLs and cores. You can’t do anything about the cost per PVU.

Distributed PVUs are the basis for licensing middleware on IFLs and are determined by the type of machine processor. The zEC12, z196, and z10 are rated at 120 PVUs. All others are rated at 100 PVUs. For example, any distributed middleware running on Linux on z this works out to:

  • z114—1IFL, 100 PVUs
  • z196—4IFLs, 480 PVUs
  • zEC12—8 IFLs, 960 PVUs

Also, distributed systems Linux middleware offerings are eligible for sub-capacity licensing. Specifically, sub-capacity licensing is available for all PVU-priced software offerings that run on:

  • UNIX (AIX, HP-UX, and Sun Solaris
  • i5/OS, OS/400
  • Linux (System i, System p, System z)
  • x86 (VMware ESX Server, VMware GSX Server, Microsoft Virtual Server)

IBM’s virtualization technologies also are included in Passport Advantage sub-capacity licensing offering, including LPAR, z/VM virtual machines in an LPAR, CPU Pooling support introduced in z/VM 6.3 APAR VM65418, and native z/VM (on machines which still support basic mode).

And in true z style, since this can seem more complicated than it should seem, there are tools available to do the job. In fact Chase doesn’t advise doing this without a tool. The current tool is the IBM License Metric Tool V9.0.1. You can find more details on it here.

If you are considering distributed Linux middleware software or are already wrestling with the pricing process, DancingDinosaur recommends you check out Chase’s links at the top of this piece. Good luck.

DancingDinosaur is Alan Radding. Follow DancingDinosaur on Twitter, @mainframeblog. You can check out more of my work at Technologywriter.com


%d bloggers like this: