This is part of a series of blog posts which will cover features of IBM MQ that I happen to be using this week. I spend a lot of time using MQ, and not everything counts as an MQ Little Gem, or a Quirk, but is still interesting to hear about. Read other posts in this series.

A good practice when writing IBM MQ Applications is to keep all the connection configuration outside of the code.

You can code an MQCONN or MQCONNX and have the decision about whether a client connection or locally bound connection is used, made outside of your code. I have written about this before so I will only summarise here.

Client Connection

To make a client (aka network attached) connection you could have one of

• MQ_CONNECT_TYPE environment variable set to CLIENT
• Installation in use only has client libraries installed

In these cases, this would be combined with either the MQSERVER environment variable being set, a CCDT being in use, or my personal favourite, the mqclient.ini file containing all the necessary information.

Locally Bound Connection

To make a locally bound connection you could have one of

• MQ_CONNECT_TYPE environment variable set to LOCAL (or unset)
• Server libraries installed

In these cases, the queue manager has to be on the same machine as the application for the connect to work of course.

Detecting which type of connection was made

Having written such an application, you might sometimes need to know what type of connection was ultimately made in order to make some other decisions in your application. I was in this situation recently with an MQ application I was writing, and this blog post details how I solved answering this question.

The first thing to note here is that, from the above possible situations, you can't solve this simply by obtaining the value of the MQ_CONNECT_TYPE environment variable, because it might not be set. I needed something that would work in all situations.

My solution is to use a little known feature of MQ added back in MQ V7, the connection option MQCNO_CD_FOR_OUTPUT_ONLY.

This option was introduced to allow applications, which made more than one connection, ensure that both connections would be made using the same channel details. This was to make sure that they would share the same socket, using the SHARECNV feature. The option meant that they could select the channel for the first connection from a CCDT, and then be given back the details and make the second connection using those returned details and thus be certain to be using the same channel, and get the benefit of sharing conversations. It was very useful for JMS applications which routinely make two connections but it was available for all language bindings.

A side effect of using this option is that you can tell whether you are using a channel for your connection or not, and that therefore lets you tell whether you are making a client or a locally bound connection.

Here's a little code snippet to show you how.

MQHCONN hConn = MQHC_UNUSABLE_HCONN;
MQCNO   cno   = { MQCNO_DEFAULT };
MQCD    cd    = { MQCD_CLIENT_CONN_DEFAULT };
MQLONG  CompCode, Reason;

cno.Options = MQCNO_CD_FOR_OUTPUT_ONLY;
cno.ClientConnPtr = &cd;

MQCONNX(QMName,
        &cno,
        &hConn,
        &CompCode,
        &Reason);
if (Reason == MQRC_NONE)
{
  if (cd.ChannelName[0])
  {
    /* A client connect was made */
  }
}

On the way into the MQCONNX call, the ChannelName field in the MQCD contains all nulls (zeroes), so on return from the MQCONNX, if the call was successful, any non-null value in the first character of the ChannelName field, shows us that a channel was used, and we have our answer. If the ChannelName field still contains a null first character we know that a locally bound connection was used.

So, now you know.

#Using-MQ-feature
#IBMMQ
#IBMChampion