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

  1. The following example runs the testjob job every hour:
    testjob every 60
  2. 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.

  3. The following example does not start the testjob2 job iteration until job testjob1 has completed successfully:
    testjob2 every 15 follows testjob1
  4. 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.

  5. 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.

  6. 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.