The chart shows that for a sender-type (SDR) channel, the maximum number of objects that can be stored in a single 4KB page is 10, and the minimum is 1.

This means that if a sender-type channel is defined with a long CONNAME, for example using the 264 bytes, and all the variable length attributes configured to their maximum lengths, only 1 similarly configured sender channel would be stored per 4KB page.

By contrast a sender-type channel that is configured with the minimum mandatory fields, i.e. example XMITQ and CONNAME only, up to 10 channels could be stored per 4KB page, depending on the length of the values in those attributes.

These channels are based on all channel definitions for a single channel type being defined with the same length attributes and should channel object “one” require more than 2048 bytes and the next object defined require less than 2048 bytes, then both objects may be stored on a single page.

Minimum Objects per 4KB Page:

For a receiver or SVRCONN-type channel, neither of which support CONNAME, a minimum of 2 objects will be stored per 4KB page of page set zero.

For all other channel types, which do support CONNAME, it is possible that 1 object may be stored per 4KB page on page set zero.

Maximum Objects per 4KB Page:

For a sender-type object, a maximum of 10 SDR-type channel objects may be stored on a single 4KB page on page set zero.

For all other channel types, a maximum of 11 channel objects may be stored on a single 4KB page on page set zero.

Note: CLNTCONN channels

CLNTCONN channels on z/OS have not been updated to support a CONNAME of greater than 48 characters in length.

Although CLNTCONN channels can be defined on z/OS, they cannot be exported to a client system because the CSQUTIL MAKECLNT tool used for this purpose was deprecated in IBM MQ 9.1.0 for z/OS.

Impact of multiple host/port names in the CONNAME attribute on channel start:

The connections are usually tried in the order they are specified in the connection list until a connection is successfully established.

Should the list contain multiple host/port names that are not available at the head of the list, there is an impact to the performance of channel start.

In MP16 “Capacity Planning and Tuning for  IBM MQ for z/OS” section titled “Channel start / stop rates and costs”, we have documented that to start 1000 channels on IBM z16 (3931-703), we achieved 649 channels per second at a cost of 220 CPU microseconds per channel.

When we repeat these measurements but provide increasing number of host/port names where the connection attempt will not be successfully established before the final connection is established we can plot the following chart:

In our environment where the remote-end of the channel was a separate LPAR on the same SYSPLEX with a low-utilization low-latency network, a channel configured with 1 host/port name took 1550 microseconds to start.

When configuring multiple host/port names in CONNAME attribute, each unsuccessful connection attempt added 380 microseconds to the channel start time.

In a higher-latency network (greater distance, generally busier or even less responsive target systems), the elapsed time to attempt the connection may be higher.

In terms of CPU attributed to the MQ channel initiator at channel start, we found that each unsuccessful attempt cost 100 CPU microseconds on IBM z16 (3931-703) in addition to the 220 CPU microseconds incurred for the successful connection.

For each unsuccessful connection attempt, the channel initiator will log the CSQX202E message, for example:

Each failed host/port name will be attempted once before MQ attempts the next machine name in the CONNAME list.

It is not until all the host/port  names have been attempted that channel retry processing is attempted.

The DISPLAY CHSTATUS() CONNAME command can be used to verify which connection name was successfully established.

The performance of “STOP CHANNEL” is not affected by the number of machines in the connection list.

As the use case for multiple host/port names is for failover reasons, the list should be specified in order of likely use.

If using multiple host/port names, ensure the entire string value of CONNAME is enclosed in single quotation marks, for example: CONNAME(‘10.20.37.22(2202),10.20.37.22(2203),10.20.36.103(2202)’)

Using CSQUTIL to define MQ channels with long CONNAME values:

The IBM documentation for CSQUTIL provides guidance on how to make object definitions that exceed SYSIN record length limits.
 

Since the CONNAME may now be up to 264 characters, it might be helpful to highlight specific parts of that guidance:

For example, a sender-type channel with a CONNAME of length 264 bytes could be defined thus:

 Another example using multiple host/port names might be:

Conclusions:

When using a list of multiple host/port names in the CONNAME attribute, be aware that channel start performance may be impacted by the order the connection names are specified and whether one or more of the connection attempts fails.

Page set zero usage may decrease when using IBM MQ 9.4.3 for z/OS compared to prior releases.

Should CONNAMEs be configured with values longer than 48 characters, page set zero usage may increase.

Monitor your page set zero usage when starting your MQ queue manager on MQ 9.4.3 to ensure that there is sufficient capacity for all the MQ objects defined.

Finally, and as a reminder, ensure that for the buffer pool used by page set zero has sufficient buffers available to avoid synchronous page set I/O.