IBM z Systems software pricing includes an overwhelming amount of options, arcane formulae and odd deductions....
This leads some companies to hire outside experts to negotiate their IBM contracts and reduce costs. However, there are ways to navigate IBM's sub-capacity software pricing and cut mainframe costs without a third party.
Sub-capacity pricing allows users to rent IBM z Systems software based how much CPU time they consume instead of total processor capacity. IBM measures CPU time in millions of service units (MSUs).
IBM bases sub-capacity pricing for its Monthly License Charge (MLC) software, which includes z Systems software, on the MSU peak four-hour rolling average (4HRA) over a billing month. The billing month stretches from the second day of the month to the first of the next.
How SCRT works
IBM created the Sub-Capacity Reporting Tool (SCRT) to compute peak 4HRA. Each month, IBM customers feed type 70 and 89 System Management Facility (SMF) records into SCRT to identify the individual products used during an hour interval. From those records, SCRT calculates the peak MSU 4HRA for each physical processor, known as a Central Electronics Complex or Central Processor Complex. SCRT creates several CSV files for the customer to review and then send to IBM for billing.
Remember two important things about SCRT reports. First, the maximum MSU depends on what software ran at the peak 4HRA time. Customer Information Control System (CICS) charges will not show up for a logical partition (LPAR) that was CICS-free for those four hours. This also means that the MSUs consumed by the operating system, z/OS, show the total for the processor at the time.
Second, you must pay for the maximum number of MSUs consumed on the LPAR, not how much the software actually used. If IBM's Information Management System (IMS) consumed one CPU cycle during the 4HRA, IBM levies IMS charges for all of the MSUs at the peak 4HRA interval.
IBM recently added a new option, Country Multiplex Pricing, in which SCRT calculates a combined 4HRA across all the processors within the same country. This option may be attractive to organizations with geographically dispersed data centers or active/active configurations.
Ten tips to manage IBM z Systems software costs
Here are some options to control and reduce your mainframe costs:
- IBM recently introduced Mobile Workload pricing, a discount for transactions that originate from tablets and phones. IBM is flexible on how you identify mobile transactions, as long as you can combine the mobile CPU into a CSV suitable for the Mobile Workload Reporting Tool, a slightly different version of SCRT.
- IBM also offers a public cloud discount similar to that for mobile workloads, if you use a well-known cloud provider such as IBM Bluemix or Amazon Web Services.
- The price of an MSU depends on the software running on individual LPARs. Segregate expensive software or nonproduction work to smaller LPARs to save money. Conversely, keep discretionary work off of LPARs with expensive software.
- IBM's new processor architectures run most efficiently when data and instructions are in cache. Busy machines, however, do a lot of context switching, which puts pressure on cache and leaves the CPU waiting for data. Therefore, the same workload will consume fewer CPUs on processors that run at lower utilization. In some cases, you can buy more engines that run at a slower speed to save money.
- Database tuning is important for a relational database management system such as DB2. When DB2 performs table space scans or updates useless indices, it drives CPU usage. Identify inefficient SQL statements and work closely with application teams on the cheapest way to get to the data. Prioritize application tuning to eliminate low-hanging fruit, such as a number of database queries, inefficient call chains or unnecessary transactions.
- Transfer everything you can onto z Integrated Information Processor (zIIP) engines. While only system-level code and Java can exploit this specialty processor, it may be worthwhile to update system software or look for other options that use zIIPs.
- The distance between a processor and its coupling facility (CF) can also increase CPU usage. Synchronous coupling facility calls essentially spin on a processor until they complete -- the greater the distance from the processor, the longer the spin. Try to keep CFs close to the processor that will use them, and try to minimize the amount of CF structure duplexing.
- Before you encounter a 4HRA, try to reduce CPU usage, avoid using MLC products and bring down discretionary LPARs. If timed correctly, some software and hardware will be essentially free.
- Even though SCRT may be opaque, you can access the SMF records to find more information. Look at the type 89 records to know when, where and which products were active. Look at usage sections in type 30 SMF records to pinpoint exactly which products an address space used. IBM has another reporting tool, IFAURP, which produces usage reports more detailed than SCRT.
- Offload to other platforms where possible to reduce IBM z Systems software costs. For example, some processing like geocoding may be more efficient on a UNIX platform. IBM also offers a DB2 Analytics Accelerator for big data analysis.
ZEnterprise gets an update for mobile, cloud and analytics
Is z Systems the champion of open source for mainframes?
Five tips for better mainframe monitoring