And if we had known about Server Time Protocol when we specced our z9, we would have gone with that, since it is a FAR better solution. As you say, the own code approach is playing with fire.
Peter -----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: August 2, 2011 13:10 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Modifying the System Clock on a Running VM System On Tuesday, 08/02/2011 at 10:08 EDT, peter.w...@ttc.ca wrote: > Yes, it can and has been done. As you say, it works well for forward > adjustments; CP abends on backward adjustments. For our old Multiprise 2000, > which ran slow, it was fine. Our z9 runs fast, so we no longer use it. I don't deny that you have had success with it, but hopefully folks recognize that adjusting the time in this fashion is kind of like bending space-time. If it were that simple, trust me, it would have been done already. - There are timers active throughout CP that must be revisited when the clock is set. But what to do? Was the timer meant to represent a delay interval or a specific time of day (e.g. midnight)? - Some of those timers represent *guest* timers. CP has no idea what kind of time that represents (interval or absolute), so.... - Virtual machine epochs must be updated in order to avoid time jumps. (CP doesn't virtualize STP/ETR timing signals.) - CP time services (DIAGs) will "jump", putting them out of sync with VTOD. Sir Rob's reference to CMS' use of both time sources now comes into play. - Timers that were scheduled to pop within the compressed time interval will now pop all at once. - Missing interrupt timers may be triggered. On current machines, normal oscillator-induced drift and small external time reference changes are automatically corrected by the TOD Clock Steering Facility (see Principles of Operations for gory details). Large changes in time (for small values of "large") are handled through time sync checks in which the host is notified of a problematic difference in time. That is, one that cannot be steered in a reasonable amount of time. It is then the host's responsibility to evaluate what it needs to do and do it, including issuing the necessary PTFF or SCK instructions. So, no surprise, IBM recommends AGAINST any use of such a mod on your VM system. (Of course, don't let that stifle your curiosity and experimentation to determine the possible effects of malleable space-time on virtual machines!) Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
