Table of contents
Alarm scenario does not start or start late
Review details problem
Alarm scenarios do not seem to run. The main scenario fails, and sometime the alarm scenario seems to run, mostly very late after the error appeared, and sometimes not at all.
A sequence looks like this:
11:56:58.721 LOG:SCHEDULE::0:2512.a00::Start scenario "Wingf" in queue "01" <<< main scenario starts
at 12:01 the main scenario WinGF runs into an error:
12:02:23.460 LOG:SCHEDULE::0:2512.804::Start scenario "Wingf_ad_kaputt" in queue "00" <<< alarm scenario starts
12:03:30.208 LOG:SCHEDULE:SCERUN:963:2512.804::-Scenario Wingf_ad_kaputt end OK <<< alarm scenario stops
12:04:12.004 LOG:SCHEDULE:SCERUN:963:2512.a00::-Scenario Wingf end OK <<< main scenario stops
So it seems that the alarms scenario indeeed started about 1 minute after the alarm occured
Is this a normal behaviour?
Solution(s)
The alarm scenarios don't have to be used to restore application. In your case (differents restauration steps) I suggests you 2 solutions:
- In your main script use the global variable (setglobalXXX) to delimitate each step (control flag). Create a restauration scenario for all the steps and added to each step a check of the control flag.
- Create a restauration scenario for each steps.
Then, call the function ScenarioExec with the appropriate restauration scenario in error case in your main script in order to perform the good restauration.
To answer you, yes the alarms scenarios can started 1 minute after the alarm occured. This is the behaviour intended because the schedule.exe service has a granularity of 1 minute.
Comments