A Quick Guide to Mainframe Performance Optimization
If your company is like 70% of the Fortune 500, it continues to use mainframes for its most business-critical IT workloads. In such organizations, finding ways to get more bang for the mainframe buck, in terms of both costs and performance, is always a high priority. If that’s the case in your company, here are some tips that can help you optimize your mainframe performance.
Use effective monitoring tools
To optimize the performance of your mainframe, you first need to understand what’s going on inside. Which workloads are placing the greatest burden on system resources? What specific operational bottlenecks and processing inefficiencies need to be addressed? How do performance baselines compare before and after optimization efforts?
To answer such questions, you’ll need tools that can provide comprehensive information through real-time system monitoring. A good example is Ironstream, the industry leader for forwarding critical operational and security data from the mainframe to analytics platforms such as Splunk and ServiceNow.
Offload processing to zIIP
Specialty hardware, such as IBM’s System z Integrated Information Processor (zIIP), can significantly reduce your mainframe’s CPU processing burden (and expense) for some types of workloads.
For example, Syncsort MFX allows you to offload as much as 90% of Copy, SMS Compression, and Sort CPU cycles to zIIP, reducing the elapsed time for those operations by up to 25%. And here’s a great bonus: the only cost for using zIIP is the initial hardware purchase; there are no software license charges.
Reduce code inefficiency
“Efficient code is king,” says Jonathan Adams, VP of Data and Performance Management at BMC Software. And he’s right.
Poorly written COBOL or Db2 SQL code can significantly degrade performance. For example, performing sorts or number rounding in COBOL is exceptionally inefficient. Rewriting critical path or intensively used legacy code could pay substantial performance dividends.
IBM has been cautious about maintaining backward compatibility so that when a mainframe’s OS, middleware, or hardware is upgraded, application programs don’t have to be recompiled. But you may well have some COBOL or PL/1 programs that should be recompiled anyway.
That’s because continuing advancements in compiler technology are yielding significant performance enhancements that can be realized by simply recompiling unchanged source code. IBM asserts that “aggressive use of the latest compiler technology” is the “biggest single performance lever for many applications,” and can result in CPU time reductions of up to 17%.
Reduce the batch processing window
Although mainframes are widely used for real-time online transaction processing (OLTP), batch processing continues to be essential. Whether it’s generating daily operational reports, producing customer account statements, or performing payroll processing so employees get paid, regular batch runs are an indispensable element of many companies’ IT workflow.
In some aspects, batch processing is substantially more efficient than OLTP. For example, whereas OLTP may require several time-consuming database queries for each transaction, a batch process might access that data only once, holding it in memory during the entire run of the program.
But when batch and OLTP applications run concurrently and compete for the same CPU or storage resources, OLTP (being real-time) must have priority. So, the JCL controlling batch jobs should be tuned to reduce resource use and to keep the time window devoted to batch processing as narrow as possible.
Mainframe performance optimization is worth it!
Because optimizing your mainframe’s performance will help you keep up with ever-growing data processing requirements without the expense of upgrading hardware, it’s definitely worth the investment of time and effort that will be required.
Download our white paper to learn how to offload, accelerate and lower cost while leaving the primary CPU with more headroom for the organization’s core business applications.