Discrepancy between total CONNAME values on DIS QSTATUS Vs DIS CHSTATUS - ibm-mq

Question

I was executing two mqsc commands on IBM MQ v8 to find out the number of connections made by App1 on queue manager QMGR and found a discrepancy between the output values on one of the attribute called CONNAME
echo 'dis chs('APP1.SVRCONN.CHL')'| runmqsc QMGR | grep CONNAME
This time I got 14 IP's as CONNAME
echo 'dis qs(APP1.QUEUE) type(handle) All where(CHANNEL eq 'APP1.SVRCONN.CHL')'| runmqsc QMGR | grep CONNAME
When I checked the number of handles on the only App1 queue connected by App1 channel I got only 7 IP's as CONNAME
So there are 7 handles on the App1 queue but there are 14 connections by the App1 channel on queue manager. How can I relate these two values? Is this multi-threaded connections on each queue handles and if so how can I find a relationship between them?

Answer 1

The DIS CHS command will show you how many channel instances are running which is really how many TCP sessions there are established between your client and the queue manager.
MQ v7.0.1 and higher supports shared conversations within each channel. Each time the app makes a connection to the queue manager this can be another conversation in the same channel instance. The client and the server can set a maximum number of shared connections. On the queue manager's SVRCONN the attribute is SHARECNV, on the client it could be in a CCDT or programatically. When the channel starts up the client and server will negotiate to the lowest value between them. On a DIS CHS you can add MAXSHCNV to see what the running channel instances negotiated the maximum to and CURSHCNV to see how many conversations are running in each channel instance.
The DIS QS command with TYPE(HANDLE) will only show you connections where the application has a handle open to that queue at the point in time you ran the command.
An application can connect to the queue manager without having a queue open, or it may open and close the queue, if you don't catch it with the queue open you won't see a handle.
A more accurate command to show what the channel is doing is DIS CONN which will show all connections, each connection represents a conversation, so the number of connections should match the number total of CURSHCNV from all channel instances.
The following command will show you all connections running through a channel with the name specified.
echo "DIS CONN(*) TYPE(ALL) WHERE(CHANNEL EQ APP1.SVRCONN.CHL)"|runmqsc QMGR
The output may look like this:
AMQ8276: Display Connection details.
CONN(ABABABABABABABAB)
EXTCONN(ABABABABABABABABABABABABABABABAB)
TYPE(*)
PID(99998) TID(998)
APPLDESC(WebSphere MQ Channel) APPLTAG(App1)
APPLTYPE(USER) ASTATE(NONE)
CHANNEL(APP1.SVRCONN.CHL) CLIENTID( )
CONNAME(10.10.10.10)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
USERID(appuser) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(BABABABABABABABA)
EXTCONN(BABABABABABABABABABABABABABABABA)
TYPE(*)
PID(99999) TID(999)
APPLDESC(WebSphere MQ Channel) APPLTAG(App1)
APPLTYPE(USER) ASTATE(STARTED)
CHANNEL(APP1.SVRCONN.CHL) CLIENTID( )
CONNAME(10.10.10.10)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
USERID(appuser) UOWLOG( )
UOWSTDA(2018-05-21) UOWSTTI(10.11.27)
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
QMURID(0.99999) UOWSTATE(ACTIVE)
OBJNAME(APP1.QUEUE) OBJTYPE(QUEUE)
ASTATE(ACTIVE) HSTATE(INACTIVE)
OPENOPTS(MQOO_INPUT_SHARED,MQOO_BROWSE,MQOO_INQUIRE,MQOO_SAVE_ALL_CONTEXT,MQOO_FAIL_IF_QUIESCING)
READA(NO)
In the above output CONN(ABABABABABABABAB) only has a connection to the queue manager and no objects open while CONN(BABABABABABABABA) had a connection to the queue manager and has the queue APP1.QUEUE open.
If you were to add to the above command |grep 'APP1.QUEUE' the count should match the number of handles from the DIS QS command.
You may have a app that browses the queue on one connection to look for messages and then dispatches to other threads to actually process the messages. In your case 7 channel instances may have the queue open for BROWSE and the other 7 would be waiting to open the queue for INPUT to read a message off.
Below is a command I use on Linux that will spit out a CSV format of the DIS CONN command along with each object that is open.
echo "DIS CONN(*) TYPE(ALL) WHERE(CHANNEL EQ CHL_NAME)"|runmqsc QMGR|grep -o '^\w\+:\|\w\+[(][^)]\+[)]' | awk -F '[()]' -v OFS='","' 'function printValues() { if ("CONN" in p) { print p["CONN"], p["CHANNEL"], p["APPLTAG"], p["USERID"], p["CONNAME"], p["OBJNAME"], p["OBJTYPE"], p["OPENOPTS"] } } /^\w+:/ { if (x !~ /YES/) {printValues()}; x = "NO"; delete p; next } { p[$1] = $2 } { if ("OPENOPTS" in p) { printValues() ; delete p["OPENOPTS"]; x = "YES"} } END { if (x !~ /YES/) {printValues()} }'|sed -e 's/^/"/g' -e 's/$/"/g'
The fields in the CSV output are:
"CONN","CHANNEL","APPLTAG","USERID","CONNAME","OBJNAME","OBJTYPE","OPENOPTS"
Objects can be the QMGR itself, a QUEUE, TOPIC, etc. The CONN id will be repeated in lines of the output if the same CONN has multiple objects open. If the CONN has no objects open you will see a single entry with no objects listed at the end of the line, if at least one object is open there will not be a line representing no objects: