| Author |
Message
|
| kun.leeing |
 Posted: Thu Aug 08, 2013 11:20 pm Post subject: Reset channel sequence number |
 |
|
Disciple
Joined: 27 Sep 2008
Posts: 171
|
In what situation does this problem happen? And we need to reset it?
the manifestation is the channel goes into a stopped or retrying status.
So , what's the reason of this problem and how do u guys resolve it?
What I did is just reset and restart the channel by explorer or command, what else actions should I take to solve it permanently?
thanks |
|
| Back to top |
|
 |
| hughson |
| Posted: Fri Aug 09, 2013 12:47 am Post subject: Re: Reset channel sequence number |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| kun.leeing wrote: |
| In what situation does this problem happen? And we need to reset it? |
Something has happened to the channel state at one end or the other. Common cause can be deleting the channel or queue manager at one end and then recreating it. In normal running you should never see this.
The other common cause we hear of that causes this, is using a connection router (for example F5's BigIP) between a sender channel and the receiver channel, and thus running the channel first into one queue manager, then after sending a few batches it gets switched to a second queue manager. This is an unsupported environment so I hope you are not doing this. If you are, let me know and I'll explain more.
| kun.leeing wrote: |
| the manifestation is the channel goes into a stopped or retrying status. |
This is as expected. A sequence number error means something needs to be fixed, and so the channel is no longer running while you fix the issue.
| kun.leeing wrote: |
| So , what's the reason of this problem and how do u guys resolve it? |
Depends on the cause - did either of the above possibilities ring true for you?
| kun.leeing wrote: |
| What I did is just reset and restart the channel by explorer or command, what else actions should I take to solve it permanently? |
Stop doing whatever caused it - so first we must work out what caused it for you.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| pfarrel |
| Posted: Fri Aug 09, 2013 1:54 am Post subject: |
|
|
Centurion
Joined: 16 Mar 2004
Posts: 120
Location: Kansas City
|
We experience this problem when we take our system down, switch our external customers over to our backup site, and start the connections to our external customers from the backup site. The external customers are still "remembering" the sequence numbers from the primary site.
When this happens I usually reset the sequence numbers in our sender channels to 1, and the sequence numbers in our receiver channels to whatever they are sending ( this value appears in a message in AMQERR01.LOG ). |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Aug 09, 2013 2:04 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| pfarrel wrote: |
We experience this problem when we take our system down, switch our external customers over to our backup site, and start the connections to our external customers from the backup site. The external customers are still "remembering" the sequence numbers from the primary site.
When this happens I usually reset the sequence numbers in our sender channels to 1, and the sequence numbers in our receiver channels to whatever they are sending ( this value appears in a message in AMQERR01.LOG ). |
Yup, restoring state to a backed version would do it too.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Aug 11, 2013 3:36 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| pfarrel wrote: |
| We experience this problem when we take our system down, switch our external customers over to our backup site, and start the connections to our external customers from the backup site. The external customers are still "remembering" the sequence numbers from the primary site. |
The sequence number will need to be reset if one of the qmgr changes its network location. Apparently MQ stores IP address as part of the channel synchonization.
| Quote: |
| When this happens I usually reset the sequence numbers in our sender channels to 1, and the sequence numbers in our receiver channels to whatever they are sending ( this value appears in a message in AMQERR01.LOG ). |
Yes. That's the easiest way of doing things, if you don't have access to your external customers system to reset their SDR to 1.
_________________
Glenn |
|
| Back to top |
|
|
| kun.leeing |
| Posted: Sun Aug 11, 2013 6:23 pm Post subject: |
|
|
Disciple
Joined: 27 Sep 2008
Posts: 171
|
Thanks for the replies above.
And Morag, I appreciate for your help.
I'm pretty sure that we never changed our environments at one end or the other and never did changes about Channels.
The problem happens not very often, we can not expect, everything works well for a long time and out of sudden it happens.
I'm not sure if we use any routers or devices in the midst of two remote qmgrs,'cause we can't see it. we just can find the remote qmgr ip and other info from the channel definition of this end. I wonder if it is because of the unsupported environment you mentioned,and I'd really like to know it .
In addition, I thought it over that if the transfer of messages is confirmed and reliable , based on the sequence number, one message with a certain number should be sent after the last message is received certainly by the opposite end with the pre number. if so, how did this happen?
Thanks.
Richard |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 11, 2013 6:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The sequence-wrap field is used by both ends of the channel to keep track of the number of messages transferred. At channel start, the two channel ends compare the contents of the sequence-wrap field values.
If the two ends sequence-wrap values match, the channel will start. If the two ends sequence-wrap values differ, the channel ends are unsure if messages have been lost; and the channel will not start.
Note the channel create and channel alter dates/times at both ends now, and again when next the channel fails due to sequence-wrap mismatch. See if someone/something recreated or altered channel definitions.
Are you at a current version/release of WMQ? Are you at a current maintenance-level?
_________________
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 |
|
|
| kun.leeing |
| Posted: Sun Aug 11, 2013 7:17 pm Post subject: |
|
|
Disciple
Joined: 27 Sep 2008
Posts: 171
|
| bruce2359 wrote: |
The sequence-wrap field is used by both ends of the channel to keep track of the number of messages transferred. At channel start, the two channel ends compare the contents of the sequence-wrap field values.
If the two ends sequence-wrap values match, the channel will start. If the two ends sequence-wrap values differ, the channel ends are unsure if messages have been lost; and the channel will not start.
Note the channel create and channel alter dates/times at both ends now, and again when next the channel fails due to sequence-wrap mismatch. See if someone/something recreated or altered channel definitions.
Are you at a current version/release of WMQ? Are you at a current maintenance-level? |
I'm at WMQ 7 and I also worked with WMQ 6 before, we got similar problem,the difference is at that time, everytime qmgrs were restarted, we had to manually start sender channels, they could not be started automatically,but it's ok in running after that. Now the problem happens unexpectedly, I doubt that temporary network failure leads to the problem and have to reset or restart the problem channel manually. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sun Aug 11, 2013 10:13 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
When you do have the problem what are the two sequence number values?
If they are always very close (ie. within a single batch then that suggests that you have either some form of environmental error or there is a bug in the product. For example, there are (or were) some devices which were not appropriate for a logging device since you could not switch off the write-through cache. It is also possible to get this situation with a channel exit I believe.
If one of the sequence numbers is always 1 then it suggests that you have either deleted and re-defined your channel and/or Queue Manager. The 1 will tell you which one.
If there is always a large gap between the sequence numbers but they are both much greater than 1 then it suggests that you have some sort of backup or redundancy switch going on where you are talking to an old 'alternate' Queue Manager you haven't spoken to for a while. This can be the case in something like an F5 configuration or some sort of takeover scenario.
Cheers,
P.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Aug 12, 2013 3:52 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| gbaddeley wrote: |
| Apparently MQ stores IP address as part of the channel synchonization. |
Not for about 15 years. Since FAP 4 which was V5.0 or V1.2 on MVS, we have used the remote queue manager name instead of the IP address. So unless you are running really back level, the IP address the queue manager is running on is not an issue.
Here's a technote about F5's BIG-IP.
http://www.ibm.com/support/docview.wss?uid=swg21606845
If you are using something like this between senders and receiver and the target queue managers that could be selected are not and image of the same queue manager, e.g. Multi-instance QMgr or an HA image, or a Queue Sharing Group (z/OS only), then you are not supported.
If you could share the sequence numbers that are reported, i.e. copy and paste the error message, we could perhaps offer some more advice.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 12, 2013 3:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| hughson wrote: |
| gbaddeley wrote: |
| Apparently MQ stores IP address as part of the channel synchonization. |
Not for about 15 years. Since FAP 4 which was V5.0 or V1.2 on MVS, we have used the remote queue manager name instead of the IP address. So unless you are running really back level, the IP address the queue manager is running on is not an issue. |
Hi Morag,
If I cleanly shut down a SDR/RCVR channel pair, cleanly shutdown a queue manager, and then save/restore one of the queue managers in the pair to alternative server hardware, start up MQ cleanly, and then start the channels, will they run OK without having to reset the sequence number? (The alternative server will have the same host name, MQ level, OS level etc. as the original server, but its IP address will be different)
As chance has it, I am actually going to do this on the weekend as part of a DR rehearsal test for a major business application.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 12, 2013 3:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you start the sender channel first, and the sender and receiver differ in sequence number, the receiver will reset it's sequence number.
If I recall correctly.
Also, if I recall correctly, both dmpmqcfg and saveqmgr will create mqsc that can reset channel sequences, as well as can preserve existing sequence numbers. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Aug 12, 2013 10:07 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
That is not quite true. Just the act of starting a sender channel will not reset the sequence number, you need to also issue a RESET CHANNEL at the sender end.
Essentially.
1) Issuing a RESET CHANNEL at the sender and then starting the channel will automatically make the receiver channel match the next time the channel starts,
2) Issuing a RESET CHANNEL at the receiver will not have any effect on the sender. You should reset the channel to the number presented by the sender. It is also a race condition since it is not clear which sender you might be talking about since many different QMs can talk to you on the same receiver channel.
It is for these reasons that it is generally recommended that if you do need to reset the sequence numbers you should do so at the sender end if you can.
Cheers,
P.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
