Channels stanza of the qm.ini file

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

Use the CHANNELS stanza in the qm.ini file to specify information about channels.

Alternatively, on Linux® (x86 and x86-64) and Windows, use the IBM MQ Explorer Channels queue manager properties page.

MaxChannels = 100 (default) |number

The maximum number of current channels allowed.

The default is 100.

You can set MaxChannels to a different value to limit the maximum number of current channels if required. For IBM MQ Appliance, the default value is 999 999 999, and should not be changed.

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

ThreadedListener= NO|YES

Whether to start RUNMQLSR (YES) or AMQCLMAA (NO) as a listener.

If you specify ThreadedListener=YES, all channels run as threads of a single job. This limits the number of connections to the resources available to a single job.

If you specify ThreadedListener=NO, the non-threaded listener (AMQCLMAA) starts a new responder job (AMQCRSTA) for each inbound TCP/IP channel. The disadvantage of this technique is that it is not as fast to start a new AMQCRSTA job as it is to start a thread within a RUNMQLSR job, therefore connection times for a non-threaded listener are slower than those for a threaded listener.

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

See Multiple thread support - pipelining for more information.

AdoptNewMCA = NO (default) |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 (default)|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.

You 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 (default) | 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.

Attention: The default if ChlauthEarlyAdopt is not present in the qm.ini file is N, however, from IBM MQ 9.0.4 all queue managers are created with ChlauthEarlyAdopt=Y automatically added to the qm.ini file.

ChlauthEarlyAdopt only adopts user IDs that have been provided to a queue manager for connection authentication, if ADOPTCTX(YES) is set on the connection authentication AUTHINFO object on the queue manager.

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 (default) |always|optional|warn

From IBM MQ 8.0, authentication credentials that IBM MQ client applications specify when they connect to a queue manager can be protected by using the IBM MQ MQCSP password protection feature, if the connection does not use TLS encryption.

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 about protecting credentials in the MQCSP structure, and the values that can be set for this attribute, see MQCSP password protection.

IgnoreSeqNumberMismatch = NO (default) | YES

The Message Channel Agents (MCAs) at the two ends of a channel each keep count of the number of messages sent through the channel to maintain synchronization. Synchronization can be lost, for example if the channel definition at one end is deleted and then re-created. Under these circumstances a RESET CHANNEL may be required to acknowledge that synchronization data has been lost and permit the channel to continue startup.

The IgnoreSeqNumberMismatch attribute must be set on the receiver queue manager.

Effectively, this attribute performs a reset channel command on the receiver channel.

This attribute controls how the queue manager handles a sequence number mismatch during channel startup using the following values:

NO

Channel sequence numbers are checked during channel resynchronization, if the two MCAs do not agree on the same sequence number, error message AMQ9526 will be reported and the channel will fail to start.

YES

Channel sequence numbers are checked during channel resynchronization, but if the two MCAs do not agree on the same sequence number, warning message AMQ9703 will be reported and the channel startup will continue. This attribute value should not be needed under normal circumstances. When it is known that synchronization data has been lost, for example during disaster recovery, this option avoids needing to manually acknowledge each sequence number mismatch. Specifying this value has a similar effect to an administrator automatically issuing a RESET CHANNEL in response to each sequence number mismatch.

ChlauthIgnoreUserCase = N (default) | Y

Enables a queue manager to make username matching within CHLAUTH rules case-insensitive. This option allows the:

• CLNTUSER in CHLAUTH TYPE(USERMAP) rules to be matched case-insensitively
• USERLIST in CHLAUTH TYPE(BLOCKUSER) rules to be matched case-insensitively

Valid values for ChlauthIgnoreUserCase are the following values:

N

The channel authentication rules attempt to match client user identification with case sensitivity, for example a rule specifying CLNTUSER('Fred') will not match 'fred' or 'FRED', it will only match a user identifier of 'Fred'. This is the default value.

Y

The channel authentication rules attempt to match client user identification with case insensitivity, for example a channel authentication rule with TYPE(USERMAP) or TYPE(USERBLOCK) specifying CLNTUSER('Fred') will match with any variation of case, for example user identifiers 'Fred', 'FRED' and 'fred' all match.

Note that, when ignoring case of user identifiers when matching channel authentication rules, it is possible for more than one rule to match. If this occurs, the rule that is matched is undefined. For example with the following rules, if user 'fred' connects to a queue manager via the CLIENT channel, they might be mapped to 'mquser1' or 'mquser2':

SET CHLAUTH('CLIENT') TYPE(USERMAP) CLNTUSER('fred') USERSRC(MAP) MCAUSER('mquser1')
SET CHLAUTH('CLIENT') TYPE(USERMAP) CLNTUSER('FRED') USERSRC(MAP) MCAUSER('mquser2')

To avoid any uncertainty when using ChlauthIgnoreUserCase=Y, avoid defining CHLAUTH rules that would overlap and result in different behavior when using a case-insensitive match.

ChlauthIssueWarn = y

Set this attribute if you want message AMQ9787 to be generated when you set the WARN = YES attribute on the SET CHLAUTH command.