Author |
Message
|
WBI_user |
Posted: Wed Sep 17, 2014 6:52 am Post subject: channel sequence number and conname |
|
|
Partisan
Joined: 07 Aug 2001 Posts: 386
|
This is for my learning purpose. My understanding all along is sending MCA and receiving MCA keep track of sequence number. The sequence number must match up otherwise we will get error
AMQ9526 Message sequence number error for channel QM_A-to-QM_B
I think in V7 of MQ we can define more than 1 IP(port#) in conname for the sender channel and the documentation is updated by
IV01566: WEBSPHERE MQ V7 DOCUMENTATION FOR SENDER CHANNEL ATTRIBUTE CONNAME NEEDS CLARIFICATION FOR MULTIPLE VALUES.
What I like ot understand is when I have 3 Qmgrs (QM1,QM2,QM3) and have a sender channel from QM1 specifying IP of QM2 and QM3 how does the sequence number when the connection is switching from QM2 to QM3
For example, asume that all qmgrs are listening of default port 1414
DEF CHL(QM1.QM) CHLTYPE (SDR) TRPTYPE(TCP) CONNAME(IPQM2,IPQM3) XMITQ(QM)
When I start the channel if QM2 is running, the channel will be established between QM1 AND QM2 and messages will start flowing between QM1 AND QM2 and sequence number will be remembered by both QM1 AND QM2.
The channel is shut down normally and start again later. At this time QM2 is down, so the channel will be established between QM1 and QM3.
IV01566 only says that there will be problem , if the channel is in doubt. It seem to indicate that the channel will start with QM3 with no problem.
How does QM3 match the sequence number ? Is there a change in V7 that the sequence number will reset automatically ?
The in doubt situation mentioned in IV01566 has to be dealt with anyway even if we only have 1 qmgr IP in conname.
Can some one help me to understand how this works or point me to docs which contains more detail. |
|
Back to top |
|
 |
exerk |
Posted: Wed Sep 17, 2014 7:11 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
It is my understanding that chaining CONNAME values is for Multi-Instance queue managers, not for 'poor mans' fail-over, which is what you're implying you're doing. If that is the case you are in for a whole world of hurt and I strongly advise you stop doing it - now. _________________ 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 |
|
 |
WBI_user |
Posted: Wed Sep 17, 2014 8:21 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001 Posts: 386
|
I agree with you exerk. This is my understanding too. However IV01566 is not specific on if multiple conname entries is for MI qmgr only (even that APAR is suppose to clear up the confusion).
I just tested on on my Windows MQ ( all 3 QM on different ports 1414,1415 and 1416) and the channel QM1 TO QM3 starts OK (no complain on sequence number) after a number of messages exchanged on channel between QM! and QM2.
Yes, some one in my account is pushing for "poor mans' fail-over," I am looking for IBM docs to help me to say NO. |
|
Back to top |
|
 |
exerk |
Posted: Wed Sep 17, 2014 9:17 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
WBI_user wrote: |
Yes, some one in my account is pushing for "poor mans' fail-over," I am looking for IBM docs to help me to say NO. |
Easy - raise a PMR with IBM asking the question, i.e. can I use this as a supported method for 'failing' over to an alternative queue manager? Supported meaning that if you use this method, and a major failure occurs, e.g. 'lost' messages, that when they finish laughing their answer is "...computer says no...". Of course, they might say yes, one just never knows with Big Blue. _________________ 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 |
|
 |
JosephGramig |
Posted: Wed Sep 17, 2014 12:30 pm Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
No. Multiple hosts in CONNAMEs is for Multi Instance Qmgrs only. If you read the manual, you will see that all references to multiple hosts in the CONNAME are associated with the topic MI. This goes for port numbers too.
Think about it. It is the same Qmgr being started on another host. That means the same LISTENERs will be started there too. The same message count on the channel will be there too because it is the same Qmgr.
Multi Instance Qmgrs are the "poor mans" HA. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Sep 17, 2014 3:08 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Joseph, I agree with you.
But take a look at this:
http://www-01.ibm.com/support/docview.wss?uid=swg1IV01566
Quote: |
Connection lists may be used
- as an alternative to queue manager groups to configure
connections for reconnectable clients
- to configure channel connections to multi-instance queue
managers
- to configure channel connections to different queue managers.
|
channel connections to different QMs?
How can that be? Why wouldn't there be Channel Sequence Number errors? And WBI_User's expirence doing something us "experts" would not even consider doing seems to show it works and there are no sequence number errors.
 _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Sep 18, 2014 5:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
The referenced document does not explicitly specify the context of the connection:
Client to qmgr
qmgr to qmgr...
My first thought was that that document was geared towards a client to qmgr approach...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Sep 18, 2014 5:46 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
fjb_saper wrote: |
The referenced document does not explicitly specify the context of the connection:
Client to qmgr
qmgr to qmgr...
My first thought was that that document was geared towards a client to qmgr approach...  |
That's the question I suppose. But the last paragraph of that link is talking about in doubt channels. Since MQI channels can't be in doubt, I assumed the article was talking about QM to QM channels as well as client channels. And the first paragraph specifically mentions a Sender channel.
Ironic that a technote produced specifically to clear up confusion in the manuals is not clear. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|