The first thought that comes to mind is to use channel switching. Define an alternate channel for the same XMIT queue. Then there are several ways you can administratively or programmatically switch over.
> -----Original Message----- > From: Wes Ramsdale [SMTP:[EMAIL PROTECTED]] > Sent: Monday, February 10, 2003 8:36 PM > To: [EMAIL PROTECTED] > Subject: Removing Items from a Transmission Queue > > I am looking for a way to remove messages from a transmission queue after a period >of time. > Does anyone have any ideas on how to accomplish this? > We have multiple methods of delivery of data to a remote site. If for some reason >the path > from the local MQ to the remote box is down, I want a mechanism whereby the message >times out, > is removed from the tranmission queue, and returned to the manframe to be delivered >via the alternate method. > Any help would be greatly appreciated. > Please see the copy of a message sent to a co-worker describing my attempts so far >below: > > I have tried 3 different methods to implement timeout extraction from a tranmission >queue. > All have failed. > > 1) Scan the transmission queue and remove entries older than x minutes. > > This sort of worked but there were several problems. MQ inhibits GETs on a >transmission > queue by default. Even if you enable them, MQ periodically re-inhibits GETS. To >get around this > I set up an independent NT Service that once a minute requested GETs to be >allowed on the transmission > queue. This worked but is kludgey and after a few days of running would end up >with some > MQ resource failure error and stop working requiring manual reboot of the box. > > 2) Use the Message Retry exit. > > After making the necessary software changes, it was discoverd that MQ does not >suppport this > under the Windows environment. > > 3) Use the MQMD.Expiry parameter to cause the message to expire after a specified >number of seconds. > > There were several problem with this approach. The check for expiration only >occurrs during a GET request, > so a service had to be written to periodically do a non-destructive browse of >the queue. > As in 1) above, GETs are inhibited by default and get re-inhibited regularly. >Plus there seems to be a security issue with this. > A REPORT was requested to be sent to a differnet queue, but every attempt to do >so resulted in an NT security failure. > > Any help/ideas would be greatly appreciated. > > Wes Ramsdale > Kleinschmidt Inc > [EMAIL PROTECTED] > > 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 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
