z/Data Perspectives: Consider Capping to Control Costs
Cost containment is important for today’s IT departments. Every decision regarding your computer resources is weighed based on the value they can deliver to your organization as well as their cost to procure, implement, and maintain. And, in most cases, if a positive ROI can’t be calculated, the software won’t be adopted or the hardware won’t be upgraded.
An often overlooked opportunity for cost containment comes from within the realm of your capacity planning group. Capacity planning is the process of determining the production capacity needed by an organization to meet changing demands for its products. But capacity planning is perhaps a misnomer, because this group should not only be planning your capacity needs but also managing your organization’s capacity. Actively managing your resources to fit your demand can reduce your IT department’s software bills—especially in a mainframe environment.
The total cost of mainframe computing continues to be high, and software is the biggest portion of that cost. The pricing model for most mainframe software remains based on the capacity of the machine on which the software will run. Note that this pricing model reflects the potential usage based on the capacity of the machine, not the actual usage. Some vendors offer usage-based pricing.
IBM offers Variable Workload License Charges (VWLC) for many of its popular software offerings, including z/OS, DB2, IMS, CICS, WebSphere MQ, and COBOL. It’s a monthly license pricing metric designed to more closely match software cost with its usage. Benefits of VWLC include the ability to:
- Grow hardware capacity without necessarily increasing your software charges
- Pay for key software at LPAR-level granularity
- Experience a low cost of incremental growth
- Manage software cost by managing workload utilization.
Basically, with VWLC, your MSU usage is tracked and reported by LPAR. You’re charged based on the maximum Rolling Four-Hour (R4H) average MSU usage; R4H averages are calculated each hour, for each LPAR, for the month. Then you’re charged by product based on the LPARs in which it runs. This information is collected and reported to IBM using the Sub-Capacity Reporting Tool (SCRT). So, you pay for what you use … sort of. You actually pay based on LPAR usage. What if you have DB2 and CICS both in a single LPAR, but DB2 is only minimally used and CICS is used a lot? Since they’re both in the LPAR, you’d be charged for the same amount of usage for both. But it’s still better than being charged based on the usage of your entire Central Processing Complex (CPC), right?
Soft capping is a way of setting the capacity for your system so you aren’t charged for the entire capacity of your CPC, but at some lower defined capacity. Without soft capping, you’re charged the maximum R4H average per LPAR; by implementing soft capping, your charge by LPAR is based on the maximum R4H average or the defined capacity you set, whichever is lower.
The downside to soft capping is that you’re setting limits on the usage of your hardware. Even though your machine has a higher capacity, you’ve set a lower defined capacity, and if the R4H average exceeds the defined capacity, your system is capped at the defined capacity level.
Sites that avoid soft capping usually do so because of concerns about performance or the size of their machines. This is usually misguided because soft capping coupled with capacity management can result in significant cost savings for many sites. As of z/OS 1.9, you can set a Group Capacity Limit, which sets a capacity limit for a single LPAR as well as a group of LPARs. This can minimize the impact of capping, but may not help minimize your cost.
Of course, it can be complicated to set your defined capacity appropriately, especially when you get into setting it across multiple LPARs. There are tools to automate the balancing of your defined capacity setting and thereby manage your R4H average. The general idea behind these tools is to dynamically modify the defined capacity for each LPAR based on usage. The net result is that you manage to a global-defined capacity across the CPC, while increasing and decreasing the defined capacity on individual LPARs. If you’re soft capping your systems but aren’t seeing the cost-savings benefits you anticipated, such a tool can pay for itself rather quickly.