On Nov 3, 2009, at 00:21, Rob van der Heij wrote:
On Mon, Nov 2, 2009 at 10:50 PM, Paul Gilmartin
<[email protected]> wrote:
Is there a stage that talks to OpenEdition CMS? (I have _no_
experience with OpenEdition CMS.) If so, all that's necessary
is to capture the output of "TZ=GMT0 date".
(In TSO it's easy enough with "address SYSCALL".)
This is cheating. Sure, if you assume the operating system has the
right time, you just ask there...
So it's cheating to ask your own OS, but not cheating to ask
a remote OS? What if your system lacks network connection?
A pipeline to encode and decode the NTP packets should not be that
hard. But even with a pipeline that can handle those you probably
still need to follow the protocol that does several requests to
eliminate the effect of network latency. This is why the ntp client
takes a while to "stabilize" before it adjusts the OS correction
factors.
When synchronizing primary clocks it's important to avoid the
effect of network latency. For a single call by an application,
it's pretty safe to assume that the time returned occurred at
some point during the latent interval, good enough for many
purposes.
I vaguely recall a CP option that causes the TOD clock to be
stored in NUCON when a VM is dispatched. Enable that; issue
any DIAG that causes your VM to be redispatched; decode the
TOD from NUCON, and voila! GMT.
-- gil
