Understanding Offset Concepts
Overview
Enterprise Scheduler follows certain concepts when it compiles a production schedule. The concepts are basic but can result in complicated timing scenarios with date shifts that cause confusion among users when put into practice. The most complex timing issues arise from the shifting of the start of the production day through a series of time offsets as scheduled jobs run.
Enterprise Scheduler compiles a production schedule from your job rules for each master. This production schedule covers at least the current day but may extend to multiple days. You determine the duration of each schedule by specifying the number of days to include. Each master in your network has its own production schedule, so schedule durations can vary. The active production schedule for a master includes history data (for dates past), the current date and any remaining days in the schedule (future).
Figure 2-1 Example of a Normal Schedule Length
The production day contains all of the job rules that are scheduled to run during the production day. A production day always contains 24 hours and by default starts at midnight and ends at 23:59:59 pm. (For simplicity’s sake, we will use the 24-hour time format in this discussion so 11:59 pm is 2359.) To accommodate all of the processing needs of a business, a production day often differs from the calendar day. You can designate that the production day start at any time. For instance, you might specify that the production day starts at 0500 instead of starting at midnight to allow for the completion of the previous day's jobs. This is called a production day offset.
If the offset is positive, the fiscal day begins at some time after midnight and continues into the next calendar day. If the offset is negative, the fiscal day begins at some time before midnight. The maximum offset that you can define is 23 hours and 55 minutes. Scheduler uses the designated start of the production day to determine when the production day starts, and to select and launch jobs accordingly.
Defining a Production Day
Positive Offset (Late Start)
If you want your production day to begin at 1200 noon and continue until 1200 noon the following day, you define the start of the production day as 1200 (+1200). When offsetting the start time, it is important to remember that no time is lost, the hours between the start of the calendar day and the start of the production day are merely shifted from the beginning of the production day to its end. There are still 24 hours in the day.
The following figure compares the calendar day to a production day with an offset of +1200. Using this production offset, a job scheduled to launch at 0800 (8:00 a.m.) on June 10th (production date) will not actually launch until 0800 on June 11th (calendar date).
Figure 2-2 Production Offset Defined As +1200 (Master/Agent in Same Time Zone)
Negative Offset (Early Start)
If you want your production day to begin at 2045 (8:45 p.m.), and continue until 2045 the following day, define the production day offset as -0315.
The following figure illustrates the calendar and production days with an offset of -0315. Using this production day offset, a job scheduled to launch at 2115 on June 12th (production date) launches at 2115 on June 11th (calendar date).
Figure 2-3
Production Offset Defined As -0315 (Master and Agent in Same Time Zone)
Scheduling Based on Agent Time Zone
While jobs normally run from the master’s time reference, you can launch jobs according to what time it is in the agent’s time zone. Selecting the
Use Agent Time Zone
option on the
Master
tab of the System Configuration dialog will launch jobs according to the time where the agent resides. This change will take effect the next time any schedule is compiled. While the jobs will launch at the intended times in the agent’s time zone, the master’s viewpoint will be compiled in for the job time windows and start time. Since the master will compensate for the offset, users should not think about the difference between the different master and agent time zones when defining jobs rules. In a nutshell, using the master time zone imposes an absolute time reference while using the individual agent time zones imposes a relative time reference.
Caution The master will be unable to predict shifts in times when compiling future schedules. Times will be calculated as an offset to the master time based on the timezone of the agent. If the agent shifts times, the master will not be able to predict this shift, as international daylight savings time laws constantly change, country to country. The schedule must be compiled under the influence of the new agent times.
The following example illustrates the differences to be accounted for when the master and the agent reside in different time zones. The master in this example is three time zones ahead of the agent. A job defined to run at 2300 on the production day of August 10th will actually be launched by the master at 0200 on the production day of August 11th to account for the difference in time zones.
Figure 2-4
Agent Residing Three Time Zones Behind Master (No Production Date Offset)
is another example of the master and agent in different time zones without a production offset. This example shows a master that is seven hours behind the agent. A job defined to run at 0500 on the production day of August 11th is actually launched by the master at 2200 on the production day of August 10th to account for the difference in time zones.
Figure 2-5
Agent Residing Seven Time Zones Ahead of Master (No Production Date Offset)
Using a Positive Production Day Offset
Agent Running Ahead of the Master
Setting a positive production day offset moves the start of the production day forward. In the example below, the difference between time zones is shown in a solid line and the production day offset is shown in a dotted line.
Figure 2-6 Positive Production Day Offset With the Agent Running Ahead of the Master
This example shows an agent that is five hours ahead of the master. A production day offset of positive three (+3) shifts the start of the production day (0000) three hours ahead in calendar time for both master and agent. A job defined to run at 0500 on the production day of August 11th launches at 0000 on August 10th on the master’s production day.
Agent Running Behind the Master
Setting a positive production day offset moves the start of the production day forward. In the example below, the difference between time zones is shown with a solid arrow and the production day offset is shown with a dotted arrow. This example has a positive production day offset of two hours ahead with the agent running eight hours behind the master. Thus a job defined to run at 2200 on the production day of August 10th is launched at 0600 on August 11th due to the difference in time zones.
Figure 2-7
Positive Production Day Offset With Agent Running Behind Master
Using a Negative Production Day Offset
Agent Running Ahead of the Master
Setting a negative production day offset moves the start of the production day back from midnight. In the example below, the difference between time zones is shown with a solid arrow and the production day offset is shown in a dotted arrow. The example shown below has a negative 4 offset so the start of the production day is moved back four hours behind the start of the calendar day. A job defined to run at 2200 on the production day of August 11th is launched at 1600 on August 10th on the master due to the time difference.
Figure 2-8
Negative Production Day Offset With Agent Running Ahead of Master
Agent Running Behind the Master
Setting a negative production day offset moves the start of the production day back from midnight. In the following example, there is a negative four hour production offset moving the start of the production day four hours behind the start of the calendar day. In the example below, the difference between time zones is shown with a solid arrow and the production day offset is shown with a dotted arrow.
Figure 2-9
Negative Production Day Offset With Agent Running Behind Master
This configuration has an agent that is running five hours behind the master. A job defined to run at 2300 on the production day of August 10th is launched by the master at 0300 on August 11th.
Defining a Compile Offset
Compiling the production schedule may consume enough CPU resources to seriously affect your system’s performance and hinder other work that may be going on concurrently. It may be better to schedule such a resource-intensive operation like compiling your schedule, at a more convenient time when your system has a lighter workload. Once the schedule is compiled, it is saved until needed when the new production day starts. You can manually compile a new schedule at any time by selecting the
Create Schedule
option in the
Activities
main menu.
Figure 2-10 Create Schedule Dialog
The compile offset is calculated from the start of the production day. The schedule will be compiled for the current day and all days that belong to the future days to include in the schedule. Any future day that was already scheduled (not forecast) will not get recompiled to reflect any job modifications or additions that were not committed to the schedule after the operation. To include any modifications that were not committed to the schedule, we must either recompile the already scheduled days or revert these schedules to a forecast type to force a compile before the day rolls into production.
There are differences between 6.x and 5.3.x as to how offsets are interpreted. If you want to preserve 5.3.x behavior, use the following.
Sysval 150
Sysval 150 provides a way to retain 5.3.1 calendar logic for offset end date calculation in 6.x. Sysval with id 150 and value 'Y should be created during database upgrade otherwise it can also be manually created using the below SQL query.
Sysval with id 150 and value 'Y enforces 5.3.1 calendar logic for offset enddate calculation.
Use the following queries to update sysvals for Oracle DB:
delete from sysval where sysval_id in (150);
insert into sysval (sysval_id, sysval_string, sysval_integer, sysval_lstchgtm) values (150, 'Y', 0, sysdate);
commit;
/
Use the following queries to do so for MSSQL DB
delete from sysval where sysval_id in (150)
go
insert into sysval (sysval_id, sysval_string, sysval_integer, sysval_lstchgtm) values (150, 'Y', 0, getdate())
go
No sysval entry with id 150 or value 'N' enforces 6.x calendar logic for offset enddate calculation.