MQRC 2195: Unexpected error

What it means

2195 is MQ's catch-all reason code. Any MQI call can return it with MQCC_FAILED when something goes wrong inside MQ that doesn't map to a specific code. Because it is generic, the reason code alone tells you nothing about the cause. MQ usually writes diagnostic data at the same moment, and that is where the real information is.

IBM's first check is on the application. The call may have been passed the wrong number of parameters, or pointers or storage keys that aren't valid. On z/OS, IBM also warns about one specific mistake. If MQCONN or MQCONNX names a Db2 subsystem instead of an MQ subsystem, the connect fails with 2195.

Where the diagnostics go depends on the platform. On AIX, Linux and Windows, MQ writes FDC (First Failure Data Capture) files to the errors directory. On IBM i it writes FFST records. On z/OS, look at the job log, LOGREC and the console, and if needed run the job again with a CSQSNAP DD statement to capture a dump for IBM.

Common causes

• The application passes a bad parameter list, for example a missing parameter in a COBOL CALL, an invalid pointer, or storage the call can't access.
• On z/OS, MQCONN or MQCONNX names a Db2 subsystem, or another non-MQ subsystem, instead of the MQ queue manager.
• An internal MQ problem, often already described in an IBM APAR, so the FDC or dump points to a known defect.
• An environment problem, such as a damaged installation or a resource the queue manager couldn't get, which MQ reports through an FDC.

How to find the problem

1. On distributed MQ, look in the errors directory (for example /var/mqm/errors on Linux) for AMQnnnnn.n.FDC files written at the time of the failure. The header shows the probe ID, the component and the major error code. ffstsummary lists them briefly.
2. Also read the queue manager error log (AMQERR01.LOG) around the same time.
3. On z/OS, check the job log, LOGREC and console messages. For an MQCONN failure, confirm the name is an active MQ subsystem.
4. On IBM i, look at the FFST record for the job.
5. Search IBM Support for the probe ID or symptom string from the FDC or dump. Many 2195 cases match a published APAR.

How to fix it

• Check the application's MQI calls against the documented parameter lists and fix any wrong count, type or pointer.
• On z/OS, correct the subsystem name on MQCONN or in the adapter configuration.
• If the FDC or dump matches a known APAR, apply the fix pack or PTF that contains it.
• If the problem continues, collect the FDC files, error logs and, on z/OS, a dump captured with a CSQSNAP DD statement, and open a case with IBM.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.