“What? Are you crazy? Of course it is,” says a little voice in your head. Maybe you will stop reading at this point, but if you want to know how to pay 20% less on your IBM MLC bill next month, with no application changes—all while maintaining your current software stack, I encourage you to read on. The usage-based mainframe MLC pricing model sounds like a fair deal at face value, and it can be, but only if you play it smart. I will show you how to change the game and significantly lower your MLC.
In a hypothetical example of the usage-based mainframe MLC pricing model, let’s consider how this would work if it were applied to a wireless phone family plan with three lines – one for you, one for your spouse and one for your child. In this model you would be charged based on the total usage of minutes, data and texting in the highest peak of the month. For the respective phone lines in this example, you use mostly calling minutes, your spouse uses mostly data, and your child uses mostly text messages. As long as your family’s usage stayed flat, at the end of the month your phone bill would reflect a consistent number. However, each member of your family is not created equal when it comes to usage. What would happen if your child decided to send double the normal number of text messages in a month? Your child’s wireless phone bill would not simply increase; ALL family members would see the same increase on their wireless bill.
If we translate this analogy to the mainframe MLC model, each wireless phone line represents an LPAR on your z Systems® mainframe and each wireless phone capability of calling minutes, data and text messages represents a subsystem on each LPAR – like CICS, DB2 and MQ. For MLC pricing, if you are a heavy CICS user on an LPAR, you don’t just pay a lot of extra cash for what extra CICS MIPS volume you use on that LPAR. Your CICS, DB2 and MQ subsystems are ALL charged the same increased price based on the total MIPS increase of the highest R4HA peak of the month. Back to the analogy, instead of paying just $50 more for your child’s heavy text message usage that month, you pay an increase of $50 on each wireless phone line with a text message capability for a total of $150.
How do you play this game more intelligently and pay ONLY for what you use? You change the game! Traditionally, subsystems like CICS and DB2 must reside on the same LPAR for technical reasons, and your MLC bill would reflect this financially poor arrangement, as I demonstrated earlier. Today, it is possible using an industry unique solution to “turn off” MLC based subsystem instances, and “turn on” these subsystem instances again on their own isolated LPARs. Now that you have isolated your heavy CICS usage to its own LPAR, it will truly be an ideal usage-based pricing system. Meanwhile, the minor MIPS volume consumed by MQ and DB2 on their respective isolated LPARS reflects a minor MIPS contribution to your MLC bill at the end of the month. Using this solution, the mainframe team can rest assured that they are getting the best run for their money with zero impact to performance, zero application changes and zero changes to the previous software stack.
So, next month are you going to keep paying $150 for the $50 extra you used? Or will you change the game?
If you would like to learn more about changing the game and truly paying an ideal usage-based MLC pricing model, you can learn more here: http://www.bmc.com/it-solutions/subsystem-optimizer.html