Problem solving in general and MQ 2195 reason codes

10 August, 2007 – 11:05 am

So I spent the best part of a day assisting our sys admin and developer resolve MQ errors that a COBOL client was throwing when opening more than one concurrent connection to a clustered queue manager.

Because the architecture had recently changed to a cluster, and my load harness was no longer getting the desired response times, we all went down the track of investigating issues with clustering as this was the new kid on the block. Whilst the developer and sys admin revealed many other interesting tid bits of information regarding correct configuration and the like, we still could not collectively resolve the problem: the COBOL code was throwing a 2195 reason code on multiple MQCONN calls to the queue manager.

Some key lessons I learned here though, was to always simplify the problem by going back to a known configuration. We ended up doing that at the end of the day (using a standard queue manager configuration) and found that the 2195 errors persisted. So this was a good indicator that we had some sort of environment/configuration error.

The second key lesson was to always trust the API documentation. In this case a 2195 error has the following info:

2195 MQRC_UNEXPECTED_ERROR
The call was rejected because an unexpected error occurred.
Corrective action: Check the application’s parameter list to ensure, for example, that the correct number of parameters was passed, and that data pointers and storage keys are valid.

If the problem cannot be resolved, contact your system programmer.
v On OS/390, check whether any information has been displayed on the console. If this error occurs on an MQCONN or MQCONNX call, check that the subsystem named is an active MQSeries subsystem. In particular, check that it is not a DB2 subsystem. If the problem cannot be resolved, rerun the application with a CSQSNAP DD card (if you have not already got a dump) and send the resulting dump to IBM.
v On OS/2 and AS/400, consult the FFST record to obtain more detail about the problem.
v On Compaq (DIGITAL) OpenVMS, Tandem NonStop Kernel, and UNIX systems, consult the FDC file to obtain more detail about the problem.

To be honest, I got put off by the “unexpected error” bit, and had the same reaction I do when I see server 500 errors for http. It’s hard not to put your head in the sand in this situation. But on closer inspection, and now with the benefit of hindsight, the corrective action does mention how to resolve this, as well as a key tip to look at the FDC file to obtain more detail about the problem. Never having seen a FDC file before I simply ignored it, but the collective nouse of the sys admin and developer later figured it all out, with the recommended solutions posted here and here. Well done Ted