The cure for this ended up being pretty simple. We deleted the escalation in question. Then we re-imported a copy of it and assigned that copy to the pool the deleted one had been assigned. After a server bounce it worked. WHY it wouldn't work before is still a mystery. We did compares on the non-working one and the working ones and there was no difference. My only assumption was some kind of database corruption. Normally troubleshooting that would have been a pre-breakfast activity but this system was covered by SOX so it took 7 separate documents and approvals to make that change. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056
________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of cpgold Sent: Tuesday, May 25, 2010 4:18 PM To: arslist@ARSLIST.ORG Subject: Re: Escalation refuses to run ** Copy this escalation to a new escalation and rename it without the underscore _, disable the original. On Tue, May 25, 2010 at 9:52 AM, William Rentfrow <wrentf...@stratacominc.com> wrote: ** I'm baffled. Tech support at BMC seems baffled as well. The OOB escalation for SLM is named SLM:EventSchedule:TAD_PollingEscalation. It has not been modified at all except for the thread/pool changes noted below. It is an interval escalation set to 5 minutes. It refuses to fire however. There is simply no mention of it in the logs. Ever. We'd added a dedicated thread - in fact, we have 6 escalations threads/pools. #6 is dedicated solely for this escalation - nothing else is on it. Escalation logging shows all the other escalations working correctly. But for some reason Pool 6 is never mentioned in the logs and the escalation named above is nevere mentioned. There is no message saying the escalation is disabled - there's nothing saying it is computing the next fire time - it is literally as if this escalation doesn't exist as far as the server is concerned. Suggestions? So far we have... -bounced the server. Repeatedly. -thread level logging -every other kind of logging imaginable -restricted pool to this single escalation -verified pool configuration, etc -verified server licensing, etc. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Corporate Website, www.stratacominc.com <http://www.stratacominc.com/> Blog, www.williamrentfrow.com <http://www.williamrentfrow.com/> 715-410-8156 C _attend WWRUG10 www.wwrug.com <http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
