If you are an IT manager, application owner, architect or developer in a corporation leveraging a mainframe, then today is a revolutionary day: Application Performance Management is now available end-to-end for the mainframe. Read about how this will drastically change the way we manage developing, refining, testing and bug-fixing applications involving a mainframe.

The Pain
Are you a mainframe developer that spent hours optimizing mainframe code and still receive complaints about bad mainframe performance from the distributed guys? Or are you a Java or .NET developer calling mainframe transactions and not satisfied with their performance? Stop playing the blame-game. APM extended its end-to-end scope and can now follow every single transaction into the mainframe, 24x7:

End-to-end visibility for the mainframe has arrived.

Developers and architects are now able to assess if they use the mainframe's resources such as CICS transactions appropriately or - the other way round - if the implementation on the mainframe fits the needs of the distributed part of the application.

Architects and application owners can now identify where the mainframe load is coming from. In other words, it is now possible to analyze what application, what feature of an application or even which tenant or user consumes how many mainframe cycles. This is the basis for optimization on an application level; beyond optimizing on the mainframe in isolation.

Monitoring what's driving our mainframe cycles. This example dashboard shows mainframe CPU duration per tenant.

Also, we are now able to measure the contribution of the mainframe to the response time for a particular application or even for a particular transaction, e.g. ‘click on purchase'.

The figure shows an API breakdown of an application using a mainframe. Only 8ms are spent in CICS, 2.5ms in DB2.

Why does that matter? In many enterprises, the mainframe plays a significant role in their IT infrastructure landscape. It is still running many backend legacy applications critical to the business. But at the same time organizations are also developing mainframe applications and investing in young specialized personnel. As the mainframe was acknowledged as the business machine back in the 1950s, it is still the central data repository for many corporations.

What's Happening

The sequence diagram helps us to understand the flow of the application.

End-to-end does not just end at the call to the mainframe, it continues into the CICS region all the way to the database. Thus, we have complete mainframe transaction visibility. We know exactly what's calling what, and in what context! For example if a certain value that's passed on to the mainframe routine, needs error handling, we identify a different flow on the mainframe than for usual values.

Analyzing the sequence of mainframe routines is easy when zooming into the Sequence Diagram.

The Mobile Banking Story
Now specifically let's think of a money transfer via an online banking mobile application. Besides the native mobile app for Android, iOS and Windows Mobile, we probably have a web server and an application server running before the actual execution of the money transfer. That transfer is done via a COBOL or PL-1 program on the mainframe. So we do have an interesting diversity of technologies, which potentially makes pinpointing an error or a performance bottleneck quite an endeavor. Let me use the following story to demonstrate the game-changer in full depth:

Identifying the Root Cause of a Frustrated User
The following scenario is based on our demo application easyTravel, an online booking platform, where the credit card authorization is implemented in CICS. Now, Hainer is just about to place his payment for his well-deserved vacation in Vientiane when he receives an ugly error.

Booking cannot be completed. Let's call the hotline.

When he calls the support, they can easily find the frustrating visit of Hainer and identify immediately that he tried to place the payment three times.

Looking at Hainer's visit and all the page actions he performed. We notice he tried to place the payment three times unsuccessfully.

From there, it's one-click to view the exact path from the Servlet across MQ into CICS and the DB2 statements. We identify that the CICS program wants to respond but fails to put the result in the response queue when looking up the return code 2053 on the WebSphere page.

The CICS routine cannot put the response into the queue; the call results with error 2053.

If we look further down the path we also see that the client waiting for the response runs into a one minute timeout and aborts with an error. Luckily we already have identified the root cause (i.e. the expected message was never put into the queue)! This would not be that easy without mainframe-visibility!

Client runs into a timeout with reason 2033, i.e. no message available

Summary
With APM, our goal is not to just increase mainframe performance. Rather, we want to optimize the way the mainframe is used by the distributed world, and that the mainframe routines are optimized to fit the needs of the distributed world. The need that APM had to extend to the mainframe is driven by legacy mainframe applications that are now used by distributed applications such as core banking applications which are now accessed by frontends such as mobile applications or browser UIs. Also for enterprise APM solutions it is crucial to support a wide range of technology to provide a complete view on applications. For that, the mainframe can't be left out. Let's remove that blindfold.