Earlier this year, we published a blog on the subject of Monthly License Charge (MLC) for IBM System z. International Program License Agreement (IPLA) software is the second major category for licensing of IBM software on the System z mainframe. Software licensing for IBM System z can be a complicated and confusing topic and there is no way to cover all the obscure idiosyncrasies (for the record, IBM is not the only player that makes license charges mystically complex). Most end-users of System z, even application developers, have no real understanding of how licensing is charged, or how to potentially save money with minor changes to the data center licensing model. This article will attempt to explain the most common licensing approaches and will make the following assumptions:
- The hardware is IBM System z mainframe hardware.
- The operating system (for all practical purposes) is z/OS.
Although there are multiple operating systems that can execute on IBM System z hardware (z/OS, zVSE, zVM, zTPF, Ubuntu Linux, Red Hat Linux, SuSe Linux, etc.), this blog focuses on software for z/OS. As a note, z/OS and zVSE have similar licensing models. Independent Software Vendors (ISVs) tend to have their own approach to licensing.
International Program Licensing Agreement (IPLA) Software
The licensing of IPLA software — traditional “system z software” — is comprised of two major parts: the initial license charge, aka one-time charge (OTC), and the recurring software subscription and support (S&S). IPLA software traditionally has a larger, up-front license charge and the customer pays a recurring S&S fee for continued support, upgrades, technical support, defect management, maintenance, etc. via access to the IBM Support Center. Although the S&S fee can vary from product to product and between vendors, it is quite common for it to fall in the range of 22-24% of the license fee.
MSUs
IBM measures the capacity of their hardware using a metric referred to as Million Service Units (MSUs). Monthly License Charge (MLC) software is priced per MSU. MSU ratings are published and readily available and vary based on the number of CPUs and CPU capacity settings. MSUs are not the same as MIPS (Millions of Instructions Per Second). Most ISVs charge based on MIPS. IPLA software is typically priced by MSU. However, there are also other metrics used for IPLA pricing which can include Value Units (VUs) and Processor Value Units (PVUs).
Sub-Capacity
Sub-capacity licensing is used by customers looking to reduce initial license and potential on-going S&S costs. Sub-capacity licensing refers to licensing portions of the hardware capacity below its total capacity. For example: licensing a product for only 400 MSUs on a machine that has 500 MSUs of compute capacity. There are several important considerations prior to implementing sub-capacity licensing:
- Is the hardware capacity that was purchased needed now or in the near future?
- Can the software being sub-capacity licensed be “fenced” (isolated or restricted) into a specific LPAR or machine?
- Will fencing the software into an LPAR or machine impede any of the existing production workload?
- Will the existing system z software experience any growth within the next five or more years?
LPARs (Logical Partitions) can be used to sub-divide the System z hardware and fence off software installations and usage, thereby controlling MLC software usage, IPLA licenses, and S&S costs. Many customers implement a sub-capacity model to reduce monthly costs and temporarily increase the capacity for special processing needs, e.g., quarter end or Black Friday.
Sub-Capacity Licensing Reference Models
MLC software and IPLA software can both be licensed at sub-capacity. But unlike MLC, where the charges are based on the four-hour rolling average determined from the SCRT report, the software charges for using IPLA above the licensed limit may be quite expensive. Above capacity consumption of IPLA software is basically a lease for that short duration of time and does not apply to OTC or S&S charges. The customer is responsible for insuring the IPLA license sub-capacity compliance and often saves money over time by licensing the full capacity.
When considering licensing IPLA software for sub-capacity and cost containment, it is extremely important to be aware of the three key licensing metrics for sub-capacity: Reference-Based, Execution-Based, or z/OS-Based.
Reference-Based
Reference-based IPLA software consists of products that must be licensed wherever a specific parent product software is executing on the hardware. Examples of parent product software include Db2 for z/OS, CICS, or IMS. Examples of Reference-Based IPLA software would be 5655-AA9 Db2 Sort for z/OS or 5655-Y01 CICS VSAM Transparency. The 5655-AA9 Db2 Sort product is required to be licensed for any LPAR where Db2 z/OS would execute and the 5655-Y01 CICS VSAM Transparency product is required to be licensed for any LPAR where CICS Transaction Server would execute. The parent product may also be IPLA licensed software (historically they are MLC products), but some shops may have licensed them as the Value Unit Edition (VUE) offerings. VUE Offerings provide for an upfront license charge, followed by annual S&S charges. Organizations should take a very close financial analysis as part of considering VUE licensing of traditional MLC products.
Execution-Based
Execution-Based IPLA software is licensed for the configured capacity of the LPAR where it is installed, implemented, or deployed. Organizations will frequently license for only the development LPAR. This allows the organization to reduce overall licensing of the software product while easily restricting its usage to a development LPAR. Debugging, load testing, application analysis, and code performance tools typically fall into this category.
z/OS-Based
z/OS-based products must be licensed for all LPARs and machine capacity where z/OS is being executed. This frequently includes products like storage management, performance management, tape management, and security management products.
Technology Dividend
IBM invests heavily into new technology on System z and incorporates the latest technology into new versions of its mainframe hardware. IBM marketing may change the naming scheme applied to the zNEXT (a term used to indicate the next upgraded version of System z hardware), but historically a basic numbering scheme has applied: z12, z13, z14, z15, etc. IBM assesses an MSU rating for each zNEXT machine that is introduced. Historically, the MSU rating for each new machine provides about a 10% reduction in cost per MSU. Theoretically, if the box were rated at 1000 MIPS, and the new box is 1100 MIPS, the MSU rating would be very close, allowing for a 10% boost in performance for nearly the same MSU rating; hence, the “technology dividend”.
More Information
Having a business partner that is savvy about IBM license protocols can save you time, money, and headaches. For further information about software license information, contact your Mainline support services representative directly, or contact us here. As an IBM Platinum Business Partner, and a 2020 Beacon Award Winner for “Most Innovative Client Experience on Z,” Mainline has proven expertise to help you solve your business challenges with IBM System z solutions.
You may be interested in:
Blog: Software Licensing on IBM Z System: Part 1, Monthly License Charge Software
Blog: Software Licensing on System z – PassPort Advantage – Part 3
Press Release: Mainline Information Systems Wins IBM Beacon Award for Most Innovative Client Experience on Z