Does the problem affect messages?

This section deals with message problems, including:

• Messages do not appear on the queue

• Messages contain unexpected or corrupted information

• Unexpected messages are received when using distributed queues

 

Messages do not appear on the queue

If messages do not appear when you are expecting them, check for the following:

• Have you selected the correct queue manager, that is, the default queue manager or a named queue manager?

• Has the message been put on the queue successfully?

  • Has the queue been defined correctly, for example is MAXMSGLEN sufficiently large?

  • Can applications put messages on the queue (is the queue enabled for putting)?

  • Is the queue already full? This could mean that an application was unable to put the required message on the queue.

• Can you get the message from the queue?

  • Do we need to take a syncpoint?

    If messages are being put or retrieved within syncpoint, they are not available to other tasks until the unit of recovery has been committed.

  • Is your timeout interval long enough?

  • Are you waiting for a specific message that is identified by a message or correlation identifier (MsgId or CorrelId)?

    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 we can get other messages from the queue.

  • Can other applications get messages from the queue?

  • Was the message you are expecting defined as persistent?

    If not, and WebSphere MQ for iSeries has been restarted, the message will have been lost.

If we 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:

• Did the application start?

  If it should have been triggered, check that the correct trigger options were specified.

• Is a trigger monitor running?

• Was the trigger process defined correctly?

• Did it complete correctly?

  Look for evidence of an abnormal end in the job log.

• Did the application commit its changes, or were they backed out?

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.

 

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:

• Has your application, or the application that put the message on to the queue, changed?

  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.

• Is an application sending messages to the wrong queue?

  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.

• Has the trigger information been specified correctly for this queue?

  Check that your application should have been started, or should a different application have been started?

• Has the CCSID been set correctly, or is the message format incorrect because of data conversion.

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.