Messages do not arrive when expected on z/OS

Missing messages can have different causes. Use this topic to investigate the causes further.

If messages do not arrive on the queue when we are expecting them, check for the following:

Has the message been put onto the queue successfully?

Did IBM MQ issue a return and reason code for the MQPUT, for example:

• Has the queue been defined correctly, for example is MAXMSGL large enough? (reason code 2030).
• Can applications put messages on to the queue (is the queue enabled for MQPUT calls)? (reason code 2051).
• Is the queue already full? This could mean that an application could not put the required message on to the queue (reason code 2053).

Is the queue a shared queue?

• Have Coupling Facility structures been defined successfully in the CFRM policy data set? Messages held on shared queues are stored inside a Coupling Facility.
• Have you activated the CFRM policy?

Is the queue a cluster queue?

If it is, there might be multiple instances of the queue on different queue managers. This means that the messages could be on a different queue manager.

• Did we want the message to go to a cluster queue?
• Is the application designed to work with cluster queues?
• Did the message get put to a different instance of the queue from that expected?

Check any cluster-workload exit programs to see that they are processing messages as intended.

Do your gets fail?

• Does the application need to take a syncpoint?

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

• Is the time interval on the MQGET long enough?

  If we are using distributed processing, you should allow for reasonable network delays, or problems at the remote end.

• Was the message we are expecting defined as persistent?

  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.

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

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

• Can other applications get 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 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 get started?

  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 (both to IBM MQ for z/OS and CICS or IMS )?
• Did it complete correctly?

  Look for evidence of an abend, for example, in the CICS log.

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

  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 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.

Have any of our 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.

Note: The message is deleted after resynchronization if CICS decides to back it out.

Also consider that the message could have been received, but that the 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 Messages contain unexpected or corrupted information on z/OS.

Parent topic: Dealing with incorrect output on z/OS