On Wednesday, 05/21/2008 at 12:45 EDT, Dave Jones <[EMAIL PROTECTED]> wrote: > A client has just installed a z10 system, with the STP server and NTP client > support enabled. In one LPAR there is z/OS 1.9 running and exploiting an > external time reference to keep it's LPAR time accurate.
With STP, you don't need an NTP client running in z/OS. z/OS will see the "temporal displacement" alerts generated by STP. The time shifts generated by STP are triggered by the NTP or other external time reference support. > With the new z/10 > STP and NTP client functions available, can the time in the z/VM LPAR also > be kept in sync with the time in the z/OS LPAR? If so, could this also be > used to keep Linux guests' time in sync as well? z/VM (CP) does not support STP and does not virtualize it. The fact that STP is getting its time via NTP doesn't matter. When the LPAR is activated, the "current" time will be given to the LPAR and the drift begins, with CP and all guests drifting together. But that's not as bad as it might seem. It has been true for some time that small changes in time due to normal clock drift have been dealt with by adjustments to the LPAR TOD clock with no STP or Sysplex Timer support required, making the TOD appear to advance at a slower or faster rate, as required to allow the TOD to "drift" back into sync again. This is called "TOD steering". Only when the operator sets the time or when the NTP/ETR connection to the external time reference has been disconnected for a significant period of time (days/weeks) does the clock drifted sufficiently to require STP/Sysplex Timer support in the operating system. Alan Altmark z/VM Development IBM Endicott
