Verarbeitung von Store Clock-Werten

Dieses Dokument behandelt verschiedene Aspekte der Verarbeitung von Store Clock-Werten in Natural-Anwendungen.

Folgende Themen werden behandelt:


Der originale Store Clock und das Jahr-2042-Problem

Die Natural-Systemvariable *TIMESTMP stellt den Großrechner-Hardware-internen Systemuhrwert (im Folgenden: "Store Clock") zur Verfügung. Der Store Clock ist ein 8 Byte langes binäres Feld, dessen Wert auch die Assembler STORE CLOCK-Instruktion (STCK) liefert. Er zählt die Mikrosekunden seit 01.01.1900 00:00:00 (UTC), wobei Bitposition 51 exakt eine Mikrosekunde darstellt (Bitposition 0 ist das ganz linke Bit). Die übrigen Bits können je nach Maschinenimplementierung höhere Genauigkeitswerte wie Nanosekunden oder eine Prozessorkennung (ID) enthalten.

STCK Layout

Der Store Clock wird seinen höchstmöglichen Wert am 17. September 2042 um 23:53:47.370495 (UTC) erreichen, wobei dann alle 52 Bits auf 1 gesetzt sein werden. Danach wird der Store Clock-Zähler zurückgesetzt und es wird wieder ab 0 hochgezählt. Das Datum, an dem die Uhr zurückgestellt wird, wird im Folgenden als Rücksprungdatum (Wrap Date) bezeichnet.

Nach dem Rücksprungdatum wird der Store Clock dieselben Werte wie im Bereich von 1900 bis 2042 verwenden. Deshalb ist es nicht möglich zu entscheiden, ob ein Store Clock vor oder nach dem Rücksprungdatum genommen wurde.

Wenn der Store Clock die Jahre von 1900 bis 2042 abdeckt, nennen wir ihn den "originalen Store Clock".

Für das Jahr 2042 ist folgendes zu beachten ("Jahr-2042-Problem"):

  • Vergleich und Sortierung
    Ein Vergleich von zeitbezogenen Werten sollte die chronologische Reihenfolge so widerspiegeln, dass frühere Werte kleiner als spätere Werte sind. Leider ist ein Store Clock-Wert, der kurz vor dem Rücksprungdatum genommen wurde, größer als ein Store Clock-Wert, der nach dem Datum genommen wurde, an dem der Store Clock auf 0 gestellt wurde. Somit führt ein Vergleich solcher Store Clock-Werte zu unrichtigen Ergebnissen. Beispiel: Der Store Clock-Wert vom 01.01.2040 (vor dem Rücksprungdatum) ist größer als der Store Clock-Wert vom 01.01.2043 (nach dem Rücksprungdatum). Sortiert man Store Clock-Werte, die vor und nach dem Rücksprungdatum genommen wurden, werden diese nicht die chronologische Reihenfolge widerspiegeln.

  • Konvertierung
    Wenn man einen Store Clock-Wert in ein Datum konvertiert, wird davon ausgegangen, dass er in den Jahren von 1900 bis 2042 genommen wurde. Wurde der Store Clock-Wert aber tatsächlich nach dem Rücksprungdatum genommen, wird die Konvertierung deshalb zu einem falschen Ergebnis führen. Beispiel: Ein Store Clock-Wert wurde am 07.12.2043 (d.h. nach dem Rücksprungdatum) genommen. Wenn man diesen Store Clock-Wert in ein Datum konvertiert, wird das Ergebnis der 21.03.1901 sein.

  • Berechnung einer Zeitdifferenz
    Wenn man Store Clock-Werte in Mikrosekunden konvertiert, kann man sie zur Berechnung einer Zeitdifferenz benutzen. Das funktioniert problemlos, falls das Rücksprungdatum nicht beteiligt ist. Wenn man einen (großen) Store Clock-Wert, der vor dem Rücksprungdatum genommen wurde, von einem (kleinen) Store Clock-Wert, der nach dem Rücksprungdatum genommen wurde, subtrahiert, erhält man ein falsches (und zwar negatives) Ergebnis. Beispiel: Wenn man die Store Clock-Zeitdifferenz zwischen den Jahren 2039 und 2043 berechnet, erhält man -138 Jahre als Ergebnis.

Um das Jahr-2042-Problem zu lösen, gibt es zwei Ansätze:

  • Genereller Ansatz: Erweiterter Store Clock.

  • Temporärer Ansatz: Store Clock mit gleitendem Jahr-Fenster.

Für beide Lösungswege stehen in der Natural System Library SYSEXT (siehe SYSEXT Utility) Anwendungsprogrammierschnittstellen (APIs) zur Verfügung. Weitere Informationen siehe Natural-APIs zur Store Clock-Verarbeitung.

Erweiterter Store Clock

Die Natural-Systemvariable *TIMESTMPX stellt den erweiterten Großrechner-Hardware-internen Store Clock-Wert (Assembler Instruktion STCKE "STORE CLOCK EXTENDED") zur Verfügung. Der erweiterte Store Clock ist ein 16 Byte langes binäres Feld. Er zählt die Mikrosekunden seit dem 01.01.1900 00:00:00 (UTC), wobei Bitposition 59 exakt eine Mikrosekunde darstellt (Bitposition 0 ist das ganz linke Bit). Die originale Store Clock-Zeitdarstellung wird in Byte 2 bis 9 beibehalten. Links wird ein zusätzliches Überlauf-Byte hinzugefügt, der so genannte Epochen-Index.

STCKE Layout

Der erweiterter Store Clock deckt die Jahre von 1900 bis 38434 ab.

Im Vergleich zum originalen Store Clock bietet der erweiterte Store Clock folgende Verbesserungen:

  • Vergleich und Sortierung
    Wenn man Werte vergleicht oder sortiert, liefert der erweiterte Store Clock immer die erwartete chronologische Reihenfolge.

  • Konvertierung
    Zum Konvertieren von erweiterten Store Clock-Werten können Natural-APIs benutzt werden. Weil jeder erweiterte Store Clock-Wert im erweiterten Store Clock-Wertebereich eindeutig ist, ist die Berechnung immer richtig.

  • Berechnung einer Zeitdifferenz
    Zum Konvertieren von erweiterten Store Clock-Werten in Mikrosekunden (seit 01.01.1900) können Natural-APIs benutzt werden. Eine Zeitdifferenzberechnung mit diesen Werten liefert die richtige Zeitdauer.

  • Ausblick
    Für die Zukunft ist keine weitere Codeänderung erforderlich.

Migration vom originalen Store Clock zum erweiterten Store Clock

Vor einer Migration vom originalen Store Clock zum erweiterten Store Clock ist Folgendes zu berücksichtigen:

  • Die Größe des binären Feldes erhöht sich von 8 Bytes auf 16 Bytes. Wenn Ihre Anwendung nur die Zeitinformation in Mikrosekunden benötigt, können Sie einfach nur die ersten 8 Bytes des erweiterten Store Clock-Wertes benutzen. Jedoch sollten Sie daran denken, dass der Wert noch das erweiterte Store Clock-Format mit dem Epochen-Index auf der linken Seite enthält. Bevor Sie ihn mit einer Natural-API verarbeiten können, müssen Sie ihn daher wieder auf 16 Bytes erweitern.

  • Ein erweiterter Store Clock-Wert kann nicht direkt mit einem originalen Store Clock-Wert verglichen werden (und auch nicht mit einem Store Clock-Wert mit gleitendem Jahr-Fenster, Beschreibung siehe weiter unten). Der erweiterte Store Clock-Wert beginnt mit dem Epochen-Index, daher kann ein Vergleich kein korrektes Ergebnis liefern.

  • Gespeicherte Store Clock-Werte müssen in erweiterte Store Clock-Werte konvertiert werden. Für diese Aufgabe können Sie den Copycode USR9201R benutzen.

  • Jedes Programm, das Store Clock-Werte verarbeitet, muss angepasst werden.

  • Die komplette Konvertierung erfordert einen größeren Aufwand.

Store Clock-Wert mit gleitendem Jahr-Fenster

Wenn ein Store Clock-Wert in ein Datum konvertiert wird, wird bei der Konvertierung des originalen Store Clock-Wertes davon ausgegangen, dass er aus dem Bereich von 1900 bis 2042 genommen wurde. Um den Bereich zu erweitern, verwenden wir ein "gleitendes Jahr-Fenster" (Year Sliding Window), das den Bereich von 1971 bis 2114 unterstützt. Das impliziert, dass die Jahre von 1900 bis 1971 nicht mehr unterstützt werden.

Im Jahr 1971 schaltet das erste Bit im Store Clock-Wert auf 1. Deshalb wird dieses Bit zur Realisierung des gleitenden Jahr-Fensters genutzt:

  • Von 1971 bis 2042 ist das erste Bit 1. Store Clock-Werte aus diesem Bereich werden wie zuvor interpretiert.

  • Von 1900 bis 1971 und von 2042 bis 2114 ist das erste Bit 0. Mit dem gleitendem Jahr-Fenster werden diese Store Clock-Werte als 2042 bis 2114 interpretiert.

Wenn ein Store Clock-Wert mit gleitendem Jahr-Fenster in Mikrosekunden konvertiert wird und das erste Bit 0 ist, wird vor der Konvertierung der binäre Store Clock-Wert auf der linken Seite mit x'01' erweitert, damit das Ergebnis immer die Anzahl an Mikrosekunden seit dem 01.01.1900 widerspiegelt.

Der Bereich des Store Clock mit gleitendem Jahr-Fenster

  • beginnt am 11.05.1971 um 11:56:53.685248 Uhr (UTC) und

  • endet am 26.01.2114 um 11:50:41.055743 Uhr (UTC).

Anmerkungen:

  1. Wenn Sie 8 Byte lange binäre Store Clock-Werte sortieren, werden diese nicht in chronologischer Reihenfolge sein, und zwar selbst dann nicht, wenn Sie das gleitende Jahr-Fenster benutzen. Für diese Aufgabe müssen Sie erweiterte Store Clock-Werte benutzen.
  2. Wenn Sie 8 Byte lange binäre Store Clock-Werte vergleichen, kann es vorkommen, dass das Ergebnis nicht die chronologische Reihenfolge widerspiegelt, und zwar selbst dann nicht, wenn Sie das gleitende Jahr-Fenster benutzen. Für diese Aufgabe können Sie den Copycode USR9201D benutzen.
  3. Wenn der Store Clock-Wert nach dem Ende des gleitenden Jahr-Fensters genommen wird, wird er falsch interpretiert. In diesem Fall müssen Sie ebenfalls erweiterte Store Clock-Werte benutzen.
  4. Ein Store Clock-Wert wird in einem 8 Byte langen Feld gespeichert, in dem die letzten 12 Bits niemals Null sind. Diese Tatsache kann benutzt werden, um zu bestimmen, ob das Feld für den Store Clock noch unbenutzt ist. Wenn alle 8 Bytes in dem Feld Null sind (NULL-Wert), dann ist das Feld noch unbenutzt und es wurde noch kein Store Clock-Wert gespeichert. Sie müssen sicherstellen, dass das Store Clock-Feld keinen NULL-Wert enthält, bevor Sie es in einer Konvertierungsfunktion benutzen.

Im Vergleich zum originalen Store Clock bietet der Store Clock mit gleitendem Jahr-Fenster folgende Verbesserungen:

  • Konvertierung
    Natural APIs können benutzt werden, um Store Clock-Werte mit gleitendem Jahr-Fenster richtig zu konvertieren, wenn die Store Clock-Werte im Zeitraum von 1971 bis 2114 genommen worden sind.

  • Berechnung einer Zeitdifferenz
    Zum Konvertieren von Store Clock-Werten mit gleitendem Jahr-Fenster in Mikrosekunden (seit 01.01.1900) können Natural-APIs benutzt werden. Eine Zeitdifferenzberechnung mit diesen Werten liefert die richtige Zeitdauer (wenn die Store Clock-Werte von 1971 bis 2114 sind).

  • Ausblick
    Das Jahr-2042-Problem wird bis 2114 hinausgeschoben.

Im Vergleich zum erweiterten Store Clock bietet der Store Clock mit gleitendem Jahr-Fenster folgende temporäre Vorteile:

  • Größe
    Die Größe des Store Clock-Werts bleibt bei 8 Bytes.

  • Datenkonvertierung
    Es besteht keine Notwendigkeit, die Store Clock-Daten auf 16 Byte lange Werte zu konvertieren. Gespeicherte 8 Byte lange Store Clock-Daten werden richtig interpretiert, wenn sie im Bereich 1971 bis 2114 sind.

  • Änderungen an Programmen
    Die Konvertierung erfordert einen geringeren Aufwand. Die Systemvariable *TIMESTMP kann weiterhin benutzt werden.

Migration vom originalen Store Clock zum Store Clock mit gleitendem Jahr-Fenster

Vor einer Migration vom originalen Store Clock zum Store Clock mit gleitendem Jahr-Fenster ist Folgendes zu berücksichtigen:

  • Die Migration muss vor dem Jahr 2042 erledigt werden.

  • Vor Ende des gleitenden Jahr-Fensters im Jahre 2114 werden weitere Codeänderungen erforderlich.

  • Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie diese API durch eine API ersetzen, die den Store Clock mit gleitendem Jahr-Fenster unterstützt.

  • Wenn Sie binäre Store Clock-Werte vergleichen oder sortieren, werden diese nicht in der chronologischen Reihenfolge sein. Siehe Anmerkung weiter oben.

Lokaler Store Clock

Die Natural-Systemvariable *TIMX stellt die lokale Uhrzeit (Ortszeit) in Zehntelsekunden zur Verfügung. Wird die lokale Uhrzeit mit höherer Genauigkeit benötigt, kann die Natural API USR9178N verwendet werden. Sie liefert die lokale Uhrzeit und die entsprechende UTC-Zeit im Store Clock-Format (B8), in Mikrosekunden seit 01.01.1900 und im Natural-Zeitformat (T). Zusätzlich liefert sie die Zeitdifferenz, einen Standard-DATETIME-Wert und die Zeitzone. Es sind Funktionen vorhanden, mit denen die Werte in andere Formate konvertiert werden können. Die Copycodes USR9178X, USR9178Y und USR9178Z bieten im Prinzip die gleiche Funktionalität, jedoch bei wesentlich besserer Performance.

Layout eines lokalen Store Clock-Werts

Die ersten 7 Bytes des lokalen Store Clock-Werts haben den gleichen Inhalt wie der originale Store Clock, wobei die Bitpositionen 0 – 51 die Mikrosekunden der lokalen Uhrzeit enthalten. Deshalb können zur Interpretation eines lokalen Store Clock-Werts Standard-APIs (z.B. USR1023* oder USR9201*) verwendet werden.

Das letzte Byte eines mit USR9178* generierten lokalen Store Clock-Werts enthält die Zeitdifferenz. Mit dieser Information kann später festgestellt werden, in welcher Zeitzone der lokale Store Clock-Wert genommen wurde, insbesondere, ob er in der Sommer- oder Winterzeit genommen worden ist.

Zeitdifferenz und Zeitzone

Die Zeitdifferenz drückt den Unterschied zwischen Local Time und UTC Time aus:

Zeitdifferenz = Local time - UTC time

Die API USR9178N und die entsprechenden Copycodes liefern die Zeitdifferenz in Einheiten von 1/10 Sekunden.

Das letzte Byte eines lokalen Store Clock-Werts enthält die Zeitdifferenz in Einheiten von 15 Minuten als Ganzzahl mit Vorzeichen (Format I1).

Die API USR9178N gibt außerdem die der Zeitdiffenz zugeordnete Zeitzone zurück.

  • -hh:ii bei einer negativen Zeitdifferenz oder

  • +hh:ii andernfalls.

Standard-DATETIME

Die API USR9178N gibt den Standard-DATETIME-Wert zurück:

yyyy-mm-ddThh:ii:ss.fff

dabei ist fff der Teilbetrag in Millisekunden.

Natural-APIs zur Store Clock-Verarbeitung

In der Natural Library SYSEXT (siehe SYSEXT Utility) stehen folgende Natural Anwendungsprogrammierschnittstellen (APIs) zur Verfügung:

Natural API Funktion Store Clock Vorgänger-Version
Original mit gleitendem Zeitfenster Erweitert
USR1009N Store Clock mit gleitendem Zeitfenster in Mikrosekunden konvertieren ja ja nein  
USR1023N Zeitbezogene Systemvariablen konvertieren ja nein nein  
USR9178N Pflege von lokalen Store Clock-Werten nein ja nein  
USR9201N Zeitbezogene Systemvariablen konvertieren nein ja ja USR1023N

USR1009N

Die API USR1009N konvertiert einen Store Clock-Wert in Mikrosekunden seit 01.01.1900. Standardmäßig wird der Store Clock-Wert ohne gleitendes Jahr-Fenster (Bereich 1900-2042) interpretiert. Ein optionaler Parameter steht zur Verfügung, um den Store Clock-Wert mit dem gleitendem Jahr-Fenster (Bereich 1971-2114) zu interpretieren.

Die Copycodes USR9201V (mit gleitendem Jahr-Fenster) und USR1023Y (ohne gleitendes Jahr-Fenster) bieten bei besserer Performance die gleiche Funktionalität an wie die API USR1009N. Es wird daher empfohlen, diese Copycodes zu benutzen.

USR1023N

Die API USR1023N konvertiert eine zeitbezogene Variable in andere Formate. Sie verwendet dazu den originalen Store Clock (1900 – 2042).

Es wird dringend empfohlen, anstelle der API USR1023N die API USR9201N zu verwenden. Andernfalls werden Store Clock-Werte nach dem Jahr 2042 falsch interpretiert. Beispiel: Wenn Sie einen Store Clock-Wert am 07.12.2043 nehmen, wird ihn die API USR1023N als 21.03.1901 interpretieren.

Als Eingabe erwartet die API USR1023N eines der folgenden Formate:

  • Natural-Datum und Uhrzeit,

  • Natural-Datum,

  • Mikrosekunden (seit 01.01.1900) oder

  • originaler Store Clock.

Die API USR1023N konvertiert die Eingabe in alle anderen Formate.

Zusätzlich stehen zur API USR1023N die folgenden Copycodes zur Verfügung:

Copycode Funktion
USR1023W Mikrosekunden in originalen Store Clock konvertieren.
USR1023X Mikrosekunden in Natural-Uhrzeit konvertieren.
USR1023Y Originalen Store Clock in Mikrosekunden konvertieren.
USR1023Z Natural-Uhrzeit in Mikrosekunden konvertieren.

Die Copycodes sind wesentlich schneller als das Subprogramm USR1023N.

USR9178N

Die API USR9178N dient zur Pflege von lokalen Store Clock-Werten. Sie unterstützt Store Clock mit gleitendem Jahr-Fenster (1971 - 2114).

Bei der Funktion C gibt die API die folgenden aktuellen Werte zurück:

  • Lokaler Store Clock

  • UTC Store Clock

  • Zeitdifferenz in 1/10 Sekunden

  • Lokale Uhrzeit (Ortszeit) in Mikrosekunden

  • UTC-Uhrzeit in Mikrosekunden

  • Lokale Uhrzeit (Ortszeit) im Natural-Format (T)

  • UTC-Uhrzeit im Natural-Format (T)

  • Standard-DATETIME

  • Zeitzone

Bei der Funktion L konvertiert die API einen lokalen Store Clock-Wert in die anderen Formate.

Bei der Funktion U konvertiert die API einen UTC Store Clock-Wert und eine Zeitdifferenz in die anderen Formate.

Zusätzlich zu der API stehen die folgenden Copycodes zur Verfügung:

  • USR9178X - Aktuellen lokalen Store Clock, UTC Store Clock und Zeitdifferenz abfragen.

  • USR9178Y - Lokalen Store Clock in UTC Store Clock und Zeitdifferenz konvertieren.

  • USR9178Z - UTC Store Clock und Zeitdifferenz in lokalen Store Clock konvertieren.

USR9201N

Die API USR9201N ist der Nachfolger der API USR1023N. Sie unterstützt Store Clock mit gleitendem Jahr-Fenster (1971 - 2114) und erweiterten Store Clock (1900 - 38434).

Als Eingabe erwartet die API USR9201N eines der folgenden Formate:

  • Natural-Datum und Uhrzeit,

  • Natural-Uhrzeit,

  • Natural-Datum,

  • Mikrosekunden (seit 01.01.1900),

  • Store Clock mit gleitendem Jahr-Fenster oder

  • erweiterten Store Clock.

Die API USR9201N konvertiert die Eingabe in alle anderen Formate.

Zusätzlich stehen zur API USR9201N die folgenden Copycodes zur Verfügung:

Copycode Funktion
USR9201R Store Clock mit gleitendem Jahr-Fenster in erweiterten Store Clock konvertieren.
USR9201S Erweiterten Store Clock in Store Clock mit gleitendem Jahr-Fenster konvertieren.
USR9201U Mikrosekunden in erweiterten Store Clock konvertieren.
USR9201V Erweiterten Store Clock in Mikrosekunden konvertieren.
USR9201W Mikrosekunden in Store Clock mit gleitendem Jahr-Fenster konvertieren.
USR9201X Mikrosekunden in Natural-Uhrzeit konvertieren.
USR9201Y Store Clock mit gleitendem Jahr-Fenster in Mikrosekunden konvertieren.
USR9201Z Natural-Uhrzeit in Mikrosekunden konvertieren.
USR9201D Zeitdifferenz von zwei Store Clock Werten mit gleitendem Jahr-Fenster berechnen.

Anmerkung:
Der Copycode USR9201D kann auch benutzt werden, um zwei Store Clock-Werte miteinander zu vergleichen, wenn diese innerhalb des gleitenden Jahr-Fensters (1971 - 2114) erfasst worden sind.

Übersicht über die Copycodes

Die Copycodes sind wesentlich schneller als das API Subprogramm USR9201N.

Beispiel - Store Clock mit gleitendem Jahr-Fenster in Mikrosekunden konvertieren

Für einen Test mit 10.000 Konvertierungen benötigt:

  • das Subprogramm USR9201N etwa 35 ms und

  • der Copycode USR9201Y etwa 5 ms.