This section deals with message problems, including:
If messages do not appear when you are expecting them, check for the following:
If messages are being put or retrieved within syncpoint, they are not available to other tasks until the unit of recovery has been committed.
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 retrieved, so you might need to reset these values in order to get another message successfully.
Also check if you can get other messages from the queue.
If not, and WebSphere MQ for iSeries has been restarted, the message will have been lost.
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 abnormal end in the job log.
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, in the meantime, another transaction might have issued a successful MQGET call for that message, so the first application receives 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.
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.
If the information contained in the message is not what your application was expecting, or has been corrupted in some way, consider the following points:
Ensure that all changes are simultaneously reflected on all systems that need to be aware of the change.
For example, a copyfile formatting the message might have been changed, in which case, re-compile both applications to pick up the changes. If one application has not been recompiled, the data appears corrupt to the other.
Check that the messages your application is receiving are not really intended for an application servicing a different queue. If necessary, change your security definitions to prevent unauthorized applications from putting messages on to the wrong queues.
If your application has used an alias queue, check that the alias points to the correct queue.
Check that your application should have been started, or should a different application have been started?
If these checks do not enable you to solve the problem, check your application logic, both for the program sending the message, and for the program receiving it.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
amqb |