GlacierI 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: arslist@ARSLIST.ORG
  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: arslist@ARSLIST.ORG
  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: arslist@ARSLIST.ORG
    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: arslist@ARSLIST.ORG
    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: arslist@ARSLIST.ORG
      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: arslist@ARSLIST.ORG
      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: arslist@ARSLIST.ORG
        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]
          www.premiereglobal.com


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.13.39/1044 - Release Date: 10/2/2007
11:10 AM

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

<<attachment: Glacier Bkgrd.jpg>>

Reply via email to