Home

 

When a channel refuses to run

 

If a channel refuses to run:

• Check that DQM and the channels have been set up correctly. This is a likely problem source if the channel has never run. Reasons could be:

  • A mismatch of names between sending and receiving channels (remember that uppercase and lowercase letters are significant)

  • Incorrect channel types specified

  • The sequence number queue (if applicable) is not available, or is damaged

  • The dead-letter queue is not available

  • The sequence number wrap value is different on the two channel definitions

  • A queue manager or communication link is not available

  • A receiver channel might be in STOPPED state

  • The connection might not be defined correctly

  • There might be a problem with the communications software (for example, is TCP running?)

• It is possible that an in-doubt situation exists, if the automatic synchronization on startup has failed for some reason. This is indicated by messages on the system console, and the status panel may be used to show channels that are in doubt.

  The possible responses to this situation are:

  • Issue a Resolve channel request with Backout or Commit.

    You need to check with your remote link supervisor to establish the number of the last message or unit of work committed. Check this against the last number at your end of the link. If the remote end has committed a number, and that number is not yet committed at your end of the link, then issue a RESOLVE COMMIT command.

    In all other cases, issue a RESOLVE BACKOUT command.

    The effect of these commands is that backed out messages reappear on the transmission queue and are sent again, while committed messages are discarded.

    If in doubt yourself, perhaps backing out with the probability of duplicating a sent message would be the safer decision.

  • Issue a RESET command.

    This command is for use when sequential numbering is in effect, and should be used with care. Its purpose is to reset the sequence number of messages and you should use it only after using the RESOLVE command to resolve any in-doubt situations.

• On WebSphere MQ for iSeries, Windows, UNIX systems, and z/OS, there is no need for the administrator to choose a particular sequence number to ensure that the sequence numbers are put back in step. When a sender channel starts up after being reset, it informs the receiver that it has been reset and supplies the new sequence number that is to be used by both the sender and receiver.

• If the status of a receiver end of the channel is STOPPED, it can be reset by starting the receiver end.

  This does not start the channel, it merely resets the status. The channel must still be started from the sender end.

• Triggered channels
  

• Conversion failure
  

• Network problems
  

• Dial-up problems
  

 

Parent topic:

Problem determination in DQM

ic19470_

 

Home