Wanted to resurrect this since it is time to set the clocks back this weekend to see if any one knows if this issue was ever resolved/fixed with remedy?
I am having my server rebooted this weekend just in case so it recalculates the escalations. Thanks, Joelie Dudley -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of O'Hara, Jim Sent: Thursday, November 03, 2005 12:44 PM To: [email protected] Subject: Re: Time Change - Processes Running Twice I tried doing this manually (disable escalations) in the admin tool server settings, but it didn't reset the clock. I didn't keep retrying to make sure, though. I just went for the bulk edit to toggle escalations off and back on. Jim O'Hara -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, November 03, 2005 9:36 AM To: [email protected] Subject: Re: Time Change - Processes Running Twice How about ARSetServerInfo for AR_SERVER_INFO_DISABLE_ESCALATIONS. This is a server setting that disables all escalations. #define AR_SERVER_INFO_DISABLE_ESCALATIONS 143 /* int - 0 - enabled */ /* 1 - not enabled */ And I was starting to think that only the java documentation was missing the constant listings provided in the c header files ;) Axton On 11/3/05, Thomas Bean <[EMAIL PROTECTED]> wrote: > ** > The "enable" column in the escalation table stores the > enabled/disabled flag, but I doubt that resetting this value at the db > level outside of the Admin tool would have any effect until ARS has > been restarted. The "arsignal -g" command is supposed to force a > reload of the data dictionary, but I'm not sure if this would work without testing it. > > --Thomas > > ----- Original Message ----- > From: Rick Cook > Newsgroups: gmane.comp.crm.arsystem.general > Sent: Thursday, November 03, 2005 09:50 > Subject: Re: Time Change - Processes Running Twice > > ** > I haven't investigated the API call, either, but I was envisioning the > script being directed by the O/S, not by the ARS. How about a stored > procedure? Is that setting stored in metadata somewhere? I don't > recall seeing it. > > Rick > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Thomas Bean > Sent: Thursday, November 03, 2005 7:27 AM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > ** > Disabling/re-enabling an escalation resets the offset calculation, so > that should work. However, I'm unfamiliar with the API that would be > needed to accomplish this. Also, assuming the script itself would not > be run via an escalation, how should the script be scheduled? > > --Thomas > > ----- Original Message ----- > From: Rick Cook > Newsgroups: gmane.comp.crm.arsystem.general > Sent: Wednesday, November 02, 2005 17:26 > Subject: Re: Time Change - Processes Running Twice > > I see your point, Thomas. How about a solution that included a script > sending an API call to turn off and back on the Escalations? Wouldn't > that be a simpler and less obtrusive call than bouncing the AR System > processes, and simpler than recalculating the time criteria, since the > reset would reload the time cache? > > > Rick > > ________________________________ > > From: Action Request System discussion list(ARSList) on behalf of > Thomas Bean > Sent: Wed 11/2/2005 2:47 PM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > > > > ** > Rick, > It doesn't really matter whether the escalations are scheduled between > 2:00 AM and 3:00 AM. Example: > > Escalation is scheduled to run at 7:00 AM daily. > > > 1. Escalation fires at 7:00 AM (Daylight Saving Time) on Saturday, > October 29, 2005. > 2. Escalation queue (incorrectly) determines next occurrence of 7:00 AM > is 86400 seconds (24 hours) in the future and schedules the next > execution of the escalation for this interval, which will be one hour > earlier than it should be due to pending time change. Correct > interval is 25 hours (90000 seconds). > 3. Local time reverts to standard time at 1:59:59 AM on Sunday, October > 30, 2005 (clock is set back to 1:00:00 AM). > 4. Escalation fires at 6:00 AM (Standard Time) on Sunday, October, 30, > 2005. This is 24 hours since the last execution, but it is an hour > early per the standard time clock. > 5. Escalation queue determines next occurrence of 7:00 AM is 3600 > seconds (1 hour) in the future and schedules the next execution of the > escalation for this interval. > 6. Escalation fires a second time at 7:00 AM (Standard Time). > > > So, this design flaw in the escalation queue causes all time-based > escalations to fire twice the first time they run following a time > change from Daylight Saving/Summer Time to standard time (once an hour > early, and again at the scheduled time). This same flaw causes all > time-based escalations to fire an hour late the first time they run > following a change from standard time to Daylight Saving/Summer Time. > > It seems to me this could be resolved by forcing the escalation queue > to recalculate the counters for time-based escalations more frequently > (instead of only at escalation run-time and at server startup). It > shouldn't be necessary to stop and restart the AR Server processes for this to occur. > > I reported this bug to Remedy Support last year, the defect # is 214057. > The status is still "Work In Progress". Maybe this will be fixed in > the "Thor" release??? > > --Thomas > > > ----- Original Message ----- > From: Rick Cook <mailto:[EMAIL PROTECTED]> > Newsgroups: gmane.comp.crm.arsystem.general > Sent: Wednesday, November 02, 2005 13:11 > Subject: Re: Time Change - Processes Running Twice > > True. You could schedule a job to run to do that for you, or > remember to disable escalations between 2 and 3 am twice a year. > > > > ______________________________________________________________________ > ___________ > > Rick Cook * Senior Remedy Consultant * Denali Advanced > Integration * > (253) 278-4112 > > ________________________________ > > From: Action Request System discussion list(ARSList) on behalf > of Heider, Stephen > Sent: Wed 11/2/2005 10:39 AM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > > > ** > I believe so. Actually, restarting the Remedy NT services (on > a Windows box) will reset the escalation counters. > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Manara > Sent: Wednesday, November 02, 2005 10:37 AM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > > ** > I wonder if a reboot of the server would cause the next time > to execute to be recalculated. > > > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook > Sent: Wednesday, November 02, 2005 9:57 AM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > > ** > Yeah, I remember this from my Administrator days - it's just > one of those annoying things to remember, that you have to either plan > for or clean up after the time switch twice a year (well, maybe only once). > > A good reason to not have Escalations running between 2 and 3 > am if possible. > > Rick > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Eric Cleereman (IT) > Sent: Wednesday, November 02, 2005 6:46 AM > To: [email protected] > Subject: Re: Time Change - Processes Running Twice > > > ** > This has happened to us as well. > > The help file for Remedy Administrator 6.3.00 shows > the following under Automating application processes with > workflow\Specifying escalation time criteria: > > Note: There might be irregularities the first > time escalations execute after Daylight Saving Time (DST) transitions. > For example, an escalation is scheduled to run at 12:00 noon every > Monday. On the first Monday after clocks are set ahead, the escalation > runs at 1:00 p.m. instead of at noon. On the first Monday after the > clocks are set back, it runs at 11:00 a.m. and again at noon. > > Rebooting the server doesn't seem to have an effect on > this one way or the other. > > I believe what likely happens is the something like this: > > * At 4:30 AM Saturday night, your Escalation ran as > normal. > * If the Escalation takes 5 minutes to run, we'll say > it finished at 4:35 AM. > * > Remedy then schedules the next instance for > 4:30 AM on Sunday, in 23 hours and 55 minutes time. > * > At 1:59:59 AM on Sunday, the server's > Operating system rolls the clock back one hour. Remedy's previously > scheduled Escalation times are already set and determined, and as such > are not affected. > * > 23 hours and 55 minutes after the Saturday > Escalation, the first Sunday Escalation runs. It is now only 3:30 AM. > * > It finishes at 3:35 AM. > * > Remedy then schedules the next instance at > 4:30 AM on Sunday, in 55 minutes time. > > Eric Cleereman > Remedy Administrator > Borders Group, Inc. > > -----Original Message----- > From: Action Request System discussion > list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Heider, Stephen > Sent: Wednesday, November 02, 2005 8:33 AM > To: [email protected] > Subject: Time Change - Processes Running Twice > > > ** > > ARS 6.3 Patch 5 > Windows Server 2003 SP1 > SQL Server 2000 SP3a > > I had something happen with our Remedy system. > It is not major and I think that rebooting the server will fix it, but > I am curious if this has happened to anyone else. > > The time changed back to Standard Time Sunday > night (set clocks back one hour). A custom routine developed in > Remedy that runs processes according to a schedule (an escalation > checks every 5 minutes to see if something needs to be run) began > running twice exactly one hour apart since the time changed. > > For example, at 4:30am a process is scheduled > run that creates tickets. Since the time change the process began > running at 3:30am and 4:30am. > > > > ______________________________This > posting was submitted via the Web interface > > ______________________________This posting was > submitted via the Web interface > > ______________________________This posting was submitted via > the Web interface ______________________________This posting was > submitted via the Web interface > ______________________________This posting was submitted via > the Web interface > > > ______________________________This posting was submitted via the Web > interface ______________________________This posting was submitted via > the Web interface ______________________________This > posting was submitted via the Web interface > ______________________________This posting was submitted via the Web > interface ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org (Support: mailto:[EMAIL PROTECTED]) _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
