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 job is set to run at 6:00PM on a given day 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 set, 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 set, then next schedule date will be used even if it is not in the future. 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. The expire time is in the format of "dd:hh:mm" (days:hours:minutes). So if you want to set it to 10 minutes, the format would be "00:00:10". You also have the option of selecting a custom expire date for each run time if you are using Custom Scheduling.
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, in the background, (until killed) looking for certain events like a file being dropped in a FTP directory...etc. 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 acutally running, so again, only one instance of the job can ever be running concurrently.
This feature does not directly impact the scheduling rule of a job, but is instead passed to a job when it is run. The start and end offsets defines the amount of days that will be added/subtracted to the next run time and last run time, respectively. When a job is run, it has access to an effective date range. The last run date the job ran is the end date, and the current run date is the start date. Normally, this is 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. This can be a very useful feature for ETL type processing applications. You also have the option of selecting a custom start and end dates for each run time.