Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Planning Better for Failure: How Mainframe Error Messages Impact CX

DZone's Guide to

Planning Better for Failure: How Mainframe Error Messages Impact CX

Mainframe developers plan. They're notorious for it. But that planning usually only concerns the mainframe-related aspects of an application, not the end-user experience.

· Performance Zone ·
Free Resource

Sensu is an open source monitoring event pipeline. Try it today.

Mainframe developers plan — they're notorious for it. But that planning usually only concerns the mainframe-related aspects of an application, not the end-user experience.

In a world where web and mobile applications increasingly rely on the mainframe as a big server, planning for how mainframe development actions will impact non-mainframe applications and customers down the line should be a critical aspect of the process. Unfortunately, it often isn't, and I think the evidence is in the bizarre mainframe error messages you sometimes see on mobile apps and websites.

When I Learned Mainframe Error Messages Matter

In my earlier years as a mainframe developer, I was given the assignment to go through a new application we were writing and find every possible failure point. I was to come up with a clear mainframe error message that would indicate where the failure occurred, what it was, and what could be done to resolve it. This assignment did not thrill me at first, but ultimately it changed my views about abends and how to handle them.

In one case, I figured out that something could go wrong in a certain place in the code, but I didn't think it would ever happen. Things would have to be totally out of sequence and that wasn't possible. I put in the error handling logic anyway and in my description noted that it should not occur again, but if it did, things would have to be restored and rerun in order.

It took two months before I saw that error message. What I'd predicted had indeed happened. I laughed and learned something that day. Had I not put in the message with clear resolution steps, it would have stopped processing and we would have had to investigate. It would have been a costly delay.

For me, the lesson was that mainframe error messages should be written at the same time as the code, and that you need to step back and consider all possibilities, no matter how unlikely. Because you never know who you're going to be impacting and how difficult it will be for them to determine a solution.

That's the ideal situation, but what you're often faced with now is a legacy application that has been repurposed for the mobile world-the mainframe error messages are already in place.

Planning Better Mainframe Error Messages for Customers

When I was designing mainframe error messages, it was for myself or someone in my group. If an error occurred with a mainframe application, it was assigned to someone like me, someone involved with writing the application, who could quickly understand the location and nature of the error and resolve it. If the message contained an error code, it would usually make sense and someone could use it to address the issue.

Flash forward: Today, mainframe developers need to think about how their actions will impact more than just their colleagues or other developers down the road.

For example, when customers' web or mobile applications display a database return code, it's not something they understand. This scenario is much worse than just the error itself because a cryptic message is confusing and disconcerting. What is the customer who is trying to buy something online supposed to do with that message? This isn't going to do them — or your business — any good.

Here's what will: a well-written message, which would explain not only what happened internally, but also what it means to the end user and what she can do about it. Comprehensible messages that say an error occurred and suggest customers either try it again or, better yet, provide contact information so they can talk with someone for assistance inspire confidence and improve the customer experience.

When you do expose logic to another application, take the time to identify any failure points and realize that any error you return will most likely just get splashed on the end screen for end users to see. When you are providing messages, avoid the temptation to give a few in a decision tree and then let any others be passed along as they are. This is the source of most of these messages, I believe.

Instead, take the time to thoroughly analyze the possible messages. It is up to you to properly handle the issue and return a message that makes sense not just to you, but to the end user — because someone looking at their phone doesn't want to know about a database timeout. But you can say that an error occurred and suggest they either try it again or, better yet, provide contact information so they can call someone for assistance.

This also has benefit for you internally in improving mean time to resolution. Good error handling and clear mainframe error messages help the people working on applications now. The time it takes to write a proper error-handling routine and description is really not much, and it's a good investment.

Take time to plan better for failures that originate from the mainframe, and ensure the actions you take improve the customer experience on the other side of an interface.

Sensu: workflow automation for monitoring. Learn more—download the whitepaper.

Topics:
mainframe ,performance ,End user ,customer experience ,customer service ,Error messaging

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}