MQRC 2059: Queue manager unavailable

What it means

2059 is one of the most common MQ errors because it covers every way a connect can fail to find a working queue manager. For an application running on the same machine (bindings mode), it nearly always means the queue manager isn't started. For a client, it means the client couldn't build a channel to the queue manager. The host may be wrong, the listener may be down, or the client and server channel definitions may not match.

Newer clients often return a more precise code for client connection failures, such as 2538 when the host can't be reached or 2537 when the channel isn't available. Depending on the client and the failure, you may see one of these codes or the general 2059. The client error log gives the detail either way.

On z/OS, batch applications get 2059 when the MQ subsystem they name isn't started, or when the job runs on an LPAR that has no queue manager. IBM also lists a shortage of common storage (ECSA), or the ACELIM system parameter limiting storage for new connections, as a cause. Message CSQ3202E goes with the ACELIM case. A command whose CommandScope names a queue manager that isn't active in the queue sharing group also returns 2059.

Common causes

• The queue manager isn't running, for example after a restart, a failed start or a failover that hasn't finished.
• For a client, the listener on the server isn't running or listens on a different port.
• The client uses the wrong host name, IP address or port, in MQSERVER, a CCDT or the connection factory.
• The client-connection and server-connection channel definitions don't match, or the server-connection channel doesn't exist.
• On a machine with more than one MQ installation, the application loads libraries from an installation that doesn't own the queue manager.
• On z/OS, the MQ subsystem isn't started, the job runs on an LPAR without one, or common storage or ACELIM limits stop the connection.

How to find the problem

1. On distributed MQ, run dspmq. It shows each queue manager and whether it is running.
2. For clients, read the client error log (AMQERR01.LOG under the client's errors directory). A message such as AMQ9202E means the remote host wasn't reachable on that port.
3. On the server, check the listener with DISPLAY LSSTATUS(*) in runmqsc, and the server-connection channel with DISPLAY CHANNEL(APP.SVRCONN).
4. Test the network path from the client with a simple TCP check to the host and port, to rule out firewalls.
5. On z/OS, check that the MSTR and CHIN address spaces are up, and look in SYSLOG for CSQ3202E and other CSQ messages.

How to fix it

• Start the queue manager with strmqm QM1 on distributed MQ, or the START QMGR command on z/OS, and the listener if it isn't controlled by the queue manager.
• Correct the host, port and channel name the client uses, and make sure the server-connection channel exists with the same name.
• Set the listener to start with the queue manager, for example DEFINE LISTENER(...) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR).
• With several installations, run setmqenv or set the library path so the application uses the installation that owns the queue manager.
• Make the application retry the connect with a delay rather than failing at once, so short outages pass on their own.

What it looks like

JMSWMQ0018: Failed to connect to queue manager 'QM1' with connection mode 'Client' and host name 'mqhost01(1414)'.
JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').

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.