Where You Put IMS, CICS, and DB2 Can Reduce Mainframe Costs

Separate-the-Placement-of-Major-Subsystems-and-Save_700x400

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.

 

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post


David Schipper

David Schipper

Dave Schipper is a lead product manager at BMC Software responsible for the BMC Subsystem Analyzer for zEnterprise (Subzero) and the BMC Database Solutions for IMS. As product manager, Dave works with customers to understand their needs and uses that information to set product directions and prioritize new product capabilities as he interfaces with the development teams. Dave has over 30 years of experience with mainframe systems and has been in product management for over 20 years. Dave has Bachelor of Science degrees in Computer Engineering and Applied Mathematics from the University of Michigan as well as a Master of Science in Computer, Information and Control Engineering from the University of Michigan.