In the spring, IBM announced, almost as an aside, new pricing discounts for z/OS mobile transactions. At the time, it didn’t seem like a big deal. But IBM’s more recent announcement of its exclusive mobile partnership with Apple, covered by DancingDinosaur here, suddenly gives it much bigger potential.
The plan is to create apps that can transform specific aspects of how businesses and employees work using iPhone and iPad, allowing companies to achieve new levels of efficiency, effectiveness and customer satisfaction. At the backend will be the mainframe.
Already zEnterprise shops, especially banks and financial services firms, are reporting growth in the volume of transactions that originate from mobile devices. The volume of these mobile-originated transactions in some cases is getting large enough to impact the four-hour peak loads that are used in calculating monthly costs.
Here’s the problem: you put out a mobile app and want people to use it. They do, but much of the workload being generated does not directly produce revenue. Rather, they are requesting data or checking invoices and balances. Kind of a bummer to drive up monthly charges with non-revenue producing work.
That’s where the new pricing discounts for z/OS mobile workloads come in. The new pricing reduces the impact of these mobile transactions on reported LPAR MSUs. Specifically, the Mobile Workload Pricing Reporting Tool (MWRT) will subtract 60% of the reported Mobile MSUs from a given LPAR in each hour, adjusting the total LPAR MSU value for that hour. Think of this as just a standard SCRT report with a discount built in to adjust for mobile workload impact.
So, what does that translate into in terms of hard dollar savings? DancingDinosaur had a private briefing with two IBMers who helped build the tool and asked that question. They are only in the earliest stages of getting actual numbers from users in the field; the tool only became available June 30. Clearly the results depend on how many mobile transactions you are handling in each reporting hour and how you are handling the workloads.
There is a little work involved but the process won’t seem intimidating to mainframe shops accustomed to IBM’s monthly reporting process. Simply record mobile program transaction data, including CPU seconds, on an hourly basis per LPAR, load the resulting data file into the new tool, MWRT, each month using the IBM-specified CSV format, and run MWRT, submitting the results to IBM each month. It replaces the SCRT process.
The MWRT will function like a partial off-load from a software pricing perspective. When an LPAR value is adjusted, all software running in the LPAR will benefit from lower MSUs. The tool will calculate the monthly MSU peak for a given machine using the adjusted MSU values.
This brings us back to the hard dollar savings question. The answer: probably not much initially unless your mobile apps already generate a sizeable proportion of your peak transaction volume. But jump ahead six months or a year when the IBM-Apple partnership’s new iOS made-for-business apps are gaining traction your mobile transaction volume could be climbing substantially each month. At that point, savings of hundreds of thousands of dollars or more seem quite possible.
Of course, the new applications or the entire partnership could be a bust. In that case, you will have burned some admin time for a one-time set up. You’ll still experience whatever normal transaction growth your current mobile apps generate and collect your discounted MSU charges. Unless the big IT analysis firms are dead wrong, however, mobile transactions are not going away. To the contrary, they will only increase. The bottom line: negligible downside risk while the upside gain could be huge.