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
