Myths About MIPS, Part 2

Blog /Myths-About-MIPS-Part-2

In my last post, I explained how MIPS usage can be a key factor in legacy modernization and how a reduction in MIPS usage is extremely important in modernization planning.

Many IT organizations have chosen to simply pay high usage fees because of the shared nature of the platform. But industry analysts estimate that most large organizations with mainframes will see their systems’ CPU resource consumption increase by 15% to 20% annually.

As a business grows, data processing increases alongside it, resulting in higher resource consumption. So it’s essential to write efficient code that can handle a large amount of data without much increase in MIPS usage. Consider a large retailer that implements new software in one store before rolling it out to other locations. (Once any problems have been identified and fixed at the beta site, it’s fairly easy to upgrade stores in a few states or a region and then the entire chain.)

The problem is that although data processing at the beta site may have occurred as expected, when the mainframe has to process data from thousands (or tens of thousands) of stores, run times will be significantly affected if performance has not been addressed. MIPS usage is driven by CPU usage, and CPU usage depends primarily on how efficiently the code is written.

Because inefficient application code is a major cause of high MIPS usage, improving that performance can significantly lower CPU resource consumption. For example, standard COBOL code usually runs much faster than a COBOL/database. Thus, improvements to the interaction between client applications and a DB2 database have the potential to yield large savings for the organization.

In many cases, you can reduce CPU cycles in SQL queries by eliminating aggregate functions or ORDER BY clauses, instead sorting the data after the fetch or adding an index, especially for a high-volume database. This requires a lot of physical input/output operations and disk storage, but changing those two lines of inefficient code can save hundreds of MIPS, adding up to significant savings.

MIPS can’t measure the actual consumption of work, but MSUs can. Both MIPS and MSUs have a direct financial implication, but we can safely say that increased MIPS capacity and MSU accrual both result in higher mainframe usage fees, impacting operational costs. So, if you have no immediate plan to modernize your applications, consider addressing these types of code issues to reduce MIPS usage and save money.

Date de la publication : 2016-03-14