HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Daylight Savings Time Change

 
Mike O'Malley
Occasional Visitor

Daylight Savings Time Change

It's that time of year 8-( ... It seems that every year we muck something up and our clock change gets undone when DTSS is restarted. For fallback we like to adjust the clock slowly to avoid two instances of the same time. What we did last October:
.
1. Stop DTSS
2. Run a program that will slow the clock down by adjusting the EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST system data cells.
After 2:00am (3:00am if no time change was performed)
3. Run DTSS$SET_TIMEZONE INITIALIZE
4. Start DTSS
At this point when DTSS was started the time on the system was 2:20am. After DTSS started it set all the clocks back to 1:20amâ a second fallback.
.
This year we will add the following before starting DTSS:
3.5 run UTC$CONFIGURE_TDF SET -420 "" "" NOSETTIME
.
Any GURU out there knows for sure that this will do the trick?
.
Thanks for input,
...Mi
5 REPLIES
Mike Naime
Honored Contributor

Re: Daylight Savings Time Change


Not 100% positive here, but in my old procedures I note that we used DTSS$SET_TIMEZONE MODIFY to change the timezone on the running systems. Since we switched to an NTP time server, we have DTSS turned off.
VMS SAN mechanic
Martin P.J. Zinser
Honored Contributor

Re: Daylight Savings Time Change

Which version of OpenVMS do you run? According to the Wizard over at

http://h71000.www7.hp.com/wizard/wiz_8589.html

DTSS should be DST aware as of OpenVMS 7.3.

I personally use NTP too and have AUTO_DLIGHT_SAV enabled, so no first hand experience with DTSS.
Ian Miller.
Honored Contributor

Re: Daylight Savings Time Change

depending on VMS and UCX version (i.e. if not current versions) you may need to adjust the TDF in UCX as well. The CRTL uses whatever TDF UCX knows about. For UCX pre V5
This sort of thing is needed.
$ UCX SET CONFIG TIME "GMT0 BST1,3.26.0/2,10.31.0/2"
$ UCX GENERATE TIME

For TCPWARE
NETCU SET TIMEZONE BST
____________________
Purely Personal Opinion
Mike O'Malley
Occasional Visitor

Re: Daylight Savings Time Change

I've found that the images I've described in my initial post are indeed the correct images to use but with different parameters. I will be using the following commands:

$! Set EXE$GQ_TDF data cell to correct
$! value, update SYS$TIMEZONE.DAT
$ MCR UTC$CONFIGURE_TDF.EXE SET -420 "" "" ""
$
$! Update all sys$timezone logicals, update
$! DTSS$TIMEZONE_DIFFERENTIAL.DAT. This
$! image will verify the need to update the
$! system time if EXE$GQ_TDF is not the new
$! timezone value.
$ MCR DTSS$SET_TIMEZONE /VERBOSE MODIFY

...Mike
Willem Grooters
Honored Contributor

Re: Daylight Savings Time Change

After heaving read this all, a word of "warning".
One of my customers reported a problem due to _switching_ time backward (all times AM, automaticly recorded (= system time...))
An incident was reported at 2:30, a unit reported "on location" at 2:40, and reported free 3:15 (summertime) - but since time changes at 3:00 over here, the recorded time was 2:15. All times stored as generated.
This causes trouble, of course, when these times are passed to other systems (as we found out) or are being analysed (this incident for instance has a NEGATIVE duration).
_Swtiching_ the clock foreward is less problematic but could impose similar problems.
What would be the best (or less worse) solution here? Full overhaul of the whole system is out of the question (it concerns a number of (loosely coupled) applications), nor stopping the systems for an hour...
Willem Grooters
OpenVMS Developer & System Manager