Supported IBM MQ client: Default behavior of client-connection and server-connection channels

The default for client and server connections is to share an MQI channel. You use the SHARECNV (share conversations) parameter to specify the maximum number of conversations that can be shared over a particular TCP/IP client channel instance.
The possible values are as follows:
SHARECNV(2) to SHARECNV(999999999)
Each of these values specifies the number of shared conversations. If the client-connection SHARECNV value does not match the server-connection SHARECNV value, then the lowest value is used. The default value is SHARECNV(10), which specifies 10 threads to run up to 10 client conversations per channel instance. However, on distributed servers there are performance issues with SHARECNV channels that can be eased by using SHARECNV(1). See Tuning client and server connection channels.
SHARECNV(1)
This value specifies no sharing of conversations over a TCP/IP socket. Performance on distributed servers is similar to that for a value of 0. Client heartbeating (whether in an MQGET call or not) and read ahead are available, and channel quiescing is more controllable.
SHARECNV(0)
This value specifies no sharing of conversations over a TCP/IP socket. Only use a value of 0 if you have existing client applications that do not run correctly when you set SHARECNV to 1 or greater.
For all SHARECNV values of 1 or greater, the channel supports the following features:
  • Bi-directional heartbeats
  • Administrator stop-quiesce
  • Read-ahead
  • Asynchronous-consume by client applications

Heartbeats

Heartbeats can flow across the channel at any time in either direction. If you use SHARECNV(0), heartbeats flow only when an MQGET call is waiting.

Channel exits

The behavior of a client or server connection channel exit changes when the channel is sharing conversations (that is, when you set SHARECNV to a value greater than 1). It is unlikely, but possible, that the change affects the behavior of existing exits. The change is as follows:
  • Send or receive exits can alter the MQCD structure on an MQXR_INIT call. The effect of these exits differs, depending on whether the conversation is shared with other conversations on the same channel:
    • If the MQCXP SharingConversations field passed to the exit instance is set to FALSE, this exit instance is the first, or only, conversation on the channel instance. No other exit can be changing the MQCD at the same time, and changes that are made to the MQCD can affect the way that the channel runs.
    • If the MQCXP SharingConversations field passed to the exit instance is set to TRUE, this exit instance is a subsequent conversation. It is sharing the channel instance with other conversations. Changes made to the MQCD in the exit instance are retained in the MQCD but do not affect the way the channel runs.
  • Send, receive, and security exit instances can alter the MQCD, when the MQCXP SharingConversations field is set to TRUE. Exit instances on other conversations might be changing the MQCD at the same time. Updates written by one exit instance can be overwritten by another instance. It might be necessary to serialize access to the MQCD across these different exit instances to maintain the consistency of fields in MQCD.

Updating MQCD when the SharingConversations field is set to TRUE does not affect the way the channel runs. Only alterations made when the MQCXP SharingConversations field is set to FALSE, on an MQXR_INIT call, change channel behavior.