The huge explosion in customer-facing Web and mobile applications is putting the spotlight on mainframe performance. While the millions of people logging onto these applications via laptops, smartphones and tablet devices might be unaware of it, they are often “using” mainframes. That’s because it’s actually established big iron that still does much of the back-end processing.
And when new tech meets “old” in this way, it’s up to systems management teams to ensure applications are using mainframe CPU efficiently, both to maintain service levels and to keep costs in check.
Mainframe workloads have increased due to the huge rise in transactions coming from Web users. Think of the volumes handled by online hotel-booking systems or financial services sites that provide quotes over the Web. The proliferation of handheld devices (tablets, smartphones, etc.) added to conventional PC-based Web access, means the work that mainframes are doing is likely to soar even higher.
Often, the mainframe applications at the back end are the same ones originally created to process transactions for internal company departments, branches or call centers. It’s a tribute to the architecture and durability of the mainframe platform that they can be adapted so easily to work as the processing engine in hybrid systems behind new Web-based interfaces.
Obviously, increased exposure to the general public can highlight problems in mainframe applications, which would have been accepted, tolerated and ignored at previously lower transaction volumes. Processes that previously had been used only within the company itself can see massive increases in transaction volumes as their use behind a Web interface explodes. And generally, for customer-facing online applications, the response from the system has to be almost instant; people are simply not prepared to wait around for a response.
In many cases, such as responding to automated requests from Web-based comparison sites, delays can lead to lost business. When a consumer applies for a quote via an insurance comparison site, for example, it sends a mass of automated XML requests to dozens of insurance-company sites. Any insurance site unable to return a quote within a relatively short time—often not much more than 30 seconds—will be presented as “unable to quote” by the comparison site.
With this kind of pressure on workload, the temptation might be to add more mainframe capacity by upgrading the processor. But this can involve a significant capital investment—and the upgrade might not necessarily fix the problem if it’s an inherent application performance issue.
Alternatively, there might be calls to re-host some applications away from the mainframe in order to free up capacity. But before taking such drastic action, the protocol should be to first look at the applications on the mainframe to check whether they are running efficiently—and tune them to run faster.
It could be that when new front-facing systems are integrated with mainframe applications, they highlight and expose inefficiencies in the way they run and use processing power. Mainframe application performance management can help to identify and correct these errors, which can mean the same workload can be handled using less processing power. So you don’t need to invest in additional capacity or to think of re-hosting on other systems to free up CPU.
Performance tuning is often ignored until severe performance problems and sudden increases in transaction volumes force one to look at it. However, in the IBM mainframe environment, effective application tuning can prevent performance problems, reduce response times so you can provide online customers with better service and, through variable workload license charging, make monthly savings against processing costs.
Philip Mann is principal consultant and a mainframe performance management expert with Macro 4. He has been working with IBM mainframes for more than 30 years, with more than 10 years at Macro 4, where application performance tuning is one of his major interests.