| Author |
Message
|
| mvic |
 Posted: Thu Jun 30, 2011 1:34 pm Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ankurlodhi wrote: |
| how is it configured that we can use 10 channel instances? |
A quick Google search found this: "Maximum instances (MAXINST)" http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzae.doc/ic11793_.htm
I have not used it myself, but it looks like the thing you are looking for.
There is also a queuemanager-wide limit. Search the MQ Information Center (a link to the V6 version is near the top of the page) for MaxActiveChannels. |
|
| Back to top |
|
 |
| ankurlodhi |
| Posted: Thu Jun 30, 2011 1:35 pm Post subject: |
|
|
Master
Joined: 19 Oct 2010
Posts: 266
|
this is what i get when i type the command dis chs(*)
dis chs(*)
1 : dis chs(*)
AMQ8417: Display Channel Status details.
CHANNEL(main.to.a) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.b) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main .to.c) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.a) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.b) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL() XMITQ( )
CONNAME(main.to.b) CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.c) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.b) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( )
AMQ8417: Display Channel Status details.
CHANNEL(main.to.b) XMITQ( )
CONNAME() CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
RQMNAME( ) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 30, 2011 1:45 pm Post subject: Re: multiple instance of same channel on same MQ box |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| ankurlodhi wrote: |
suppose the Server name is "MAIN"
|
Do you mean that you have a queue manager named 'MAIN'?
And that you have several CLNTCONN channels (or you use MQSERVER= using the same channel names) to the single qmgr named MAIN?
And you see multiple instances of the same channel name(s)?
This is normal. It indicates that you have multiple client apps using the same channel name concurrently. Each new instance of the client app creates another instance of the SVRCONN channel.
One SVRCONN channels can support many separate client instances.
Have I misunderstood your issue?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 30, 2011 3:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ankurlodhi wrote: |
| vitor : the server connection channel from A,B,C has there respetive IP address so the conname is different but all the channel form A are identical with the same conname , and same applies for B and C |
In your original post (which like a fool I was using as a basis for my comments) you described the channels as CLIENT.TO.MAIN, which would all have the same conname, that of MAIN.
In the command output you've posted, the channels are named main.to., main.to.b & main.to.c which of course have 3 different connames if that really is the direction they're running.
Though this of course begs the question why is the central server establishing a client connection to the clients....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 30, 2011 3:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
As we've seen here many times, channel names don't need to make sense. And clients don't need to use the same conname, as there can be multiple listeners.
And then there's the qmgr attribute CHAD, which allows for any channel name at the client-end to connect to an automatically-defined SVRCONN channel with the exact same name.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| ankurlodhi |
| Posted: Thu Jun 30, 2011 4:00 pm Post subject: |
|
|
Master
Joined: 19 Oct 2010
Posts: 266
|
i am sry for creating a confssion with the channel name . Now i will give the whole descrition in proper manner
When i give the command
Dis chs(*)
It give me 10 instances of single channel from 3 diff systems.
The channel table file is being used for this.
I came to understand this after discussing with u guys. So my appologies for not stating the problem proprly.
Now the main thing is how is this happening |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jul 01, 2011 12:23 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ankurlodhi wrote: |
| Now the main thing is how is this happening |
You have several clients connecting with the same CLNTCONN/SVRCONN channel name, that's all.
Or is there something more to this? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 01, 2011 12:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| ankurlodhi wrote: |
| ...Now the main thing is how is this happening |
Because you have three different SVRCONN channels, not one? And because you have three different CCDT files, not one? What does the output of dis chl(*) type(svrconn) show?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| ankurlodhi |
| Posted: Fri Jul 01, 2011 4:08 am Post subject: |
|
|
Master
Joined: 19 Oct 2010
Posts: 266
|
the command dis chl(*) type(svrconn)
gives the below result.
DIS CHANNEL (*) TYPE (SVRCONN)
5 : DIS CHANNEL (*) TYPE (SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(CLIENT.TO.main)
AMQ8414: Display Channel details.
CHANNEL(CLIENT.TO.main.ssl)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.ADMIN.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.AUTO.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SVRCONN) |
|
| Back to top |
|
|
| ankurlodhi |
| Posted: Fri Jul 01, 2011 4:13 am Post subject: |
|
|
Master
Joined: 19 Oct 2010
Posts: 266
|
as you said I might be having 3 different svrconn channel. so had taken a look at all the channel
there i found that the channel (client.to.main.ssl) is the single channel whose instances are showing there which are being used by the server A,B,C
so I guess we have 10 instances of once single channel not 3 diff server connection channel. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 01, 2011 4:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You appear to have two different application-related SVRCONNs, 'CLIENT.TO.main' and 'CLIENT.TO.main.ssl' (why the mixed-case is beyond me) in your display channel output, yet you also have 'main.to.a', 'main.to.b', 'main.to.c', and 'main .to.c' in your display channel status output.
Please explain why you think one particular SVRCONN is being used, and clarify the version of WMQ being used (including FixPack level) and the platform that hosts the queue manager.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| ankurlodhi |
| Posted: Fri Jul 01, 2011 4:40 am Post subject: |
|
|
Master
Joined: 19 Oct 2010
Posts: 266
|
when i give the command dis chs(*) all the instances i get to c has the channel name client.to.main.ssl
the other channel client.to.main is not being used, dont know y.
and please neglect that
'main.to.a', 'main.to.b', 'main.to.c', and 'main .to.c'
consider them all as client.to.main.ssl |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 01, 2011 4:58 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| ankurlodhi wrote: |
when i give the command dis chs(*) all the instances i get to c has the channel name client.to.main.ssl
the other channel client.to.main is not being used, dont know y.
and please neglect that
'main.to.a', 'main.to.b', 'main.to.c', and 'main .to.c'
consider them all as client.to.main.ssl |
On one of my test systems I get the following output for channel status:
| Code: |
dis chs(*)
2 : dis chs(*)
AMQ8417: Display Channel Status details.
CHANNEL(JAVA.NO.SSL) CHLTYPE(SVRCONN)
CONNAME(127.0.0.1) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE) |
And for channels of type SVRCONN:
| Code: |
dis chl(*) type(svrconn)
3 : dis chl(*) type(svrconn)
AMQ8414: Display Channel details.
CHANNEL(JAVA.NO.SSL) CHLTYPE(SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(JAVA.SSL) CHLTYPE(SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) |
Note the channel name, which is exactly the same as the CLNTCONN definition contained within the CCDT, appears in both display commands. I cannot reconcile your two different display results, i.e. channels running bear no relation to those defined. Are you sanitising the output in any way? If so then please state you are doing so. And please answer my previous question in regard to WMQ version etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jul 01, 2011 5:16 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ankurlodhi wrote: |
| the command dis chl(*) type(svrconn) |
You were asking about DIS CHS.
(UPDATE: Just spotted that this was in answer to exerk; still it is not clear what the point is, when it is DIS CHS that was/is the problem)
Are you now OK with the answers about why you got multiple entries in the DIS CHS output?
If so, what is the new problem?
Last edited by mvic on Fri Jul 01, 2011 5:21 am; edited 1 time in total |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jul 01, 2011 5:17 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ankurlodhi wrote: |
| consider them all as client.to.main.ssl |
Why?
Why consider them as something they are not?
I am really confused by what problem you are now having. Maybe it is time to begin a new thread, and re-state your problem.
Hope this helps |
|
| Back to top |
|
|
|
|
