Have you failed to receive a response from an MQSC command?

Use this topic for investigating problems where you fail to receive a response from an MQSC command.

If you have issued an MQSC command from an application (and not from a z/OS® console), but you have not received a response, consider the subsequent questions:
Is the command server running?
Check that the command server is running, as follows:
  1. Use the DISPLAY CMDSERV command at the z/OS console to display the status of the command server.
  2. If the command server is not running, start it using the START CMDSERV command.
  3. If the command server is running, issue the DISPLAY QUEUE command. Use the name of the system-command input queue and the CURDEPTH and MAXDEPTH attributes to define the data displayed.

    If these values show that the queue is full, and the command server has been started, the messages are not being read from the queue.

  4. Try stopping the command server and then restarting it, responding to any error messages that are produced.
  5. Issue the display command again to see if it is working now.
Has a reply been sent to the dead-letter queue?

Use the DISPLAY QMGR DEADQ command to find out the name of the system dead-letter queue (if you do not know what it is).

Use this name in the DISPLAY QUEUE command with the CURDEPTH attribute to see if there are any messages on the queue.

The dead-letter queue message header (dead-letter header structure) contains a reason or feedback code describing the problem. (See Reason (MQLONG) for information about the dead-letter header structure.)

Are the queues enabled for PUTs and GETs?
Use the DISPLAY QUEUE command from the console to check, for example, DISPLAY QUEUE(SYSTEM.COMMAND.INPUT) PUT GET.
Is the WaitInterval parameter set to a sufficiently long time?
If your MQGET call has timed out, your application receives completion code of 2 and a reason code of 2033 (MQRC_NO_MSG_AVAILABLE). (See WaitInterval (MQLONG) and MQGET - Get message for information about the WaitInterval parameter, and completion and reason codes from MQGET.)
Is a sync point required?

If you are using your own application program to put commands onto the system-command input queue, consider whether you must take a sync point.

You must take a sync point after putting messages to a queue, and before attempting to receive reply messages, or use MQPMO_NO_SYNCPOINT when putting them. Unless you have excluded your request message from sync point, you must take a sync point before attempting to receive reply messages.

Are the MaxDepth and MaxMsgL parameters of your queues set sufficiently high?
See CSQO016E for information about defining the system-command input queue and the reply-to queue.
Are you using the CorrelId and MsgId parameters correctly?

You must identify the queue and then display the CURDEPTH. Use the DISPLAY QUEUE command from the console (for example, DISPLAY QUEUE (MY.REPLY.QUEUE) CURDEPTH), to see if there are messages on the reply-to queue that you have not received.

Set the values of MsgId and CorrelId in your application to ensure that you receive all messages from the queue.

The following questions are applicable if you have issued an MQSC command from either a z/OS console (or its equivalent), or an application, but have not received a response:
Is the queue manager still running, or did your command cause an abend?
Look for error messages indicating an abend, and if one occurred, see IBM MQ for z/OS dumps.
Were any error messages issued?
Check to see if any error messages were issued that might indicate the nature of the error.
See Issuing commands for information about the different methods you can use to enter MQSC commands.