Schedule Behavior When Queue is Stopped And Cross Over Midnight

Discussion created by laura_albrecht_automic on Sep 6, 2016
Latest reply on Sep 15, 2016 by laura_albrecht_automic
I am pretty sure this would affect a small minority of people (if anyone), but just thought I'd give people a heads-up.  Cause this could really mess you up if you weren't expecting it.  

I don't know how most people handle outages and/or recover from outages, but when I was at CME and now here at Shire we have a GSO solution implemented that makes this super easy.  Basically bring down your system, do your maintenance, bring it back up, run a job or two and anything that should have been triggered while the system was done will be.  If anyone is interested I can go into more detail (I'll start a separate thread).

In the course of implementing this at Shire during testing we came across some strange behavior.  This is a very specific situation.

- Stop Queue A that has schedules running in it.  For example, at 10pm.
- Outage crosses or continues past midnight.
- Outage is over after midnight.  For example, at 5am.
- Start Queue A.

Without doing anything with our special process or recovery, etc. - anything in the schedule between midnight and 5am automatically has a "reset task" done on it and if the calendar conditions, etc. are right - will go ahead and start running.

This is very unusual behavior.  Generally, whether the system is down, client is stopped, or even just activating a new schedule object - the system never goes back in time and triggers processes.

In the situation above - it will.

I've reported this as a bug and if you are interested / want to follow - the ticket number is PRB00122726.  

Again, very small audience here I think.  And even smaller chance this could occur.  I personally never schedule any maintenance to cross over midnight as it is so difficult to recover from, but just wanted to make people aware.

I'm on 11.2 - it's entirely possible that this situation doesn't exist in prior versions - I have no way (or time) to test that.

Any questions, let me know.