Many mainframe customers have moved, or plan to move, applications away from the mainframe and to distributed platforms such as Windows or Linux. This is done with the expectation of saving MIPS.
A common approach is to move the application logic but keep the data on the mainframe as the ”system of record”, at least initially. However, many customers are surprised to find that their mainframe capacity usage can actually increase when this is done. This effect is commonly referred to as the ”offload boomerang”. While offloading the application, logic should reduce the load on the mainframe. In many cases it is replaced by remote data access techniques and these can be much more expensive and a lot less transparent than the code they replace.
This project creates transparency into how the distributed- and mainframe components interact with each other. It also provides optimization recommendations to the customer, recommendations focused primarily on the ”Offload Boomerang”.
The developers have limited transparency into the performance and capacity impact that their distributed programs have on the mainframe, and the mainframe operations staff have limited insight into, or ability to manage, the workload coming to the mainframe from the distributed platform. No one has a complete end-to-end understanding of the situation.
The overall objective of this offering is the same as in the previous section ‘Understanding how distributed workload drives MIPS usage’, to create transparency into how the distributed and mainframe components interact with each other and to provide optimization recommendations to the customer. The primary difference between the two services offerings is that this offering focuses more narrowly on the ‘Offload Boomerang’.
What we will deliver
Using ITBI™ as a starting point, SMT Data analyses the impact of the distributed workload on the mainframe. This can be done for example based on SMF 101 which gives insight into DB2’s resource usage, including the DDF components.
With this data it is possible to see how many MIPS are being used by remote data access, which plans or packages are involved, and which applications, servers and users are driving the MIPS usage. It is also possible to enrich this technical data with business information, for example by translating a server or user name to an organization orapplication.
Once the cost drivers coming from the distributed environment are identified and understood, the second step is to analyze the setup on the distributed systems based on interviews with the customer’s technical staff. This includes investigation of the standard software components such as drivers.
Have the correct versions been installed and havethey been configured optimally? The distributed architecture and coding practices are also evaluated. Is dynamic SQL used to access the DB2 data? How does the installation ensure optimal access paths for the SQL?
The result of this offering is a presentation containing the technical findings as well as specific recommendations as to activities that can be carried out to reduce mainframe resource consumption and thereby reduce costs. Regular meetings are then held to follow up on the implementation of the recommendations, quantify cost savings, and identify new findings and recommendations.