every (used for jobs)
Defines the repetition rate for a job. The job is launched repeatedly at the specified rate. If the job has a dependency that is not satisfied, the iteration is started only after the dependency is satisfied. The keyword is specified within the definition of a job.
Syntax
every rate
Arguments
- rate
- The repetition rate expressed in hours and minutes, in the hhmm format. The rate can be longer than 24 hours. The maximum supported value is 99 hours and 59 minutes.
Comments
- The every iteration of a job does not stop even if one of the job repetitions abends.
- If the every option is used without the at dependency, the rerun jobs are scheduled respecting the every rate specified, starting from the time when the job actually started.
- In the specific case that the every option is used with
the at dependency and one rerun is delayed (for a dependency
or for any other reason), then, while IBM Workload Scheduler realigns
to the at time, there might one or two iterations that do not
respect the every rate. For all other cases the every rate
is always respected.
Example 2 explains how IBM Workload Scheduler realigns to the at time if the job starts later than the defined at time and some iterations are lost.
- If an every instance of a job does not start
at its expected start time, use the bm late every option to
set the maximum number of minutes that elapse before IBM Workload Scheduler skips
the job. The value of the option must be defined in the <TWSHOME>/localopts file:
- bm late every = xx
- Where xx is the number of minutes.
This option is local for each agent, therefore it must be defined on every fault-tolerant agent that has every jobs with bm late every option set.
The bm late every option applies only to jobs with both the every option and the at time dependency defined, it has no impact on jobs that have only the every option defined. Only jobs whose every rate is greater than the bm late every value will be impacted.
Example 4 shows the behavior of IBM Workload Scheduler when the delay of an every instance does not exceed the bm late every option value.
Example 5 shows the behavior of IBM Workload Scheduler when the delay of an every instance exceeds the bm late every option value.
Example 6 shows the behavior of IBM Workload Scheduler when the first instance of a job does not run at its expected start time and exceeds the bm late every option value.
- If the every keyword is defined for a job when the Daylight Saving Time (DST) turns off, that is the clock is put one hour back, the command every job is DST aware and it runs also during the second, repeated time interval.
Examples
- The following example runs the
testjob
job every hour:testjob every 60
- The following example shows the
testjob1
job that is defined to run every 15 minutes, between the hours of 6:00 p.m. and 8:00 p.m.:
The job is supposed to run at 1800, 1815, 1830, and so on every 15 minutes.testjob1 at 1800 every 15 until 2000
If the job is submitted
adhoc
at 1833, the reruns are at 1833, 1834, 1845, etc. The reason for this is explained next:At first notice that in a job there are two time values to consider:- The start_time; this is the time when the job is expected
to run. It is set to the at time specified for the job or to
the time when the rerun should be launched. This value can be viewed
using
conman showjobs
before the job iteration starts. - The time_started; this is the time when the job actually
starts, for example 1833. This value can be viewed by using
conman showjobs
after the job iteration started.
testjob1
was submittedadhoc
at 1833, this is the information you see immediately after submission:- with
conman showjobs
TESTJOB1 HOLD 1800
- in the Symphony file
-
start_time=1800
(because the job is expected to run at 1800)time_started=NULL
(because the job has not yet started)
start_time
(1800) is smaller than the current time (1833),testjob1
starts immediately and the updated information becomes:- with
conman showjobs
TESTJOB1 SUCC 1833
- in the Symphony file
-
start_time=1800
(because the job was expected to run at 1800)time_started=1833
(because the job started at 1833)
start_time=1800
rate=0015
current_time=1833
Since the next iteration time (1800+0015=1815) would still be sooner than the current_time value (1833), batchman identifies the last planned iteration that was not run by adding to the start_time as many every_rate as possible without exceeding the current_time
1800 + 0015 + 0015 = 1830 < 1833
and then issues the command to run that iteration. Assuming that this iteration is run at 1834, the information, after the job starts, becomes the following:- with
conman showjobs
TESTJOB1 SUCC 1834
- in the Symphony file
-
start_time=1830
(because that job iteration was expected to run at 1830)time_started=1834
(because that job iteration started at 1834)
start_time=1830
rate=0015
current_time=1834
The fact that the next iteration time (1830+0015=1845) is later than the current_time value (1834), shows batchman that the iteration is recovered. The iteration time, starting from 1845 onwards, can now be realigned with the planned iteration times set in the job definition by the at and every keywords.
- The start_time; this is the time when the job is expected
to run. It is set to the at time specified for the job or to
the time when the rerun should be launched. This value can be viewed
using
- The following example does not start the
testjob2
job iteration until jobtestjob1
has completed successfully:testjob2 every 15 follows testjob1
- In the following example, the delay
of an instance of an every job does not exceed the bm late
every option value:
bm late every = 10 JOB AT 1400 EVERY 0030
This job is supposed to run at 1400, 1430, 1500, and so on every thirty minutes.
If the server is down from 1435 to 1605, the instances at 1500, 1530, and 1600 do not run. At 1605, IBM Workload Scheduler restarts. When it analyses the Symphony file, it determines that the potential best time for the next every job instance is 1600. IBM Workload Scheduler checks if the potential best time (1600) exceeds the maximum allowed delay for an every job (10 minutes).
In this case the delay has not exceeded the bm late every option, therefore IBM Workload Scheduler behaves as usual and creates the instance of the every job with start time set to 1600. The subsequent instances are at 1630, 1700 and so on, every thirty minutes.
- In the following example, the delay
of the instance of an every job exceeds the bm late every option
value:
bm late every = 10 JOB AT 1400 EVERY 00030
This job is supposed to run at 1400, 1430, 1500, and so, on every thirty minutes.
If the server is down from 1435 to 1620, the instances at 1500, 1530, and 1600 do not run. At 1620, IBM Workload Scheduler restarts. When it analyses the Symphony file, it determines that the potential best time for the next every job instance is 1600. IBM Workload Scheduler checks if the potential best time (1600) exceeds the maximum allowed delay for an every instance of a job (10 minutes).
In this case the delay is greater that the bm late every option, therefore IBM Workload Scheduler applies the new behavior, it does not launch the instance of the every job at 1600 and it creates the instance of the every job with start time set to 1630.
- The following example shows the behaviour
of IBM Workload Scheduler when
the first instance of a job does not run at its expected start time
and exceeds the bm late every option value:
bm late every = 10 JOB AT 1400 EVERY 00030
This job is supposed to run at 1400, 1430, 1500, and so on, every thirty minutes.
If the server is down from 1000 to 1415, the first instance of the job does not run. At 1415, IBM Workload Scheduler restarts. When it analyses the Symphony file, it determines that the first instance of this every job has not run. In this case IBM Workload Scheduler launches the job at 1415.