| Author |
Message
|
| George Carey |
 Posted: Thu May 26, 2011 11:11 am Post subject: indeed |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| "Then raise a PMR - ask right out if this is a supported configuration." |
That is the plan ...
OH, Ramires ... you haven't already contacted IBM and asked the support question by any chance have you ??
I think you assumed it was supported because you stated you did not see exclusionary statements in the documentation about it ... but an explicit support statement would be obviously better !
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu May 26, 2011 12:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Its interesting that this works when the destination QMs are 2 different non MI QMs.
Now what happens when you enable the RCVR channel on destination QM1 and now disable the RCVR channel on destination QM2? Can you flop back and forth just as easily?
Otherwise I'm with mqjeff on this one. How do you know the next Fix Pack doesn't "fix" this little feature so that it no longer works as you like, but it otherwise works as advertised with the M.I. QMs?
A PMR is definitely the way to go. The doc will need clarification one way or the other as to whether this can be used for non MI QMs for the destination QM. I suppose the sending QM does not have to be an MI QM in either case.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ramires |
| Posted: Thu May 26, 2011 1:09 pm Post subject: Re: indeed |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| George Carey wrote: |
| OH, Ramires ... you haven't already contacted IBM and asked the support question by any chance have you ?? |
No I didn't open a pmr, it's one option to go.
There is also another option, use the supportpac MR01 that does exactly the same. It's a message exit to change CONNAME based on a list of possible destinations, but its category 2 supportpac.
The session "Ask the Experts" I refereed previously talks about this, the link to mp3 file is this one:
http://public.dhe.ibm.com/software/websphere/techexchange/Mar-30-2011-Robbins.mp3
at 26:32 is the question/answer about this.
_________________
Obrigado / Thanks you |
|
| Back to top |
|
|
| ramires |
| Posted: Thu May 26, 2011 1:29 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
but... listening to all the session , they contradict themselves at 35:51
_________________
Obrigado / Thanks you |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 26, 2011 1:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Its not clear if the question or answer in that mp3 is asking whether the sending QM needs to be M.I., or the receiving QM. Depends what you want to hear I guess.
But this makes it clear that the destination QM needs to be a multi instance QM. Whether this is 100% correct is another matter.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc11040_.htm
Under the section for CONNAME
| Quote: |
| Connection lists are an alternative to queue manager groups to configure connections for reconnectable clients, and also to configure channel connections to multi-instance queue managers. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 26, 2011 1:42 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
This http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzae.doc/ic10120_.htm is the CONNAME reference from the dreaded Info Center.
Connection name (CONNAME)
CONNAME is the communications connection identifier. It specifies the particular communications links to be used by this channel.
It is optional for server channels, unless the server channel is triggered, in which case it MUST specify a connection name.
Specify CONNAME as a comma separated list of names of machines for the stated TransportType. Typically, only one machine name is required. You can provide multiple machine names to configure multiple connections with the same properties. The connections are tried in the order they are specified in the connection list until a connection is successfully established. If no connection is successful, the channel starts retry processing. Connection lists are an alternative to queue manager groups to configure connections for reconnectable clients, and also to configure channel connections to multi-instance queue managers.
--------------------
This seems to imply that connection lists are not just for MI.
_________________
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 |
|
|
| George Carey |
| Posted: Thu May 26, 2011 2:03 pm Post subject: agree |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I read that as well ... boy the INFOCENTER really does suck even worse now then when I last used it ... seems like the format is even more cut up ???
Anyway ... that was my take away as well. I have a PMR on it ... so we'll see.
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 26, 2011 4:18 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Having multiple sender channels (from multiple qmgrs) to a single receiver channel works just fine.
As each new instance of the channel is started, a DIS CHS(receiverchannelname) shows a separate and unique channel status for each connection - each with a unique RQMNAME (to distinguish this channel instance from another qmgrs channel instance).
After a persistent message is put from sender end, and arrives at the receiver end, a DIS CHS on the receiver end shows a unique jobname and UofWid.
Clever, these MCAs.
I don't have a current enough v7 (MI) image to test CONNAME with multiple ip(port)s; but I don't think this will restrict this scenario.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu May 26, 2011 4:22 pm Post subject: Re: agree |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| George Carey wrote: |
... boy the INFOCENTER really does suck even worse now then when I last used it ... seems like the format is even more cut up ???
|
_________________
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 |
|
|
| mqjeff |
| Posted: Fri May 27, 2011 3:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Having multiple sender channels (from multiple qmgrs) to a single receiver channel works just fine. |
Yes, but that is not what we are discussing. We are discussing having a single sender channel talk to multiple receiver channels. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 27, 2011 5:41 am Post subject: Re: cluster over Wan or not |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
From the OP:
| George Carey wrote: |
[/b] Could not under MQ v7 sdr/rcvr channels be defined with alternative destination points being used (e.g. conname ('IP1(p1)', 'IP2(p2)'). |
Did I get lost somewhere here?
_________________
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 |
|
|
| mqjeff |
| Posted: Fri May 27, 2011 5:48 am Post subject: Re: cluster over Wan or not |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
From the OP:
| George Carey wrote: |
[/b] Could not under MQ v7 sdr/rcvr channels be defined with alternative destination points being used (e.g. conname ('IP1(p1)', 'IP2(p2)'). |
Did I get lost somewhere here? |
We are discussing configuring a sender channel to have multiple CONNAMES, each of which resolves to a separate queue manager, and thus a separate receiver.
Receivers don't have connames. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 27, 2011 6:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Isn't that precisely what multiple connames on sdr channels accomplish?
Where have I gone wrong?
_________________
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 |
|
|
| mqjeff |
| Posted: Fri May 27, 2011 6:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
Isn't that precisely what multiple connames on sdr channels accomplish?
Where have I gone wrong? |
Multiple connames on SDR channels are used to talk to Multi-instance queue managers, where a single queue manager exists at more than one network address.
This is entirely different than talking to more than one queue manager.
Multiple connames on SVRCONN/CLNTCONNS are used to provide client failover instead of using a queue manager group where you are not concerned about which queue manager you are talking to.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzae.doc/ic11650_.htm |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 27, 2011 7:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| Multiple connames on SDR channels are used to talk to Multi-instance queue managers, where a single queue manager exists at more than one network address. |
The doc narrative goes on to say:
| Quote: |
| Connection lists are an alternative to queue manager groups to configure connections for reconnectable clients, and also to configure channel connections to multi-instance queue managers. |
This seems to me to imply that the other qmgr doesn't need to have the exact same name.
This also seems to me to broadens the use of multiple connames beyond just MI qmgrs. All that needs to exist is a receiver channel with the same name at the other qmgr(s) - or CHAD.
This seems to me to broaden the definition of client failover a bit, as well, to include recovering a sdr-rcvr channel pair to an alternate qmgr - MI or not, same qmgr name or not.
_________________
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 |
|
|
|
|
