Channel states

Figure 29 shows the hierarchy of all possible channel states and the substates that apply to each of the channel states. The substates are shown inside boxes, below the states to which they apply. Figure 30 shows the links between channel states. These apply to all types of message channel and server-connection channels.

Figure 29. Channel states and substates
The diagram shows the hierarchy of channel states. At the top level, a channel is inactive or current. A current channel can be stopped, starting, retrying, or active. An active channel can be initializing, binding, requesting, running, paused, or stopping. An active, binding channel can be in one of the substates InMsgExit, InSndExit, InRcvExit, InMRExit, InScyExit, InChadExit, Sending, Receiving, Serializing, SSLHandshake, NameServer or NetworkConnecting. An active, requesting channel can be in one of the substates InMQICall, SSLHandshake, Sending, Receiving, NameServer or NetworkConnecting. An active, running channel can be in one of the substates InMsgExit, InSndExit, InRcvExit, InMRExit,, Sending, Receiving, InMQGET, InMQPUT, Resyncing, Heartbeating, EndofBatch, InMQICall or Compress. An active, stopping channel can be in one of the substates InMsgExit, InSndExit, InRcvExit, InMRExit ,or InScyExit

Current and active

The channel is "current" if it is in any state other than inactive. A current channel is "active" unless it is in RETRYING, STOPPED, or STARTING state. If a channel is "active" it may also show a substate giving more detail of exactly what the channel is doing.

Figure 30. Flows between channel states
The diagram shows the flows between channel states. A stopped channel can be started, and becomes inactive. A start command, trigger, remote initiation, or a channel initiator places the channel in the initializing state. The channel moves into starting state, and then binding state, while it establishes session and initial data exchange. If the status is OK, the channel state becomes running. The channel can be placed into a paused state while waiting for message-retry interval, or a stopping state after an error, a STOP request, or if a disconnect interval expires. The channel could then move into a retrying state, or back to the stopped state.

Notes:
  1. When a channel is in one of the six states highlighted in Figure 30 (INITIALIZING, BINDING, REQUESTING, RUNNING, PAUSED, or STOPPING), it is consuming resource and a process or thread is running; the channel is active.
  2. When a channel is in STOPPED state, the session may be active because the next state is not yet known.
Specifying the maximum number of current channels

You can specify the maximum number of channels that can be current at one time. This is the number of channels that have entries in the channel status table, including channels that are retrying and channels that are stopped. Specify this using ALTER QMGR MAXCHL for z/OS, the queue manager initialization file for i5/OS, the queue manager configuration file for UNIX(R) systems, or the WebSphere MQ Explorer. For more information about the values you set using the initialization or the configuration file see Appendix B. Configuration file stanzas for distributed queuing. For more information about specifying the maximum number of channels, see the WebSphere MQ System Administration Guide for WebSphere MQ for UNIX systems, and Windows systems, the WebSphere MQ for iSeries V6 System Administration Guide book for WebSphere MQ for iSeries, or the WebSphere MQ Script (MQSC) Command Reference for WebSphere MQ for z/OS.

Notes:
  1. Server-connection channels are included in this number.
  2. A channel must be current before it can become active. If a channel is started, but cannot become current, the start fails.
Specifying the maximum number of active channels

You can also specify the maximum number of active channels. You can do this to prevent your system being overloaded by a large number of starting channels. If you use this method, you should set the disconnect interval attribute to a low value to allow waiting channels to start as soon as other channels terminate.

Each time a channel that is retrying attempts to establish connection with its partner, it must become an active channel. If the attempt fails, it remains a current channel that is not active, until it is time for the next attempt. The number of times that a channel will retry, and how often, is determined by the retry count and retry interval channel attributes. There are short and long values for both these attributes. See Channel attributes for more information.

When a channel has to become an active channel (because a START command has been issued, or because it has been triggered, or because it is time for another retry attempt), but is unable to do so because the number of active channels is already at the maximum value, the channel waits until one of the active slots is freed by another channel instance ceasing to be active. If, however, a channel is starting because it is being initiated remotely, and there are no active slots available for it at that time, the remote initiation is rejected.

Whenever a channel, other than a requester channel, is attempting to become active, it goes into the STARTING state. This is true even if there is an active slot immediately available, although in this case it will only be in STARTING state for a very short time. However, if the channel has to wait for an active slot, it is in STARTING state while it is waiting.

Requester channels do not go into STARTING state. If a requester channel cannot start because the number of active channels is already at the limit, the channel ends abnormally.

Whenever a channel, other than a requester channel, is unable to get an active slot, and so waits for one, a message is written to the log or the z/OS console, and an event is generated. When a slot is subsequently freed and the channel is able to acquire it, another message and event are generated. Neither of these events and messages are generated if the channel is able to acquire a slot straightaway.

If a STOP CHANNEL command is issued while the channel is waiting to become active, the channel goes to STOPPED state. A Channel-Stopped event is raised as usual.

Server-connection channels are included in the maximum number of active channels.

For more information about specifying the maximum number of active channels, see the WebSphere MQ System Administration Guide for WebSphere MQ for UNIX systems, and Windows systems, the WebSphere MQ for iSeries V6 System Administration Guide for WebSphere MQ for iSeries, or WebSphere MQ Script (MQSC) Command Reference for WebSphere MQ for z/OS.

Channel errors

Errors on channels cause the channel to stop further transmissions. If the channel is a sender or server, it goes to RETRY state because it is possible that the problem may clear itself. If it cannot go to RETRY state, the channel goes to STOPPED state. For sending channels, the associated transmission queue is set to GET(DISABLED) and triggering is turned off. (A STOP command with STATUS(STOPPED) takes the side that issued it to STOPPED state; only expiry of the disconnect interval or a STOP command with STATUS(INACTIVE) will make it end normally and become inactive.) Channels that are in STOPPED state need operator intervention before they will restart (see Restarting stopped channels).

Note:
For i5/OS, UNIX systems, and Windows systems, a channel initiator must be running for retry to be attempted. If the channel initiator is not available, the channel becomes inactive and must be manually restarted. If you are using a script to start the channel, ensure the channel initiator is running before you try to run the script.

Long retry count (LONGRTY) describes how retrying works. If the error clears, the channel restarts automatically, and the transmission queue is re-enabled. If the retry limit is reached without the error clearing, the channel goes to STOPPED state. A stopped channel must be restarted manually by the operator. If the error is still present, it does not retry again. When it does start successfully, the transmission queue is re-enabled.

If the channel initiator (on z/OS) or queue manager (on platforms other than z/OS) stops while a channel is in RETRYING or STOPPED status, the channel status is remembered when the channel initiator or queue manager is restarted. However, the channel status for the SVRCONN channel type is reset if the channel initiator (on z/OS) or queue manager (on platforms other than z/OS) stops while the channel is in STOPPED status.

If a channel is unable to put a message to the target queue because that queue is full or put inhibited, the channel can retry the operation a number of times (specified in the message-retry count attribute) at a given time interval (specified in the message-retry interval attribute). Alternatively, you can write your own message-retry exit that determines which circumstances cause a retry, and the number of attempts made. The channel goes to PAUSED state while waiting for the message-retry interval to finish.

See Channel attributes for information about the channel attributes, and Channel-exit programs for information about the message-retry exit.