This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

IBM MQ Client Channels have had the concept of sharing conversations over the same TCP/IP socket for a number of releases now. Your server-connection channels are set-up by default to accept up to 10 shared conversations over the same socket, although you can change that value to meet your own requirements. It can be a useful saving of resources when you have applications hosted in the same Application Server process that are not particularly busy and wouldn't be making heavy use of the socket, so grouping them together saves on the socket resource, and makes start-up time quicker because TLS handshakes and security exits don't have to run again for each one.

As an MQ administrator, you have a few controls and status output fields to understand exactly what sharing is taking place in your system, and since I've seen a few questions about this on forums lately, I thought that would make a good topic for this months post.

Controlling conversation sharing

The main way to control conversation sharing is at the server-connection channel, where you can disallow sharing, or increase the number of conversations that can be shared. For example, to ensure that exactly one and only one conversation goes over each instance of a server-connection channel, you can mandate this at the queue manager end with the following command.

ALTER CHANNEL(MQGEM.SVRCONN) CHLTYPE(SVRCONN) SHARECNV(1)

However, if you are the owner of a client application that does not want to share its socket, or wants to use a specific number of shared conversations, and you are connecting to a queue manager that is happy to have larger numbers of shared conversations, you can control this from the client-connection end. In your CCDT where you define your CLNTCONN channel, you can also set the maximum amount of sharing you want to allow.

ALTER CHANNEL(MQGEM.SVRCONN) CHLTYPE(CLNTCONN) SHARECNV(1)

The SHARECNV attribute is a negotiated one, and the running instance of the channel will use the lower value specified from the two ends of the channel.

Alternatively, if you know that your client application is not good at sharing (it's a bit of a network hog!) or you don't want it to be shared for any other reason, you can disable sharing for your application's conversation by using the MQCNO_NO_CONV_SHARING option on your MQCONNX call. This will cause your running instance of the SVRCONN to act as if it was defined with SHARECNV(1).

How much sharing is happening

To see how many conversations are being shared across a channel, there is an attribute on channel status that shows this. Here is some output that demonstrates.

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(2) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)

The MAXSHCNV value shows you the final negotiated value of the two SHARECNV values (and also takes into account MQCNO_NO_CONV_SHARING). As it's name suggests, this is the maximum number of conversations that can be shared on this running instanced of the SVRCONN channel, before another channel instance will be started for any additional client conversations.

The CURSHCNV value shows you how many conversations are currently being shared over this SVRCONN instance, and therefore this TCP/IP socket. If you need to see the details of these applications, you can use the DISPLAY CONN command as I described in an earlier post. If you're looking at the numbers of connections you have into a queue manager, and comparing it to the number of channel instances, remember about the CURSHCNV value, as you need to take it into account in your totals, as I wrote about before in this blog post.

The interesting thing that I want to cover in this post is when you see several channel instances running, but when they are not all "full". By "full", I mean they do not have CURSHCNV at a value equal to the MAXSHCNV. You may look at that and wonder why they did not fill one SVRCONN before creating a new one.

There are several reasons for this (and maybe others I have not thought about - please add a comment!).

1. In order to share a TCP/IP socket and channel instance, the client application must be connecting from the same machine. This may be obvious to you, but some people forget.
2. In order to share, the client application must be connecting from inside the same O/S process on the client machine. A TCP/IP socket cannot be shared between two O/S processes. This is why conversation sharing is most useful in Application Server style hosting environments, where you are within a single O/S process.

Assuming that the above points are met, you may still have times when you don't see "full" SVRCONNs when you expect to.

3. Shared conversations are not re-balanced across TCP/IP sockets when some conversations close.

This means that you might have several "full" SVRCONN channels, e.g.

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(10) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)
AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(10) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)
AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(10) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)

And then you look back a little later, and see something like this:

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(7) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)
AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(3) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)
AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(9) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)

These numbers should only require two SVRCONN instances to be running, not three. What has happened here is that some of the client applications have completed, and disconnected from the queue manager, so their conversation is gone and the CURSHCNV value for that instance reduces, leaving you wondering why a new SVRCONN instance was started. This is normal and working properly. Those empty slots will be reused should another client application connect from the same process, and until the empty slots are used up, another SVRCONN instance won't need to be started.

So remember about these values in your channel status displays when you are next looking into how your client applications are running.