If messages do not appear on the queue when you are expecting them, check for the following:
Did WebSphere MQ issue a return and reason code for the MQPUT, for example:
If it is, there might be multiple instances of the queue on different queue managers. This means the messages could be on a different queue manager.
Check any cluster-workload exit programs to see that they are processing messages as intended.
If messages are being put or got within syncpoint, they are not available to other tasks until the unit of recovery has been committed.
If you are using distributed processing, you should allow for reasonable network delays, or problems at the remote end.
If not, and the queue manager has been restarted, the message will have been deleted. Shared queues are an exception because nonpersistent messages survive a queue manager restart.
Check that you are waiting for a message with the correct MsgId or CorrelId. A successful MQGET call sets both these values to that of the message got, so you might need to reset these values to get another message successfully.
Also check if you can get other messages from the queue.
If so, has another application already retrieved the message?
If the queue is a shared queue, check that applications on other queue managers are not getting the messages.
If you cannot find anything wrong with the queue, and the queue manager itself is running, make the following checks on the process that you expected to put the message on to the queue:
If it should have been triggered, check that the correct trigger options were specified.
Look for evidence of an abend, (for example, in the CICS log).
Look for messages in the CICS log indicating this.
If multiple transactions are serving the queue, they might occasionally conflict with one another. For example, one transaction might issue an MQGET call with a buffer length of zero to find out the length of the message, and then issue a specific MQGET call specifying the MsgId of that message. However, while this is happening, another transaction might have issued a successful MQGET call for that message, so the first application will receive a completion code of MQRC_NO_MSG_AVAILABLE. Applications that are expected to run in a multi-server environment must be designed to cope with this situation.
Have any of your systems suffered an outage? For example, if the message you were expecting should have been put on to the queue by a CICS application, and the CICS system went down, the message might be in doubt. This means that the queue manager does not know whether the message should be committed or backed out, and so has locked it until this is resolved when resynchronization takes place.
Also consider that the message could have been received, but that your application failed to process it in some way. For example, did an error in the expected format of the message cause your program to reject it? If this is the case, refer to Messages contain unexpected or corrupted information.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq424b |