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 HCL Workload Automation 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 HCL Workload Automation 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 HCL Workload Automation 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 HCL Workload Automation when the delay of an every instance does not exceed the bm late every option value.
Example 5 shows the behavior of HCL Workload Automation when the delay of an every instance exceeds the bm late every option value.
Example 6 shows the behavior of HCL Workload Automation 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 100
```
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.:
```
testjob1 at 1800 every 15 until 2000
```
The job is supposed to run at 1800, 1815, 1830, and so on every 15 minutes.
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.
Because testjob1 was submitted adhoc 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)

Since the 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)

When batchman calculates the time for the next iteration, it uses the following data:
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)

After this job iteration completed, batchman calculates again the time the next iteration has to start using these updated values:

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 following example does not start the testjob2 job iteration until job testjob1 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, HCL Workload Automation restarts. When it analyses the Symphony file, it determines that the potential best time for the next every job instance is 1600. HCL Workload Automation 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 HCL Workload Automation 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, HCL Workload Automation restarts. When it analyses the Symphony file, it determines that the potential best time for the next every job instance is 1600. HCL Workload Automation 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 HCL Workload Automation 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 HCL Workload Automation 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, HCL Workload Automation restarts. When it analyses the Symphony file, it determines that the first instance of this every job has not run. In this case HCL Workload Automation launches the job at 1415.