|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
|
|
IPprocs and the corresponding SVRCONN channel count mismatch |
« View previous topic :: View next topic » |
Author |
Message
|
krypton |
Posted: Thu Apr 25, 2019 3:28 am Post subject: IPprocs and the corresponding SVRCONN channel count mismatch |
|
|
Disciple
Joined: 14 Mar 2010 Posts: 186
|
Hi All, I got an application which is connecting to a local Q for INPUT.
And just now I checked there were 12 IPPROCS on that Queue and 6 IPPROCS belong to Server1 and 6 IPPROCS belong to server 2.
All the IPProcs has same svrconn channel - POSTER.SVRCONN
So I went ahead and ran a MQSC command to filter out all the SVRCONN instance of this channel for Server1. And I got only 2 instances of that SVRCONN channel, why the mistmatch?
Shouldn't there be 6 SVRCONN instance?
Quote: |
dis chs(POSTER.SVRCONN) curshcnv CHSTADA CHSTATI lstmsgda lstmsgti msgs WHERE (CONNAME EQ SERVER1HOST)
9 : dis chs(POSTER.SVRCONN) curshcnv CHSTADA CHSTATI lstmsgda lstmsgti msgs WHERE (CONNAME EQ SERVER1HOST)
AMQ8417: Display Channel Status details.
CHANNEL(POSTER.SVRCONN) CHLTYPE(SVRCONN)
CHSTADA(2019-04-21) CHSTATI(01.09.00)
CONNAME(SERVER1HOST) CURRENT
LSTMSGDA(2019-04-25) LSTMSGTI(07.22.20)
MSGS(2676102) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(10)
AMQ8417: Display Channel Status details.
CHANNEL(POSTER.SVRCONN) CHLTYPE(SVRCONN)
CHSTADA(2019-04-21) CHSTATI(01.09.05)
CONNAME(SERVER1HOST) CURRENT
LSTMSGDA(2019-04-25) LSTMSGTI(07.22.20)
MSGS(475524) STATUS(RUNNING)
SUBSTATE(RECEIVE) CURSHCNV(5)
|
|
|
Back to top |
|
|
PaulClarke |
Posted: Thu Apr 25, 2019 10:21 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
It is not clear to me what you are trying to say here. Firstly you say there are 'only' two instances of the channel but then highlight the bit ('curshcnv') that shows you there are a lot more than two channels running.
If you want to look at applications, their connections and the queues they have open then it would seem to me that DISPLAY CONN is the command to use, not DISPLAY CHSTATUS.
What happens if you issue a command such as
Code: |
DISPLAY CONN(*) TYPE(ALL) where(channel eq 'POSTER.SVRCONN') |
does that show the infomation you expected to see ?
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
|
krypton |
Posted: Thu Apr 25, 2019 11:45 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010 Posts: 186
|
PaulClarke wrote: |
What happens if you issue a command such as
Code: |
DISPLAY CONN(*) TYPE(ALL) where(channel eq 'POSTER.SVRCONN') |
does that show the infomation you expected to see ?
Cheers,
Paul. |
Hi Paul, yes you were right, when I run the above command I got 6 results for that channel and Server1Host. My last question , then we can close this thread, how do we correlate between Queue Status IPPROCS and these connections? Is there a correlation ID thing which matches between these 2.
AMQ8276: Display Connection details.
CONN(BDFABB5CAE39AB22)
EXTCONN(414D5143454149505247573120202020)
TYPE(*)
PID(2021) TID(61)
APPLDESC(WebSphere MQ Channel) APPLTAG(jar)
APPLTYPE(USER) ASTATE(STARTED)
CHANNEL(POSTER.SVRCONN) CLIENTID( )
CONNAME(SERVER1HOST)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
USERID(mqbikeusr) UOWLOG( )
UOWSTDA(2019-04-25) UOWSTTI(15.25.13)
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
QMURID(0.3052924) UOWSTATE(ACTIVE)
OBJNAME(UAT.BIKE.POSTER.REQ) OBJTYPE(QUEUE)
ASTATE(ACTIVE) HSTATE(ACTIVE)
OPENOPTS(MQOO_INPUT_SHARED,MQOO_INQUIRE,MQOO_SAVE_ALL_CONTEXT,MQOO_FAIL_IF_QUIESCING)
READA(NO) _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
|
PaulClarke |
Posted: Thu Apr 25, 2019 11:55 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
I am not entirely sure what you are asking. A DISPLAY CONN(*) TYPE(ALL) will return two types of record. A connection record, which tells you the application name, pid, connection id etc. And a number of Handle records - one for each object handle the connection has open. Not surprisingly the Handle records belong to the preceding Connection record.
I have never been a huge fan of the DISPLAY CONN(*) command but it does return some useful stuff. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
|
ankurlodhi |
Posted: Fri Apr 26, 2019 4:41 am Post subject: |
|
|
Master
Joined: 19 Oct 2010 Posts: 266
|
did you try
dis qs() type(handle) all
what does that show. |
|
Back to top |
|
|
ankurlodhi |
Posted: Fri Apr 26, 2019 4:42 am Post subject: |
|
|
Master
Joined: 19 Oct 2010 Posts: 266
|
PaulClarke wrote: |
I am not entirely sure what you are asking. A DISPLAY CONN(*) TYPE(ALL) will return two types of record. A connection record, which tells you the application name, pid, connection id etc. And a number of Handle records - one for each object handle the connection has open. Not surprisingly the Handle records belong to the preceding Connection record.
I have never been a huge fan of the DISPLAY CONN(*) command but it does return some useful stuff. |
i think he is trying to find out how many instances of a channel is connected to the queue and from which server. |
|
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
|
|
|
|