So, you have some responsibility for the performance of your company’s mainframe. All your efforts at tuning what’s executing have been successful. There are very few “rogue” DB2 SQL statements, IMS DL/I calls or CICS transactions that keep you up at night. In fact, you sleep quite well. But there’s one problem: The mainframe is demanding more and more CPU, which is causing MIPS to rise. This trend has been attributed to an increase in volume. More volume must mean more customers, and more customers translates into higher revenues. This is good! But, wait, what if the increase in the number of customers doesn’t match the growth of MIPS? Poorly tuned applications could be the culprit. Maybe customers are accessing their data more frequently. Or, is it something else? Perhaps the business made a decision that’s driving the uptick in MIPS.

A friend at a wireless company told me that when they started implementing monthly limits on data, they saw a large spike in customers inquiring about how much data they had used in a current month. Each time a customer requested his current data usage, the system accessed DB2 to get the information to the customer. Now think about the number of people with smartphones today. Even if a small fraction of them request their data usage, how many transactions is that going to generate? It’s going to be a huge number. How do we mitigate this additional MIPS usage? For starters, we can ensure the SQL executing on the mainframe has a solid and efficient access path and we make as much use of the System z Integrated Information Processor (zIIP) as possible, if available.      

The bigger question we should be asking is whether the distributed application is getting the data efficiently; not via the access paths, but rather, how many SQL calls is that application making to get the data. Does it make one call or 10 calls, and if the application is designed to make 10 calls, can the data be acquired in fewer calls? Does the application even need all the data that it’s asking for?

These activities—some necessary, some not—are what drive your mainframe today. You’re tuning what the application is sending you with no idea why it’s being requested. To be able to tune this type of workload, what you really need to see is the context of the requests being sent to the mainframe, and of those requests, how the data is being used. With context, you will know what’s needed and what’s being thrown away so you can determine exactly how the application should interact with the mainframe.

Achieving this level of efficiency requires transaction visibility that traditional application performance monitoring tools simply don’t provide. End-to-end transaction visibility—from the edge of the Internet, across all distributed tiers and into the depth of the mainframe—provides data on a transaction each step of the way. This unprecedented insight affords the necessary context for determining how the mainframe is being driven so you can properly tune your applications to reduce MIPS and postpone hardware upgrades.

Web and mobile applications are placing tremendous demand on the mainframe. This increased demand should be prompting developers to look at their mainframe application development landscape differently. It’s no longer feasible to view transactions myopically. Equipped with the ability to trace a transaction from its origin all the way to the mainframe and back, you’re in the driver’s seat now.