MIPS-devouring vendor software. It sounds like something from a science-fiction B movie, but it’s a real issue.
It used to be that you could purchase a vendor software package, install it and let it do its thing without much regard for how it accessed the mainframe. Today, however, the explosion in mobile Web is driving a huge increase in mainframe transactions and workload, making MIPS usage top of mind for organizations. Distributed applications are accessing and utilizing data from the mainframe now more than ever to fulfill millions of end-user requests around the world—from bank balance inquiries and money transfer requests to e-commerce orders. The transactions travel a complex path from the browser, through the cloud, past the firewall through the middle tiers and into the mainframe.
While traditional mainframe monitors can see and quantify this workload, mainframe administrators are blind to the true impact distributed applications are having on the mainframe. The inability to trace a transaction as it moves along the application delivery chain is costing organizations dearly in more MIPS, not to mention the resources required to troubleshoot and resolve application bottleneck issues.
I covered this topic during a session at the April IDUG conference in Orlando. As I was doing some last-minute prepping for the session, a friend I hadn’t seen for many years came up to me and we started talking. I previewed the premise of my session—that distributed developers are driving an increasing number of MIPS in DB2. Traditional tools (i.e., system and DB2 monitors) are doing a poor job of catching application logic that causes SQL with rock-solid access paths to execute when small changes in logic would eliminate the need for certain SQL to execute. He relayed a story about how an accounting vendor package his company purchased was causing the same problem.
He told me the vendor software applications were calling the mainframe to get the customer ID, last name and first name and then returning that data to the application. Then, a follow-up SQL was getting the address of the customer. The SQL statements looked good in the mainframe monitors, but when they started digging into the application logic (which was no easy feat), they discovered that many of these SQL statements were unnecessary, or could be re-written so one SQL statement could take the place of two or three SQL statements. When this issue in logic was pointed out to the vendor, they refused to address it and said the product was “working as designed.”
Excessive SQL is an all-too-common issue that’s driving more and more MIPS. Customers often believe that more MIPS mean higher volume when it may be poorly architected vendor software that’s behind the spike in MIPS. Companies add more MIPS when what they really need is an end-to-end transaction monitoring capability to allow them to trace each and every transaction, from the time they’re initiated on the browser until they reach the mainframe. With that level of visibility, companies can begin working with vendors to acquire MIPS-friendly software.