The way day/date attributes are used has changed. Recall how Recall day/date with time attributes:
Here the day/date act like a guard over the time. Hence the time is not considered until the day/date is free.
|
|
|---|
In ecflow 4.0 the The definition below can produce unexpected runs.
...
in ecflow 4.
...
Here the time 10:00, was set free on Sunday.
(when time attributes are set free, they stay free, until re-queue.)
X.X can produce an unexpected run of task t1, on Monday at 00:00
| Code Block | ||
|---|---|---|
|
...
| |
... family f1 day monday task t1 |
...
|
...
|
...
# runs |
...
| title | ecflow 4.0 |
|---|
...
Monday@00:00 and Monday@10.00 time 10:00 |
...
# time was set free on Sunday |
...
In ecflow 5.
...
X.X the day/date act like a guard over
...
any other time attribute.
...
Hence the time is not
...
considered until the day is free.
Hence this produces the expected results.
| Code Block | ||
|---|---|---|
| ||
...
family |
...
f1 day monday # Guards the time, until day/date is free task t1 time 10:00 # |
...
runs on |
...
Monday@10.00 |
However, both behave the same way for the following definition.
| Code Block |
|---|
. |
...
| title | ecflow 5.0 |
|---|
...
.. family f1 time 10:00 # |
...
set free on |
...
the sunday task t1 day monday # runs |
...
Monday@00:00 and |
...
Monday@10.00 |
Repeat with day/date
The behavior of day/date attribute under a repeat has changed from ecflow 4.0.
In ecflow 4.X, if task t1 took longer than 1-hour task t2 would not run.
In ecflow 5.X, once the day monday is free on family f1, it stays free until the automatic re-queue caused by the parent repeat. The net effect being that task t2 will still run, even if we have strayed into Tuesday.
| Code Block |
|---|
suite s1
family f
repeat integer rep 0 1
|
Hence in ecflow 5.0, in the following definition, the task will never run:
...
family f1
|
...
|
...
|
...
day |
...
monday |
...
task t1 |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
time 23:00 |
...
task t2
... |