RE: MN 4.4, XNTP and Time Change

"Fairfield, Ken :CO IR" <KFairfield@LHS.ORG> wrote on 10/26/2007 05:29:56
PM:
[color=blue]
> Norm Raphael wrote:
>[color=green]
> > I always run the command procedure for time setup
> > sys$manager:utc$time_setup.com
> > interactively to fix up the TDF.[/color]
>
> In my new job, I "discovered" that you can execute UTC$TIME_SETUP with
> parameters and avoid having to answer prompts. :-) See below...
>[color=green]
> > It should be submittable, but I question the comments.[/color]
>
> Yes.
>[color=green]
> > 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?[/color]
>
> 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
>[/color]

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....]
[color=blue]
> 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]
>[color=green]
> > I am using Multinet XNTP which does not do the TDF.[/color]
>
> 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[/color]
running",[color=blue]
> albeit with AUTO_DLIGHT_SAV set to 1... YMMV
>
> ---
> On a related but separate subject, it seems that when doing[/color]
UTC$TIME_SETUP[color=blue]
> 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[/color]
just[color=blue]
> spend <more time than I care to admit> tracing through the system[/color]
startup[color=blue]
> 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",[/color]
one[color=blue]
> minute past the time change, but it looks like an interesting[/color]
alternative.[color=blue]
> OTOH, setting AUTO_DLIGHT_SAV to 1 is probably easier and more robust[/color]
(but[color=blue]
> 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,[/color]
contains[color=blue]
> information that may be confidential or privileged, and is intended[/color]
solely[color=blue]
> for the entity or individual to whom it is addressed. If you are not[/color]
the[color=blue]
> intended recipient, you should contact the sender and delete the[/color]
message.[color=blue]
> Any unauthorized disclosure, copying, or distribution of this message is
> strictly prohibited. Nothing in this email, including any attachment,[/color]
is[color=blue]
> intended to be a legally binding signature.[/color]

[email]norm.raphael@metso.com[/email] wrote:[color=blue]
> "Fairfield, Ken :CO IR" <KFairfield@LHS.ORG> wrote on 10/26/2007 05:29:56
> PM:
>[color=green]
>> Norm Raphael wrote:
>>[/color][/color]
[...][color=blue][color=green][color=darkred]
>>> What would be the correct values to go back to EST?[/color]
>> 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
>>[/color]
>
> 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....][/color]

....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
--
Ken & Ann Fairfield
What: Ken dot And dot Ann
Where: Gmail dot Com