Determining whether the channel is running

If we have a problem with a transmission queue, check whether the channel is running.

About this task

Perform the following steps to check the status of the channel that is servicing the transmission queue:

Procedure

1. Issue the following command to find out which channel you expect to process the transmission queue QM2:

   DIS CHANNEL(*) WHERE(XMITQ EQ QM2)
   

   In this example, the output of this command shows that the channel servicing the transmission queue is QM1.TO.QM2
2. Issue the following command to determine the status of the channel, QM1.TO.QM2:

   DIS CHSTATUS(QM1.TO.QM2) ALL
   

3. Inspect the STATUS field of the output from the CHSTATUS command:
   • If the value of the STATUS field is RUNNING, check that the channel is moving messages
   • If the output from the command shows no status, or the value of the STATUS field is STOPPED, RETRY, BINDING, or REQUESTING, perform the appropriate step, as follows:

4. Optional: If the value of the STATUS field shows no status, the channel is inactive, so perform the following steps:
   1. If the channel should have been started automatically by a trigger, check that the messages on the transmission queue are available. If there are messages available on the transmission queue, check that the trigger settings on the transmission queue are correct.
   2. Issue the following command to start the channel again manually:

      START CHANNEL(QM1.TO.QM2)
      

5. Optional: If the value of the STATUS field is STOPPED, perform the following steps:
   1. Check the error logs to determine why the channel stopped. If the channel stopped owing to an error, correct the problem. Ensure also that the channel has values specified for the retry attributes: SHORTRTY and LONGRTY. In the event of transient failures such as network errors, the channel will then attempt to restart automatically.
   2. Issue the following command to start the channel again manually:

      START CHANNEL(QM1.TO.QM2)
      

   On IBM MQ for z/OS, we can detect when a user stops a channel by using command event messages.

6. Optional: If the value of the STATUS field is RETRY, perform the following steps:
   1. Check the error logs to identify the error, then correct the problem.
   2. Issue the following command to start the channel again manually:

      START CHANNEL(QM1.TO.QM2)
      

      or wait for the channel to connect successfully on its next retry.

7. Optional: If the value of the STATUS field is BINDING or REQUESTING, the channel has not yet successfully connected to the partner. Perform the following steps:
   1. Issue the following command, at both ends of the channel, to determine the substate of the channel:

      DIS CHSTATUS(QM1.TO.QM2) ALL
      

      Note:
      1. In some cases there might be a substate at one end of the channel only.
      2. Many substates are transitory, so issue the command a few times to detect whether a channel is stuck in a particular substate.

   2. Check Table 1 to determine what action to take:

      Initiating MCA substate 1	Responding MCA substate 2	Notes
      NAMESERVER		The initiating MCA is waiting for a name server request to complete. Ensure that the correct host name has been specified in the channel attribute, CONNAME, and that your name servers are set up correctly.
      SCYEXIT	SCYEXIT	The MCAs are currently in conversation through a security exit. For more information, see Determining whether the channel can process messages fast enough.
      	CHADEXIT	The channel autodefinition exit is currently executing. For more information, see Determining whether the channel can process messages fast enough.
      RCVEXIT SENDEXIT MSGEXIT MREXIT	RCVEXIT SENDEXIT MSGEXIT MREXIT	Exits are called at channel startup for MQXR_INIT. Review the processing in this part of our exit if this takes a long time. For more information, see Determining whether the channel can process messages fast enough.
      SERIALIZE	SERIALIZE	This substate only applies to channels with a disposition of SHARED.
      NETCONNECT		This substate is shown if there is a delay in connecting due to incorrect network configuration.
      SSLHANDSHAKE	SSLHANDSHAKE	A TLS handshake consists of a number of sends and receives. If network times are slow, or connection to lookup CRLs are slow, this affects the time taken to do the handshake. On IBM MQ for z/OS this substate can also be indicative of not having enough SSLTASKS.

      Notes:
      1. The initiating MCA is the end of the channel which started the conversation. This can be senders, cluster-senders, fully-qualified servers and requesters. In a server-requester pair, it is the end from which you started the channel.
      2. The responding MCA is the end of the channel which responded to the request to start the conversation. This can be receivers, cluster-receivers, requesters (when the server or sender is started), servers (when the requester is started) and senders (in a requester-sender call-back pair of channels).

Parent topic: Monitor channels