Have you failed 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 following 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, using 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, this indicates that 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 the WebSphere MQ Application Programming Reference manual 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, you will see a completion code of 2 and a reason code of 2033 (MQRC_NO_MSG_AVAILABLE). (See the WebSphere MQ Application Programming Guide for information about the WaitInterval parameter, and completion and reason codes from MQGET.)

Is a syncpoint required?

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

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

Are the

MaxDepth and MaxMsgL parameters of your queues set sufficiently high?

See the WebSphere MQ for z/OS Concepts and Planning Guide for information about defining the system-command input queue and the reply-to queue.

Are you using the CorrelId and MsgId parameters correctly?

You need to 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. See the WebSphere MQ Application Programming Guide for information about using these fields.

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, refer to WebSphere MQ dumps

Were any error messages issued?

Check to see if any error messages were issued that might indicate the nature of the error.

See the WebSphere MQ for z/OS Concepts and Planning Guide for information about the different methods we can use to enter MQSC commands.