This is more in Joergen's territory than mine but here goes... I was thinking that you could implement this as a security exit along the lines of BlockIP. Only instead of looking at the conname information, the exit simply opens the XMitQ and looks at the first message. If it's your channel stop message, you delete it and suppress the channel start. As we have seen with BlockIP, suppressing the channel startup in the SCYEXIT does not disable the channel. I *think* triggering would reset at this point and the next message would start the process all over again.
-- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin, Paul Sent: Wednesday, May 12, 2004 9:38 AM To: [EMAIL PROTECTED] Subject: Re: Remote Event Queues and Active Channels Hi T. Rob, I was wondering about an exit. Would it actually work, do you think? I thought it would have to be a message exit which would parse the message and, if it was a start channel event message for the event channel it would shut down the channel without sending on the message. But wouldn't this create another stop channel event and so on with the channel going into a loop (stop channel event; start channel (to send event message); discard event message and stop channel (message exit); stop channel event etc)? Did you have another method in mind? Cheers, Paul -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 12 May 2004 14:21 To: [EMAIL PROTECTED] Subject: Re: Remote Event Queues and Active Channels Paul, How about a channel exit that suppresses the stop messages for this channel? The compromise costs you the stop events for this channel but at least allows it to time out. -- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Meekin, Paul Sent: Wednesday, May 12, 2004 7:02 AM To: [EMAIL PROTECTED] Subject: Re: Remote Event Queues and Active Channels Dave, I think you're right. Thanks for the confirmation, although it seems a bit drastic! Cheers, Paul -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David C. Partridge Sent: 12 May 2004 11:48 To: [EMAIL PROTECTED] Subject: Re: Remote Event Queues and Active Channels I guess the only way round this is to use a local agent to collect events and use an out of band (i.e. non MQ) transport to centralise the event data. I think this is what some of the commercial monitoring products do. Dave 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 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 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
