MQ messaging application trouble shooting: Asking for help.

Whether you are new to IBM MQ or new to the application you are supporting, this discussion is intended to help give you the foundation to reach out for help in the cases where you need it. This information is targeted at those who are new at supporting an application that uses MQ.

Every now and then in your career as a developer you may have to support an application that uses IBM MQ to communicate with other applications. Most likely the reason this application has come to your attention is that perhaps it is having an issue of some sort. Depending upon what tools and access you have at your disposal, you may need to reach out for assistance.

The purpose of these notes are to give you some language/tools to discuss the issue with support professionals that work with IBM MQ.
You may encounter a variety or experience levels and in some cases you will need to bring in a number of groups to get to the bottom of the performance issue. Hopefully these notes will help you get to the resolution more quickly.

Problem Categorization and category evolution:

The problem usually starts out as "We have a MQ problem". If this issue came to your attention by monitoring of MQ reason codes or application logs you likely have a fairly good idea of the issue. If the issue was brought to your attention by a complaint from the business community, you may not know where the issue lies. As you look into the issue, you may start to have an inclination that the issue is related to MQ. These are common observations that are made.

1. Lost message. ->Not really lost, just not where it was expected.
2. Not getting a response. ->Messaging servicing application had a problem with the request. What group supports this application?
3. Not getting a response on-time. ->Everything appears to work, just not fast enough. These issues can be challenging.

Helpful information to gather prior to contacting MQ Support:

Calling in the MQ support group and saying "we have a MQ problem" and having no additional information may not get you very far. If you need help you have to ask, so reaching out for help is encouraged. The first time you do this may not go as well as you hope, but with knowledge and experience trouble shooting will become easier. If you show patience with the person who may be supporting hundreds of queue managers, they will likely be patient with incomplete information.

It is understood that an application support person may not always know all the details of what infrastructure is being used. Not knowing the details should not be a barrier for reaching out for assistance. It may be a barrier for conclusive answers.

Common reasons for not knowing the details:

1. Application support people are new to the application.
2. No access to information or tools. Security related.
3. Details hidden in layers of application abstractions.
4. Details scattered throughout configuration files or code.

Any number of reasons could contribute to this lack of information. At some point these details will likely be needed. It would be good to know how to qet these details if you are going to be supporting the application.

What information to gather prior to contacting the MQ group?

1. Hostname.
2. TCP/IP port.
3. MQ Channel.
4. queue manager name.
5. queue name(s).
6. Time the problem was first noted.
7. MQ Reason Code.
8. Application logs, JVM stack trace.

Gather what information you can, don't get stuck trying to find information you can't gather or don't have access to. Problem investigations often don't take the most ideal route. As you gain experience, and your tooling improves problem investigation becomes easier.

Is there anything I can ask of the MQ support group if I don't know the the details of any suspected issue?

There are questions you can ask that may be revealing, however even if this information can be provided by the MQ support group it may not be conclusive.

Questions to ask MQ support when you don't know underlying MQ infrastructure that supports your application:

1. Are any queue managers down?
2. Are there messages on dead-letter queues?
3. Are there messages on transmit queues?

If messages started building up on either transmit or dead letter queues at the same time that the application started having issues this may be a good indicator that these events are related. This line of questioning can prove less productive in a development environment where the state of application and infrastructure is in a constant state of change.

Many MQ groups would be hesitant to replay dead-letter messages without application support group confirming their infrastructure and understanding how messages ended up on dead-letter queues.

Some things to consider about having incomplete information:

One thing to note about approaching the MQ support group with incomplete information is that you won't know definitively the root cause of the issue. If the problem goes away after the queue manager is back active or the transmit queues clear, that may be a good indicator it was related. Once the MQ environment is back to a fully operational status, issues can clear up. If your issue is resolved without you ever determining the details of what infrastructure you use, it would still be wise to learn the MQ details.

Ask for help!

Asking for help and knowing what groups to bring to the table when you are having issues will help you provide the service your business expects. Learning the details of how your application uses the infrastructure and getting to the root of issues may reveal options for you to provide a HA(Higly Available) environment. Your MQ support group is likely there to assist you with production and development integration challenges.