Have you obtained incorrect output?

In this section, incorrect output refers to our application: not receiving a message that you were expecting it to receive; receiving a message containing unexpected or corrupted information; receiving a message that you were not expecting it to receive, for example, one that was destined for a different application.


Messages that do not arrive on the queue

If messages do not arrive 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 you need to take a sync point?

      If messages are being put or retrieved within sync point, 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 IBM 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 IBM 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 our 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 so, refer to the subsequent information in this topic.


Messages that contain unexpected or corrupted information

If the information contained in the message is not what our application was expecting, or has been corrupted in some way, consider the following:

  • Has our application, or the application that put the message onto the queue, changed?

    Ensure that all changes are simultaneously reflected on all systems that need to be aware of the change.

    For example, the format of the message data might have been changed, in which case, both applications must be recompiled to pick up the changes. If one application has not been recompiled, the data will appear corrupted to the other.

  • Is an application sending messages to the wrong queue?

    Check that the messages your application is receiving are not 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 our application uses 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 started; or should a different application have started?

If these checks do not enable you to solve the problem, check our application logic, both for the program sending the message, and for the program receiving it.


Problems with incorrect output when using distributed queues

If our application uses distributed queues, consider the following points:

  • Has IBM MQ been correctly installed on both the sending and receiving systems, and correctly configured for distributed queuing?
  • Are the links available between the two systems?

    Check that both systems are available, and connected to IBM MQ. Check that the connection between the two systems is active.

    We can use the MQSC command PING against either the queue manager (PING QMGR) or the channel (PING CHANNEL) to verify that the link is operable.

  • Is triggering set on in the sending system?
  • Is the message for which you are waiting a reply message from a remote system?

    Check that triggering is activated in the remote system.

  • Is the queue already full?

    If so, check if the message has been put onto the dead-letter queue.

    The dead-letter queue header contains a reason or feedback code explaining why the message could not be put onto the target queue. See Use the dead-letter (undelivered message) queue and MQDLH - Dead-letter header for information about the dead-letter queue header structure.

  • Is there a mismatch between the sending and receiving queue managers?

    For example, the message length could be longer than the receiving queue manager can handle.

  • Are the channel definitions of the sending and receiving channels compatible?

    For example, a mismatch in sequence number wrap can stop the distributed queuing component. See Distributed queuing and clusters for more information about distributed queuing.

  • Is data conversion involved? If the data formats between the sending and receiving applications differ, data conversion is necessary. Automatic conversion occurs when the MQGET call is issued if the format is recognized as one of the built-in formats.

    If the data format is not recognized for conversion, the data conversion exit is taken to allow you to perform the translation with your own routines.

    Refer to Data conversion for further information about data conversion.