| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Understanding CURSHCNV and MAXINSTC in SVRCONN |
« View previous topic :: View next topic » |
| Author |
Message
|
| krypton |
 Posted: Wed Apr 12, 2017 10:00 am Post subject: Understanding CURSHCNV and MAXINSTC in SVRCONN |
 |
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
looking for some opinion here,
I am trying to read this particular channel on our queue manager and as can be seen, it has listed the same channel 6 times whereas ConnName remains the same.
our MAXINSTC is set to 999999999, so my doubts is -
1. Isn't there should be a single listing here instead of 6, because the client(ConnName) and APPLTAG is same for all listing.
2. Also the value of CURSHCNV is being different in different listing.
(On another topic, we have this value as 10 by default , does it mean that once value of 10 reached for this parameter, it creates another listing ?)
21 : dis chs(WHIZ.KIDCHL) CURSHCNV
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(6)
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV('8')
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV('8')
AMQ8417: Display Channel Status details.
CHANNEL(WHIZ.KIDCHL) CHLTYPE(SVRCONN)
CONNAME(14.154.143.90) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
CURSHCNV(10)
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 12, 2017 12:02 pm Post subject: Re: Understanding CURSHCNV and MAXINSTC in SVRCONN |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| krypton wrote: |
| l1. Isn't there should be a single listing here instead of 6, because the client(ConnName) and APPLTAG is same for all listing. |
Why would you expect that for an SVRCONN?
| krypton wrote: |
| l2. Also the value of CURSHCNV is being different in different listing. |
Why would you expect it to be the same?
| krypton wrote: |
| l(On another topic, we have this value as 10 by default , |
How have you done this? CURSHCNV is an attribute of the DISPLAY command & is not valid for DEFINE or ALTER.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| krypton |
| Posted: Wed Apr 12, 2017 12:42 pm Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
| Quote: |
Why would you expect that for an SVRCONN?
|
In MQ 7 and later, the parameter MAXINSTC was introduced, which says if that many client connections can connect to a single server connection channel, if the Client is same.
so there is no need of creating another instance of SVRCONN channel, if the client remains the same. (even if multiple instances of same client).
| Quote: |
How have you done this? CURSHCNV is an attribute of the DISPLAY command & is not valid for DEFINE or ALTER.
|
The parameter I meant was SHARECNV , so if we increase the value of this parameters from 10 to 100, does that mean the SVRCONN will not create another intstancs until it reaches 100.
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Apr 12, 2017 3:36 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
| hughson |
| Posted: Wed Apr 12, 2017 4:39 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| krypton wrote: |
In MQ 7 and later, the parameter MAXINSTC was introduced, which says if that many client connections can connect to a single server connection channel, if the Client is same.
so there is no need of creating another instance of SVRCONN channel, if the client remains the same. (even if multiple instances of same client). |
If MAXINSTC is exceeded it will not create a new SVRCONN it will block all further connections from that IP address.
If MAXSHCNV (the negotiated value from SHARECNV on both ends) is exceeded, then a new SVRCONN will be created.
| krypton wrote: |
| If we increase the value of SHARECNV from 10 to 100, does that mean the SVRCONN will not create another instance until it reaches 100. |
There are several points here.
- You need to change the SVRCONN
- You need to change the CLNTCONN - what client connection method are you using?
- the client machine connections have to come from the same process on the client machine or they can't share no matter what else you set.
If you're unsure whether you have succeeded in upping the value in use for SHARECNV, look in DISPLAY CHSTATUS for MAXSHCNV, as that contains the negotiated value, and thus the value that will be used.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
