Chris, I'm not at all surprised that Gary was able to provide a quality solution, but if I may clarify for a moment, I don't think many (if any) of us are displeased with the support that the "old-timers" like Gary give us - it's usually stellar. It's the offshore people that are hit and miss, and are the source and direction of our ire.
Just want to be sure it's clear that we know who and where the good techs are, and we value them as highly as you do. Thanks for sharing the solution with all of us. Rick On 10/4/07, Pickering, Christopher <[EMAIL PROTECTED]> wrote: > > ** Ladies and Gentlemen, > > For future reference, if your system is included in a Server Group AND > your escalations start acting particularly obnoxious (duplicate tickets, > multiple TID's, etc) - Thad identified that aspect - there is no way to > "turn off" escalations are you normally would in the admin tool using the > "disable escalations" switch. To accomplish this feat all you need to do is > arsignal -e [servername] on the primary server running the escalations and > presto its fixed. This command recaches escalations. The fix was ultimately > offered by Gary Reif in BMC Technical Support. I fully believe that > credit should be given when they do well considering all the blasting they > take at other times. Thank you Thad and Joe D'Souza (keep drinking that > caffeine) for your patience and suggestions. > > Chris P > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Thad K Esser > *Sent:* Tuesday, October 02, 2007 4:57 PM > *To:* [email protected] > *Subject:* Re: Escalation creating dup tickets > > > > Chris, > > I haven't followed this whole thread, so I apologize if I missed > something, but is there only one TID (thread id) in your escalation log? > I've had situations on an unpatched 6.3 server where "ghost" escalation > threads would show up. Escalations would appear to fire twice on the same > data and the only evidence was multiple thread id's in the escalation logs. > > The fix was to disable escalations in server settings (stops all the > escalation threads), and then re-enable them. I never tracked down what > caused it, but the problem went away with a later patch (20, I think). > > *Thad Esser* > Remedy Developer > "*Argue for your limitations, and sure enough, they're yours."*-- Richard > Bach > > > *"Joe D'Souza" <[EMAIL PROTECTED]>* > Sent by: "Action Request System discussion list(ARSList)" < > [email protected]> > > 10/02/2007 01:17 PM Please respond to > [email protected] > > To > [email protected] cc > Subject > Re: Escalation creating dup tickets > > > > > ** > I noticed duplicate actions but actions with no mappings on them.. I was > wondering what was with that too.. > > *Joe D'Souza* > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher* > Sent:* Tuesday, October 02, 2007 3:41 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Thats the another odd part of it. Although the first firing indicates > that the escl failed, then the next log entry is the firing of the same escl > again, but if you wade through the push fields, you will see that each field > is pushing twice, then actions 2 & 3 are duplicated. I've been waiting for > BMC to call back with their diagnosis, but I can't wait that much longer. I > have to get this back into production. > > > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza* > Sent:* Tuesday, October 02, 2007 3:25 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > I noticed that but it fails qualification once, and the second time around > it passes the qualification, and performs the push operation once.. Did that > create a duplicate ticket even though it appears like it performs the push > once? > > Re-creating the escalation might help. It may be that the Escalation > definition cache has encountered some sort of corruption. > > What you could try doing is exactly what I've emailed you directly - i.e. > - Delete the Escalation, stop the Escalation server by disabling the > Escalation thread, recreate or import that escalation back, and then restart > the escalation server. > > If that doesn't work, re-engineer the whole thing to see if that works. > Have the Escalation check for an unprocessed record in the Alerts 7.1 form > (this I recognize as a Netcool form???). When an Escalation finds an > unprocessed record in the Alerts 7.1 form set the acknowledge flag, and > have a filter process the push to the helpdesk form by checking for the TR > value of the flag. > > *Joe D'Souza* > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher* > Sent:* Tuesday, October 02, 2007 3:04 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Joe, > > I've sent the log file and a def file. The oddity here is that when you > look into log file, a single escl is firing within itself. The escl starts, > then starts again in mid operation and it completes the operation twice. > I've never seen this before. The most obvious thought would be to delete > and recreate, but I would love to have BMC tell me how this happens. > > C > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza* > Sent:* Tuesday, October 02, 2007 2:47 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Sure send it on this email account directly if you do not intend to send > it on the list.. It might take me a while to take a look at it but I'll see > if I can spot anything.. > > I might ask for a combination of a filter and escalation log too later if > the escalation log alone is not enough, but for a start lets have a look at > the escalation log only and see if I can spot something there.. > > *Joe D'Souza* > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher* > Sent:* Monday, October 01, 2007 2:56 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Joe, > > Is there a better email acct to send a piece of the escalation log. There > is something very odd within it. > > C > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza* > Sent:* Monday, October 01, 2007 1:49 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Chris, > > What are the chances that both your escalations evaluate to True, thus > firing actions twice during the runtime of both the escalations resulting in > 2 tickets? > > *Joe D'Souza* > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher* > Sent:* Monday, October 01, 2007 1:41 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Joe, > > There are no filters firing on this. Only 2 escalations, one for US and > one for Row. Each escalation has 3 actions. > 1. A push field taking data from the original form and pushing to Help > Desk with a 1=2 qualification. > 2. Takes the HD request ID and sets it back to the original form. > 3. Sets a single field from No to Yes in the original form acknowledging > that the data was acted upon via the escalation. > > This is the run if on the escalation: ( 'Acknowledged' = "No") AND ( > 'Location' != "EU_SuperNode" ) > > C > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza* > Sent:* Monday, October 01, 2007 12:50 PM* > To:* [EMAIL PROTECTED] > Subject:* Re: Escalation creating dup tickets > > ** > Chris, > > What is the workflow behind the creation of the ticket? > > I mean when the Escalation fires, is the Escalation directly creating that > ticket? Or is a Filter set to fire on that Escalation create that ticket? > > What are the exactly actions on your Escalations as well as filters > created to fire on that Escalation? > > It definitely isn't a problem with the Server Groups. Server groups allow > for only one Escalation server within the server group. > > *Joe D'Souza* > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher* > Sent:* Monday, October 01, 2007 12:24 PM* > To:* [EMAIL PROTECTED] > Subject:* Escalation creating dup tickets > > ** > > Hello all, > > Has anyone seen where a single escalation fires and creates matching > tickets where the only difference is the Request ID? In the logs, it shows > the escalation firing, doing a push to ITSM (Help Desk), does a return > setfield back into the original form that a second setfield changes the > value which triggered the escl firing in the first place, then immediately > there after, with no escalation fire a second Help Desk Desk ticket is > created with a sequential requestID. > > This is in a server group, but I have confirmed that the escalations are > only firing on one of the 3 servers. > > ARS 6.3, CSS 5.01, ITSM 6.0, Solaris 5.9, Sybase 12.5.3. > > C > > > Christopher H. Pickering > Remedy System Administrator > Premiere Global Services, Inc. > 100 Tormee Drive > Tinton Falls, NJ 07712 > 732.389.3900 X2411/800.333.0568 X2411 > [EMAIL PROTECTED] <[EMAIL PROTECTED]> > *www.premiereglobal.com* <http://www.premiereglobal.com/> > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
