Third-party mainframe software costs are a cost killer and a major hindrance to mainframe growth. Tuning these applications can not only improve performance but also save millions of dollars, experts said.
"Mainframe resources can be really expensive," said Andi Mann, a research director at Enterprise Management Associates. "If you have applications using those resources, you can find yourself in a multimillion-dollar upgrade much sooner than you might need to."
What can mainframe shops do to postpone a mainframe upgrade or otherwise save money?
The first place to look is mainframe software licensing, which Mann said is an order of magnitude more expensive than in the x86 and even Unix systems world. Making matters worse, mainframe shops often have more licenses than they really need, especially in companies with multiple mainframes.
"A lot of companies will license the same software across every system," Mann said. "If you can optimize how applications run and where they run, you can reduce the number of licenses down to one or two."
Though not as problematic as with distributed servers, Mann said that mainframe shops often have wasted capacity. A banking or insurance application, for example, might run heavy during the day, but not at night. In that case, administrators can apply workload management principles to identify applications that now run during the day but that could be safely shifted to run on the box's spare capacity at night.Tuning z/OS and DB2 applications
Once that low-hanging fruit is picked, mainframers begin tuning applications to save on software and avoid costly upgrades. Macro 4, a U.K.-based IT consulting company, says a good place to start is with z/OS and DB2. The savings from tuning those apps is so substantial that Macro 4 will not charge a customer if it doesn't save twice as much money as its consulting fee.
Philip Mann, a principal consultant at Macro 4 (and is no relation to Andi Mann), said that Macro 4's first step is to "understand where existing resources are used on various workloads: online, batch, etc."
"We would then turn our attention to where the majority of resources are being used on critical parts of the day when the system is most under pressure," he continued.
Different consultants at Macro 4 have their specialties, such as z/OS or DB2. With z/OS, Macro 4's Mann said, "it's a fairly well known fact that when you go from one release to another release, you'll need more resources. You can do configuration for z/OS parameters that can help you avoid that increase."
Macro 4's Mann focuses mostly on DB2 ,where database performance is often undermined by incorrect or absent indexing.
When Macro 4 does a customer installation, it often finds one or two database calls using 90% of the computer's resources.
In one instance, Mann said that it "was quickly obvious that those database calls weren't using any indexes to retrieve the records and that results in a tablespace scan, rather than going from an index."
Even on those sites where indexes are set up, DB2 might not use them. Mann said DB2 administrators often go through the binding process too early (i.e., indexes are built before there are sufficient records in the database). In this case, the binding process dictates that DB2 do a tablespace scan instead of using indexes.
"Then you load a couple hundred thousand rows into the table, but it will carry on the original scanning procedure," Philip Mann said. "What we might do is collect information about how many rows are in there and re-bind the whole thing."
In other words, a trained eye can find significant cost savings by examining an application that others might overlook.
"I would say that if the customer has applications that use DB2, and they're not on a continuous basis looking at the performance of their applications, if our people came onto the site we could probably make very significant savings very quickly," Mann said. "Most savings we find come out of tuning the area of DB2 and SQL resources, where you can improve application performance by 90% to 95%."