Starting in 2019, Brazil will no longer observe Daylight Savings Time. Updates are required to AutoSys and UNIX/Linux tz data to accommodate this change and avoid impact to AutoSys scheduling. This will impact any jobs that have a timezone attribute set to one of the following...
Brasilia
RioDeJaneiro
SaoPaulo
America/Sao_Paulo
1. Change the timezone value in the AutoSys database(s) by executing the following query...
update ujo_timezones set zone='EST3' where name='America/Sao_Paulo';
2. (Windows Only) Change BRASILIA values as shown below in file: %AUTOSYS%\Win4TimezonesNewDSTRule.cfg
<TZ="BRASILIA">
"EST3"
180
"E. South America Standard Time"
0, 0, 0, 0, 0, 0, 0, 0
0
"E. South America Daylight Time"
0, 0, 0, 0, 0, 0, 0, 0
0
</TZ>
4. (UNIX/Linux Only) - Schedulers/Application Servers running on UNIX/Linux will always first use what is defined in the O/S's tz data before using the zone definition stored in the AutoSys database to resolve a timezone. You can run the following command to check whether or not the America/Sao_Paulo zone has been updated at the O/S level...
zdump -v -c 2019,2020 America/Sao_Paulo
The output of this command should not show any DST change occurring past February 2019. If it does, your O/S tz data is not up-to-date. You will need to consult with your system administrator or O/S vendor for steps on how to update the tz data for your O/S.
5. Once the above steps are performed, restart the Scheduler and Application Server.
6. The final step is to force the Scheduler to re-evaluate the next start time for jobs that have a timezone attribute set to one of the zones listed in the introduction of this article. You can use the following SQL query run by the aedbadmin user in the AutoSys database to help build a list of these jobs...
select distinct(j.job_name) from ujo_job j, ujo_sched_info s where j.joid=s.joid and s.timezone in ('Brasilia','RioDeJaneiro','SaoPaulo','America/Sao_Paulo') and j.is_active=1;
Issue each of the jobs an "update_job:" in jil. It is not necessary to actually change any job attribute. A simple "update_job" is sufficient. For example, if you wanted to do it for a single job called JOBA, you would run jil and enter the following
1>update_job: JOBA
2>exit
It is also acceptable to create a file containing 'update_job: <job_name>' for each impacted job on a separate line. You can then feed that file as standard input to jil...
jil < job_list_file
This will perform the action for all listed jobs at once.
WARNING: If you issue an "update_job" in jil within one minute of a job's next scheduled start time, that next start time will be skipped and the job will be scheduled for the next start time after that. If possible, try to perform the updates on the jobs at a time when none of them are scheduled to run. However, you will want to watch for this and take manual action (force start) on any job that misses a start due to the updates.