Scott, You're fairly close. When we did clustering we decided not to check the sequence numbers for cluster channels. The reason being that
a) Sequence numbers are not required for reliable message delivery since that uses the LUWID b) With cluster channels we can not be certain that channels have not been deleted and recreated since the last time the channel ran. However, for normal Sender/Receiver channels we still do check whether the sequence number of a passed message is the one we expected. If not, you should ensure you know the reason why (deleted channel/queue manager - re-reouted channel etc) and issue a RESET channel. Cheers, P. Paul G Clarke WebSphere Messaging Clients IBM Hursley MQSeries List <[email protected]> wrote on 14/07/2005 16:31:12: > This occurs when the channel agents begin their negotiation process (to > establish the connection) - driven by the active participant (ie. the SENDER > channel) initiating a 'start channel'. The sequence number is checked at > this point. It used to be that if this number did not match, the channel > stayed in a 'binding' state, and required you as an administrator to do a > 'reset' of the channel. I believe that IBM changed the logic at this binding > stage, to disregard the sequence number and simply 'reset' the channel > sequence number (on the passive agent end) to whatever the sender channel > belives the sequence number to be. > > Paul Clarke, or another IBM'er on here can likely comment on the internals > of this better than I can, but I think I've generally got the idea here... > > Scott. > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of > Emile Kearns > Sent: Thursday, July 14, 2005 1:31 AM > To: [email protected] > Subject: Re: Channel status question > > To quote you "receiver channel simply obligates the sender channel and sets > its sequence number to match that of the sender channel". > Would you mind ellaborating on this, where and how this is done? > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of > Scott Meridew > Sent: Wednesday, July 13, 2005 4:12 PM > To: [email protected] > Subject: Re: Channel status question > > > Back in earlier version of MQ, (5.0?5.1?), the sequence numbers used to = go > out of sync in these situations. However, I think this was changed in = 5.2, > where the receiver channel simply obligates the sender channel and sets = > its sequence number to match that of the sender channel.=20 > > Does stopping and starting your sender channel on the windows box help? > > Scott Meridew. > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On = Behalf > Of Potkay, Peter M (ISD, IT) > Sent: Thursday, July 07, 2005 8:20 PM > To: [email protected] > Subject: Re: Channel status question > > Don't know the answer on how to solve your problem, but I can tell you = its > not normal. Our MFs get IPLed at least every other weekend, and we never > have a problem with sequence numbers to our Windows QM. > > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf = > Of [EMAIL PROTECTED] > Sent: Thursday, July 07, 2005 6:25 PM > To: [email protected] > Subject: Re: Channel status question > > > Sorry, I was out for the holidays. > > The queues are defined as non-persistent and the channel is = > NPMSPEED(FAST). > > I am sending data from a Win2003 Server MQ 5.3 CSD 7 to the mainframe > running z/OS 1.4 MQ 5.3.1. On Saturday night all Win2003 servers are = > cycled (using start --> shutdown --> restart) and both the curseqno on the = > sender > (Win2003 server) and the receiver (mainframe) are still in sync. Then = the > mainframe is cycled, with respect to mq on the mainframe, the queue = > manager is stopped, the mainframe is IPLed and the queue manager is > restarted. = Now the curseqno is out of sync and the curseqno on the > mainframe receiver channel is much higher then what the curseqno on the > sender channel = which has not changed. > > I have an open PMR ticket with IBM but no body has gotten back with me = on > this issue yet. Am I crazy or is this how it is suppose to work? And = are > nine other identically configured servers not having a sequence number > problem configured wrong? > > Doug > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On = Behalf > Of Hubert Kleinmanns > Sent: Monday, July 04, 2005 5:36 AM > To: [email protected] > Subject: AW: Channel status question > > > Doug, > > do you have non-persistent messages and are the channels defined with > NPMSPEED(FAST)? I found, that for non-persistent in this case the = counter > CURSEQNO increases, but not the counter LSTSEQNO. When you stop and = start > the channel again, the counter CURSEQNO decreases to the value of the > counter LSTSEQNO. This works as designed, because NPMSPEED(FAST) means, = > that non-persistent messages are not committed by the receiver channel. > > Regards > Hubert > > > > -----Urspr=FCngliche Nachricht----- > > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im = > Auftrag > > von [EMAIL PROTECTED] > > Gesendet am: Donnerstag, 30. Juni 2005 23:34 > > An: [email protected] > > Betreff: Channel status question > >=20 > > Is there a way to determine the current sequence number for a > >channel=20 that is stopped or inactive. If I issue dis > >chs(Channel-Name)=20 curseqno when the channel is active it works > >fine. But we have our=20 channels disconnect interval set at 1200 and > >if there are no messages=20 folowing, I have to start the channel > >manually first before I get a=20 valid response from the chs request to > find out the sequence number. > >=20 > > What happened was our channel sequence numbers got way out of sync=20 > >(sending 1240 when the receiver was expecting 9546) and the=20 > >application shut down because no messages were getting through. So > >I=20 put together a little script that runs every 15 minutes that > >starts=20 the channel and then display the curseqno on both sender > >channel and=20 receiver channel. Unfortunately, I don't know if I > >need to start the=20 channel or not and an exception is logged when I > >try to start an=20 already "started" channel. > >=20 > > As I have been monitoring this problem, I have seen the curseqno count > >= > > > increase over time from 28 to 59 to 128 on up with the sender and=20 > > receiver channels in sync. Then I see the sequence number drop > > from=20 1600 to 1280 (still in sync) with no exceptions being logged > > anywhere. = > =20 > > > The application does not car and MQ doesn't seem to car. MQ just=20 > > keeps on working. Until some point when the sequence numbers get > > out=20 of sync and then the channel shuts down -- which I am sure > > most of us = > > > have experienced. This problem is unique to this machine which is=20 > >identical to 3 other servers running at the remote site and 5 other=20 > >systems running where I am located. Does anyone have a suggestion? > >=20 > > Doug > >=20 > > Instructions for managing your mailing list subscription are > >provided=20 in the Listserv General Users Guide available at > >http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in = > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in = > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > *************************************************************************= > > PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, = is > for the exclusive use of addressee and may contain proprietary, = > confidential and/or privileged information. If you are not the intended > recipient, = any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the = sender immediately by return e-mail, delete this communication and > destroy all copies. > *************************************************************************= > > > Instructions for managing your mailing list subscription are provided in = > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in the > Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > ----------------------------------------------------------------- > ATTENTION: > The information in this electronic mail message is private and confidential, > and only intended for the addressee. Should you receive this message by > mistake, you are hereby notified that any disclosure, reproduction, > distribution or use of this message is strictly prohibited. Please inform > the sender by reply transmission and delete the message without copying or > opening it. > > Messages and attachments are scanned for all viruses known. > If this message contains password-protected attachments, the files have NOT > been scanned for viruses by the ING mail domain. > Always scan attachments before opening them. > ----------------------------------------------------------------- > > Instructions for managing your mailing list subscription are provided in the > Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
