??? There is nothing to do.
You cant browse the message. If you bounce the channel, its still there. If you stop the channel, you cant clear the queue. If you try and resolve the channel with either a commit or back out, it does nothing. There are no outstanding units of work. Who knows if its even a real message? -----Original Message----- From: Awerbuch, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Peter, Once you get messages stuck in your XMIT queues, what do you have to do to get them to flow again? I can't imagine you just leave them there until they start to flow again on their own, that makes no sense and would not work for most business environments where message content is of a timely (read that as 'immediate') nature. Dave A. -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:39 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in cluster transmit queue Messages stuck on CLUSTER TRANSMIT queues is a problem that has been kicking around for a while. There are a few post on mqseries.net about this. If you go to www.mqseries.net, and do a search on "TRANSMIT" and or "STUCK", while pointing your search at the Cluster forum, you'll get a few hits. I'd post a solution common to them all, but there doesn't see to be one, other than upgrade. Yet I am at 5.3 CSD04, and 2 of my queue managers get messages stuck in their XMIT queues for days at a time. Weird. Annoying. -----Original Message----- From: Lovett, Alan J [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Messages stuck in cluster transmit queue Hi, We have a problem on our systems that I hope someone might be kind enough to respond to. We are well stuck! We have an up till now stable system where central servers on OS/390 write persistent messages across a set of remote Windows queue managers. All the systems are 5.2. The target queues are clustered aliases, one per remote, each uniquely named, and resolving to a local queue. The situation as I write is that significant numbers of messages are stuck on one of the z/OS systems SYSTEM.CLUSTER.TRANSMIT.QUEUE. The cluster channel is running, the cluster has been refreshed at both ends, no in-doubt is reported. The source can open the target queue, the channel (both ends) reports a 'SAVED' status.and yes, I did say please! My suspicion is that the size of the unit of work exceeds the receiving system's capacity, but we did redefine the system some months ago, to increase the logs well in excess of what we believe to be demanded of it. We are hounding our user to get some figures from them. Can anyone suggest what might be causing the problem, or how to increase our understanding of it? Many thanks in advance of your charity. Regards, Alan *** Credit Lyonnais **************************************************** This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais **************************************************** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential 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 email and 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://vm.akh-wien.ac.at/MQSeries.archive
