Verarbeitung von Store Clock-Werten

#### Search Results

Search

# 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

- Wie das Jahr-2042-Problem gelöst werden kann

- Store Clock-Wert mit gleitendem Jahr-Fenster

- Erweiterter Store Clock

- Smarter Store Clock

- Übergang zum smartem Store Clock

- Lokaler Store Clock

- Natural-APIs zur Store Clock-Verarbeitung

## Der originale Store Clock und das Jahr-2042-Problem

Die Natural-Systemvariable `*TIMESTMP` liefert den maschineninternen Store Clock-Wert, wie er durch die Großrechner-Maschineninstruktion `STCK` (Store Clock Format) bereitgestellt wird. Der Store Clock ist ein 8 Byte langes binäres Feld. 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.

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. Ein `READ`-Statement, das die genannten Werte als Start- und Endwerte verwendet, wird keinen Wert zurückgeben, da der Endwert kleiner ist als der Startwert.

- 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.

Die Zeit, in der wir nur Store Clock-Werte kleiner als das Rücksprungdatum (17.09.2042) verarbeiten, bezeichnen wir als Übergangszeit. Während dieser Zeit sollten die ursprünglichen Store Clock-Werte durch einen der in den folgenden Abschnitten beschriebenen Lösungsansätze ersetzt werden.

## Wie das Jahr-2042-Problem gelöst werden kann

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

1. Temporärer Ansatz: Store Clock mit gleitendem Jahr-Fenster.
   Der Store Clock mit gleitendem Jahr-Fenster interpretiert den Store Clock-Wert in einem gleitendem Jahr-Fenster. Er unterstützt den Zeitbereich von 1971 bis 2114. Die binären Werte können nicht zum Sortieren oder Vergleichen verwendet werden.

2. Genereller Ansatz: Erweiterter Store Clock.
   Der erweiterte Store Clock ist 16 Bytes lang und unterstützt den Zeitbereich von 1900 bis 38434. Die binären Werte können zum Sortieren und Vergleichen verwendet werden. Erweiterte Store Clock-Werte sind nicht kompatibel zu Store Clock-Werten (weder original noch mit gleitendem Jahr-Fenster). Daten und Programme, die sich auf Store Clock-Werte beziehen, müssen in einem einzigen, großen Schritt auf erweiterte Store Clock-Werte umgestellt werden.

3. Smarter Ansatz: Smarter Store Clock
   Der smarte Store Clock ist 9 Bytes lang und unterstützt den Zeitbereich von 1900 bis 38434. Die binären Werte können zum Sortieren und Vergleichen verwendet werden. Während der Übergangszeit sind die smarten Store Clock-Werte mit den originalen Store Clock-Werten kompatibel. Daten und Programme, die sich auf Store Clock-Werte beziehen, können schrittweise in Smart Store Clock-Werte umgewandelt werden. Dies ist der empfohlene Ansatz, um das Jahr-2042-Problem zu lösen.

Für diese Ansätze stehen in der Natural System Library SYSEXT (siehe auch SYSEXT Utility) Anwendungsprogrammierschnittstellen (APIs) zur Verfügung, siehe Natural-APIs zur Store Clock-Verarbeitung.

## 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 smarte oder 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 smarte oder 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 genutzt 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 smarten oder zum erweiterten Store Clock bietet der Store Clock mit gleitendem Jahr-Fenster die folgenden temporären Vorteile:

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

- Datenkonvertierung (im Vergleich zum erweiterten Store Clock
  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 nur einen geringen Änderungsaufwand. 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:

- 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 chronologischer Reihenfolge sein. Siehe Anmerkung weiter oben.

## Erweiterter Store Clock

Die Natural-Systemvariable `*TIMESTMPX` liefert den maschineninternen erweiterten Store Clock-Wert, so wie er durch die Großrechner-Instruktion `STCKE` (Store Clock Extended Format) zur Verfügung gestellt wird. 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.

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.

- Erweiterte Store Clock-Werte sind nicht kompatibel mit Store Clock-Werten im Format B8. Es ist nicht möglich, einen Store Clock-Wert in einen erweiterten Store Clock-Wert zu verschieben oder umgekehrt.

  Beispiel:

      #STORECLOCK: DD943485BC302002

      MOVE #STORECLOCK TO #EXTENDED

      Erhalten: 0000000000000000DD943485BC302002
      Erwartet: 00DD943485BC30200200000000000000

- 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). Der erweiterte Store Clock-Wert enthält sieben auf der rechten Seite hinzugefügte zusätzliche Bytes. Daher wird ein Vergleich kein richtiges 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.

- Wenn Store Clock-Werte im Format B8 in Adabas gespeichert werden, müssen Sie die Daten so editieren, dass das neue Feld vom Format B16 richtige erweiterte Store Clock-Werte enthält.

- Jedes Programm, das Store Clock-Werte verarbeitet, muss an erweiterte Store Clock-Werte angepasst werden. Weil aber Store Clock-Werte und erweiterte Store Clock-Werte nicht kompatibel sind, müssen die Änderungen in einem einzigen Schritt erledigt werden.

- Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie sie durch eine API ersetzen, die den erweiterten Store Clock-Wert unterstützt.

- Diese komplette Konvertierung erfordert größere Änderungen.

- Es wird empfohlen, statt des erweiterten Store Clock den smarten Store Clock zu verwenden. Dies wird im folgenden Abschnitt beschrieben.

## Smarter Store Clock

Der smarte Store Clock ist ein 9 Byte langes binäres Feld. Es 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 Zeitdarstellung des originalen Store Clock wird in Byte 2 bis 9 beibehalten. Auf der linken Seite wird ein zusätzliches Überlaufbyte hinzugefügt, der so genannte Epochen-Index. Mit anderen Worten: Der smarte Store Clock umfasst die ersten 9 Bytes des erweiterten Store Clock.

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

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

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

- Konvertierung
  Zum Konvertieren von smarten Store Clock-Werten können Natural-APIs benutzt werden. Weil jeder smarte Store Clock-Wert im smarten Store Clock-Wertebereich eindeutig ist, ist die Interpretation immer richtig.

- Berechnung einer Zeitdifferenz
  Zum Konvertieren von smarten 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 smarten 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 9 Bytes.

- Während des Übergangszeitraums:

  - Erhöht man die Länge des originalen Store Clock-Wertes von B8 nach B9, erhält man den richtigen smarten Store Code-Wert. Der Grund dafür ist, dass in Natural und Adabas binäre Felder rechtsbündig sind. Durch Vergrößerung der Länge wird das Überlaufbyte mit `H'00'` gefüllt.

  - Smarte Store Clock-Werte sind kompatibel mit originalen Store Clock-Werten. Man kann einen originalen Store Clock-Wert in einen smarten Store Clock-Wert verschieben und umgekehrt.

    Beispiel:

        #STORECLOCK: DD943485BC302002

        MOVE #STORECLOCK TO #SMART

        Erhalten: 00DD943485BC302002
        Erwartet: 00DD943485BC302002

  - Smarte Store Clock-Werte können mit originalen Store Clock-Werten verglichen werden.

- Jedes Programm, das Store Clock-Werte verarbeitet, muss an smarte Store Clock-Werte angepasst werden. Weil Store Clock-Werte und smarte Store Clock-Werte kompatibel sind, können die Änderungen schrittweise erledigt werden.

- Falls Ihre Anwendung eine Natural API aufruft, die den originalen Store Clock-Wert unterstützt, müssen Sie sie durch eine API ersetzen, die den smarten Store Clock-Wert unterstützt.

- Diese komplette Konvertierung erfordert geringfügige Änderungen.

## Übergang zum smartem Store Clock

- Datendefinition in Natural ersetzen

- Aktuellen Store Clock-Wert erhalten

- Store Clock-Wert verschieben

- Aufruf eines Subprogramms durchführen

- Store Clock-Werte vergleichen

- Felddefinition in Adabas ändern

- Superdeskriptor-Definition in Adabas anpassen

### Datendefinition in Natural ersetzen

Ein Feld, das Store Clock-Werte enthält, wird wie folgt definiert:

    1 #TIMESTMP (B8)   /* Originaler Store Clock-Wert

Ersetzen Sie die Definition durch:

    1 #TIMESTMP (B9)   /* Smarter Store Clock-Wert

### Aktuellen Store Clock-Wert erhalten

Um den aktuellen Store Clock-Wert zu erhalten, wird das folgende Statement ausgeführt:

    MOVE *TIMESTMP TO #TIMESTMP   /* Aktuellen Store Clock-Wert ermitteln

Während des Übergangszeitraums kann das Statement noch verwendet werden, auch wenn die Länge von `#TIMESTMP` auf B9 erhöht worden ist. Langfristig sollte das Statement aber ersetzt werden durch:

    INCLUDE USR9201F '*TIMESTMPX' '#TIMESTMP' /* Aktuellen Store Clock-Wert ermitteln

Alternativ können Sie aber auch eine Redefinition durchführen:

    1 #TIMESTMPX (B16)   /* Erweiterter Store Clock-Wert
    1 REDEFINE #TIMESTMPX
      2 #TIMESTMP (B9)   /* Smarter Store Clock-Wert

Und das folgende Statement verwenden:

    MOVE *TIMESTMPX TO #TIMESTMPX /* Aktuellen Store Clock-Wert ermitteln

### Store Clock-Wert verschieben

Während des Übergangszeitraums können Store Clock-Werte von einem zum anderen verschoben werden, auch wenn die Länge des einen B9 und die des anderen noch B8 ist.

    MOVE #TIMESTMP-A TO #TIMESTMP-B   /* Store Clock-Wert verschieben

### Aufruf eines Subprogramms durchführen

Bei einem Subprogramm wird ein Store Clock-Wert als Parameter verwendet:

    1 #TIMESTMP (B8)   /* Store Clock-Wert

Wenn Sie die Länge des Feldes auf B9 erhöhen und es Programme gibt, die es mit B8 aufrufen, wird das Programm fehlschlagen. Verwenden Sie in diesem Fall die folgende Definition:

    1 #TIMESTMP (B9) BY VALUE RESULT  /* Store Clock-Wert

Sobald alle Aufrufer Store Clock-Werte im Format B9 verwenden, kann das `BY VALUE RESULT` entfernt werden.

### Store Clock-Werte vergleichen

Während des Übergangszeitraums können Store Clock-Werte miteinander verglichen werden, auch wenn die Länge des einen Werts B9 ist und die des anderen noch B8 ist.

    IF #TIMESTMP-A > #TIMESTMP-B   /* Store Clock-Werte vergleichen

### Felddefinition in Adabas ändern

Ein Feld, das Store Clock-Werte enthält, wird wie folgt definiert:

    1,AA,8,B,...

Ersetzen Sie die Definition durch:

    1,AA,9,B,...

Auf dem Großrechner können Sie dies mit dem Adabas Online Service oder dem Dienstprogramm ADADBS (Database Services) erreichen, unter Linux und Windows mit dem Dienstprogramm ADAFDU (File Definition). Beachten Sie, dass unter Linux und Windows ein Feld, das Store Clock-Werte enthält, mit der Option HF (high order first) definiert werden muss.

Aufgrund der Änderung der Länge enthält die Datenbank gültige smarte Store Clock-Werte. Es ist nicht notwendig, die Daten zu bearbeiten. Handelt es sich bei dem Feld um einen Deskriptor, liefert es die richtige chronologische Reihenfolge.

Auf der Natural-Seite müssen Sie das Datendefinitionsmodul (DDM) entsprechend ändern. Falls eine Länge angegeben ist, müssen Sie außerdem die zugehörigen Datensichten (Views) ändern.

### Superdeskriptor-Definition in Adabas anpassen

Ein Feld `AA`, das Store Clock-Werte enthält, wird als übergeordnetes Feld eines Superdeskriptors verwendet:

    SA=AC(1,20),AA(1,8)

Während des Übergangszeitraums kann der Superdeskriptor auch dann noch weiterverwendet werden, wenn die Feldlänge des übergeordneten Feldes auf 9 Bytes erhöht worden ist. Das liegt daran, dass die Bytes in einem binären Feld von rechts nach links gezählt werden.

Langfristig sollte das Statement aber ersetzt werden durch:

    SA=AC(1,20),AA(1,9)

Alle Variablen in Natural-Programmen (z.B. Start- und Endwerte), die sich auf den Superdeskriptor beziehen, müssen zusammen mit den Datenbankänderungen angepasst werden. Alternativ können Sie auch den ursprünglichen Superdeskriptor beibehalten und zusätzlich einen neuen Superdeskriptor mit der neuen Länge anlegen. Dann können Sie ein Programm nach dem anderen auf den neuen Superdeskriptor umstellen. Sobald alle Programme auf den neuen Superdeskriptor zugreifen, kann der alte Superdeskriptor freigegeben (gelöscht) werden.

## 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 in der Sommer- oder der Winterzeit.

#### 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 Zeitdifferenz 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 Jahr-Fenster | Smart / Erweitert
USR1009N | Store Clock mit gleitendem Jahr-Fenster 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 Variablen 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), smarten 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,

- erweiterten Store Clock oder

- smarten 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
--- | ---
USR9201D | Zeitdifferenz von zwei Store Clock Werten mit gleitendem Jahr-Fenster berechnen.
USR9201F | Erweiterten Store Clock in smarten Store Clock konvertieren.
USR9201G | Smarten Store Clock in erweiterten Store Clock konvertieren.
USR9201H | Store Clock mit gleitendem Jahr-Fenster in smarten Store Clock konvertieren.
USR9201I | Smarten Store Clock in Store Clock mit gleitendem Jahr-Fenster konvertieren.
USR9201J | Mikrosekunden in smarten Store Clock konvertieren.
USR9201K | Smarten Store Clock in Mikrosekunden konvertieren.
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.

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.

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.

### On this page

- Der originale Store Clock und das Jahr-2042-Problem
- Wie das Jahr-2042-Problem gelöst werden kann
- Store Clock-Wert mit gleitendem Jahr-Fenster
- Erweiterter Store Clock
- Smarter Store Clock
- Übergang zum smartem Store Clock
- Lokaler Store Clock
- Natural-APIs zur Store Clock-Verarbeitung