There is no denying that mainframe computing can be costly. The hardware alone can cost several million US dollars, and over time the software can be just as, if not more costly. As such, reducing mainframe software costs is an important goal for every organization that uses the platform.
Please note that I am not saying that the mainframe is too costly, or more expensive long-term than other commodity servers. The mainframe is very cost-effective when managed appropriately. And part of that, management needs to be understanding mainframe pricing strategies and cost control.
A significant component of overall mainframe cost is the software you are billed for monthly, known as Monthly License Charge (MLC) software. Not all mainframe software falls into the MLC category, but most of the big system software offerings do, such as z/OS, Db2, CICS, IMS, MQ, and COBOL. Furthermore, this software is billed based on usage, therefore reducing usage can reduce your monthly software bill. Of course, there are many nuances to how this usage-based pricing and billing occurs (we will mention a few in a moment), so it is not as easy as simply reducing workload to reduce costs.
But in a moment, I will tell you about a tool you can use to help estimate cost savings as you modernize your mainframe applications. First, let’s talk more about mainframe software costs.
Using zIIPs to Reduce Cost
One method of reducing cost is to increase the usage of zIIP specialty processors. The zIIP is a dedicated processor available on the IBM Z mainframe. When you activate zIIP processors, some percentage of the relevant workload can be redirected off of the general processors onto the zIIP. Why would you do this? Well, a workload that runs on the zIIP is not subject to monthly software charges. You can save money by running work on the zIIP instead of the general-purpose processor.
But not all workload is eligible to run on the zIIP. You need to understand what types of processing can utilize zIIPs to accrue cost savings. Java programs are zIIP eligible and therefore represent a very ripe opportunity for cost reduction in mainframe shops. If you convert traditional workload, such as COBOL programs, to run on a Java Virtual Machine, that workload becomes zIIP eligible and can deliver significant cost savings.
Of course, this means you will need options for converting from COBOL to Java.
CloudFrame Solutions for Application Modernization
So, chances are you are sitting there with a large portfolio of COBOL applications written over the course of multiple decades. They run in batch and online. They access databases. And they run much of your business. Who has the time, let alone the resources, to re-write all of that code into Java?
Nobody does, right. And that is where CloudFrame’s application modernization solutions can help. They provide two different offerings, supporting different use cases, both of which can be used to reduce cost by converting COBOL to Java.
The first option is CloudFrame Renovate which converts your COBOL code to Java. The resulting source code is not JOBOL (that is, Java that looks like COBOL) but well-written object-oriented Java source code. Using this approach, you can get rid of the COBOL and start working with Java, running your code on the mainframe, another platform, or in the cloud – anywhere that Java runs.
Another approach is offered by CloudFrame Relocate. In this case, you keep the COBOL source code but convert the executable code to run in a Java Virtual Machine. No change is necessary to your data or other processes, but now that the code runs as Java, it is zIIP-eligible and can help reduce costs.
Both are viable methods of generating cost savings and can be deployed separately or together for different workloads and use cases.
How Much Can You Save?
Of course, to this point, we have been discussing cost savings as a broad generality under the assumption that moving workload to zIIPs using Java will result in savings. But how much? To that end, CloudFrame has put together an ROI estimation tool for customers to help them estimate how much money they can save using the CloudFrame solutions. The tool is a spreadsheet with calculations to analyze cost reduction based on workload mix, average MIPS cost, cost of licensing CloudFrame, and other metrics.
You can click here to request access to use the cost estimation tool, and CloudFrame will help walk you through it. After you complete the registration, a CloudFrame representative will schedule time to help you walk through the cost estimation process. You will need to provide information about your environment to make the tool worthwhile. For example, you’ll need to know the average cost per MIP for your organization and the monthly MIPS usage for the workload you plan to convert from COBOL to Java. You will also need to provide additional information about your environments, such as the number of mainframes installed and the total number of disaster recovery environments you use.
You will also be asked to provide some details about the workload mix, such as the mixture of batch vs. online processing. The actual MSU rating for a CPC model will generally be highest for batch-type workloads and lowest for online type workloads, so this type of information is helpful.
The cost estimation tool will also consider the percentage of Db2/SQL workload involved, as that can impact the zIIP offload and cost savings that may be possible.
After supplying the appropriate input, the tool will show an estimate of your net savings (or ROI) over a three-year period, along with an Executive Summary that shows year by year break down of the annual cost to run your applications, the projected annual cost savings, the cost of the CloudFrame subscription, and the over net savings. Of course, the results will depend significantly on the accuracy of the information you provide.
You would do well to keep the following issues in mind as you work through your ROI evaluation. First of all, the spreadsheet is based on MIPS instead of MSUs. IBM no longer really talks about MIPS, but many mainframe shops are still more comfortable talking about MIPS than MSUs. That said, the customer’s monthly MLC software bills are calculated based on MSUs reported by the SCRT. So, you may need to do some MIPS to MSU conversions along the way. Loosely speaking, 1 MSU equals approximately 8.5 MIPS.
Another thing that you will need to know is the average cost of a MIP in your organization. This can be a difficult thing to ascertain. The CloudFrame tool provides some assistance with some analyst-sourced cost/MIPS estimates that you can plug in based on the size of your environment. That said, an average is just that, an average. It may or may not be the actual cost at your site, which can change from month to month based on the type of mainframe software pricing your organization uses.
This brings up another nuance, sub-capacity pricing, which most organizations use. Subcapacity pricing, such as AWLC or VWLC, means your MLC software is billed monthly based on a calculated rolling four-hour average (R4HA) of LPAR MSU usage. The monthly LPAR peak of the R4HA, by product, determines your software bill. This is a good thing because it means you are paying for capacity based on the R4HA instead of the maximum capacity of your system.
So, what does this mean for your cost estimation when converting COBOL to Java? Well, MSUs run on the zIIP are not factored into the R4HA, so if the workload contributed to the monthly peak R4HA period, then you can accrue savings. However, if the converted workload does not run during the peak monthly R4HA, you will not accrue any savings for that workload.
Of course, if you are using a full-capacity pricing metric, or perhaps tailored-fit pricing, then every saved MSU can help to reduce your software bill. The bottom line is that you will need to understand the type of pricing your organization uses and when the workload to be converted runs to understand the type of savings you might be able to achieve.
That said, many organizations’ monthly mainframe software bill is so high that analyzing and estimating methods of reducing that cost makes a lot of sense!
Cost of CloudFrame
The CloudFrame pricing model differs from those used by most mainframe software vendors. The goal is to provide a simple, understandable method for charging. The CloudFrame Relocate software is priced based on a flat fee subscription license per IBM CPC instance. The CloudFrame Renovate offering is based on an annual subscription license based on lines of code migrated. Additionally, the CloudFrame Developer Kit is priced based on the number of developer seats required.
So, it is relatively easy to determine the cost of the CloudFrame solutions.
I discussed the pricing and business case calculator with CloudFrame’s COO, Hans Otharsson, and here’s what he told me: “CloudFrame has created a pricing model based on input from customers and our years of enterprise software experience that can be summed up with this phrase, ‘easy to understand.’ We’re eliminating surprises and hidden fees and presenting pricing that offers great value to customers.” That will be music to the ears of most mainframe software buyers!
The Bottom Line
Using CloudFrame to renovate and/or relocate COBOL programs to Java can reduce costs, perhaps significantly. Why not get in touch with CloudFrame today and use the ROI estimation tool to see what type of savings you can achieve?!?!