IFS Problem..

[takeoff/400]

Hallo Forum,
wenn wir aus der 400er ein file (z.b. pdf) ins IFS senden und mittels netzlaufwerk hin verbinden, so hat dieses object im IFS eine erstellungszeit um exact 1 stunde höher als tatsächlich. im IFS mittels navigator stimmt die zeit genau mit der tatsächlichen erstellungzeit überein. es tritt nur mittels netzlaufwerk auf und tritt bei jedem object auf. d.h. die erstellugszeit ist in der zukunft !?
kennt dieses problem jemand, wir sind völlig ratlos..
lg,
michael gruber:confused:

[Fuerchau]

Datum Uhrzeit einer IFS-Datei (auch bei Unix/Windwos) wird in GMT abgelegt.
GMT wird aktuell gerechnet aus Systemzeit - QUTCOFFSET.

Da wir nun Sommerzeit haben, steht der QUTCOFFSET wohl immer noch auf '+01:00', so dass bei der Windowsanzeige eben 2 Stunden draufgerechnet werden.

Set V5R3 kann man die Sommer/Winterzeitumstellung incl. QUTCOFFSET automatisieren.

[takeoff/400]

ja, in diesem wert steht +1:00:00 drinnen, kann den aber nicht ändern, dürfte nur mit qsecofr funktionieren. gut, ich werde das testen, aber komisch ist, dass es nur auftritt, wenn man sich mittels netzlaufwerk verbindet, direkt über den navigator ist die zeit ja richtig.
werde das mit diesem wert weiterverfolgen, vielen dank für die prompte antwort!!

[Fuerchau]

Der OpsNav nimmt natürlich die AS/400-Systemzeit und berücksichtigt QUTCOFFSET.

Bei Netzlaufwerk wird die Zeit eben aus dem Windows in GMT umgerechnet und an den IFS-Server übermittelt.

Hintergrund:
Nur wenn alle Objekte weltweit die GMT-Zeit als Erstell-/Änderungsdatum enthalten ist eine korrekte Sortierung und Kontrolle möglich.
Daher ist es wichtig, dass alle beteiligten System neben der Uhrzeit natürlich auch ihre aktuelle Zeitzone berücksichtigen müssen.

PS:
Ich bekomme auch schon mal Mails aus der Zukunft, da wohl Notes bei falscher Konfiguration sowohl die eigene Zeitzone als auch die Windowszeitzone berechnet.
Denn auch bei Mails gilt:
Alle Zeitmarken sind intern GMT und werden je nach System-Einstellung in die lokale Zeit umgerechnet.

[takeoff/400]

:D ja, vielen dank. ich hab den hintergrund verstanden, und auch den QTIMZON auf
QP0100CET2 geändert, damit ist das problem mit dem NLW behoben. ich bin dann neugierig ob die nächste sommer/winterzeit umstellung auch wirklich automatisch durchgeführt wird vom system. das müsste dann über den SNTP-server laufen, denk ich mir..

vielen dank nochmal für die infos..

mfg,
michael gruber

[Fuerchau]

Der SNTP server ist hierzu nicht erforderlich, die Zeitumstellung läuft voll automatisch (bereits erfolgreich getestet).

Ein SNTP-Server ist nur für die Synchronisation erforderlich.
Übrigens gilt auch hier QUTCOFFSET da auch die SNTP-Zeit grundsätzlich GMT ist.

Steht der SNTP-Server nicht korrekt auf der Sommerzeit kann es auch hier zu Problemen kommen.

[mmaschke]

QP0100CET4 ist der richtige Wert bei QTIMZON.

Bei QP0100CET2 wir die Uhrzeit im Oktober schon um 2 Uhr
und nicht um 3 Uhr umgestellt.

MFG

Manfred Maschke