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.
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.
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.
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.
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).
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.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
chstate |