Mainframe workloads are increasingly driven by mobile apps. The good news is that this mobile-driven activity greatly augments the business value that companies can derive from their significant investments in mainframe infrastructure, programming and databases. The somewhat problematic news is that these rapidly growing and often highly variable mobile-driven workloads can have a serious impact on your Mainframe Licensing Costs (MLC) as determined by the rolling four-hour average (R4HA).
Every mainframe team facing mobile-driven workload growth must therefore adopt appropriate measures to effectively mitigate the impact of that growth on their company’s mainframe costs.
There are three basic ways mainframe teams can do this: Mobile Workload Pricing (MWP), application behavior tuning and proactive cost-aware DevOps.
Capitalizing on Mobile Workload Pricing
IBM introduced MWP in April 2014 to help enterprises improve the mainframe-enabled mobility value equation. Essentially, the MWP program reduces the impact of mobile-driven MIPS on R4HA metrics by 60 percent. So if you have a 100 millions of service units per hour (MSU) peak of which 70 MSUs are generated by mobile activity, that peak is reduced to 100 - (70 x .6) = 58 MSU.
You can’t, however, just make an educated guess about how many MIPS are being driven by mobile. You need a technically legitimate means of identifying mobile MIPS that fulfills IBM’s criteria—and you must be able to use that means of identification to drive IBM’s Mobile Workload Reporting Tool (MWRT).
There are many ways to identify mobile transactions in the z System environment. IBM has published an excellent whitepaper on the topic, “Measuring CPU Eligible for Mobile Workload Pricing”
by Ian J. Mitchell. However, it’s important to note that regardless of how mobile transactions are identified within the mainframe environment (i.e., via a dedicated CICS Region or SMF analysis), that identification requires some sort of segmentation outside the mainframe environment—for example, by passing transactions from mobile browsers and desktop browsers through different application servers.
Mitchell makes this point when he writes: “All acceptable distinctions [for quantifying mobile workloads] originate outside of System z and z/OS. It is not possible to measure CPU eligible for MWP without using a distinction flowing into the system.”
In other words, mainframe and distributed teams have to collaborate to establish effective means of capitalizing on the MWP opportunity.
Application Behavior Tuning
Code running in distributed environments often utilizes mainframe resources in inefficient ways. Common problems include:
- The starburst effect. This type of inefficiency occurs when a distributed application makes a call to DB2 or CICS that, in turn, triggers other calls that are not material to the mobile transaction at hand. The result is a lot of activity that—when multiplied by a large number of transactions during a period of peak utilization—can have a non-trivial impact on MSU utilization. This starburst effect can be remediated by understanding exactly what the mobile app needs, analyzing the call to see what other extraneous actions are triggered and dialing back that application activity appropriately.
- Too much information (TMI) syndrome. This inefficiency occurs when too much data is returned to a distributed application. As with the starburst effect, TMI syndrome can be remediated by understanding the actual needs of the application and dialing back data retrieval to address only those needs.
- Stored procedures vs. Dynamic SQL. To get the data they need, distributed developers can write their own SQL for execution via a JDBC connection. Unfortunately, this SQL can overutilize DB2 resources because it’s not properly tuned. Savvy mainframe DBAs should instead create native Stored Procedures to get the zIIP offload and reduce MSU impact.
Of course, some inefficiencies result from the same kinds of on-platform issues that mainframe teams have always dealt with, such as less than perfectly written COBOL or SQL statements. The key is to apply these MIPS-minimizing disciplines to the new mobile-generated workloads that threaten to drive R4HA costs up unnecessarily.
Proactive Cost-aware DevOps
In addition to identifying MWP discount opportunities and remediating inefficiencies in existing mobile-driven workloads, mainframe teams should also work with internal and external distributed/Web/mobile development teams to proactively avoid unnecessary cost drivers.
At the highest level, this collaboration should include basic education about how mainframe resources are consumed by code running in the distributed environment. Most distributed developers have no idea what the R4HA is, how MIPS consumption is driven or even how the mainframe works. And historically there has been no equivalent to R4HA in the distributed world. So it’s difficult to hold developers entirely responsible for the impact their code has on mainframe costs. But with the advent of usage-based cloud/Anything as a Service models, the MSU/R4HA concept is probably easier than ever for developers to understand. Mainframe ops teams should take responsibility for providing this understanding.
At a more granular level, mainframe development and ops teams can help minimize the impact of new mobile workloads on the mainframe by being a little smarter about how they design and publish APIs and other services to the distributed development community. These design decisions should not just be driven by technical expediency as they may have been in the past, but also by the cost-efficiency imperative.
Finally, given the increasing pace at which mobile app code is being iterated (i.e., Agile and continuous delivery), IT organizations should consider integrating mainframe impact analysis into their dev/QA process so that they can nip potential cost issues in the bud without adversely impacting the ability of the business to keep up with the breakneck pace of competition in the world of mobile customer experience.
Mainframe ops teams have always tried to exercise reasonable control over MIPS utilization. But the mobile revolution is substantially raising the financial stakes of the cost-control game, while also introducing new technical challenges. By adopting the right practices and tools—and by working more collaboratively with the non-mainframe community—mainframe teams can successfully meet those challenges and optimize the economics of IT.
Spencer Hallman is product manager at Compuware.