"Start Of Day" in Tivoli Workload Scheduler

While writing the article about Scheduling FINAL I've realized the need to write a specific article about the meaning of the "Start Of Day" and how it works.

Most of the customers are still running TWS using Start Of Day set to 0600 (the 6 in the morning), or they are scheduling FINAL 1 minute before the Start Of Day. This is no more required since TWS 8.3, but changing this setting in an existing production environment is not easy, and just since 8.6 the default value for a fresh installation has been changed to 0000.

"Start Of Days" setting is stored with optman in the database, with the keys startOfDay and its value is set in the format HHMM.

The meaning and usage of "Start Of Days" has slightly changed during the history of the product and since 8.3 FP1 depends on the setting of the enLegacyStartOfDayEvaluation optman option.
In any case since 8.3 this is no more related to when the plan is created or extended (when FINAL runs), TWS is able to generate correctly the plan even if a day is split in 2 different plans, and is able to create dependencies between jobs created in the 2 plans.

When enLegacyStartOfDayEvaluation is NO, the default setting for fresh installations, the meaning of Start Of Day is the time of the day we consider as the start of the day.

If the Start Of Day is 0000 (midnight) the day starts at midnight as the calendar day, this is the default and the more natural way to consider a day. Any time specified in TWS definition is just the time you have set, if you specify that a job have to run every Monday at 2 AM, it will run on Monday at 2 AM.

The question at this point is: why I have to consider a different behavior?
Let's start describing what's the behavior with a different Start of Day.
A value different from 0000 for Start Of Day moves the start of the day at that time, e.g. if we set Start Of Day at 06:00, TWS will consider the day as starting at 6 AM and completing right before 6 AM the next day, so Monday for TWS is now the time windows from Monday at 6 AM to Tuesday at 5:59:59 AM.

As consequence, if we specify that a job has to run on Monday at 4 AM, the job will start when on the wall clock it's Tuesday at 4AM. That's probably the hardest and less intuitive part of using a different value for Start Of Day.
On the other side this can be useful if you consider the workload run in the night as closure of the previous day and for example you consider the night between Sunday and Monday as part of Sunday. This can be important especially when you want to apply free day calendar to decide if that night is free or working time.
So the usage of Start Of Day still has some area of application, but the drawback is that every time you have to set a time between midnight and the start of day you have to think what's day it is.

Above I was saying that Start Of Day behavior depends on enLegacyStartOfDayEvaluation option, but I have not yet specified how.
When enLegacyStartOfDayEvaluation is set to NO, the same behavior applies to any timezone, regardless of what's the master and the agent timezone, if you are in a single timezone or enLegacyStartOfDayEvaluation is NO the behavior is the one described above, leave enLegacyStartOfDayEvaluation set to NO and don't care about it.

The purpose of enLegacyStartOfDayEvaluation set to YES is to assure backward compatibility if you are coming from a TWS 8.2.x or previous release, you use multiple timezones and you have enTimeZone set to YES. This behavior is coming from the limitations present in TWS until release 8.2.1 where the product was only able to create plans of 24 hour where it was including all workload scheduled on a specific date.
But for every specific date, for 49 hours there is a place on the planet where the current date is that date. Consider for example Jan 1st and how long it takes from when Jan 1st starts in New Zealand and when if ends in the Hawaii, and there are some small island in the pacific sea that makes it even longer.
The legacy behavior that was until 8.2.1 was introduced to fit a date in the plan, considering a day (e.g. Monday) as the time window from Start Of Day on the master timezone, to the Start Of Day of the next day on the master timezone.

In the picture for example, we have Start Of Day set to 6 AM, the master in New York and the agent in Los Angeles. The legacy Start Of Day behavior consider 3 AM as the Start Of Day for times in the Los Angeles timezone. This makes definitions very complex since the Start Of Days varies in every timezone, this is even more complex if you have timezones with different DST rules making the Start Of Day different during the year.
That's the reason I suggest to not use enLegacyStartOfDayEvaluation and leave it set to NO, but of course this requires to change the scheduling definitions if coming from releases before 8.3 with multiple timezones.

The need to include completely a date in a plan and the inability to have dependencies between plan, is also the reason that until 8.2 the FINAL had to run 1 minute before Start Of Day, as said above these limitation as been removed since 8.3 and you can now run FINAL when you want as described in the Scheduling FINAL article.

If you like this article and you find it useful, please share it on social media so other people may take advantage of it.