Its not a critical issue for most cases where Escalation run times are often 
arbitrarily selected at the least active times. But if a slight miss does get 
noticed, it could mean that something that was fairly important, may have not 
been triggered at that expected time which could possibly be  David’s case..

Most of us (including me) never even noticed that until David pointed it out.. 
We may have possibly gone through the rest of our merry ARS lives not worrying 
about it..

Joe



From: Mueller, Doug 
Sent: Monday, March 12, 2012 2:35 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG 
Subject: Re: Where does $DATE$ come from?

** 
Fred is on the right track with his answers.

 

The way escalations work is to calculate when things should NEXT fire and that 
is what is keyed off of.

The calculation is not considering that DST change may be crossed for the next 
fire time (a fair question is

why not and that is something that could be submitted as a bug, but the 
escalation does run and for one

time, it is 1 hour off so is it a critical issue?  but, definitely feel free to 
submit the bug).

 

You should find all back on track after the first firing.

 

Now, the comment about restarting the server.  Why does that "fix" things?  
Well, when you restart the

server, we have to calculate all the next fire times so the restart after the 
change in DST will calculate the

fire times correctly even for the first firing interval.  It isn't that a 
restart is required, it is just that the

restart causes a recalculation of the firing times.

 

NOTE however that any interval fired operation would not have any issue with 
the one hour off and a

restart of the system will reset the interval counter so the current interval 
will get longer for the interval

based escalations – however long it has been since the last run plus the 
interval for the first interval.

 

I just wanted to explain what effect the restart had on the issue and why it 
seemed to "fix" a problem.

 

 

Again, the answer was already there, I just wanted to confirm it and offer a 
bit more information about

the affect on interval escalations.

 

Doug Mueller

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Monday, March 12, 2012 11:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

 

** 

Even by time it is calculated when it runs.  (You can tell by watching the 
Escalation Log and seeing that each escalation states)   

   (enabled) : going to fire in xxxx seconds  

 

It would only be able to do that if it is calculated at the time of the last 
run (to know how many seconds until the next run).

 

Fred

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling
Sent: Monday, March 12, 2012 1:20 PM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

 

** 

Fred,

 

This was the first time “A” ran since the time change, but it’s set to run by 
‘Time’, not ‘Interval’.  But if what you said applies anyway, I should find out 
tomorrow when it’s supposed to run again.

 

Thanks,

David

 

David Durling

University of Georgia

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Monday, March 12, 2012 2:01 PM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

 

** 

Had “A” ran since the time change?  I believe all escalation next run times are 
computed when they run (and are in seconds until next run) so if “A” had not 
run since the time change it would have been calculated to run x seconds from 
the last time (and with the time change that would be 1 hour later than you 
thought)

 

Fred

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling
Sent: Monday, March 12, 2012 12:56 PM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

 

** 

Dave,

 

So you’ve had to restart arsystem server to get things back in sync?

 

I had an issue this morning where one escalation (“A”) scheduled for 8:00 went 
off at 9:00, yet another escalation (“B”) scheduled for 8:05 went off at the 
correct time.  Differences I could think of:  escalation A came from workflow 
originally built on a 6.0 server (and it’s set to run on specific weekdays) , 
and B was built on our current 7.5 server (and it’s set to run every day).

 

David Durling

University of Georgia

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Shellman, David
Sent: Monday, March 12, 2012 1:13 PM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

 

** 

Mark,

 

Remember that most of the US changed time yesterday.  We have seen some issues 
with things being off an hour after a time change until we cycle services.  
That's mostly dealing with escalations.

 

Dave

 


--------------------------------------------------------------------------------

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Monday, March 12, 2012 12:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Where does $DATE$ come from?

** 

 

Depending on what is used to set it.. Is it an Active Link? Or a 
Filter/Escalation?

 

In case of an Active Link, the $DATE$ would taken from the client.

 

In case of server side workflow objects, Filters or Escalations, they are set 
from the AR System application server (not the database application server).

 

Joe

 

From: Brittain, Mark 

Sent: Monday, March 12, 2012 12:28 PM

Newsgroups: public.remedy.arsystem.general

To: arslist@ARSLIST.ORG 

Subject: Where does $DATE$ come from?

 

** 

Hi All,

 

Where does the $DATE$ function get the date/time information, the OS server or 
the database server. This may seem like a strange question but yesterday I had 
a case where $TIMESTAMP$ was work correctly and diary field entries were 
correct but the $DATE$ was on hour behind as 3/10/2012 23:00:00 PM. Strangely 
today, it working correctly as  3/12/2012 00:00:00 AM

 

ARS 6.3 patch 20

SunOS 5.9

Oracle 9.2

 

Thanks

Mark

 

Mark Brittain

Remedy Developer

ITILv3 Foundation

NaviSite – A Time Warner Cable Company

mbritt...@navisite.com

Office: 315-453-2912 x5335

Mobile: 315-317-2897

 

 

 

_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_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"

Reply via email to