The old adage, “A place for everything, everything in its place,” can take on a new meaning when it applies subsystems. Why? Because mainframe subsystems that you rely on to support critical business and drive the digital enterprise — like IMS, DB2, and CICS — are charged based on where they are placed, rather than the amount of usage, or MIPs. Duplicate subsystem copies raise costs. So, every IMS, DB2, or CICS workload that requires an instance of each communicating system to be present on the same logical partition (LPAR) increases costs. But if you can place the subsystems on separate LPARs and still communicate, then you can lower costs dramatically.
How the sub-capacity pricing model works
First, here’s a primer on sub-capacity pricing. IBM Monthly License Charge (MLC) costs are based on the 4-hour rolling average (4HRA), which is calculated every hour and is the average MSU consumption over the previous 4 hours. You’re charged based on the highest single reported 4HRA for the month. It doesn’t even matter if certain subsystems, such as DB2 and IMS, only use a small portion of the peak MSUs, either. Fortunately, with subsystem optimization, you can move MLC products off certain LPARs and place them on their own.
A close look at potential savings
MLC costs represent about 30 percent of the mainframe’s budget and they are increasing at a rate of four to seven percent a year. Wow! With subsystem optimization you can save up to 20% on MLC costs and minimize business risk. Here’s how:
Without subsystem optimization
- Example: If your CICS transaction wants to interact with IMS, and if an IMS TM transaction wanted to access DB2 data, all of those subsystems would have to be on the same LPAR. Then you’d have to pay the top usage for the month for everything running on that LPAR added together. So, when the consumption peaks, you get charged the peak rate for the entire month!
With subsystem optimization:
- If you can take DB2 off of that LPAR and put it on its own, then DB2 doesn’t contribute to the charges for subsystems on the original LPAR. It doesn’t get added to the cost of CICS processing, so your MLC bill is lower. Instead, DB2 is charged for consumption based on its own LPAR. And, the subsystems don’t need to live together anymore on the same LPAR to communicate with each other.
- Subsystem Optimizer for zEnterprise® gives you options that were not available even just a few years ago. It separates CICS and DB2 and/or CICS and IMS DB into different LPARS. Separating these subsystems means the peak MSUs on one LPAR do not contribute to the peak for the subsystem running on the other LPAR.
- Because Subsystem Optimizer allows data access, you don’t have to make application code changes to your transaction programs to get these benefits.
Ready to optimize? Begin with a safe and easy-to-implement subsystem optimization strategy
A good way to begin is to plan and model changes with Cost Analyzer for zEnterprise to get an idea of the costs and how much you can save by more efficient placement of subsystems. Then you can use Subsystem Optimizer for zEnterprise to optimize where subsystems are placed. This solution provides data access and communication across LPARs and efficiently redirects workloads to reduce MLC costs. In fact, with the release of Subsystem Optimizer v2.0, BMC goes beyond supporting CICS connecting to the IMS database and has added the capability to support IMS TM linked into DB2.
By understanding the MLC cost pricing model and by optimizing your subsystems, you can reduce MLC spend and minimize business risk. Learn more.
- Calling All DB2 DBAs and Managers: Don’t Just Survive the Data Deluge – Thrive
- DB2 LOBs: Unstructured Data Management
- It’s Not Your Daddy’s DB2! – Part 4
- DB2 for z/OS buffer pools – the basics
- New World, New Tools: Transforming DB2 Data Management