When a channel refuses to run

If a channel refuses to run, there are a number of potential reasons.

Carry out the following checks:

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

      We need to check with your remote link supervisor to establish the number of the last-committed unit of work ID (LUWID) 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 CHANNEL 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 we should use it only after using the RESOLVE command to resolve any in-doubt situations.

  • When sequential numbering is being used, and a sender channel starts up after being reset, the sender channel takes two actions:

    • It tells the receiver channel that it has been reset.
    • It specifies the next message sequence number that is to be used by both the sender and receiver channels.

  • If the status of a receiver end of the channel is STOPPED, it can be reset by starting the receiver end. Note: This does not start the channel, it merely resets the status. The channel must still be started from the sender end.

Parent topic: Problem determination in DQM