Operating Systems

Saving Software Costs With Group Capacity Limits

3 Pages

The December/January 2005 z/Journal article, “Getting Started With Sub-Capacity License Charges,” provided the basics for using Logical Partition (LPAR)- defined capacities to manage the IBM z/OS Variable Workload Charges (VWLC) software costs. With the advent of z/OS 1.8, IBM introduced group capacity, adding a new dimension to subcapacity license charges management and control for z9 and newer processors. Basically, several LPARs on the same Central Electronics Complex (CEC) can be grouped together and treated as a single entity for defining capacity limits. The same Sub-Capacity Reporting Tool (SCRT) reports and reporting mechanism are used for group capacity limits.

Benefits of Group Capacity Limits

The new group capacity limits may provide better and simpler control of VWLC software costs. These limits can provide better sharing of the CPU resource among LPARs when running capped. Consider this scenario. There are two LPARs on a CEC: LPAR 1 has an LPAR-defined capacity of 400 Million Service Units (MSUs) and LPAR 2 has an LPAR-defined capacity of 300 MSUs. The maximum software charge will be for 700 MSUs. Both LPARs run under the cap for a few hours daily (i.e., their 4-Hour Rolling Averages [4HRAs] are greater than 400 or 300, respectively, at some time during the day. You or your management have decided you’re willing to pay for 700 MSUs of software to meet business needs. However, some of the time LPAR 1 (400 MSUs) is running under the LPAR cap; LPAR 2 (300 MSUs) is not. Wouldn’t it be nice to let LPAR 1 use that “extra” CPU or LPAR 2 use “extra” CPU not used by LPAR 1? Group capacity limits accommodate that. Because of this CPU resource sharing, group capacity limits may let you set lower capacity limits than you can with LPAR-defined capacity and realize additional software cost savings.

Depending on your needs or contractual requirements, the old LPARdefined capacity limits may be eliminated, reducing the number of defined capacity control points. This can make managing the VWLC software cost easier because there are fewer points of control.

Creating LPAR Groups and Group Capacity Limits

Creating the LPAR groups and establishing their MSU limit is fairly easy, as you do it from the Hardware Management Console (HMC). IBM provides a predefined group (DEFAULT) requiring only identification of its LPARs and the group capacity limit. With multiple CECs, each CEC will contain a group called DEFAULT. It makes sense to define your groups with your preferred names to differentiate CECs. For a z9 processor, refer to the System z9 Support Element Operations Guide (SC28-6860-01) page 6-40 to define a group and page 9-4 to change the group capacity limit. For a z10 processor, refer to the System z10 Support Element Operations Guide (SC28-6868-00) page 6-41 to define a group and page 9-4 to change the group capacity limit.

If possible, change the group capacity limits only once per month. If a group capacity limit is raised during the month, the odds are pretty good it will be reached, or at the least, the aggregate 4HRA will be higher. Lowering the group capacity limit during the month probably won’t lower the VWLC software cost because the high water mark up to that time will be used to determine the software cost. As a result, lower the group capacity limit on the first of the month and raise it on the second of the month.

Determining Where to Set the Group Capacity Limit

Your management may decide there’s no desire or need to limit the CPU resource and truly manage your VWLC software cost. If so, there’s no need to define the LPAR groups and group capacity limit(s).

A quick way to create the group capacity limit is to count the LPARdefined capacities for the LPARs in the group and make it the group capacity limit. You can then turn off (set to zero) the appropriate LPAR-defined capacities. This solution assumes LPARdefined capacities are being used.

3 Pages