+

Search Tips | Advanced Search

Channels stanza of the qm.ini file

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= 999 999 999|number
    The maximum number of current channels allowed.
    The default is 100.

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

    IgnoreSeqNumberMismatch = NO| 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.
    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| 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 we want message AMQ9787 to be generated when you set the WARN = YES attribute on the SET CHLAUTH command.

Parent topic: Attributes for changing queue manager configuration information


Related concepts

Last updated: 2020-10-04