On Wed, 11 Sep 2013 12:12:14 -0500, John McKown wrote: >The "problem" is that z/OS _cannot_ allow the TOD clock (hardware clock) to >go "backwards". The way that STP addresses this is that the STP software >can "speed up" or "slow down" the TOD increment pulse (or whatever it's >called). This is the hardware portion of STP. And I think that hardware >addition is a major portion of the cost of getting STP. > Aren't the facilities of STP and all its "speed up" and "slow down" registers and the instructions to manipulate them described in the P[rO]ps? Or does this presume the customer has paid for (enabling) the hardware? (I'm cynical enough to assume it's there anyway; you just need to pay for the key.)
Suppose a customer has a z running nothing but Linux in LPARs? How does its time get set? I understand that in the day Linux (also VM) was ETR-ignorant. >If your application software can be written to use the z/OS software (TIME >macro et al.) timing interfaces, getting the _local_ time, then it is >possible to have a NTP "steer" this by adjusting the GMT to local offset >value in the CVT. This is basically doing a periodic SET CLOCK=hh.mm.ss >type command. I assume everybody can understand the problem because there >would now be no way to actually relate the TOD clock values to the current >"software clock" values. > Yuck! If I were doing this, I'd "steer" CVTLSO (isn't its range sufficient?) rather than CVTLDTO. At least that would get GMT correct also. Even with the best facilities provided by IBM, STCKCONV gives results in error by the value of CVTLSO at the time of the STCK. (I'm guessing; IBM refuses to document the behavior, claiming it's "common knowledge".) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
