Attributes of the channels stanza

These attributes determine the configuration of a channel.

This information is not applicable to IBM MQ for z/OS®.

Use the Channels queue manager properties page from the IBM MQ Explorer, or the CHANNELS stanza in the qm.ini file, to specify information about channels.

MaxChannels= 100|number

The maximum number of current channels allowed.

The default is 999 999 999, which means that the number is unlimited.

MaxActiveChannels= MaxChannels_value

The maximum number of channels allowed to be active at any time. The default is the value specified for the MaxChannels attribute.

MaxInitiators= 3|number

The maximum number of initiators. The default and maximum value is 3.

MQIBindType=FASTPATH|STANDARD

The binding for applications:

FASTPATH

Channels connect using MQCONNX FASTPATH; there is no agent process.

STANDARD

Channels connect using STANDARD.

PipeLineLength=1|number

The maximum number of concurrent threads a channel will use. The default is 1. Any value greater than 1 is treated as 2.

When we use pipelining, configure the queue managers at both ends of the channel to have a PipeLineLength greater than 1.

Note: Pipelining is only effective for TCP/IP channels.

AdoptNewMCA= NO|SVR|SDR|RCVR|CLUSRCVR|ALL|FASTPATH

If IBM MQ receives a request to start a channel, but finds that an instance of the channel is already running, in some cases the existing channel instance must be stopped before the new one can start. The AdoptNewMCA attribute allows you to control which types of channels can be ended in this way. If you specify the AdoptNewMCA attribute for a particular channel type, but the new channel fails to start because a matching channel instance is already running:

1. The new channel tries to stop the previous one by requesting it to end.
2. If the previous channel server does not respond to this request by the time the AdoptNewMCATimeout wait interval expires, the thread or process for the previous channel server is ended.
3. If the previous channel server has not ended after step 2, and after the AdoptNewMCATimeout wait interval expires for a second time, IBM MQ ends the channel with a CHANNEL IN USE error.

The AdoptNewMCA functionality applies to server, sender, receiver, and cluster-receiver channels. In the case of a sender or server channel, only one instance of a channel with a particular name can be running in the receiving queue manager. In the case of a receiver or cluster-receiver channel, multiple instances of a channel with a particular name might be running in the receiving queue manager, but only one instance can run at any one time from a particular remote queue manager.

Note: AdoptNewMCA is not supported on requester or server-connection channels.

Specify one or more values, separated by commas or blanks, from the following list:

NO

The AdoptNewMCA feature is not required. This is the default.

SVR

Adopt server channels.

SDR

Adopt sender channels.

RCVR

Adopt receiver channels.

CLUSRCVR

Adopt cluster receiver channels.

ALL

Adopt all channel types except FASTPATH channels.

FASTPATH

Adopt the channel if it is a FASTPATH channel. This happens only if the appropriate channel type is also specified, for example: AdoptNewMCA=RCVR,SVR,FASTPATH. Attention!: The AdoptNewMCA attribute might behave in an unpredictable fashion with FASTPATH channels. Exercise great caution when enabling the AdoptNewMCA attribute for FASTPATH channels.

AdoptNewMCATimeout= 60|1 - 3600

The amount of time, in seconds, that the new channel instance waits for the old channel instance to end. Specify a value in the range 1 - 3600. The default value is 60.

AdoptNewMCACheck=QM|ADDRESS|NAME|ALL

The type of checking required when enabling the AdoptNewMCA attribute. If possible, perform full checking to protect your channels from being shut down, inadvertently or maliciously. At the very least, check that the channel names match.

Specify one or more of the following values, separated by commas or blanks in the case of QM, NAME, or ALL:

QM

Check that the queue manager names match.

Note that the queue manager name itself is matched, not the QMID.

ADDRESS

Check the communications source IP address. For example, the TCP/IP address.Note: Comma separated CONNAME values apply to target addresses and are, therefore, not relevant to this option.

In the case that a multi-instance queue manager fails over from hosta to hostb, any outbound channels from that queue manager will use the source IP address of hostb. If this is different from hosta, then AdoptNewMCACheck=ADDRESS fails to match.

We can use SSL or TLS with mutual authentication to prevent an attacker from disrupting an existing running channel. Alternatively, use an HACMP type solution with IP-takeover instead of multi-instance queue managers, or use a network load balancer to mask the source IP address.

NAME

Check that the channel names match.

ALL

Check for matching queue manager names, the communications address, and for matching channel names.

The default is AdoptNewMCACheck=NAME,ADDRESS,QM.

ChlauthEarlyAdopt = Y| N

The order in which connection authentication and channel authentication rules are processed is a significant factor in determining the security context for IBM MQ client application connections.

Valid values for ChlauthEarlyAdopt are the following values:

Y

The channel validates and adopts user ID and password credentials that have been provided by an application using queue manager connection authentication before applying channel authentication rules. In this mode of operation, channel authentication rules match against the user ID resulting from connection authentication checks.

N

The channel delays connection authentication validation of user ID and password credentials that have been provided by an application until after channel authentication rules have been applied. Note that in this mode of operation, channel authentication blocking and mapping rules cannot consider the results of user ID and password validation.

For example, the default authentication information object is set to ADOPTCTX(YES), and the user fred is logged in. The following two CHLAUTH rules are configured:

SET CHLAUTH('MY.CHLAUTH') TYPE(ADDRESSMAP) DESCR('Block all access by
default') ADDRESS('*') USERSRC(NOACCESS) ACTION(REPLACE)
SET CHLAUTH('MY.CHLAUTH') TYPE(USERMAP) DESCR('Allow user bob and force
CONNAUTH') CLNTUSER('bob') CHCKCLNT(REQUIRED) USERSRC(CHANNEL)

The following command is issued, with the intention of authenticating the command as the adopted security context of the user bob:

runmqsc -c -u bob QMGR

In fact, the queue manager uses the security context of fred, not bob, and the connection fails.

To use the security context of bob, ChlauthEarlyAdopt must be set to Y.

PasswordProtection = Compatible|always|optional

From IBM MQ Version 8.0, set protected passwords in the MQCSP structure, rather than using TLS.

MQCSP password protection is useful for test and development purposes as using MQCSP password protection is simpler than setting up TLS encryption, but not as secure.

For more information, see MQCSP password protection.