The Xron product seems rather "fragile" in use. That is, if things go wrong when an Xron DTML Method is triggered, that method doesn't get rescheduled. An example of this is that my intranet DNS server needed to be rebooted. Xron couldn't look up the appropriate domain name, and stopped working. ------ 2000-10-11T08:16:34 PROBLEM(100) Products.Xron.Loggerr Trigger event: http://my.development.server:4080/my_xron_method Trigger time: 2000/10/11 09:14:00 GMT+1 Failed to trigger event. Type=bci.NotAvailable Val=host not found (File: http://my.development.server/my_xron_method/trigger Line: []) None None for None ------ 2000-10-11T08:19:04 PROBLEM(100) Products.Xron.Loggerr Failed to disarm event Also, if something bad happens in the Dispatcher thread, the thread dies. Before I leap in and start patching Xron, I'd like to have a discussion about how Xron should handle problems. My first thought is that on errors in the dispatcher thread, Xron should enter an "error state" where it probes every so often to see whether it can resume normal operation. The length of time between probes could increase with each probe, to give good performance with transient problems whilst preventing Xron from choking resources. -- Steve Alexander Software Enigneer Cat-Box limited http://www.cat-box.net