IBM billing methods

There are two pricing categories framed in an IBM contract:

  • ICA (IBM Customer Agreement) which includes the MLC Software, Monthly License Charge including licenses and support fees for the base running the IT System as z/OS, DB2, IMVS,CICS, MQ, etc… The customer has to choose the MLC pricing metric depending on its Mainframe environment: AWLC, CMLC, WLC (vWLC or FWLC) , AEWLC, EWLC, MWLC, zNALC, and PSLC. The retained unit will be the MSU (Million Service Units).
  • IPLA (International Product License Agreement) for IPLA products such as Application, Data or Systems Management Tools. The pricing is OTC (One Time Charge) + yearly Support & Subscription Charges. The retained unit will be the VU (Value Unit).

Generally, these two contracts are included in an Enterprise Agreement such as ELA, OIO, ESSO.

Most Enterprises are using for IBM MLC software products Advanced Workload License Charges (AWLC) – a Sub-Capacity charging for z15, z14, z13, zEC12, and z196 or Workload License Charges (WLC) – a Sub-Capacity charging for z10 EC, z9 EC, z990 and z900 machines.

CMLC (using CMP as Country Multiplex Pricing) allows combining products from multiple LPARs in different sites within one country without the requirement for a parallel sysplex (PSLC Rule of 50%):

  • CMP is designed to reduce the cost of growth
  • The Baseline: the last 3 months MSUs and software bills are averaged and those values are used to create baselines
  • This Baseline will determine the future bills.

Both AWLC and CMLC have the same terms. AWLC includes discount due to the Technology Dividends (look at “AWLC Technology Transition Offerings” in the AWLC IBM web page).


Parallel Sysplex License Charge is a billing method which allows aggregating the product billed capacity across more than one server. You must validate that your biggest Sysplex environment across several CPCs or servers consumes more than 50% of the full consumption of each server. The validation tool is named PLEXCALC and the terms are described here.


Sub-Capacity Pricing such as vWLC as “variable Workload License Charge” or AWLC as “Advanced WLC” allow MLC products to be charged based on the size of the LPAR or LPARs where a product executes. Structured by 7 levels, the concept is more MSU you have, less is the MSU cost:

The product billed capacity will be based on the highest observed rolling 4-hour average utilization (R4HA) of an LPAR or LPARs where that product is executing. The product billed capacity report is provided by the SCRT (Sub Capacity Reporting Tool) each month. The rule is one SCRT per CPC, so one invoice per CPC.

Figure 1: here the R4H peak is 100 MSU at July 2nd – 8 pm for LPA1. In case the product “COBOL FMID 5655-G53 runs only on LPA1 inside CPC1, this product will be invoiced on 100 MSU.

Soft Capping

IBM Soft-Capping is a feature which allows controlling the WLC bill by setting a limit for each LPAR of a MAXIMUM for the average consumption of MSU (R4H). This limit is called Defined Capacity (DC).

The Soft-Capping rule is when the Rolling 4 Hours (R4H) becomes superior or equal to DC then the LPAR is capped. That means that the IMSU consumption will not be able to exceed the DC anymore until the R4H becomes lower than the DC.

Figure 1: the LPAR01 billing level cannot reach 110 MSU but the IMSU is brought back to 110 MSU (DC) when the soft-capping starts, so when the R4H reach 110 MSU.

Because DC is a fixed limit, we face a lack of flexibility. During capping period the LPAR is constrained while other LPAR have a highest DC than necessary for their consumption and these reserved MSU cannot be used by the capped LPAR.


Introduced by IBM from zOS.1.8 and z9 + µcode, Group Capacity Limit (GCL) allows to set a capacity limit for a group of LPARs. When the sum of the LPARs’ R4Hs in the group reaches the GCL, all LPARs in the group are capped at the level of their share% weight in the group (and not at the level of their DC).

It allows to simplify the soft-capping management but the good thing is GCL is basic and the bad thing is GCL is basic too because of not using white space and because of the use of the weight for the capping by PR/SM.

This metric is used for other things as Hard-Capping or guaranty of MSU when the server is 100%busy, so the value of the weight can be not at the right value at the right time during group capping. Here we face the same lack of flexibility as standard soft-capping.

Restrictions (*): Defined and Group Capacity

  • A partition must not be defined with dedicated processors and a partition must be defined with shared processors and WAIT Completion = NO
  • Hard Capping (Initial Capping) must not be defined
  • z/OS must not run as a VM guest
  • PR/SM capping works within ±3.6% from the defined capping value

* IBM Germany Research & Development, 2010, August


The Sub-Capacity Reporting Tool (SCRT) allows you to generate Sub-Capacity reports which you must send to IBM monthly. The reported period is from the second day at midnight to the first of the next month at 11:59 pm with the SMF record input number 70 and 89 from all LPAR of all CPC. 100% of SMF data are required.

The output will be one CSV file per CPC with more sections. E5 section reports the product summary information in MSU. The detail with the LPAR’ contributors and date/time for each product is in the P5 section.

SCRT runs hourly for 720 hours in the month and computes the highest hour in the month with the following rule per product:


Without Soft-Capping

  • Takes the SMF70LAC (R4H) and means this record in the hour
  • Sums the result for each LPAR running the product
  • Retains the peak, so the highest hour

With Soft-Capping

  • Takes the SMF70LAC (R4H) and means this record in the hour
  • Takes the SMF70WLA (DC) and means this record in the hour
  • Retains the minimum between these two averages
  • Sums the result for each LPAR running the product
  • Retains the peak, so the highest hour

Figure 1: considering a SMF Interval of 15 mns, so 4 records per hour. Without Soft-Capping, the SCRT retains 217 MSU hour 2 and with Soft Capping, that will be the 1st hour with 212 MSU for a product running on the 4 LPARs.

SCRT will compute the same algorithm with only LPAR2 and LPAR3 for a product running only these 2 LPARs.

Country Multiplex Pricing

CMP as Country Multiplex Pricing allows combining products from multiple LPARs in different sites within one country without the requirement for a parallel sysplex (PSLC Rule of 50%):

  • CMP is designed to reduce the cost of growth
  • The Baseline: the last 3 months MSUs and software bills are averaged and those values are used to create baselines
  • This Baseline will determine the future bills.

With the launch of CMP, IBM has extended its monthly pricing structure, based on MSU Ranges, from 9 levels (the base level and Level 0 to Level 7) to 15 levels (the base level and Level 0 to Level 13). This provides users experiencing workload growth with greater savings on the incremental MSUs they require to handle their growth. Clients running under aWLC would get the better MSU pricing up to Level 7; beyond 1975 MSU and up, their price was fixed. With CMP, the structure is extended up to 14000 MSU, with clients receiving further discounts at each subsequent level.

Migrating to CMP – A Planning example using ZETALY Automated Capacity (including a Baseline optimization project):

In this example, the same planning and preparation is undertaken as above, but this time ZETALY Automated Capacity is installed and run before generating the SMF data to be used for the baseline and invoicing. The goal is to set a controlled limit for MLC which will be taken into account when creating the optimal baseline level.

Then, using “flying” MSUs (*), ZETALY AC will be switched to CMP mode in July to distribute the best capacity across CPCs into Multiplex.

*: to decrease DCs from LPARs from one CPC to increase DCs from a LPAR from other CPC while respecting a fixed MSU limit across all CPCs in the Multiplex).

Mobile Workload Pricing

  • Available to all enterprises running a z15, z14, z13/zEC12 or zBC12 server (actual mobile work may run on any zEnterprise machine including z196 and z114)
  • No infrastructure changes required, no separate LPARs needed
  • MWRT Mobile Workload Report Tool or SCRT from Version V23.10.0
  • Improves the cost of growth for mobile transactions processed in System z environments such as CICS, IMS, DB2, and WAS.
  • MWRT calculates the 4RHA of the reported mobile transaction by using processor time consumed by the Mobile Workload Pricing Defining Programs.

MWRT subtracts 60% of those values from the traditional sub-capacity MSUs.

Z Collocated Application Pricing

  • The approval process which validates the workload is a new application on the z/OS platform
  • zCAP Defining Programs include key sub-capacity-eligible IBM programs
  • Customer reports CPU time for zCAP Defining Programs, similar to Mobile but less complex
  • Software pricing for other programs in the same LPAR:
    No effect on the reported MSUs for other unrelated sub-capacity middleware programs (it adjusts MSUs like an offload engine, similar to Mobile Workload Pricing for z/OS)– For z/OS, only 50% of the zCAP-defining program MSUs will be applied … it provides a price benefit similar to zNALC for z/OS, without the requirement for a separate LPAR

– New IPLA Reference-Based programs with a zCAP Defining Program as their Parent, purchased in support of an approved zCAP application and not running elsewhere in the machine or Sysplex, will be referenced only to the MSUs for the zCAP Defining Program

  • Software pricing for zCAP Defining Programs:
    Net-new zCAP program measured based on program usage MSUs (SMF89 records)
  • zCAP enhancement to MWRT V3.3.0 sub-capacity reporting tool available from April 28, 2015

Identifying zCAP Transaction Workload

  • For each sub-capacity reporting period, customers are responsible for processing their zCAP transaction data into a predefined format to be loaded into MWRT:– IBM must approve the data gathering methodology

– Detailed MWRT instructions, including CSV file format, available in the MWRT Users Guide

  • When zCAP Defining Program is only running in the LPAR for zCAP purposes:– SMF89 records are used to determine the zCAP MSUs to be removed from the report