Here, our processor's HMC gets time from one of our routers, which gets time from NIST (the HMC can go directly to NIST but I found firewalls were troublesome). The HMC then steers the processor's time. zOS doesn't know what's going on, I think, other than seasonal time changes. This has been a very stable config for many years.
I've used plain language above instead of the jargon and complexity "Time people" seem to love. See Redbook: Server Time Protocol Implementation Guide http://publib-b.boulder.ibm.com/abstracts/sg247281.html?Open Ken Smith State of Maryland On Tue, Dec 22, 2015 at 1:05 PM, Paul Gilmartin < [email protected]> wrote: > On Tue, 22 Dec 2015 10:28:38 -0600, John McKown wrote: > > > >But you could use a custom NTP client to change the _local_ time by > >adjusting the offset. The simplest way would be to just have your NTP > >client code do a 'T CLOCK=' command. This doesn't change the TOD hardware > >clock. It does not affect the TIME macro if you requiest "GMT" time. But > it > >will reset the local time. Oh, this is _not_ going to help if you problem > >is that you are trying to get Kerberos or some other SSL process to work > >because I'm fairly sure that they use the TOD hardware clock (STCK or > STCKE > >instruction). > > > What about fudging CVTLSO which ought to get TIME GMT correct? If > Kerberos, > etc. need to avoid UTC skew they must be CVTLSO-savvy even if they STCK. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
