| Author |
Message
|
| John89011 |
 Posted: Tue Oct 20, 2009 11:30 am Post subject: finding a channel |
 |
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Just curious..
Is there a way to find the channel associated with a queue assuming you know the queue name? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Oct 20, 2009 11:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Your documentation?
_________________
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 |
|
|
| Vitor |
| Posted: Tue Oct 20, 2009 11:42 am Post subject: Re: finding a channel |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| Is there a way to find the channel associated with a queue assuming you know the queue name? |
The only queue associated with a channel is a transmit queue that's associated with a sender channel.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Oct 20, 2009 11:43 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
May be you can try this one:
dis conn(*) where(objname EQ <queuename>) channel
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 20, 2009 11:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
May be you can try this one:
dis conn(*) where(objname EQ <queuename>) channel |
I think you mean dis channel(*) etc...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 20, 2009 11:49 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Our app process only needs to know the local qmgr and qname so we only store the qmgr and qname info in our DB. So most of the time it becomes a guessing game as to which channel corresponds to which queue if you're not familiar with the system. We also store the MQ defs but I'd rather get the info directly from MQ. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Oct 20, 2009 12:00 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Do you know whether the app and MQ manager resides on the same machine?. If so, does the app connects in Binding mode or Client mode?.
If the app is connecting via Client mode, it needs a channel name. You should check with MQ Admin and get the channel info. You should hard code or store it in your DB and should not change each time.
Why you are trying to find out the channel name on your own?. It is your MQ Admin's duty to create one and provide it to you sothat you can use it all the time.
Thanks. |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 20, 2009 12:24 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Sam Uppu wrote: |
Do you know whether the app and MQ manager resides on the same machine?. If so, does the app connects in Binding mode or Client mode?.
If the app is connecting via Client mode, it needs a channel name. You should check with MQ Admin and get the channel info. You should hard code or store it in your DB and should not change each time.
Why you are trying to find out the channel name on your own?. It is your MQ Admin's duty to create one and provide it to you sothat you can use it all the time.
Thanks. |
QMGR and App do reside on the same machine, I am not sure how the app connects to the qmgr. We don't have a dedicated MQ Admin so the app folks create MQ defs as needed (I know I know.. that's just part of the problem) so the MQ info is not stored anywhere since it's irrelavant to the app other then qmgr and queue name. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Oct 20, 2009 12:36 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
This looks ugly to me.
If you guys didn't create any new/ specific channel for your app, you can use the default channels to connect to MQ manager
SYSTEM.AUTO.SVRCONN or SYSTEM.DEF.SVRCONN ( assuming the MCAUSER on thse channels is empty and you are not concerned about the secure environment).
Thanks. |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 20, 2009 12:39 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Sam Uppu wrote: |
This looks ugly to me.
If you guys didn't create any new/ specific channel for your app, you can use the default channels to connect to MQ manager
SYSTEM.AUTO.SVRCONN or SYSTEM.DEF.SVRCONN ( assuming the MCAUSER on thse channels is empty and you are not concerned about the secure environment).
Thanks. |
Yea, I think we use the default channels to connect to qmgr |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Oct 20, 2009 12:39 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
If the app connects locally then it doesn't even use a channel.
The local queue definition of the remore queue will have (hopefully) the name of a transmission queue. That transmission queue will be defined in a sender channel definition somewhere.
*edit* I see it is client attaching so the application should define the channel name somewhere (or use the MQServer setting, or a channel table) |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 20, 2009 12:48 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| kevinf2349 wrote: |
If the app connects locally then it doesn't even use a channel.
The local queue definition of the remore queue will have (hopefully) the name of a transmission queue. That transmission queue will be defined in a sender channel definition somewhere.
*edit* I see it is client attaching so the application should define the channel name somewhere (or use the MQServer setting, or a channel table) |
We usually define the non clusterd ones as follows:
DEFINE CHANNEL(A.B) CHLTYPE(SDR) DESCR('SENDER CHANNEL FOR B') CONNAME('1.1.1.1(1234)') XMITQ(XXX) TRPTYPE(TCP) BATCHSZ(50) SHORTRTY(60) SHORTTMR(120) LONGRTY(999999999) LONGTMR(1200) CONVERT(YES) DISCINT(0) HBINT(300) REPLACE
DEFINE CHANNEL(B.A) CHLTYPE(RCVR) DESCR('RECEIVER CHANNEL FOR B') HBINT(300) MAXMSGL(4194304) TRPTYPE(TCP) REPLACE
DEFINE QLOCAL(XXX) MAXDEPTH(100000) DESCR('XMITQ FOR XXX') DEFBIND(OPEN) DEFSOPT(SHARED) DEFPSIST(YES) GET(ENABLED) PUT(ENABLED) MAXMSGL(4194304) MSGDLVSQ(PRIORITY) SHARE USAGE(XMITQ) REPLACE
DEFINE QLOCAL(A.B.RESP.QL) DESCR('LOCAL QUEUE FOR B') SHARE GET(ENABLED) PUT(ENABLED) MSGDLVSQ(FIFO) MAXMSGL(4194304) USAGE(NORMAL) TRIGDPTH(1) QDEPTHHI(80) QDEPTHLO(20) DEFBIND(OPEN) DEFPSIST(YES) MAXDEPTH(100000) REPLACE
DEFINE QREMOTE(A.B.REQ.QR) DESCR('REMOTE QUEUE FOR B') RQMNAME(XXX) RNAME(B.A.REQ.QA) XMITQ(XXX) DEFPSIST(YES) REPLACE
DEFINE QALIAS(A.B.REQ.QA) DESCR('ALIAS QUEUE FOR B REQUESTS') TARGQ(A.B.REQ.QR) DEFBIND(OPEN) DEFPSIST(YES) GET(ENABLED) PUT(ENABLED) REPLACE
DEFINE QALIAS(A.B.RESP.QA) DESCR('ALIAS QUEUE FOR B RESPONSES') TARGQ(A.B.RESP.QL) DEFBIND(OPEN) DEFPSIST(YES) GET(ENABLED) PUT(ENABLED) REPLACE |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 20, 2009 12:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| Our app process only needs to know the local qmgr and qname so we only store the qmgr and qname info in our DB. So most of the time it becomes a guessing game as to which channel corresponds to which queue if you're not familiar with the system. We also store the MQ defs but I'd rather get the info directly from MQ. |
In terms of connection, there's no correlation between the channel the app is using and the queue the app is using. So your guessing game is slightly futile as you can tell all you can tell from the app details in your database.
And you shouldn't be using the default SYSTEM objects.
The question becomes what information are you actually trying to obtain and why.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 20, 2009 12:58 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Vitor wrote: |
| John89011 wrote: |
| Our app process only needs to know the local qmgr and qname so we only store the qmgr and qname info in our DB. So most of the time it becomes a guessing game as to which channel corresponds to which queue if you're not familiar with the system. We also store the MQ defs but I'd rather get the info directly from MQ. |
In terms of connection, there's no correlation between the channel the app is using and the queue the app is using. So your guessing game is slightly futile as you can tell all you can tell from the app details in your database.
And you shouldn't be using the default SYSTEM objects.
The question becomes what information are you actually trying to obtain and why. |
For example...
We queue up a request and we don't get a response back.. so we want to check the sender/receiver status...
or
Some app calls stating they are not getting responses back from us "can you please check your sender channel"
or
the queue sequence is out of whack.. "can you please reset your channel" etc.... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 20, 2009 1:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
We queue up a request and we don't get a response back.. so we want to check the sender/receiver status...
or
Some app calls stating they are not getting responses back from us "can you please check your sender channel"
or
the queue sequence is out of whack.. "can you please reset your channel" etc.... |
All of these touch back my original post - the only hard link is between a sender channel and a transmission queue. Once you put a message on a remote queue only the admin knows the route it will take.
The scenarios you describe are depressingly familiar to all of us, and often have nothing to do with WMQ setup or channel status. 
Also there's no such thing as queue sequence. There is channel sequence, it has nothing to do with message delivery sequence, and even in dev channels should not need reseting.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
