MaxChannels vs DIS QMSTATUS CONNS

I got asked this question on twitter the other day, so I thought it would make an interesting blog post.

Let’s look at each piece of the question.

DISPLAY QMSTATUS CONNS

You can use the DISPLAY QMSTATUS command to see how many connections there are currently made into the queue manager. This is a count of the number of applications (or some queue manager processes too) that have made an MQCONN(X) to the queue manager. It is also the same number of responses you should see returned by DISPLAY CONN(*) – if you don’t want to count them, find an MQ admin tool that counts them for you. These connections might be local or client connections – both contribute to the total.

To see the local ones use command:-

DISPLAY CONN(*) ALL WHERE(CHANNEL EQ ' ')

To see the remote ones use command:-

DISPLAY CONN(*) ALL WHERE(CHANNEL NE ' ')

Client Connections and MaxChannels

So having ruled out the local connections what should you think if the number of connections coming in over a channel is more than MaxChannels? As the question asks, “Shouldn’t that be failing?”

The other thing to remember here is that, since MQ V7, one SVRCONN channel can relay several client MQCONNs over to the queue manager.

To see this take a look at the DISPLAY CHSTATUS command. There is a status attribute CURSHCNV that shows the number currently being shared over that one SVRCONN instance.

To see the number of running channels, use the command:-

DISPLAY CHSTATUS(*) CURSHCNV

The number of responses will show you how many running channel instances there are – which is the number to compare against MaxChannels. If you add up the total of all the numbers shown in CURSHCNV, this total will be less than (or equal to) the above number of channel based connections shown when you used the DISPLAY CONN command. Both queue manager channels and client channels contribute to that total.

HINT: If you want an easy way to total up all the numbers shown in CURSHCNV, try out MQSCX with this single line:-

@total=0;foreach(DISPLAY CHSTATUS(*) CURSHCNV);@total=@total+CURSHCNV;endfor;print @total

Or you could make a little import file to print out all the various numbers:-

=echo cmds(NO)
=echo resp(NO)
print 'Show all the connections into queue manager',_connqmgr
print _sep

DISPLAY QMSTATUS CONNS
print 'Total connections ',CONNS

DISPLAY CONN(*) ALL WHERE(CHANNEL EQ ' ')
print 'Local connections ',_matches

DISPLAY CONN(*) ALL WHERE(CHANNEL NE ' ')
print 'Remote connections',_matches

@total = 0
@svrcn = 0
foreach(DISPLAY CHSTATUS(*) CURSHCNV CHLTYPE)
  if (CHLTYPE = "SVRCONN")
    @svrcn = @svrcn + 1
  endif
  @total = @total + CURSHCNV
endfor
print 'Total Channel instances ',_matches
print 'QMgr Channel instances  ',_matches - @svrcn
print 'Client Channel instances',@svrcn
print 'Client connections',@total
=echo cmds(YES)
=echo resp(YES)

UPDATE: This script evolved further with the release of MQSCX V9.0.0 and the use of functions – see more in MQSCX Functions.


IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson Twitter: https://twitter.com/MoragHughson SlideShare: http://www.slideshare.net/moraghughson developerWorks: https://www.ibm.com/developerworks/community/profiles/html/profileView.do?userid=110000EQPN

Advertisements

4 thoughts on “MaxChannels vs DIS QMSTATUS CONNS

  1. I’m using DataPower (an xi52) to connect to MQ and I keep seeing the odd 2025 error so I thought I was hitting maxchannels but it doesn’t appear to be the case based on what you’ve explained above (which is excellent!).

    Like

  2. This is weird. I see the following errors in the datapower logs but nothing in the MQ logs that correspond. In Datapower, I have max connections set as 4 but the channel in brokers (7.0.0.6) mq (7.0.1.11) is set at 8 max and 8 max per client.

    The messages come in hot and heavy in my load test but shouldn’t it just be slow and not fail?

    12:32:37 PM mq error 38521063 0x80e00648 mpgw (mpg): A new connection could not be opened (Reason Code 2025), MQ Reason Code = 2025, MQ URL = dpmq://IIBMQ/?RequestQueue=MYQUEUE;Transactional=true
    12:32:37 PM mq error 38521063 0x01330011 mpgw (mpg): A new connection could not be opened (Reason Code 2025)
    12:32:37 PM mpgw error 38521063 0x80e00616 mpgw (mpg): Network Error (Connection timed out) on Back interface (URL: dpmq://IIBMQ/?RequestQueue=MYQUEUE;Transactional=true) when processing the server response

    Like

The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s