On Tue, Dec 22, 2015 at 10:17 AM, Pommier, Rex <[email protected]> wrote:
> Hi Craig, > > Not quite the same question. We already have NTP running on the windows > boxes. I was asked if the mainframe could participate as a client, getting > its time from a windows based NTP server. > If you mean "steer the TOD clock" (i.e. speed it up or slow it down to slowly synchronize it), then the answer is NO. That requires the STP hardware to do. Even if you could do an SCK (Set Clock) instruction to set the TOD clock, you would most likely cause z/OS to hard wait because there is _NO_ API into z/OS to tell it you did it. If you set it backwards, you are guaranteed to hard wait. 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). > > Thanks, > > Rex > -- Computer Science is the only discipline in which we view adding a new wing to a building as being maintenance -- Jim Horning Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
