The Sub-Capacity Corner is the place to learn more about the licensing and pricing rules concerning System z Sub-Capacity charges. In addition to an explanation of the contractual terms and conditions there are also different procedures to follow for certain circumstances (such as machine upgrades) and some information about the technology which forms the basis for the Sub-Capacity licensing rules.
Sub-Capacity Rules for moving Programs and/or moving Workloads
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 for that reporting period. 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 2817-12345 to 2827-34567 on July 17". IBM will use the higher of the two MSU numbers reported as the billing value for that product that reporting period (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 the combined rolling 4 hour average of LPARs A and B during those intervals when 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.
For help with the Sub-Capacity Reporting Tool (SCRT) or questions related to Sub-Capacity pricing, please see the System z Software Pricing Help page.