Wer hat an der Uhr gedreht

[Fuerchau]

Da es ja schon lange die Sommer/Winterzeit gibt, sollte inzwischen auch SAP das Problem nicht mehr haben.
Und was Datenbanktransaktionen angeht so dürfte keine DB mit einer verstellten Uhr ein Problem haben, wie Dieter schon sagte.

Ich weiß ja nun nicht, was der erste FSP ist, aber der sollte doch nur geringfügig andere Zeit haben (< 1 Sekunde) als die Hauptpartition, die man ja mit NTP aktuell halten kann.
Die AS/400 selber ist nun mal leider nicht Mehrzonenfähig!
D.h., dass die Systemzeit immer die lokale Zeit ist und per UTCOFFSET dann in die GMT-Zeit umgerechnet werden kann.
Bei Unix/Windows ist das genau umgedreht. Die Zeit ist immer GMT und die Zeitzone bestimmt die lokale Zeit.

Wenn man nun mehrere LPAR's mit unterschiedlichen Zeitzonen einrichten will wüsste ich im Moment nicht, ob das überhaupt geht.
Das Setzen von QTIME/QDATE setzt ja auch die Maschinenzeit.
Wenn ich das in einer LPAR mache, haben die anderen LPAR's dann auch plötzlich die neue Zeit?
Kann das mal jemand ausprobieren?
Andererseits würde das ja obiges Problem erklären, wenn ich definitiv eine andere Zeitzone auf der LPAR haben will.

[holgerscherer]

Wenn man nun mehrere LPAR's mit unterschiedlichen Zeitzonen einrichten will wüsste ich im Moment nicht, ob das überhaupt geht.
Das Setzen von QTIME/QDATE setzt ja auch die Maschinenzeit.

Klar geht das. Die Maschinenzeit wird bei partitionierten Kisten nicht modifiziert, das wäre ja fatal, und ab 10 Partitionen etwas unübersichtlich.