Hi,
I did my PTT (Performance Tuning & Troubleshooting class) in 1998, and had
an argument with the teacher.
I produced some log files to prove my case during class, but she refused
to accept that as proof, and I gave up ;-)
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> That shatters a long standing understanding I had about data driven
> escalations. I had received this info at a Remedy training facility in
> Bracknell in UK years ago, that you ought to help Escalations with Filters
> triggered off modifications by the Escalation User in processing 2nd and
> 3rd
> stage actions. I guess they were wrong when they instructed us so then..
>
> That is one of the benefit that they explained of having Filters running
> with a Run If of $USER$ = "AR_ESCALATOR" AND whatever else the rest of the
> qualification may be.. The other benefit I'm guessing (I wasn’t told this
> but it makes sense) is if you need to override filter phasing during the
> run
> of an escalation..
>
> Joe
>
> -----Original Message-----
> From: Misi Mladoniczky
> Sent: Saturday, December 10, 2011 4:04 AM Newsgroups:
> public.remedy.arsystem.general
> To: [email protected]
> Subject: Re: Application-Query-Delete-Entry
>
> Hi,
>
> Filters triggered by an Escalation, either via Set-Fields or Push-Fields,
> will ALWAYS be run in the same thread.
>
> This has ALWAYS been the case.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Now that you remind me, I actually remember discussing this once with
>> you..
>>
>> I'll really need to log the workflow to see what thread processes the
>> filter
>> workflow when filters are executed triggered by the AR_ESCALATOR user.
>>
>> I was told this in a performance tuning class years ago (version 4.0 -
>> 4.5
>> days so probably 11 or 12 years ago) that you let escalations perform
>> first
>> stage actions, and leave any 2nd and 3rd stage actions (deletes, push
>> fields, notifications) to be performed by filters that are run using the
>> admin thread. Maybe the design was different back then? So this is
>> obsolete
>> now?
>>
>> I wish I had a server to verify this :-)
>>
>> Joe
>>
>> -----Original Message-----
>> From: LJ LongWing
>> Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
>> public.remedy.arsystem.general
>> To: [email protected]
>> Subject: Re: Application-Query-Delete-Entry
>>
>> Joe,
>> I know this discussion comes up every once in awhile....but you and I
>> seem
>> to differ in our opinions of how it works.
>>
>> So...based on your statement below, having the escalation set a field,
>> and
>> having a filter fire on that field being set, then performing the delete
>> will be 'faster' because of a 'fire and forget' type of mechanism?
>>
>> I would argue that an action of delete within the escalation, and a
>> setfield
>> causing a filter to fire that causes the delete are 'the same', in that
>> the
>> escalation thread does not 'go onto the next record' till after the
>> filters
>> on the current record are done...so, in essence, the performance of
>> either
>> action would be the same and the escalation thread would still be tied
>> up
>> for exactly the same amount of time regardless
>>
>> At least, that's my understanding :)
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[email protected]] On Behalf Of Joe Martin D'Souza
>> Sent: Thursday, December 08, 2011 11:33 AM
>> To: [email protected]
>> Subject: Re: Application-Query-Delete-Entry
>>
>> End Date as Linda pointed out should be a field on that form you are
>> searching for, represented by 'End Date' in the qualification and not
>> $End
>> Date$..
>>
>> That being said, LJ's suggestion is right..
>>
>> The qualification should be in the Run If of the Escalation and the run
>> process should be
>>
>> Application-Delete-Entry $SCHEMA$ $Request ID$
>>
>> Having an Escalation with no Run If instructs it to be run over the
>> entire
>> data table. You do not want to do that in case you have like a million
>> or
>> more records in it.. It may probably hang the escalation thread waiting
>> for
>> it to complete..
>>
>> Also a faster way to do it would be to 'mark that entry for deletion'
>> using
>> a tag on a field created for that. This would mean that the Escalation
>> would
>> do a single update to that table which is a faster operation that
>> multiple
>> deletes and be done with it.. Create a filter that runs if the $USER$ is
>> AR_ESCALATOR and the flag for delete is set, to delete that entry. So on
>> a
>> fairly large set of data, although the deletes are still potentially
>> happening triggered by that filter, the escalation thread has already
>> finished processing the escalation and is ready to take on a new job..
>>
>> Joe
>>
>> -----Original Message-----
>> From: LJ LongWing
>> Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
>> public.remedy.arsystem.general
>> To: [email protected]
>> Subject: Re: Application-Query-Delete-Entry
>>
>> Larry,
>> Your approach is a bit ‘off’. An escalation performs a search that
>> matches
>> your qualification, and then performs your action on ALL records that
>> match
>> that qualification. So in this case, I would expect your run-if
>> qualification to be
>>
>> ('Status' = "Past") and ($End Date$ < ($TIMESTAMP$ - (86400 * 180)))
>>
>> Or, whatever qual you want to identify your specific records,
>>
>> Then, from there, you will be modifying ‘that’ record…so you wouldn’t
>> want
>> to then perform an Application-Query-Delete-Entry, you could simply
>> perform
>> an
>>
>> Application-Delete-Entry $SCHEMA$ $Request ID$
>>
>>
>>
>> From: Action Request System discussion list(ARSList)
>> [mailto:[email protected]] On Behalf Of Larry Barnes
>> Sent: Thursday, December 08, 2011 10:23 AM
>> To: [email protected]
>> Subject: Application-Query-Delete-Entry
>>
>> **
>> Hello Listers,
>>
>> I'm trying to learn how to delete records that are past and the End Date
>> is
>> more than 6 months prior to todays date. I built the escalation and
>> when
>> I
>> run it nothing happens. Can someone point in the right directions with
>> the
>> Run Process syntax.
>>
>> I'm using SQL 2008 and Windows 2008. ITSM is 7.5
>>
>> The form I'm deleting from is: AP:Alternate
>>
>> Run IF Qualification is: 'Status' = "Past" (also tried without
>> setting
>> a Run If Qualification)
>>
>> Run Process is: Application-Query-Delete-Entry "AP:Alternate"
>> ('Status'
>> =
>> "Past") and ($End Date$ < ($TIMESTAMP$ - (86400 * 180)))
>>
>> I have also tried: Application-Query-Delete-Entry "AP:Alternate"
>> ('Status' = "Past") and ($End Date$ < ($DATE$ - (86400 * 180)))
>>
>>
>> Thanks in advance for your time,
>>
>> Larry B
>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
