Die Zeitumstellung kann unterbrechungsfrei erfolgen, d.h., das System wird kontinuierlich über eine Zeitumstellung hinweg betrieben.
An den beiden Terminen der Zeitumstellung wird die Systemzeit entsprechend angepasst: d.h. in unserer mitteleuropäischen Zeitzone wird die Systemzeit im Frühjahr (meist am letzten Märzwochenende) um 1 Stunde vorgestellt, im Herbst (am letzten Oktoberwochenende) um 1 Stunde zurückgestellt.
Das Verstellen erfolgt in einem Schritt und damit anders als die sonstigen Zeitsynchronisationen: Das TODR wird nicht geändert, es läuft monoton weiter. Stattdessen wird der TODR-Korrekturwert entsprechend manipuliert, um die verstellte Systemzeit zu erhalten. Diese Umstellung wird dadurch ausgelöst, dass die Systemtask TIME bei Startup (und nach jeder Umstellung) einen Timer mit dem nächsten Umstelltermin aufzieht.
Umstellungszeitpunkte werden über den GTIME-Abschnitt der Startup-Parameterdatei bekanntgegeben. Fehlen dort zukünftige Umstellzeitpunkte, wird eine entsprechende Warnung ausgegeben. Umstellungszeitpunkte können auch im laufenden BS2000-Betrieb mit den Kommandos ADD-/MODIFY-/REMOVE-/SHOW-CHANGE-DATE verwaltet werden. Änderungen von Umstellungszeitpunkten durch die Kommandos müssen aber manuell in die Parameterdatei eingetragen werden, wenn sie im nächsten Systemlauf gültig sein sollen.
Falls die Anwendungs-Software noch nicht vollständig von Zeitermittlung mit STCK auf GTIME umgestellt ist, kann die Systemzeitumstellung durch Angabe von DIFF=0:00 im Parameterservice unterbunden werden. Das System muss dann neu gestartet werden.
Hinweise
Die Schnittstelle CTIME stellt zusätzliche Warnungen für Eingabe- bzw. Ausgabezeitstempel in der doppelten bzw. übersprungenen Stunde bereit. Die mit GTIME gelieferte Systemzeit (lokale Zeit) macht zum Umstellungszeitpunkt einen entsprechenden Sprung. Anwendungen, die mit Zeitstempeln rechnen bzw. diese vergleichen, müssen negative Zeitsprünge der lokalen Zeit verarbeiten können. Es wird entweder eine Verfahrensumstellung auf UTC-Zeit oder die zusätzliche Mitführung der Sommerzeit-/Winterzeit-Anzeige empfohlen, welche bei GTIME/CTIME ebenfalls bereitgestellt wird. Die aktuelle Zeit darf nicht durch direkten TODR-Zugriff ermittelt werden.
Benutzen Benutzerprogramme statt GTIME noch den STCK-Befehl und eigene Umrechnungsalgorithmen für Zeitstempel, sind sie auf die lokale Zeit im TODR angewiesen. In diesem Fall muss das System bei Zeitumstellung wie bisher neu geladen werden.
Sind alle Benutzerprogramme schon auf GTIME zur Zeitabfrage umgestellt worden oder verrechnen sie STCK-Werte nur zu Differenzen, kann die unterbrechungsfreie Zeitumstellung genutzt werden.
Verhalten des Job-Managements bei Zeitumstellung
Umstellung von Winter- auf Sommerzeit
Termin-Jobs
Durch die Umrechnung der Startzeit in UTC und anschließender Rückkonvertierung kommt ein um eine Stunde verschobener Startzeitpunkt zustande.
Beispiel: ENTER <datei>,START=AT(02:30) führt zum Start um 03:30 (LTI).
Diese Startzeit vererbt sich auf die Nachfolgejobs, wenn der Job der erste von mehreren Repeat-Jobs ist.Repeat-Jobs mit Periode DAILY/WEEKLY:
Repeat-Job-Wiederholungen, die in diesem Intervall starten müssten, fallen aus. Stattdessen wird der nächste Nachfolger genommen, das nächste Starten erfolgt also 1 Tag oder 1 Woche später.
Repeat-Jobs mit Stunden-/Minute-Perioden
Die Startzeiten der Jobwiederholungen werden einfach durch Addition der Minuten der Periode auf die letzte Startzeit berechnet (in JMS-Zeit, UTC), sie überspringen also das Intervall einfach.
Beispiel Startzeitpunkte: ... 01:45 , 01:55 , 03:05 , 03:15 ... (LTI)
Umstellung von Sommer- auf Winterzeit
Termin-Jobs
Die interne Umrechnung der Startzeit eines Termin-Jobs in UTC unterstellt Winterzeit bei der Umrechnung; der Start erfolgt dann entsprechend in der zweite Stunde des Intervalls.
Repeat-Jobs mit Periode DAILY/WEEKLY:
Repeat-Job-Wiederholungen, die in diesem Intervall starten müssten, werden ebenso behandelt, starten also im zweiten Intervall.
Repeat-Jobs mit Stunden-/Minute-Perioden
Die Startzeiten der Jobwiederholungen werden einfach durch Addition der Minuten der Periode auf die letzte Startzeit berechnet (in JMS-Zeit, also UTC), sie laufen also ggf. in jedem der beiden Intervalle.
Hinweise zum Verhalten von AVAS bei Zeitumstellung
Umstellung von Winter- auf Sommerzeit
Die für den Zeitraum 2.00 – 3.00 Uhr geplanten Netze werden plötzlich entsprechend den Einstellungen für Verspätungen (NET-DELAY-SOLUTION) gestartet und laufen dann normal ab. Kurz nach 3.00 Uhr kommt es somit vermehrt zu AVAS-Aktivitäten, da alle Netze, die in der verlorenen Stunde gestartet werden sollen, sofort behandelt werden.
Umstellung von Sommer- auf Winterzeit
Die (seit 2.00 Uhr) bereits gestarteten Netze laufen normal weiter, da sie unabhängig von der Zeit nach dem Vorläufer-Nachfolger-Prinzip gestartet werden. Nach dem Zurückstellen der Zeit werden bis 3.00 Uhr keine Netze gestartet. Mit dem Zeitstempel in der Journaldatei kann es u.U. beim Sortieren Probleme geben, da die Startzeiten von Nachfolgejobs vor denen der Vorläufer liegen können.