Tailor the channel initiator parameters

Use ALTER QMGR to customize the channel initiator to suit we requirements.

  • Repeat this task for each IBM MQ queue manager, as required.
  • We must perform this task when migrating from a previous version.

A number of queue manager attributes control how distributed queuing operates. Set these attributes using the MQSC command ALTER QMGR. The initialization data set sample thlqual.SCSQPROC(CSQ4INYG) contains some settings that we can customize. For more information, see ALTER QMGR.

The values of these parameters are displayed as a series of messages each time you start the channel initiator.


The relationship between adapters, dispatchers, and maximum number of channels

The ALTER QMGR parameters CHIADAPS and CHIDISPS define the number of task control blocks (TCBs) used by the channel initiator. CHIADAPS (adapter) TCBs are used to make IBM MQ API calls to the queue manager. CHIDISPS (dispatcher) TCBs are used to make calls to the communications network.

The ALTER QMGR parameter MAXCHL influences the distribution of channels over the dispatcher TCBs.

    CHIDISPS

    If we have a small number of channels use the default value.

    One task for each processor optimizes system performance. As dispatcher tasks are CPU intensive, the principle is to keep as few tasks as busy as possible, so that the time taken to find and start threads is minimized.

    CHIDISPS(20) is suitable for systems with more than 100 channels. There is unlikely to be any significant disadvantage in having CHIDISPS(20) where this is more dispatcher TCBs than necessary.

    As a guideline, if you have more than 1000 channels, allow one dispatcher for every 50 current channels. For example, specify CHIDISPS(40) to handle up to 2000 active channels.

    If we are using TCP/IP, the maximum number of dispatchers used for TCP/IP channels is 100, even if we specify a larger value in CHIDISPS.

    CHIADAPS

    Each IBM MQ API call to the queue manager is independent of any other and can be made on any adapter TCB. Calls using persistent messages can take much longer than those for nonpersistent messages because of log I/O. Thus a channel initiator processing a large number of persistent messages across many channels may need more than the default 8 adapter TCBs for optimum performance. This is particularly so where achieved batchsize is small, because end of batch processing also requires log I/O, and where thin client channels are used.

    The suggested value for a production environment is CHIADAPS(30). Using more than this is unlikely to give any significant extra benefit, and there is unlikely to be any significant disadvantage in having CHIADAPS(30) if this is more adapter TCBs than necessary.

    MAXCHL
    Each channel is associated with a particular dispatcher TCB at channel start and remains associated with that TCB until the channel stops. Many channels can share each TCB. MAXCHL is used to spread channels across the available dispatcher TCBs. The first ( MIN( (MAXCHL / CHIDISPS ), 10 ) ) channels to start are associated with the first dispatcher TCB, and so on, until all dispatcher TCBs are in use.
    The effect of this for small numbers of channels and a large MAXCHL is that channels are NOT evenly distributed across dispatchers. For example, if you set CHIDISPS(10) and left MAXCHL at its default value of 200 but had only 50 channels, five dispatchers would be associated with 10 channels each and five would be unused. We suggest setting MAXCHL to the number of channels actually to be used where this is a small fixed number.
    If we change this queue manager property, we must also review the ACTCHL, LU62CHL, and TCPCHL queue manager properties to ensure that the values are compatible. See Queue manager parameters for a full description of these properties, and their relationship.


Set up your z/OS UNIX System Services environment for channel initiators

The channel initiator (CHINIT) uses OMVS threads. Review the OMVS configuration parameters before creating a new CHINIT, or modifying the number of dispatchers or SSLTASKS.

Each CHINIT uses 3 + CHIDISP + SSLTASKS OMVS threads. These contribute to the total number of OMVS threads used in the LPAR, and towards the number of threads used by CHINIT started task user ID.

We can use the D OMVS,L and review the current usage, highwater usage, and system limit of MAXPROCSYS (the maximum number of processes that the system allows).

If we are adding a new CHINIT or increasing the values of CHIDISPS or SSLTASKS then we must calculate the increase in threads and review the impact on the MAXPROCSYS values. We can use the SETOMVS command to dynamically change the MAXPROCSYS, or update the BPXPRCxx parmlib value or both.

The OMVS parameter MAXPROCUSER is the number of OMVS threads a single OMVS user, that is with the same UID, can have. The threads count towards this value. So if you have 2 CHINITS with the same started task user ID, with 10 dispatchers and 3 SSLTASKS each then there are 2 *( 3 +10 + 3) = 32 threads for the OMVS uid.

We can display the default MAXPROCUSER by issuing the D OMVS,O command and we can use the SETOMVS command to dynamically change the MAXPROCUSER, or update the BPXPRCxx parmlib value or both.

We can override this value on a per user basis with the RACF command ALTUSER userid OMVS(PROCUSERMAX(nnnn)) or equivalent.

To start the channel initiator, issue the following command: 
START CHINIT
To ensure that the channel initiator has started successfully, check that there is no ICH408I error in the xxxxCHIN(ssidCHIN) job log. Parent topic: Configure the queue manager and channel initiator


Related concepts


Related information