Sub-Capacity Corner

Terms & Conditions

Procedures

Technology

Initial Sub-Capacity Billing Effective Date (April 30, 2002)
MSU changes submitted on Sub-Capacity Reports for programs with recurring charges will be billed effective the first day of the month following the month in which the Sub-Capacity Report was received. Recurring charges are Monthly License Charges (MLC) and IPLA software maintenance which is also referred to as Subscription and Support (S&S). This means that when you initially decide to implement sub-capacity on a machine you will not see the changes reflected in your billing until the first day of the month following the submission of the report. For example, if you collect data for the month of January (from January 2nd through February 1st) and submit the report at the beginning of February (between February 2nd and 9th) the billing changes will become effective March 1st. For January and February the billing will be at full capacity. Billing is not done in arrears. Although March's billing is determined by data collected in January, the bill is for the month of March

MSU changes submitted on Sub-Capacity Reports for programs with IPLA One Time Charges (OTC) will be billed effective with the processing of the report by IBM.

Sub-Capacity Pricing and Priced Features (03 October 2000)
Priced features of a base program will be charged at the same MSU value as the base program, on a machine-by-machine basis. The Sub-Capacity Reporting Tool will only report on the MSUs of the base program. Determination of the presence of a priced feature is solely on IBM's listing of priced features which are installed in machine's inventory, according to our inventory systems. For example, DB2 MSUs on machine1 are 100 and on machine2 are 200. Our inventory system reflects QMF on machine1, therefore QMF will be charged only on machine1 at the 100 MSU level. Changes to installed inventory should be communicated to IBM in writing and will become effective on the 1st day of the month following IBM's receipt of the notification.

Sub-Capacity Billing for New Licenses (10 July 2006)
When a brand new product license not eligible for Single Version Charging is added to a Sub-Capacity WLC/EWLC machine (whether a standalone machine or a sysplexed machine), Sub-Capacity measurements for the new product are not initially available. Therefore, the new product MSUs on that machine are set at the same level as the z/OS MSUs (plus the z/OS.e MSUs if applicable) for the first billing month. (If the new product is eligible for Single Version Charging please read the appropriate sections below for additional information.)

Sub-Capacity Single Version Charging (29 March 2005)
When a machine has sub-capacity Workload License Charges (WLC) or sub-capacity Entry Workload License Charges (EWLC), and a version to version migration is taking place, and if IBM has determined that the migration is eligible for Single Version Charging, then charges for the previous version are waived for a maximum 12 month migration period. The new version is charged at the higher of:

• The new version MSUs, reported on the customer's Sub-Capacity Report for that month
• The previous version MSUs, reported on the customer's Sub-Capacity Report for that month

Sub-Capacity Single Version Charging Special Case 1 (29 March 2005)
In the case where Sub-Capacity Single Version Charging applies but the new version MSUs are not yet available on the Sub-Capacity Report, then charges for the previous version will be waived and the new version will be charged at the reported previous version MSUs.

Sub-Capacity Single Version Charging Special Case 2 (16 Dec. 2005)
In the case where Sub-Capacity Single Version Charging applies but the previous product version does not have a variable pricing metric (for example FWLC or TWLC), charges for the previous version will be waived and the new product MSUs charged on that machine are set at the same level as the z/OS MSUs (plus the z/OS.e MSUs if applicable) until such time as the new version appears on the Sub-Capacity Report.

Product Not Appearing on Sub-Capacity Report (10 July 2006)
Once a Sub-Capacity eligible MLC product is past the initial month billing period, it is IBM's policy to charge for that Sub-Capacity eligible MLC product based upon the MSUs reported for that product on the customer's Sub-Capacity Reports. Therefore, if a product does not appear in certain months, the customer should not be charged for that product. However, there is a 3 MSU minimum for each Sub-Capacity eligible product per environment. In a standalone machine environment, the customer must pay a minimum of 3 MSUs per Sub-Capacity eligible MLC product per month. In a sysplex environment, the customer must meet the 3 MSU minimum per Sub-Capacity eligible product across the sysplex (e.g., 1 MSU on box1, 1 MSU on box2 and 1 MSU on box3).  Note: It is a requirement of the sub-capacity process that customers accurately update the appropriate NO89 DD product statements in the SCRT JCL to indicate in which LPARs those products are executing.

Permanently Moving Product Licenses from One Machine to Another
IBM licenses software on a machine-by-machine basis. If you move a product from one machine to another you must immediately notify IBM in writing of this event so that the license can be redesignated in the inventory. When a product is moved between two Sub-Capacity machines it will appear on the Sub-Capacity Reports for both machines. In addition to the written notification, you should also indicate in the "Customer Comments" field of both Sub-Capacity Reports that a product has been moved, for example, "5655-G53 was moved from 2064-12345 to 2084-34567 on July 17". IBM will use the higher of the two MSU numbers reported as the billing value for that product that month (capped, if appropriate, by the Full-Capacity MSU value of the target machine). If a product is moved between a Full-Capacity machine and a Sub-Capacity machine then the billing value will be the higher of the reported Sub-Capacity MSU value from the one machine and the Full-Capacity MSU value of the other machine (again, capped as appropriate).

Moving Workload from One LPAR to Another on a Machine
MLC software required to support a workload is licensed to a machine, not to an individual LPAR. Let's say you want to run DB2 in LPARA for the first part of a month and then move DB2 to LPARB for the second part of the month. How you do your migration will affect the billable MSUs for DB2. If you plan carefully, you can ensure DB2 does not run in both LPARA and LPARB during any intervals. That is, bring DB2 down in LPARA during hour X and then wait until hour Y to bring DB2 up in LPARB. If you run DB2 in both LPARA and LPARB for some intervals during the migration, then SCRT will consider for the combined rolling 4 hour average of LPARs A and B during those intervals where the overlap occurs.

Moving Workload from One Machine to Another
Let's say you want to run LPARA on Machine1 during the first part of a month and then move LPARA to Machine2 for the second half of the month. Be prepared to see the products in LPARA, and their MSUs, appear on the Machine1 Sub-Capacity Report and also appear on the Machine2 Sub-Capacity Report. IBM charges for software on a machine-by-machine basis. Therefore, SCRT analyzes one machine at a time and determines the applicable MSUs per product for each machine. The fact that LPARA moved from Machine1 to Machine2 is unknown and irrelevant to SCRT and, therefore, not factored into any calculations. Each product running on any machine at any time during the month will be charged on each machine. Also, if moving LPARA from Machine1 to Machine2 introduces any new software products on to Machine2 which were not previously licensed, please notify your IBM representative to ask that the new licenses be added to Machine2, and possibly discontinued from Machine1, if applicable.

Product Discontinuance Rule (25 March 2003)
The product discontinuance rule is invoked when the customer notifies IBM in writing that they wish to discontinue a licensed product. The product discontinuance rule indicates that the product will be discontinued effective the first day of the month following the month in which the discontinuance communication was received by IBM. At the time the product is discontinued, all billing should cease permanently.

Due to the nature of the lag between data collection, Sub-Capacity reporting and billing effective date, there may be a period of two months when the product is reported but not billed following the discontinuation. For example, if a product is discontinued in January, the product may still appear in the January Sub-Capacity Report but not in the February Sub-Capacity Report. Even though it appears in the January Sub-Capacity Report (which is effective March 1st) the product would not be billed in March. If the product continues to appear in Sub-Capacity Reports for data collected after the month of discontinuance, IBM will consider this a violation of our terms and conditions.

Getting Help
Help for the Sub-Capacity Reporting Tool (SCRT) or anything related to Sub-Capacity pricing is available by emailing scrt@us.ibm.com