Home

 

Messages that do not appear on the queue

 

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

• Has the message been put on the queue successfully?

  • Has the queue been defined correctly? For example, is MAXMSGL sufficiently large?

  • Is the queue enabled for putting?

  • Is the queue already full?

  • Has another application got exclusive access to the queue?

• Are you able to get any messages 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 wait interval long enough?

    We can set the wait interval as an option for the MQGET call. Ensure that you are waiting long enough for a response.

  • 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 whether 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 has been restarted, the message has been lost.

  • Has another application got exclusive access to the queue?

If we cannot find anything wrong with the queue, and WebSphere MQ is running, check the process that you expected to put the message onto the queue for the following:

• Did the application start?

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

• Did the application stop?

• Is a trigger monitor running?

• Was the trigger process defined correctly?

• Did the application 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 can conflict with one another. For example, suppose one transaction issues an MQGET call with a buffer length of zero to find out the length of the message, and then issues a specific MQGET call specifying the MsgId of that message. However, in the meantime, another transaction issues a successful MQGET call for that message, so the first application receives a reason code of MQRC_NO_MSG_AVAILABLE. Applications that are expected to run in a multiple 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 that contain unexpected or corrupted information.

 

Parent topic:

Have you obtained incorrect output?

fa15000_

 

Home