Problems with missing messages when using distributed queuing - Middleware News
If your application uses distributed queuing, consider the following points:
Has distributed queuing been correctly installed on both the sending and receiving systems?
Ensure that the instructions about installing the distributed queue management facility in the WebSphere MQ for z/OS® System Setup Guide have been followed correctly.
Are the links available between the two systems?
Check that both systems are available, and connected to WebSphere® MQ for z/OS. Check that the LU 6.2 or TCP/IP connection between the two systems is active or check the connection definitions on any other systems that you are communicating with.
Start of changeSee Monitoring WebSphere MQ for more information about trace-route messaging in a network.End of change
Is the channel running?
Issue the following command for the transmission queue:
DISPLAY QUEUE (qname) IPPROCS
If the value for IPPROCS is 0, this means that the channel serving this transmission queue is not running.
Issue the following command for the channel:
DISPLAY CHSTATUS (channel-name) STATUS MSGS
Use the output produced by this command to check that the channel is serving the correct transmission queue and that it is connected to the correct target machine and port. You can determine whether the channel is running from the STATUS field. You can also see if any messages have been sent on the channel by examining the MSGS field.
If the channel is in RETRYING state, this is probably caused by a problem at the other end. Check that the channel initiator and listener have been started, and that the channel has not been stopped. If somebody has stopped the channel, you need to start it manually.
Is triggering set on in the sending system?
Check that the channel initiator is running.
Does the transmission queue have triggering set on?
If a channel is stopped under specific circumstances, triggering can be set off for the transmission queue.
Is the message you are waiting for a reply message from a remote system?
Check the definitions of the remote system, as described above, and check that triggering is activated in the remote system. Also check that the LU 6.2 connection between the two systems is not single session (if it is, you cannot receive reply messages).
Check that the queue on the remote queue manager exists, is not full, and accepts the message length. If any of these criteria are not fulfilled, the remote queue manager tries to put the message on the dead-letter queue. If the message length is longer than the maximum length that the channel will allow, the sending queue manager tries to put the message on its dead-letter queue.
Is the queue already full?
This could mean that an application could not put the required message on to the queue. If this is so, check if the message has been put on to the dead-letter queue.
The dead-letter queue message header (dead-letter header structure) contains a reason or feedback code explaining why the message could not be put on to the target queue. See the WebSphere MQ Application Programming Reference manual for information about the dead-letter 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. Check the console log for error messages.
Are the channel definitions of the sending and receiving channels compatible?
For example, a mismatch in the wrap value of the sequence number will stop the channel. See the WebSphere MQ Intercommunication manual for more information about distributed queuing.
Has data conversion been performed correctly?
If a message has come from a different queue manager, are the CCSIDs and encoding the same, or does data conversion need to be performed.
Has your channel been defined for fast delivery of nonpersistent messages?
If your channel has been defined with the NPMSPEED attribute set to FAST (the default), and the channel has stopped for some reason and then been restarted, nonpersistent messages might have been lost. See the WebSphere MQ Intercommunication manual for more information about fast messages.
Is a channel exit causing the messages to be processed in an unexpected way?
For example, a security exit might prevent a channel from starting, or an ExitResponse of MQXCC_CLOSE_CHANNEL might terminate a channel.
If your application uses distributed queuing, consider the following points:
Has distributed queuing been correctly installed on both the sending and receiving systems?
Ensure that the instructions about installing the distributed queue management facility in the WebSphere MQ for z/OS® System Setup Guide have been followed correctly.
Are the links available between the two systems?
Check that both systems are available, and connected to WebSphere® MQ for z/OS. Check that the LU 6.2 or TCP/IP connection between the two systems is active or check the connection definitions on any other systems that you are communicating with.
Start of changeSee Monitoring WebSphere MQ for more information about trace-route messaging in a network.End of change
Is the channel running?
Issue the following command for the transmission queue:
DISPLAY QUEUE (qname) IPPROCS
If the value for IPPROCS is 0, this means that the channel serving this transmission queue is not running.
Issue the following command for the channel:
DISPLAY CHSTATUS (channel-name) STATUS MSGS
Use the output produced by this command to check that the channel is serving the correct transmission queue and that it is connected to the correct target machine and port. You can determine whether the channel is running from the STATUS field. You can also see if any messages have been sent on the channel by examining the MSGS field.
If the channel is in RETRYING state, this is probably caused by a problem at the other end. Check that the channel initiator and listener have been started, and that the channel has not been stopped. If somebody has stopped the channel, you need to start it manually.
Is triggering set on in the sending system?
Check that the channel initiator is running.
Does the transmission queue have triggering set on?
If a channel is stopped under specific circumstances, triggering can be set off for the transmission queue.
Is the message you are waiting for a reply message from a remote system?
Check the definitions of the remote system, as described above, and check that triggering is activated in the remote system. Also check that the LU 6.2 connection between the two systems is not single session (if it is, you cannot receive reply messages).
Check that the queue on the remote queue manager exists, is not full, and accepts the message length. If any of these criteria are not fulfilled, the remote queue manager tries to put the message on the dead-letter queue. If the message length is longer than the maximum length that the channel will allow, the sending queue manager tries to put the message on its dead-letter queue.
Is the queue already full?
This could mean that an application could not put the required message on to the queue. If this is so, check if the message has been put on to the dead-letter queue.
The dead-letter queue message header (dead-letter header structure) contains a reason or feedback code explaining why the message could not be put on to the target queue. See the WebSphere MQ Application Programming Reference manual for information about the dead-letter 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. Check the console log for error messages.
Are the channel definitions of the sending and receiving channels compatible?
For example, a mismatch in the wrap value of the sequence number will stop the channel. See the WebSphere MQ Intercommunication manual for more information about distributed queuing.
Has data conversion been performed correctly?
If a message has come from a different queue manager, are the CCSIDs and encoding the same, or does data conversion need to be performed.
Has your channel been defined for fast delivery of nonpersistent messages?
If your channel has been defined with the NPMSPEED attribute set to FAST (the default), and the channel has stopped for some reason and then been restarted, nonpersistent messages might have been lost. See the WebSphere MQ Intercommunication manual for more information about fast messages.
Is a channel exit causing the messages to be processed in an unexpected way?
For example, a security exit might prevent a channel from starting, or an ExitResponse of MQXCC_CLOSE_CHANNEL might terminate a channel.
Comments
Post a Comment