If you choose IBM's Monthly License Charge software payment option, implement soft capping and LPAR groups to manage CPU usage without performance glitches.
Monthly License Charge software
IBM licensing structures are, to be generous, arcane. IBM has many types of billing, some designed to lure people into the mainframe world, others supporting customers with fleets of Z processors and millions of lines of COBOL code.
IBM customers have the option to pay an amount determined by CPU consumption each month. This pricing, which encompasses IBM's trademark software products, such as z/OS, DB2, CICS and IMS, comes under the umbrella of Monthly License Charge (MLC) software. MLC applies to IBM's Parallel Sysplex License Charges (PSLC), not One Time Charge (OTC) or subscription-based software.
Within the MLC software pricing model, IBM charges according to the Millions of Service Units (MSUs) consumed by a logical partition (LPAR), or instance of the operating system. While MSUs roughly correspond to the traditional Millions of Instructions per Second (MIPS) metric for processor capacity, IBM does sometimes manipulate the MSU rating of a machine to encourage customers onto new processors with discounts. This is sometimes called the technology dividend. IBM's Resource Management Facility collects both software MSU and hardware MSU values.
MLC licenses in action
With MLC agreements, IBM charges based on the highest four-hour rolling average MSUs used by each LPAR for a month. The four-hour average only applies to the software that actually ran on the LPAR.
IBM keeps track of what software runs where with type 89 Systems Management Facility records. A utility in z/OS tracks MLC products as they run and cuts a record for each, usually at 15-minute intervals. Each record contains labels identifying the software along with CPU consumption.
The MLC billing cycle runs from the second of the month to the first of the next month. At the end of the cycle, customers feed the type 89 records through IBM's Subcapacity Reporting Tool (SCRT). The SCRT produces a usage report and a comma separated value (CSV) file suitable for sending to IBM. Mapping the type 89 records to the usage report isn't always straightforward, as SCRT uses transformation rules for accumulating the usage statistics into product report buckets. In some cases, you'll have to do extensive research to figure out exactly what's going into the individual product categories.
Before sending the CSV file, you can adjust the report for extenuating circumstances, as outlined in your software contract, but IBM requires at least 95% of the type 89 records to be in the report. If you fail to meet that requirement, be prepared to pay software charges for the entire capacity of the box.
With IBM's MLC payment methodology, some MSUs are cheaper than others. For instance, an enterprise running four LPARs may decide to confine CICS to half of the z/OS instances. The MSUs on the non-CICS machines are suddenly cheaper because they don't include charges for the transaction server. The CICS bill may go down, as the company is now billed only on the CPU that CICS consumes.
Soft capping an LPAR
Hard capping an LPAR can cut software costs, but can also risk performance degradation during an unexpected workload surge. The Processor Resource/System Manager (PR/SM) hypervisor enables soft capping as well, wherein systems programmers assign each LPAR a defined capacity in MSUs. Soft capping lets LPARs momentarily exceed their software caps in case of workload bursts or sudden online demand.
With the cap in place, Workload Manager (WLM) watches the four-hour rolling average as the LPAR's workload waxes and wanes. When the LPAR's four-hour rolling average exceeds its assigned defined capacity, WLM asks PR/SM to manage the partition's processor usage until the average moves below defined capacity. PR/SM's throttling keeps an installation from paying more for MLC software than the LPAR's defined capacity. If the LPAR never reaches its limit, the software charges will be even lower.
LPAR capacity groups
For additional flexibility, capacity planners can put LPARs into capacity groups. The systems programmer assigns a defined capacity to the group; each LPAR's share is governed by the partition's PR/SM weight value. An LPAR can belong to only one group, though you can define more than one group per Central Electronic Complex (CEC). None of the LPARs in the group can have dedicated processors and a group may not span CECs.
Though usage may vary between the individual LPARs, the group as a whole cannot exceed its cap. The LPARs share the CPU as needed, until the group reaches its cap, whereupon the LPAR with the highest weight will get its share and lower-weight LPARs will be limited.
About the author:
Robert Crawford spent 29 years as a systems programmer, covering CICS technical support, Virtual Storage Access Method, IBM DB2, IBM IMS and other mainframe products. He programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. Crawford is currently an operations architect based in south Texas, establishing mainframe strategy for a large insurance company.