On 09/12/2013 06:55 AM, Shmuel Metz (Seymour J.) wrote: > In > <of811b14da.8838eb3f-on48257be4.0035cc4f-48257be4.00386...@sg.ibm.com>, > on 09/12/2013 > at 06:14 PM, Timothy Sipples <[email protected]> said: > >> OK, so that's where you'd like to draw the "no additional >> charge"/"separately chargeable" line. > > I can see several possibilities. In order of preference: > > 1. Using NTP to set the TOD forward by a small amount. > > 2. Using NTP to set a virtual TOD forward by a small amount. > > 3. Using NTP to set the TOD at the next POR. > > Note that I am not suggesting the ability to set the TOD backwards, > nor do I consider it desirable to use clock steering to correct major > discrepancies unless an IPL is totally unacceptable. > > Have their been any discussions at Share about this issue? I assume > that it's only the small shops that would be interested; the large > ones presumably need STP due to multi-CEC configurations. >
Forward-only nudging wouldn't be very useful unless the TOD clock was also deliberately designed to always run a hair slow (is it?). Perhaps that can be done and yet have TOD relative accuracy still good enough for those installations not using any external time synchronization that need TOD drift to be "minimal". Although conceptually I like the idea of being able to provide a cheaper NTP option, if you allow z/OS time to jump discontinuously as on UNIX systems with NTP and that happens very often, you will be introducing strange anomalies into SMF data that might make it impossible to rely on measured transaction response times. I would say proceed with caution. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
