IT Management

Over the past 20 years, the software charges related to an upgrade or acquisition of a new mainframe have overtaken the hardware charges. The software cost is now an obstacle to upgrades, replacements, and new mainframe systems. Users are willing to pay for what they use, but the mainframe charging model has been primarily based on the size of the computer — not computer usage. Installations also want charges they can more easily plan and budget for.

Initial WLC Announcement

IBM’s solution to help installations control their software costs as they continue to grow on the mainframe platform is Workload License Charges (WLCs). At the time of the initial announcement, customers who acquired a z900 processor and used z/OS as the operating system and didn’t use OS/390 on any Logical Partition (LPAR) had their IBM software priced according to the WLC schema. There was no alternative. Within WLC, there are two different types of products: variable and flat. The variable WLC products include z/OS, CICS, IMS, DB2, and other key “middleware” products.

The charges for these products are based on the size of the LPARs in which they run. IBM refers to this as “sub-capacity” pricing, but you should think of it as “container” pricing, where your LPARs are the containers. The flat WLC products have one fixed charge per zSeries processor, regardless of the LPAR sizes or processor size.

A pitfall in IBM’s original WLC pricing scheme was that the sub-capacity pricing was based on the LPARs capacity, not the capacity actually consumed. The true limit of an LPAR’s capacity is based on the number of logical engines (LPs) assigned to the LPAR. A primary benefit of the Processor Resource/System Manager (PR/SM) feature is the ability to share the physical engines of a computer between LPARs. However, the z900’s initial engine capacity was 41 MSUs (about 250 MIPS and basing software charges on the LPAR size didn’t provide enough granularity to most installations.

This led IBM to make available a new optional LPAR parameter, defined capacity. An installation could specify the size of each LPAR in MSUs with this parameter. This provides granularity of one MSU rather than 41 MSUs. (While the granularity is one MSU, be aware that variable WLC products have a minimum MSU base of 45 MSUs.) If you set a defined capacity, then your variable WLC products will be charged based on that MSU value.

The new defined capacity parameter is used to specify the size of the LPAR as a container and as the basis for charging based on capacity, but the number of logical engines still determines the true upper bound on an LPAR’s capacity. So, WLC would allow each LPAR to use capacity up to its upper bound. This provides installations the capability to handle spikes in a workload’s demand for capacity while paying for the user-specified capacity. The z/OS Workload Manager (WLM) monitors each LPAR with a four-hour rolling average of utilization. When the four-hour rolling average exceeds the defined capacity, then the LPAR will be “soft capped” to limit the CPUs consumed by the LPAR down to a specified defined capacity limit (see Figure 1).

IBM License Manager and SCRT

IBM originally planned to provide the benefits of sub-capacity pricing to installations through the IBM License Manager (ILM), a component of z/OS. Since ILM wasn’t ready when z/OS became available, but customers wanted to use WLC pricing, IBM decided to implement an interim solution with the Sub-Capacity Reporting Tool (SCRT). While ILM was to be “active” within z/OS and functioning real-time, the SCRT is an SMF postprocessor that generates pricing reports. At the end of each month, customers run the SCRT and process their SMF70 and SMF89 data for an entire month for each zSeries processor.

5 Pages