| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RCVR Channel Sequence Numbe is not increasing |
« View previous topic :: View next topic » |
| Author |
Message
|
| nageshshiv |
 Posted: Fri Jan 08, 2010 1:07 am Post subject: RCVR Channel Sequence Numbe is not increasing |
 |
|
Apprentice
Joined: 09 May 2008
Posts: 30
|
Hi All,
Recently we had connectivity test between RCVR & SDR happend during that Both Sender & Receiver did the channel sequence number reset and the channels were in running status . From Next day onwards channels always to Retrying status from Sender . After more than 7 to 10 days observation we found that channel sequence number at the RCVR is never increasing unless manually if RESET Command gives .
The channel sequence number never increases automatically and it is requiring Manual intervention .
We have recreated the channels on both sides but no use .
We have changed the NPMSPEED(FAST) Parameter to NPMSPEED(NORMAL) -(Recommended by IBM MQ Support ) But still there is no use .
RCVR
Name: WebSphere MQ
Version: 6.0.2.2
CMVC level: p600-202-070801
BuildType: IKAP - (Production)
OS : AIX 5.3
SDR
IBM WebSphere MQ for z/OS V6
OS : RELEASE z/OS 01.10.00
Error Logs:
01/08/10 15:24:46 - Process(2889588.1) User(mqm) Program(amqcrsta_nd)
AMQ9526: Message sequence number error for channel 'ME14.R001786'.
EXPLANATION:
The local and remote queue managers do not agree on the next message sequence
number. A message with sequence number 1367 has been sent when sequence number
1337 was expected.
ACTION:
Determine the cause of the inconsistency. It could be that the synchronization
information has become damaged, or has been backed out to a previous version.
If the situation cannot be resolved, the sequence number can be manually reset
at the sending end of the channel using the RESET CHANNEL command.
--------
We did the RESET Both sides SENDER & RCVR .. Channel comes to RETRYING Status after sometime due to No activity channel goes to sleep state when again message comes and about channel start it will throw error ..And everytime it requires Manual RESET .
Pls help
Regards,
Nagesh
|
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jan 08, 2010 5:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
What effect does stopping the SDR and resetting only the SDR have? Is someone/something doing something funny to the SYSTEM.CHANNEL.SYNCQ? Are incremental backups being restored?
As an observation, you are down-level on FixPack on the UNIX end.
_________________
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 |
|
|
| zpat |
| Posted: Fri Jan 08, 2010 5:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Sequence numbers are only incremented for persistent messages under normal circumstances.
Sequence numbers are not checked until you attempt to send a message which increments the sequence number.
This is not a problem or solution, but it may help understand the behaviour.
What I have found helpful is a loopback queue that one end can send a message on to have it sent straightback on another queue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 08, 2010 9:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Recently we had connectivity test between RCVR & SDR happend during that Both Sender & Receiver did the channel sequence number reset and the channels were in running status . |
Working as designed. The two channel ends will not notice your corruption (RESET) of the seqwrap fields until the next message needs to be sent.
| Quote: |
| From Next day onwards channels always to Retrying status from Sender |
.
Again, working as designed, as both ends seqwrap fields do not agree.
| Quote: |
| After more than 7 to 10 days observation we found that channel sequence number at the RCVR is never increasing unless manually if RESET Command gives |
.
I'm presuming that the channels are RETRYING, and that no messages are flowing from SDR to RVCR. Again working as designed. Both ends need RESET for the channel to come back to life.
_________________
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: Fri Jan 08, 2010 9:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Sequence numbers are only incremented for persistent messages under normal circumstances. |
Uh... this seemed odd. I did a quick test of both persistent and non-persistent across FAST channels (irritatingly, the factory initial value for channels). Both incremented ok on both ends.
[edit]
I did the same test (persistent and non-persistent messages) on a NORMAL channel pair, with identical results; namely: sequence increments for each message on both channel ends.
This is all working as designed, isn't it?
MCAs count messages to ensure non are lost (assured message delivery).
RESET issued at the SDR or SVR resets the sequence at both ends; but if RESET is issued at the RCVR end, only the RCVR end is reset.
_________________
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: Fri Jan 08, 2010 10:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Sequence numbers are only incremented for persistent messages under normal circumstances. |
Now I believe I understand this statement. This is the usual misunderstanding is the two sequence fields on the DIS CHS() CURRENT output.
CURSEQNO - For a sending channel, this is the message sequence number of the last message sent. It is updated as each message is sent, and when the channel becomes in doubt it is the message sequence number of the last message in the in-doubt batch.
...
For a receiving channel, it is the message sequence number of the last
message that was received. It is updated as each message is received.
LSTSEQNO - Message sequence number of the last message in the last committed batch. This number is not incremented by nonpersistent messages using channels with a NPMSPEED of FAST.
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
