MN 4.4, XNTP and Time Change

[Fairfield, Ken :CO IR]

Folks, I need (yet another) sanity check on instructions from our
primary vendor, Cerner. See below for our vital statistics, but
basically, MN 4.4 on VMS 7.3-2 with XNTP patched to 030, and very
vanilla NTP configuration parameters.

For the time change, our local procedure consists of the following
semi-manual steps:

1) Disable XNTP
2) At 2AM PDT, $ Set Time/Cluster 1:00:00

(Yes, this caught my eye as I'd very much prefer a
"SYSMAN> conf set time 0-1:00:00" which I'll probably use.
Main point is that the time is changed manually.)

3) Invoke Sys$Manager:UTC$Time_Setup with parameters correct
for PST (in this case) to change the system TDF and
Sys$TimeZone_* logical names
3) Submit a batch job that runs 8 HOURS LATER to restart XNTP.


QUESTIONS:

Cerner documentation purports to quote *Process* saying,

"If you are going to use an automated time change procedure,
XNTP should be disabled during the time change and NOT BE
RESTARTED FOR 6 TO 8 HOURS." [emphasis mine]

1) Is this correct?
2) Does it apply only for *automated* time change, e.g., with
AUTO_DLIGHT_SAV
set to 1?
3) Does XNTP have some sort of very long "memory" of something? I would
have thought merely stopping and restarting XNTP would get you a
"fresh"
synchronization, etc.

And finally:

4) I just noticed the NTP.DRIFT on our system is at version ;32767 and
was last modified on 22-SEP-2007 (oops!). Our systems seem to be well
synched. Do I need to rename this back to ;1, or will XNTP continue
to function properly as is?


Thanks very much, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Who: my-first-initial-full-last-name
Where: lhs -dot- org


----------------------------------------------------------------------------
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AXP V7.3-2
$
$ sear multinet:multinet_version ntp
XREPLACED NTPDATE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPQ.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPTRACE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED START_XNTPD_COM.VUF XNTP-020_A044 24-JUN-2003
XREPLACED XNTPD.VUI XNTP-020_A044 24-JUN-2003
XREPLACED XNTPDC.VUI XNTP-020_A044 24-JUN-2003
XREPLACED LOADABLE_XNTP_CONTROL.VUI XNTP-030_A044
11-MAR-2007
XREPLACED MULTINET_SOCKET_LIBRARY.VUI XNTP-030_A044
11-MAR-200
7
XREPLACED NTPDATE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPQ.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPTRACE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED START_XNTPD_COM.VUF XNTP-030_A044 11-MAR-2007
XREPLACED TIMEZONES_DAT.VUF XNTP-030_A044 11-MAR-2007
XREPLACED XNTPD.VUI XNTP-030_A044 11-MAR-2007
XREPLACED XNTPDC.VUI XNTP-030_A044 11-MAR-2007
$
$ type multinet:ntp.conf
;=========================================
;
; XNTP Configuration File
; Created by user LHSREW
; Created at 2-DEC-2003 15:06:34.22
;
;=========================================
;
server ntpserver1
server ntpserver2
----------------------------------------------------------------------------



IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely
for the entity or individual to whom it is addressed. If you are not the
intended recipient, you should contact the sender and delete the message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment, is
intended to be a legally binding signature.

[Richard Whalen]

I would say that the "rule" would apply to any mechanism that would set
the clock outside of the use of XNTP, particularly when leaving daylight
saving time for standard time. XNTP refers to the time when the clocks
fall backwards as the "twilight zone". Restarting XNTP on a system that
has entered the twilight zone could result in a double set back. I
would wait at least an hour to restart XNTP.

The statement about not restarting XNTP for 6+ hours may be due to fears
about trying to synchronize with systems that are slewing their clocks
rather than stepping their clocks. Current documentation says that
systems that slew their clocks should never be used as time servers.

The code does not appear to have anything in it to deal with the drift
file getting to the maximum version number, so I would recommend
renaming it back to ;1.

-----Original Message-----
From: Fairfield, Ken :CO IR [mailto:***@LHS.ORG]
Sent: Friday, October 26, 2007 3:11 PM
To: info-***@process.com
Subject: MN 4.4, XNTP and Time Change

Folks, I need (yet another) sanity check on instructions from our
primary vendor, Cerner. See below for our vital statistics, but
basically, MN 4.4 on VMS 7.3-2 with XNTP patched to 030, and very
vanilla NTP configuration parameters.

For the time change, our local procedure consists of the following
semi-manual steps:

1) Disable XNTP
2) At 2AM PDT, $ Set Time/Cluster 1:00:00

(Yes, this caught my eye as I'd very much prefer a
"SYSMAN> conf set time 0-1:00:00" which I'll probably use.
Main point is that the time is changed manually.)

3) Invoke Sys$Manager:UTC$Time_Setup with parameters correct
for PST (in this case) to change the system TDF and
Sys$TimeZone_* logical names
3) Submit a batch job that runs 8 HOURS LATER to restart XNTP.


QUESTIONS:

Cerner documentation purports to quote *Process* saying,

"If you are going to use an automated time change procedure,
XNTP should be disabled during the time change and NOT BE
RESTARTED FOR 6 TO 8 HOURS." [emphasis mine]

1) Is this correct?
2) Does it apply only for *automated* time change, e.g., with
AUTO_DLIGHT_SAV
set to 1?
3) Does XNTP have some sort of very long "memory" of something? I
would
have thought merely stopping and restarting XNTP would get you a
"fresh"
synchronization, etc.

And finally:

4) I just noticed the NTP.DRIFT on our system is at version ;32767
and
was last modified on 22-SEP-2007 (oops!). Our systems seem to be
well
synched. Do I need to rename this back to ;1, or will XNTP
continue
to function properly as is?


Thanks very much, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Who: my-first-initial-full-last-name
Where: lhs -dot- org


------------------------------------------------------------------------
----
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AXP V7.3-2
$
$ sear multinet:multinet_version ntp
XREPLACED NTPDATE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPQ.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPTRACE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED START_XNTPD_COM.VUF XNTP-020_A044
24-JUN-2003
XREPLACED XNTPD.VUI XNTP-020_A044 24-JUN-2003
XREPLACED XNTPDC.VUI XNTP-020_A044 24-JUN-2003
XREPLACED LOADABLE_XNTP_CONTROL.VUI XNTP-030_A044
11-MAR-2007
XREPLACED MULTINET_SOCKET_LIBRARY.VUI XNTP-030_A044
11-MAR-200
7
XREPLACED NTPDATE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPQ.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPTRACE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED START_XNTPD_COM.VUF XNTP-030_A044
11-MAR-2007
XREPLACED TIMEZONES_DAT.VUF XNTP-030_A044 11-MAR-2007
XREPLACED XNTPD.VUI XNTP-030_A044 11-MAR-2007
XREPLACED XNTPDC.VUI XNTP-030_A044 11-MAR-2007
$
$ type multinet:ntp.conf
;=========================================
;
; XNTP Configuration File
; Created by user LHSREW
; Created at 2-DEC-2003 15:06:34.22
;
;=========================================
;
server ntpserver1
server ntpserver2
------------------------------------------------------------------------
----



IMPORTANT NOTICE: This communication, including any attachment,
contains
information that may be confidential or privileged, and is intended
solely
for the entity or individual to whom it is addressed. If you are not
the
intended recipient, you should contact the sender and delete the
message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment,
is
intended to be a legally binding signature.

[n***@metso.com]

I always run the command procedure for time setup
sys$manager:utc$time_setup.com
interactively to fix up the TDF.

It should be submittable, but I question the comments.

The interactive prompt for TDF seems to be in (plus/minus)hh:mm
while the comment says the parameters for TDF and offset are in
minutes (and doesn't explain what the "offset" is, by the way).
The TDF is usually in (plus/minus)hh:mm and the offset is
usually in (plus/minus)seconds.
What would be the correct values to go back to EST?
(I do not have DTSS running.)

Do I want:

$ @ sys$manager:Utc$time_setup.com "" "TDF" "-300" "-300"

or some other values?

I am using Multinet XNTP which does not do the TDF.

-Norm
=====

"MULTINET_TIMEZONE" = "EDT"
SYS$TIMEZONE_DIFFERENTIAL" = "-14400"

=========

$ @ sys$manager:Utc$time_setup.com "" show

AUTO_DLIGHT_SAV is set to "1". [Not used with DTSS off]
OpenVMS will automatically change to/from Daylight Saving Time.
(in timezones that use Daylight Saving Time)

The logical name SYS$TIMEZONE_RULE is not defined
The logical name SYS$TIMEZONE_NAME is not defined
The logical name SYS$TIMEZONE_DAYLIGHT_SAVING is not defined

LOCAL TIME ZONE = EASTERN / US -- STANDARD TIME
LOCAL SYSTEM TIME = 26-OCT-2007 15:31:22.36
()
TIME DIFFERENTIAL FACTOR = -4:00
TIME ZONE RULE =

=======
$!* [SYSMGR]UTC$TIME_SETUP.COM
$! Author: Charles Hammond
$!
$! Created: 27 March 2000

===

You selected EASTERN / US as your time zone.
Is this correct? (Yes/No) [YES]:


Configuring the Time Differential Factor (TDF)




The Time Differential Factor (TDF) is the difference between your
system time and Coordinated Universal Time (UTC). UTC is similar
in most respects to Greenwich Mean Time (GMT).

The TDF is expressed as hours and minutes, and should be entered
in the hh:mm format. TDFs for the Americas will be negative
(-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor:

===

$! P3: optional only if function TDF is specified
$! Invalid with any other function
$! The time differential factor (TDF) in minutes
$! Option is to prompt for TDF
$!
$! P4: optional only if function TDF is specified
$! Invalid with any other function
$! The system time offset in minutes
$! Default is to prompt for time offset
$!

===

Post by Fairfield, Ken :CO IR
Folks, I need (yet another) sanity check on instructions from our
primary vendor, Cerner. See below for our vital statistics, but
basically, MN 4.4 on VMS 7.3-2 with XNTP patched to 030, and very
vanilla NTP configuration parameters.
For the time change, our local procedure consists of the following
1) Disable XNTP
2) At 2AM PDT, $ Set Time/Cluster 1:00:00
(Yes, this caught my eye as I'd very much prefer a
"SYSMAN> conf set time 0-1:00:00" which I'll probably use.
Main point is that the time is changed manually.)
3) Invoke Sys$Manager:UTC$Time_Setup with parameters correct
for PST (in this case) to change the system TDF and
Sys$TimeZone_* logical names
3) Submit a batch job that runs 8 HOURS LATER to restart XNTP.
Cerner documentation purports to quote *Process* saying,
"If you are going to use an automated time change procedure,
XNTP should be disabled during the time change and NOT BE
RESTARTED FOR 6 TO 8 HOURS." [emphasis mine]
1) Is this correct?
2) Does it apply only for *automated* time change, e.g., with
AUTO_DLIGHT_SAV
set to 1?
3) Does XNTP have some sort of very long "memory" of something? I

would

Post by Fairfield, Ken :CO IR
have thought merely stopping and restarting XNTP would get you a
"fresh"
synchronization, etc.
4) I just noticed the NTP.DRIFT on our system is at version ;32767

and

Post by Fairfield, Ken :CO IR
was last modified on 22-SEP-2007 (oops!). Our systems seem to be

well

Post by Fairfield, Ken :CO IR
synched. Do I need to rename this back to ;1, or will XNTP

continue

Post by Fairfield, Ken :CO IR
to function properly as is?
Thanks very much, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209
Who: my-first-initial-full-last-name
Where: lhs -dot- org

----------------------------------------------------------------------------

Post by Fairfield, Ken :CO IR
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AXP V7.3-2
$
$ sear multinet:multinet_version ntp
XREPLACED NTPDATE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPQ.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPTRACE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED START_XNTPD_COM.VUF XNTP-020_A044

24-JUN-2003

Post by Fairfield, Ken :CO IR
XREPLACED XNTPD.VUI XNTP-020_A044 24-JUN-2003
XREPLACED XNTPDC.VUI XNTP-020_A044 24-JUN-2003
XREPLACED LOADABLE_XNTP_CONTROL.VUI XNTP-030_A044
11-MAR-2007
XREPLACED MULTINET_SOCKET_LIBRARY.VUI XNTP-030_A044
11-MAR-200
7
XREPLACED NTPDATE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPQ.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPTRACE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED START_XNTPD_COM.VUF XNTP-030_A044

11-MAR-2007

Post by Fairfield, Ken :CO IR
XREPLACED TIMEZONES_DAT.VUF XNTP-030_A044 11-MAR-2007
XREPLACED XNTPD.VUI XNTP-030_A044 11-MAR-2007
XREPLACED XNTPDC.VUI XNTP-030_A044 11-MAR-2007
$
$ type multinet:ntp.conf
;=========================================
;
; XNTP Configuration File
; Created by user LHSREW
; Created at 2-DEC-2003 15:06:34.22
;
;=========================================
;
server ntpserver1
server ntpserver2

----------------------------------------------------------------------------

Post by Fairfield, Ken :CO IR
[snip]

[Bennett, Carl]

All,

I don't know what I'm missing here, but as long as I have
AUTO_DLIGHT_SAV set to 1 and the correct XNTP patches, daylight savings
changes just happen.

We've tested here a number of times and have updated all of
our client sites (~150) to use it and time change has become something
of a non-issue.



We run Multinet 4.4 on OpenVMS Alpha 7.3-2 and Multinet 5.1
on OpenVMS Alpha / I64 8.3









________________________________

From: ***@metso.com [mailto:***@metso.com]
Sent: Friday, October 26, 2007 4:18 PM
To: info-***@process.com
Subject: Re: MN 4.4, XNTP and Time Change




I always run the command procedure for time setup
sys$manager:utc$time_setup.com
interactively to fix up the TDF.

It should be submittable, but I question the comments.

The interactive prompt for TDF seems to be in (plus/minus)hh:mm
while the comment says the parameters for TDF and offset are in
minutes (and doesn't explain what the "offset" is, by the way).
The TDF is usually in (plus/minus)hh:mm and the offset is
usually in (plus/minus)seconds.
What would be the correct values to go back to EST?
(I do not have DTSS running.)

Do I want:

$ @ sys$manager:Utc$time_setup.com "" "TDF" "-300" "-300"

or some other values?

I am using Multinet XNTP which does not do the TDF.

-Norm
=====

"MULTINET_TIMEZONE" = "EDT"
SYS$TIMEZONE_DIFFERENTIAL" = "-14400"

=========

$ @ sys$manager:Utc$time_setup.com "" show

AUTO_DLIGHT_SAV is set to "1". [Not used with DTSS off]
OpenVMS will automatically change to/from Daylight Saving Time.
(in timezones that use Daylight Saving Time)

The logical name SYS$TIMEZONE_RULE is not defined
The logical name SYS$TIMEZONE_NAME is not defined
The logical name SYS$TIMEZONE_DAYLIGHT_SAVING is not defined

LOCAL TIME ZONE = EASTERN / US -- STANDARD TIME
LOCAL SYSTEM TIME = 26-OCT-2007 15:31:22.36
()
TIME DIFFERENTIAL FACTOR = -4:00
TIME ZONE RULE =

=======
$!* [SYSMGR]UTC$TIME_SETUP.COM
$! Author: Charles Hammond
$!
$! Created: 27 March 2000

===

You selected EASTERN / US as your time zone.
Is this correct? (Yes/No) [YES]:


Configuring the Time Differential Factor (TDF)




The Time Differential Factor (TDF) is the difference between your
system time and Coordinated Universal Time (UTC). UTC is similar
in most respects to Greenwich Mean Time (GMT).

The TDF is expressed as hours and minutes, and should be entered
in the hh:mm format. TDFs for the Americas will be negative
(-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor:

===

$! P3: optional only if function TDF is specified
$! Invalid with any other function
$! The time differential factor (TDF) in minutes
$! Option is to prompt for TDF
$!
$! P4: optional only if function TDF is specified
$! Invalid with any other function
$! The system time offset in minutes
$! Default is to prompt for time offset
$!

===

Post by Fairfield, Ken :CO IR
Folks, I need (yet another) sanity check on instructions from our
primary vendor, Cerner. See below for our vital statistics, but
basically, MN 4.4 on VMS 7.3-2 with XNTP patched to 030, and very
vanilla NTP configuration parameters.
For the time change, our local procedure consists of the following
1) Disable XNTP
2) At 2AM PDT, $ Set Time/Cluster 1:00:00
(Yes, this caught my eye as I'd very much prefer a
"SYSMAN> conf set time 0-1:00:00" which I'll probably use.
Main point is that the time is changed manually.)
3) Invoke Sys$Manager:UTC$Time_Setup with parameters correct
for PST (in this case) to change the system TDF and
Sys$TimeZone_* logical names
3) Submit a batch job that runs 8 HOURS LATER to restart XNTP.
Cerner documentation purports to quote *Process* saying,
"If you are going to use an automated time change procedure,
XNTP should be disabled during the time change and NOT BE
RESTARTED FOR 6 TO 8 HOURS." [emphasis mine]
1) Is this correct?
2) Does it apply only for *automated* time change, e.g., with
AUTO_DLIGHT_SAV
set to 1?
3) Does XNTP have some sort of very long "memory" of something? I would
have thought merely stopping and restarting XNTP would get you a
"fresh"
synchronization, etc.
4) I just noticed the NTP.DRIFT on our system is at version ;32767 and
was last modified on 22-SEP-2007 (oops!). Our systems seem to be well
synched. Do I need to rename this back to ;1, or will XNTP continue
to function properly as is?
Thanks very much, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209
Who: my-first-initial-full-last-name
Where: lhs -dot- org

------------------------------------------------------------------------
----

Post by Fairfield, Ken :CO IR
$ mu show/vers
Process Software MultiNet V4.4 Rev A-X, hp AlphaServer GS1280 7/1300,
OpenVMS AXP V7.3-2
$
$ sear multinet:multinet_version ntp
XREPLACED NTPDATE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPQ.VUI XNTP-020_A044 24-JUN-2003
XREPLACED NTPTRACE.VUI XNTP-020_A044 24-JUN-2003
XREPLACED START_XNTPD_COM.VUF XNTP-020_A044

24-JUN-2003

Post by Fairfield, Ken :CO IR
XREPLACED XNTPD.VUI XNTP-020_A044 24-JUN-2003
XREPLACED XNTPDC.VUI XNTP-020_A044 24-JUN-2003
XREPLACED LOADABLE_XNTP_CONTROL.VUI XNTP-030_A044
11-MAR-2007
XREPLACED MULTINET_SOCKET_LIBRARY.VUI XNTP-030_A044
11-MAR-200
7
XREPLACED NTPDATE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPQ.VUI XNTP-030_A044 11-MAR-2007
XREPLACED NTPTRACE.VUI XNTP-030_A044 11-MAR-2007
XREPLACED START_XNTPD_COM.VUF XNTP-030_A044

11-MAR-2007

Post by Fairfield, Ken :CO IR
XREPLACED TIMEZONES_DAT.VUF XNTP-030_A044

11-MAR-2007

Post by Fairfield, Ken :CO IR
XREPLACED XNTPD.VUI XNTP-030_A044 11-MAR-2007
XREPLACED XNTPDC.VUI XNTP-030_A044 11-MAR-2007
$
$ type multinet:ntp.conf
;=========================================
;
; XNTP Configuration File
; Created by user LHSREW
; Created at 2-DEC-2003 15:06:34.22
;
;=========================================
;
server ntpserver1
server ntpserver2

------------------------------------------------------------------------
----

Post by Fairfield, Ken :CO IR
[snip]

Attention:
The information contained in this message and or attachments 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
of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you've
received this in error, please contact the sender and delete the
material from any system and destroy any copies.
--------------------------------------------------------------------------------
This email message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal
--------------------------------------------------------------------------------

[Fairfield, Ken :CO IR]

Post by n***@metso.com
I always run the command procedure for time setup
sys$manager:utc$time_setup.com
interactively to fix up the TDF.

In my new job, I "discovered" that you can execute UTC$TIME_SETUP with
parameters and avoid having to answer prompts. :-) See below...

Post by n***@metso.com
It should be submittable, but I question the comments.

Yes.

Post by n***@metso.com
The interactive prompt for TDF seems to be in (plus/minus)hh:mm
while the comment says the parameters for TDF and offset are in
minutes (and doesn't explain what the "offset" is, by the way).
The TDF is usually in (plus/minus)hh:mm and the offset is
usually in (plus/minus)seconds.
What would be the correct values to go back to EST?

I think you want the following for EST (TDF is -5 hours = -300 minutes,
right?):

@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0

The last parameter (P4 = 0) says *don't* change the system time. If
you *do* want to change the system time, set P4 to the number of minutes
you want to change, so:

@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 -60

[snip]

Post by n***@metso.com
I am using Multinet XNTP which does not do the TDF.

See Richard Whalen's remarks about XNTP and time changes. I take his
answer to be, shut down XNTP during the time change.

OTOH, see also Carl Bennett's response that he "just leaves XNTP running",
albeit with AUTO_DLIGHT_SAV set to 1... YMMV

---
On a related but separate subject, it seems that when doing UTC$TIME_SETUP
on a system where the logical SYS$TIMEZONE_RULE is define, only the only
logical changed is SYS$TIMEZONE_DIFFERENTIAL. In particular, neither
SYS$TIMEZONE_NAME nor SYS$TIMEZONE_DAYLIGHT_SAVING are changed. I've just
spend <more time than I care to admit> tracing through the system startup
procedures, etc., to figure out where/when those get defined on system
boot.

Through various circuitous paths, during VMS$BASEENVIRON-050-VMS, will
execute Sys$Startup:TDF$UTC_Startup.Com (if present). That file invokes
Sys$System:TDF$Set_Timezone.Exe with appropriate parameters. But the
command file takes an early exit if Sys$Timezone_Rule is defined.

So I experimented on a test system. If I Deassign/System/Exec
SYS$TIMEZONE_RULE
logical and then execute Sys$Startup:TDF$UTC_Startup.Com, *all* the
Sys$Timezone*
logicals get updated, as well as the system TDF in EXE$GQ_TDF. :-)

I don't know what would happen if you were to do this at "02:01 PDT", one
minute past the time change, but it looks like an interesting alternative.
OTOH, setting AUTO_DLIGHT_SAV to 1 is probably easier and more robust (but
requires a system reboot since it's not dynamic).

Cheers, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Who: MyFirstInitialMyFullLastName
Where: lhs -dot- org



IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely
for the entity or individual to whom it is addressed. If you are not the
intended recipient, you should contact the sender and delete the message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment, is
intended to be a legally binding signature.

[Kosko, Michael]

Thanks =)

-----Original Message-----
From: Fairfield, Ken :CO IR [mailto:***@LHS.ORG.]
Sent: Friday, October 26, 2007 5:30 PM
To: info-***@process.com.
Cc: Fairfield, Ken :CO IR
Subject: RE: MN 4.4, XNTP and Time Change

Post by n***@metso.com
I always run the command procedure for time setup
sys$manager:utc$time_setup.com
interactively to fix up the TDF.

In my new job, I "discovered" that you can execute UTC$TIME_SETUP with
parameters and avoid having to answer prompts. :-) See below...

Post by n***@metso.com
It should be submittable, but I question the comments.

Yes.

Post by n***@metso.com
The interactive prompt for TDF seems to be in (plus/minus)hh:mm
while the comment says the parameters for TDF and offset are in
minutes (and doesn't explain what the "offset" is, by the way).
The TDF is usually in (plus/minus)hh:mm and the offset is
usually in (plus/minus)seconds.
What would be the correct values to go back to EST?

I think you want the following for EST (TDF is -5 hours = -300 minutes,
right?):

@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0

The last parameter (P4 = 0) says *don't* change the system time. If
you *do* want to change the system time, set P4 to the number of minutes
you want to change, so:

@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 -60

[snip]

Post by n***@metso.com
I am using Multinet XNTP which does not do the TDF.

See Richard Whalen's remarks about XNTP and time changes. I take his
answer to be, shut down XNTP during the time change.

OTOH, see also Carl Bennett's response that he "just leaves XNTP
running",
albeit with AUTO_DLIGHT_SAV set to 1... YMMV

---
On a related but separate subject, it seems that when doing
UTC$TIME_SETUP
on a system where the logical SYS$TIMEZONE_RULE is define, only the only
logical changed is SYS$TIMEZONE_DIFFERENTIAL. In particular, neither
SYS$TIMEZONE_NAME nor SYS$TIMEZONE_DAYLIGHT_SAVING are changed. I've
just
spend <more time than I care to admit> tracing through the system
startup
procedures, etc., to figure out where/when those get defined on system
boot.

Through various circuitous paths, during VMS$BASEENVIRON-050-VMS, will
execute Sys$Startup:TDF$UTC_Startup.Com (if present). That file invokes
Sys$System:TDF$Set_Timezone.Exe with appropriate parameters. But the
command file takes an early exit if Sys$Timezone_Rule is defined.

So I experimented on a test system. If I Deassign/System/Exec
SYS$TIMEZONE_RULE
logical and then execute Sys$Startup:TDF$UTC_Startup.Com, *all* the
Sys$Timezone*
logicals get updated, as well as the system TDF in EXE$GQ_TDF. :-)

I don't know what would happen if you were to do this at "02:01 PDT",
one
minute past the time change, but it looks like an interesting
alternative.
OTOH, setting AUTO_DLIGHT_SAV to 1 is probably easier and more robust
(but
requires a system reboot since it's not dynamic).

Cheers, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209

Who: MyFirstInitialMyFullLastName
Where: lhs -dot- org



IMPORTANT NOTICE: This communication, including any attachment,
contains
information that may be confidential or privileged, and is intended
solely
for the entity or individual to whom it is addressed. If you are not
the
intended recipient, you should contact the sender and delete the
message.
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment,
is
intended to be a legally binding signature.

[n***@metso.com]

Post by Fairfield, Ken :CO IR

Post by n***@metso.com
I always run the command procedure for time setup
sys$manager:utc$time_setup.com
interactively to fix up the TDF.

In my new job, I "discovered" that you can execute UTC$TIME_SETUP with
parameters and avoid having to answer prompts. :-) See below...

Post by n***@metso.com
It should be submittable, but I question the comments.

Yes.

Post by n***@metso.com
The interactive prompt for TDF seems to be in (plus/minus)hh:mm
while the comment says the parameters for TDF and offset are in
minutes (and doesn't explain what the "offset" is, by the way).
The TDF is usually in (plus/minus)hh:mm and the offset is
usually in (plus/minus)seconds.
What would be the correct values to go back to EST?

I think you want the following for EST (TDF is -5 hours = -300 minutes,
@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0

This looks exactly right, thanks.

Now if one were to submit it, would that be at 2:00:30 am?
One would want it to run after the second 2:00am, yes or it would
run too early?
Or would one submit something to run at the first
1:59:00 to submit it to run at the second 1:01 am (Oops, that would
release, not hold)? [I guess that'w why they made it a sysgen
parameter....]

Post by Fairfield, Ken :CO IR
The last parameter (P4 = 0) says *don't* change the system time. If
you *do* want to change the system time, set P4 to the number of minutes
@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 -60
[snip]

Post by n***@metso.com
I am using Multinet XNTP which does not do the TDF.

See Richard Whalen's remarks about XNTP and time changes. I take his
answer to be, shut down XNTP during the time change.
OTOH, see also Carl Bennett's response that he "just leaves XNTP

running",

Post by Fairfield, Ken :CO IR
albeit with AUTO_DLIGHT_SAV set to 1... YMMV
---
On a related but separate subject, it seems that when doing

UTC$TIME_SETUP

Post by Fairfield, Ken :CO IR
on a system where the logical SYS$TIMEZONE_RULE is define, only the only
logical changed is SYS$TIMEZONE_DIFFERENTIAL. In particular, neither
SYS$TIMEZONE_NAME nor SYS$TIMEZONE_DAYLIGHT_SAVING are changed. I've

just

Post by Fairfield, Ken :CO IR
spend <more time than I care to admit> tracing through the system

startup

Post by Fairfield, Ken :CO IR
procedures, etc., to figure out where/when those get defined on system
boot.
Through various circuitous paths, during VMS$BASEENVIRON-050-VMS, will
execute Sys$Startup:TDF$UTC_Startup.Com (if present). That file invokes
Sys$System:TDF$Set_Timezone.Exe with appropriate parameters. But the
command file takes an early exit if Sys$Timezone_Rule is defined.
So I experimented on a test system. If I Deassign/System/Exec
SYS$TIMEZONE_RULE
logical and then execute Sys$Startup:TDF$UTC_Startup.Com, *all* the
Sys$Timezone*
logicals get updated, as well as the system TDF in EXE$GQ_TDF. :-)
I don't know what would happen if you were to do this at "02:01 PDT",

one

Post by Fairfield, Ken :CO IR
minute past the time change, but it looks like an interesting

alternative.

Post by Fairfield, Ken :CO IR
OTOH, setting AUTO_DLIGHT_SAV to 1 is probably easier and more robust

(but

Post by Fairfield, Ken :CO IR
requires a system reboot since it's not dynamic).
Cheers, Ken
--
Ken Fairfield
System Administrator, Information Resources
Legacy Health System
1919 NW LoveJoy, Portland, OR 97209
Who: MyFirstInitialMyFullLastName
Where: lhs -dot- org
IMPORTANT NOTICE: This communication, including any attachment,

contains

Post by Fairfield, Ken :CO IR
information that may be confidential or privileged, and is intended

solely

Post by Fairfield, Ken :CO IR
for the entity or individual to whom it is addressed. If you are not

the

Post by Fairfield, Ken :CO IR
intended recipient, you should contact the sender and delete the

message.

Post by Fairfield, Ken :CO IR
Any unauthorized disclosure, copying, or distribution of this message is
strictly prohibited. Nothing in this email, including any attachment,

is

Post by Fairfield, Ken :CO IR
intended to be a legally binding signature.

[Ken Fairfield]

[...]

Post by n***@metso.com

Post by Fairfield, Ken :CO IR

Post by n***@metso.com
What would be the correct values to go back to EST?

I think you want the following for EST (TDF is -5 hours = -300 minutes,
@Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0

This looks exactly right, thanks.
Now if one were to submit it, would that be at 2:00:30 am?
One would want it to run after the second 2:00am, yes or it would
run too early?
Or would one submit something to run at the first
1:59:00 to submit it to run at the second 1:01 am (Oops, that would
release, not hold)? [I guess that'w why they made it a sysgen
parameter....]

...Sorry to be so late in following up to this...

To answer your question, it depends mostly on whether you have
any applications that care about UTC, and therefore the TDF,
being correct precisely at the time change. My personal take
is that having the TDF be changed in precise synchronization
with the time change is not particularly important. But if
that's what you want, you can tell UTC$TIME_SETUP to do both
the time change and the TDF change, right? (I don't recall how
you said you change the time, but it sounded separate from
UTC$TIME_SETUP.)

I suppose you could change the TDF at 01:59:59 EDT, then have
the clock jump back at 02:00:00 EDT to be 01:00:00 EST and
you'd be fine. You can't submit a job to run at 02:00:01 EDT,
but change the clock back an hour at 02:00:00 and expect that
job to release in the next second: it will, of course wait
until 02:00:01 EST (you having changed the system clock). And
neither can you submit to run at 01:00:01 "EST" because that
time will have come and gone while you were still in EDT.

Another thing you could do, but I think it's going to way too
much work, would be to submite a job to release at 01:59:59,
bnut then have it $ Wait 00:00:02 (or however many seconds you
want) so that it changes the TDF one second past the time change.
But like I said...

----
I re-read your prevoius post where you show the output of
@sys$manager:utc$time_setup show. That output implies you
have AUTO_DLIGHT_SAV set to 1. It also shows that most of
the SYS$TIMEZONE_* logicals are *not* defined.

It seems to me the easiest/most reliable thing for you to do
would be to go through UTC$TIME_SETUP once, with prompting, and
set up your timezone correctly, once and for all. Then with
AUTO_DLIGHT_SAV already set to 1, let VMS change everything for
you automatically: the time, the TDF, the logical names,
everything. The only thing you need to do (if I'e understood
your configuration) is to shutdown XNTP before the time change,
let the "twilight zone" hour pass, and then restart XNTP.
(That's certainly my plan next time, or if I ever, get to reboot
the cluster to change AUTO_DLIGHT_SAV...)

-Ken