![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I'm investigating the use of the freeware tool SETCLOCK.COM for our upcoming transition to daylight-wastings-time. On an Alphaserver 2100 running VMS V6.2-1H3, it seems that the EXE$GL_TIMEADJUST value decays much more rapidly than SETCLOCK is expecting, causing a time change of only about 34 seconds over a few minutes rather than 1 hour over 5 hours. Just from observing the EXE$GL_TIMEADJUST value with SDA and my watch, it looks like it should be more like 6199200 rather than the 175770 that comes in SETCLOCK. Am I right? We have a variety of Alphaservers; could this value be different depending on the particular model Alphaserver? The system in question is running DECnet phase IV and UCX V3.3 with no time servers configured. The Answer is : Please contact the author of the SETCLOCK tool for assistance. Neither Compaq nor OpenVMS Wizard are in a position to provide support for OpenVMS Freeware packages. For information on the EXE$GL_TIMEADJUST and EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see _OpenVMS AXP Internal and Data Structures", circa page 348. EXE$GQ_SYSTIME - quadword that contains the current system time. EXE$GL_SYSTICK - The standard clock tick when DECdtss is not running or is not performing an adjustment. The default value is typically 100000. EXE$GL_TICKLENGTH - This is the increment that is added to the clock at each hardware clock interrupt. Values are in 100ns units. EXE$GL_TIMEADJUST - This is the number of ticks for which the EXE$GL_TICKLENGTH value applies. When EXE$GL_TICKLENGTH reaches 0, the TICKLENGTH is restored to the EXE$GL_SYSTICK default. EXE$GL_DTSFLAGS - DECdtss flags. Bit 0 is set if DTSS is active. The OpenVMS Wizard suspects the value found in TICKLENGTH is valid, but the value for TIMEADJUST should be set to %hex 01194000 (18432000 decimal). You should also be aware that the SETCLOCK program must execute on the primary CPU in an SMP system (with multiple active CPUs).
|