The scheduling rule types of Daily, Weekly, Monthly, and Interval have additional scheduling properties that can be set using the advanced settings interface. There are several advanced settings that can be configured. They are:
This features defines what a job does if it falls behind in its schedule. Normally this feature does not come into play. But for example, if a daily job is configured to run every day at 6:00PM but JobServer is down for 3 days due to say a hardware problem. When JobServer is started, the job will get kicked off, since its next run date has long past. Now this is when the Skip-Ahead feature comes into play. If this field is checked, then after the initial run, the job will "skip" ahead to the next valid run date that is in the future. If it is not checked, then it will run two additional times for the two other days it should have run (it does not skip to the next run date in the future but instead continues to run to the next valid next run date even though it is in the past). The job will keep running until it encounters a next run date that is in the future again.
Expire mode prevents a job from running if its next run date exceeds a given range of time. By default, this feature is not enabled. If enabled, it defines the amount of time from the next run date that the job must run in. For example, if a job is scheduled to run at 1:00PM and its expire time is 10 minutes and the job for some reason is prevented from running at 1:00PM but instead runs at 1:15PM then it will not run, but will instead be marked as expired and the following next run date will be scheduled instead. The expire time is in the format of "dd:hh:mm" (days:hours:minutes). So if you want set it to 10 minutes, the format would be "00:00:10".
This flag can be used with the Expire Rule to allow you to control whether you want Expire Rule events to be logged by the Job Tracker or not. By default, if a job gets expired it will not run and the expire event will be logged by Job Tracker. In some cases, if this Expire Rule event is a common situation for a particular job, you may not want the event to be logged by Job Trackers to avoid cluttering the logging records. By unchecking this flag, Expire Rule events will not be logged.
When this flag is set, this permits only one instance of this job to be running at any one time. This is useful in scenarios where you want to prevent more than one instance of a job from being scheduled at any one time. For example, you may have a job that runs every two minutes and in some rare cases the job might take 3 minutes to complete its processing. This flag prevents any other instance of the job from running until the current instance has completed. This feature can also be used in scenarios where you want a job to be running for extended periods of time and you only want to have one instance of the job to ever be running at any moment. So as an example, you might schedule the job to run every 2 seconds and this job might be polling indefinitely (until killed) looking for certain events like a file being dropped in a FTP directory. In this scenario the job runs forever looking for such events. If it ever dies due to a failure the scheduler will start another instance. This flag will also prevent jobs that are manually run from actually running, so again, only one instance of the job can ever be running at any point in time.
This setting allows you to control if and how a job's schedule is terminated. By default, a job does not have an end by rule; it will keep running according to its scheduling rules indefinitely. You can configure a job to end on a given date/time or you can define how many times a job should run before it stops. Once a job's end date is reached, it will go into a "stop" state.
This feature does not directly impact the scheduling rules of a job, but is instead passed to the
when it is run. The start and end offsets define the amount of days that will be
added/subtracted to the next run
time (scheduled time) and last run time. The "last run date" is the "start
date and the "next run date" is the end date.
These dates are passed to the JobContext and can be referenced
contain the last time date the job ran and the next date (current date) the job ran, respectively.
The offset settings can be used to add or subtract dates from each.
This can be used to make
business decisions. For example, if you have a job that runs every day and it pulls data
from a database, the start date and end date can be used to access data from the database over that given
date range (or an offset date range). This can be a very useful feature for ETL type processing applications.
The last run date can be edited manually by a user. This feature is only necessary for a situations
where the user needs to adjust the last run date that is passed to a job when it runs using