Tuning mainframe applications cuts software costs

Article

Tuning mainframe applications cuts software costs

Mark Fontecchio, News Writer
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

    Requires Free Membership to View

    When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with data center technologies.

    Cathleen A. Gagne, Senior Editorial Director

    By submitting your registration information to SearchDataCenter.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDataCenter.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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."

For more on mainframe management:
Roadmap to mainframe application modernization

Mainframe capacity planning: More than MIPS

IBM mainframes still have room for improvement

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."

Macro 4 says the first step in tuning applications is to understand where resources are being used.
,

"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%."

Let us know what you think about the story; email Mark Fontecchio, News Writer. You can also check out our Mainframe blog.