If the channel in another state

If the channel in another state

Having issued the command
DIS CHSTATUS(QM1.TO.QM2) ALL, if the output shows the status of the channel is
BINDING or REQUESTING, then it has not yet successfully connected to the partner. Do the following:
Issue the following command, at both ends of the channel, to determine the substate of the channel:
DIS CHSTATUS(QM1.TO.QM2) ALL
Notes:

In some cases there might be a substate at one end of the channel only.
Many substates are transitory, so issue the command a few times to detect whether a channel is stuck in a particular substate.
Check Table 25 to determine what to do next:
Table 25. Substates seen with status binding or requesting

Initiating MCA substate ¹ Responding MCA substate ² Notes

NAMESERVER The initiating MCA is waiting for a nameserver request to complete. Ensure that the correct hostname 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 Are there exits processing?.
CHADEXIT The channel autodefinition exit is currently executing. For more information, see Are there exits processing?.

RCVEXIT
SENDEXIT
MSGEXIT
MREXIT

RCVEXIT
SENDEXIT
MSGEXIT
MREXIT

Exits are called at channel startup for MQXR_INIT. Review the processing in this part of your exit if this takes a long time. For more information, see Are there exits processing?.
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 An SSL handshake is made up 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 WebSphere MQ for z/OS this substate can also be indicative of not having enough SSLTASKS.

Notes:

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

Initiating MCA substate ¹	Responding MCA substate ²	Notes
NAMESERVER		The initiating MCA is waiting for a nameserver request to complete. Ensure that the correct hostname 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 Are there exits processing?.
	CHADEXIT	The channel autodefinition exit is currently executing. For more information, see Are there exits processing?.
RCVEXIT SENDEXIT MSGEXIT MREXIT	RCVEXIT SENDEXIT MSGEXIT MREXIT	Exits are called at channel startup for MQXR_INIT. Review the processing in this part of your exit if this takes a long time. For more information, see Are there exits processing?.
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	An SSL handshake is made up 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 WebSphere MQ for z/OS this substate can also be indicative of not having enough SSLTASKS.
Notes: 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. 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).