| Author |
Message
|
| loudcfla |
 Posted: Thu Jul 14, 2005 11:30 am Post subject: Message sequence error on channel |
 |
|
Acolyte
Joined: 05 May 2002
Posts: 58
|
Hi, we recently started getting these messages in the CHIN address space on the Mainframe. I keep resetting the channel but it is no solving the problem. I have a simple point to point config with the Mainframe/CICS on one end and Sun Solaris on the other. I can't find any dup records in the SYNCQ. How do resolve this problem?
SUNTEST.TO.MQT1, sent=3 expected=1
+CSQX599E +MQT1 CSQXRESP Channel SUNTEST.TO.MQT1 ended abnormally
+CSQX500I +MQT1 CSQXRESP Channel SUNTEST.TO.MQT1 started
+CSQX526E +MQT1 CSQXRESP Message sequence error for channel 592 |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Jul 14, 2005 1:28 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| You will need to reset at both ends of the channel, not just the MVS end. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Jul 14, 2005 1:41 pm Post subject: Re: Message sequence error on channel |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| loudcfla wrote: |
Hi, we recently started getting these messages in the CHIN address space on the Mainframe. I keep resetting the channel but it is no solving the problem. I have a simple point to point config with the Mainframe/CICS on one end and Sun Solaris on the other. I can't find any dup records in the SYNCQ. How do resolve this problem?
SUNTEST.TO.MQT1, sent=3 expected=1
+CSQX599E +MQT1 CSQXRESP Channel SUNTEST.TO.MQT1 ended abnormally
+CSQX500I +MQT1 CSQXRESP Channel SUNTEST.TO.MQT1 started
+CSQX526E +MQT1 CSQXRESP Message sequence error for channel 592 |
If this is a Receiver Channel it will need to be reset from the Sender Side.
The SDR should first be stopped
Then run resolve chl(SUNTEST.TO.MQT1) action(backout)
reset chl(SUNTEST.TO.MQT1)
Then just for giggles and grins you can reset the channel on the z/OS side but it's usually not necessary.
-------copy from WMQ Command Reference Guide begin--------------------
2. This command can be issued to a channel of any type except SVRCONN and CLNTCONN channels, (including those that have been defined automatically). However, if it is issued to a sender, server or cluster-sender channel, then in addition to resetting the value at the end at which the command is issued, the value at the other (receiver, requester, or cluster-receiver) end is also reset to the same value the next time this channel is initiated (and resynchronized if necessary).
------copy from WMQ Command Reference Guide end-----------------------
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Jul 14, 2005 8:10 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| If this is a Receiver Channel it will need to be reset from the Sender Side. |
No. If you reset from the Sender side, it will automatically reset the receiver as well. If you know the sequence number of the sender, you can just reset the receiver to match.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Jul 14, 2005 8:36 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| EddieA wrote: |
| Quote: |
| If this is a Receiver Channel it will need to be reset from the Sender Side. |
No. If you reset from the Sender side, it will automatically reset the receiver as well. If you know the sequence number of the sender, you can just reset the receiver to match.
Cheers, |
Eddie, under the circumstances I kinda assumed that, the poster didn't know the CURSEQNO of the Sender. Further from the Channel name I rather gleened that the channel he/she was having problems with was receiver channel. z/OZ MQManager names are limited to four characters.
The Channel name SUNTEST.TO.MQT1 is a rather obvious hint that he is talking about a RCVR Channel and the poster said he/she was seeing this on the error on the Mainframe.
Indeed he can do a reset chl all he wants from the RCVR side. Indeed he actually said he/she did so "I keep resetting the channel but it is no solving the problem" which leads me to believe he does not indeed know the CURSEQNO of the SDR Channel.
Please read the thread before you offer advice or indeed attempt to correct someone who has given valid advice.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Jul 14, 2005 10:26 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I kinda assumed that, the poster didn't know the CURSEQNO of the Sender |
Huh:
| Quote: |
| SUNTEST.TO.MQT1, sent=3 expected=1 |
| Quote: |
| Indeed he actually said he/she did so "I keep resetting the channel but it is no solving the problem" |
Yeah, but the OP didn't say exactly what they were issuing. RESET CHANNEL without SEQNUM defaults to 1, which is exactly what they were seeing.
The quote:
| Quote: |
| If this is a Receiver Channel it will need to be reset from the Sender Side. |
Is not 100% accurate, as the sequence can be corrected from the receiver side. Although, I will admit it is easier from the sender side.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| loudcfla |
| Posted: Fri Jul 15, 2005 7:57 am Post subject: |
|
|
Acolyte
Joined: 05 May 2002
Posts: 58
|
Hello All,
Yes sorry, the message is showing up on the mainframe. Messages come in from the Sun ( our Web enabled app ), to the mainframe ( CICS ), and a reply is sent back. A pair of sender/recvr channles on my side and a pair of sender/recvr channels on the SUN side.
We also see the message sequence number error on the SUN.
I have been issuing RESET with seq number 1, but it only fixes it for a short time.
Any ideas on how I can fix this for good? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 15, 2005 8:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, you are issuing a RESET CHANNEL on both sides for both sender and receiver pairs (four resets in all), and the message sequences get in sync.
Then, later, the channel is out of sync again.
You should see errors that indicate that the channel is failing, and indicate why.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| loudcfla |
| Posted: Fri Jul 15, 2005 8:24 am Post subject: |
|
|
Acolyte
Joined: 05 May 2002
Posts: 58
|
| Actually no I did not. I did a resolve with a backout and a reset with number 1 on the mainframe sender and the SUN sender. I did not do the recvr channels. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 15, 2005 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How do you know you need a resolve with backout and not a resolve with commit once your channel falls into retry mode ?
Looks like you might have some serious network problems.
Enjoy  |
|
| Back to top |
|
|
| loudcfla |
| Posted: Fri Jul 15, 2005 12:39 pm Post subject: |
|
|
Acolyte
Joined: 05 May 2002
Posts: 58
|
Since I did the resolve and the reset, I have not had a message sequence error, and we load tested the app, plenty of messages went back and forth.
Does anyone know how to find out how the messages got out ouf sync?
I'm curious as to why this happened in the first place. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 15, 2005 1:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
as per the manual :
Message sequence can get out of sync if the channel response gets cut off before the sender receives it.
In this case you do not know if the last sequence was committed or rolled back. Only a comparison of the seqnum at both ends of the channel will tell you whether to force the commit or the rollback.
Other frequent reason: User and admin stuff.
If I rebuild a qmgr or channel the channel seqnum are likely not the same....
Enjoy |
|
| Back to top |
|
|
|
|
