It is possible to perform the time change without interrupting to the system, i.e. the system continues to operate across the time change.
The system time is adapted accordingly on both time change dates: i.e. in the Central European Time zone, the system time is advanced by 1 hour in the spring (usually during the last weekend of March) and put back by 1 hour in the autumn (during the last weekend of October).
This time change involves a single step and is therefore different from the other time synchronization operations: the TODR is not modified and continues to run in monotonic mode. Instead, the TODR correction value is manipulated in order to yield the adjusted system time. This conversion is triggered when the system task TIME sets a timer with the next conversion date on startup (and following every changeover).
Changeover dates are declared in the GTIME section of the startup parameter file. If the future changeover dates are missing in this file, a corresponding warning is output, unless the SINGLE keyword is specified after the last changeover date. Time reset points can also be managed during ongoing operation using the ADD-/ MODIFY-/REMOVE-/SHOW-CHANGE-DATE commands. However, changes to time reset points by means of commands must be entered manually in the parameter file if they are to apply in the next session.
For regions currently using summer/winter time changeover, but are planning to move to a single season time in future, the keyword SINGLE should be specified after the last changeover date in the system parameter file.
If the application software has not yet been fully converted to GTIME by means of STCK time determination, the system time changeover can be prevented by specifying DIFF=0:00 in the parameter service. The system must then be restarted.
Notes
The CTIME interface also issues warnings for input or output time stamps in the duplicated or skipped hour. The system time supplied by GTIME (local time) is shifted accordingly at changeover time. Applications that work with or compare time stamps must be able to process negative shifts in the local time. A procedural change to UTC time or the maintenance of a summer time / winter time indicator, which is also provided in GTIME/CTIME, is recommended. The current time should not be determined by directly accessing the TODR.
If user programs continue to use the STCK command and their own conversion algorithms for time stamps instead of using GTIME, then they are still dependent on the local time in the TODR. In this case, the system must be reloaded as previously on time changeover.
If all the user programs have already been converted to GTIME for time polling or if they only calculate STCK values to determine differences, then interrupt-free time changeover can be used.
Job management behavior on changeover
Changeover from winter time to summer time
Scheduled jobs
As a result of the conversion of the start time to UTC and the subsequent back-conversion, the start time is delayed by one hour.
Example: ENTER <file>,START=AT(02:30) results in the job being started at 03:30 (LTI). This start time is inherited by successor jobs if the job is the first of multiple repeat jobs.
Repeat jobs with the period DAILY/WEEKLY
Any job repetitions which have to start in this time period are omitted. Instead, the next successor is used and the next start takes place 1 day or 1 week later.
Repeat jobs with hour/minute periods
The start times of job repetitions are calculated simply by adding the minutes of the period to the last start time (in JMS time, UTC); therefore this period is simply skipped.
Example start times:... 01:45 , 01:55 , 03:05 , 03:15 ... (LTI)
Changeover from summer to winter time
Scheduled jobs
The internal conversion of a start time of a scheduled job in UTC assumes winter time; the start is therefore correspondingly performed in the second hour of the period.
Repeat jobs with the period DAILY/WEEKLY
Job repetitions which have to start during this period are handled in the same way i.e. they start in the second hour.
Repeat jobs with hour/minute periods
The start times of job repetitions are calculated by simply adding the minutes of the period to the last start time (in JMS time, i.e. UTC); therefore they may run in both of the two hours.
Notes on AVAS behavior on time changeovers
Changeover from winter time to summer time
Nets planned for the period 2.00 - 3.00 are suddenly started in accordance with the delay settings (NET-DELAY-SOLUTION) and run normally. Shortly after 3.00 am there is therefore increased AVAS activity since all the nets due to be started in the lost hour are immediately processed.
Changeover from summer to winter time
The nets which have already been started (since 2.00 am) continue to run normally since they are started on the basis of the predecessor/successor principle independently of the time. When the time is put back, no nets are started until 3.00 am. Time stamp-related problems may affect sorting in the journal file since the start times of successive jobs may lie before those of the predecessors.