topic Re: pathworks time not moving to DST in Operating System - OpenVMS

pathworks time not moving to DST

Dean McGorrill — Mon, 12 Mar 2007 18:35:08 GMT

We moved our alpha servers to the new DST
using utc$time_setup.com. The system time
moved aok, logicals look ok. we then shutdown
and brought pathworks back up, but pathworks
won't take the new time. we tried several
iterations, no luck. anyone know why it ignores the system clock? the pathworks
book says it is supposed to pick it up ?

tx if any help Dean

Re: pathworks time not moving to DST

Martin Hughes — Tue, 13 Mar 2007 03:06:22 GMT

Hi Dean, welcome to ITRC forums :-)

It has been a few years since I touched Pathworks, but I checked the manual and with V7.* it does seem that Pathworks should just take the new system timezone settings after a restart. All I could suggest is re-check your logicals. If all is ok then I would log a call with HP, assuming you have a support agreement.

Failing that, you might want to post some more details, versions etc. Also, are you running the timesource service? perhaps you could post the info from your lanman.ini file.

Re: pathworks time not moving to DST

Dean McGorrill — Tue, 13 Mar 2007 10:28:15 GMT

Hi Martin
tx for the reply. we are actually
in az where the time doesn't move, however since we saw it in the field, I reproduced it here. the systems logicals are

"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.US]MOUNTAIN."

"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "-21600"
"SYS$TIMEZONE_NAME" = "MST"
"SYS$TIMEZONE_RULE" = "MST7"

eg local time
ENGDS2::MCGORRILL 09:20:27 (DCL)

then a net time from a PC

C:\>net time \\engds2
Current time at \\engds2 is 2/13/2007 8:21 AM

it should have moved.
a look at the pathworks pathworks logs shows
its still back on MST.
12-MAR-2007 17:03:55.08 20402253:007325C0 GMTinit: timezone = 25200 12-MAR-2007 17:03:55.09 20402253:007325C0 GMTinit: daylight = 1

any ideas?

Re: pathworks time not moving to DST

Ian Miller. — Tue, 13 Mar 2007 11:22:43 GMT

could it be that the version of pathworks that you are running is written in C and the CRTL has its own rules built in (for which there where patch kits for supported versions).

Re: pathworks time not moving to DST

Ian Miller. — Tue, 13 Mar 2007 11:34:32 GMT

which TCPIP stack are you using? If HP TCP/IP then try
$ ucx show conf time

If wrong then try setting the correct values
$ UCX SET CONFIG TIME "xxx"
$ UCX GENERATE TIME

Re: pathworks time not moving to DST

Dean McGorrill — Tue, 13 Mar 2007 12:58:44 GMT

tx Ian,
you may be on to something, from the log..
13-MAR-2007 10:36:29.31 2040272A:007325C0 Using OpenVMS V7 DEC C time logicals <<<
13-MAR-2007 10:36:29.32 2040272A:007325C0 GMTinit: timezone = 25200

I don't see any logicals. Anyway, I see
now its behavior is, if daylight savings
is set, pathworks takes the system time
and subtracts an hour! thus if my alpha
is at 11am, pathworks offers 10am. why
would it do that?

ucx, we're using tcpip which doesn't use config time anymore..

TCPIP> sho conf time

TIME configuration

Value: not defined
Differential: not defined

PLEASE NOTE WELL:

These values are from the configuration DB but are not actually used by TCPIP.

TCPIP uses the system service SYS$GETUTC() to find the
timezone differential information used by the operating system.
Setting and showing this information is described in the
OpenVMS System Management documentation.

This command is supplied for minimal compatability with UCX command files.
Use of this command is currently depricated. This command may be removed
in a future version of TCPIP.

Re: pathworks time not moving to DST

Dave Gudewicz — Tue, 13 Mar 2007 13:41:05 GMT

>"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
>"SYS$TIMEZONE_DIFFERENTIAL" = "-21600"
>"SYS$TIMEZONE_NAME" = "MST"
>"SYS$TIMEZONE_RULE" = "MST7"

Wonder if this might be a concern.

The TIMEZONE_DIFFERENTIAL of -21600 listed above does not match the TIMEZONE_RULE of MST7.

MST7 should = -24200

I checked our Advanced Server here ( vms 7.3-2/Adv. Serv. v 7.3B) and the time was OK.

Re: pathworks time not moving to DST

Dave Gudewicz — Tue, 13 Mar 2007 15:35:00 GMT

MST7 should = -24200

Oops. Make that -25200

Re: pathworks time not moving to DST

Dean McGorrill — Tue, 13 Mar 2007 15:44:24 GMT

Dave,
you may be right. I took what utc$time_setup calculated which for this test was -6
6*3600=-21600. I thought maybe it was rules for the crtl. I'd tested that by moving
the vms time ahead a few months, so we'd know we were in what was DST. pathworks still removed an hour.
One fix is to run utc$time_setup and enable
daylight savings and but add an extra -TDF hour to what utc$time_setup calculates. making it -7 instead of -6 pathworks offers time matching the system. Or run utc$time_setup, set for no daylight savings, then it calculates -7 anyway. pathworks offers time matching the system as well. so if it has to be 25200, why did
utc$time_setup calculate -6 (21600)?

Re: pathworks time not moving to DST

Hoff — Tue, 13 Mar 2007 16:18:44 GMT

utc$time_setup.com sets the timezone and the defaults for various of the components, but you can still need the definitions loaded and zic'd, or the TDF and TZ ECOs loaded; there are still pieces that access and use the system timezone definitions.

I haven't seen any details on the OpenVMS version posted, which in conjunction with the discussion here would lead me to assume it isn't V7.3-2 or one of the other supported releases.

Fixing this is several steps, depending on the version and the installed products. I've posted a list of the wrinkles I know about over at http://64.223.189.234/node/72

On the plus side, this error will probably fix itself in about three weeks or so. :-)

Stephen Hoffman
HoffmanLabs

Re: pathworks time not moving to DST

Dean McGorrill — Tue, 13 Mar 2007 16:28:25 GMT

yes, visiting the problem again in 3 weeks or so is a worry. the version is vms7.2-1
I didn't think there was autotime zone in
this version. do you think there will be
a problem in a few weeks?

Re: pathworks time not moving to DST

Ian Miller. — Tue, 13 Mar 2007 16:56:34 GMT

in a few weeks will be the original date for start of DST and the CRTL(?) built in rules will change to DST.

I wonder if you have been caught by the sign change in the DST rules.

Re: pathworks time not moving to DST

Hoff — Tue, 13 Mar 2007 19:51:40 GMT

Dean, has the system been re-loaded and re-zic'd with the new DST rules?

If not, start there.

If you are not familiar with zic or the TZ rules -- which was most folks in the US, prior to this exercise -- I've posted a pointer previously.

Problems with the GMT sign change -- positive values west of the prime meridian for the POSIX TZ and now some of the GMT offsets, and negative for UTC-style offsets west of GMT -- "fun" is possible, but use of these zones is comparatively unlikely. Most folks simply do not use the GMT offsets. (And a sign bit "flippage" on GMT would be a whole lot more than an hour for anywhere other than right around the prime meridian.)

Re: pathworks time not moving to DST

Sebastian Bazley — Wed, 14 Mar 2007 07:53:35 GMT

Note that if the logical TZ is defined, then the CRTL will use that in preference to the system settings.

Re: pathworks time not moving to DST

Dean McGorrill — Wed, 14 Mar 2007 17:02:05 GMT

>has the system been re-loaded and re-zic'd >with the new DST rules?

I thought I wouldn't need to, but I think
I should. theres not tz kit for V7.2-1
from HP. Anyone have an edited "NORTHAMERICA." - or from my
file the dates are apr 3, oct30. What are the new dates? I can edit mine

# From U. S. Naval Observatory (January 19, 1989):
# USA EASTERN 5 H BEHIND UTC NEW YORK, WASHINGTON
# USA EASTERN 4 H BEHIND UTC APR 3 - OCT 30
# USA CENTRAL 6 H BEHIND UTC CHICAGO, HOUSTON
# USA CENTRAL 5 H BEHIND UTC APR 3 - OCT 30
# USA MOUNTAIN 7 H BEHIND UTC DENVER
# USA MOUNTAIN 6 H BEHIND UTC APR 3 - OCT 30

Re: pathworks time not moving to DST

Ian Miller. — Thu, 15 Mar 2007 04:56:41 GMT

See "how to use zic on openvms alpha"
http://64.223.189.234/node/148

Re: pathworks time not moving to DST

Dean McGorrill — Thu, 15 Mar 2007 12:35:56 GMT

tx Ian,
Rules changed, compiled in place. but
I still have to keep my timezone offset to
MST ( -7 ) in order to have pathworks offer
the correct time. looks like pathworks does its own wrong time calculations. I took the
sample time program out of the C rtl manual.
heres what it does with us in MDT, but timezone at MST to keep pathworks running...

$! system time
ENGDS2::_TNA25: 10:27:53 (DCL)CPU=00:00:00
$ run time
The current time is: Thu Mar 15 11:27:55
$ !sample code 1 hour ahead
C:\>net time \\engds2
Current time at \\engds2 is 3/15/2007 10:27
AM

So the sample time code works as I would expect it. pathworks timesource does not.
? I don't get it.

Re: pathworks time not moving to DST

Hoff — Thu, 15 Mar 2007 13:21:59 GMT

Did you restart PATHWORKS Server?

Is the TZ logical name (still) set?

Did you alter the Denver TZ definitions as you had listed earlier, or with US as shown on the web page Ian pointed to. (The change is to the US and not the Denver definitions, those Denver definitions are historical.)

Can you provide a pointer to the sample code out of the C manual, or attach your particular C code to a reply here? (I'd not expect to see the C code display anything other than the current time, unless it is specifically seeking standard time.)

If it's feasible, I might well also reboot the box to ensure most everything is cleaned out, cleaned up, and all working from the new timezone definitions.

Re: pathworks time not moving to DST

Dean McGorrill — Thu, 15 Mar 2007 15:26:34 GMT

Yes I did restart pathworks. heres the time
snip from the C rtl manual..

#include
#include

main ()
{
time_t t;

t = time((time_t)0);
printf ("The current time is: %s\n",asctime (localtime (&t)));
}

(wish this buffer had more than 50chrs in width!)

Re: pathworks time not moving to DST

Hoff — Thu, 15 Mar 2007 15:40:01 GMT

The DST definitions (still) appear problematic, or the change-over is slamming into a remnant logical name or other artifact somewhere.

On OpenVMS, the return from localtime should be the same as the current system time, as OpenVMS is itself typically configured to operate in localtime.

Did you reboot the system?

Were the definition changes applied to "Denver", or to the US-wide definitions as was described over in that web page that Ian referenced?

--

$ cc/ver
Compaq C V6.2-003 on OpenVMS Alpha V7.2-1
$ cc x
$ lin x
$ r x
The current time is: Thu Mar 15 15:36:43 2007

$ sho time
15-MAR-2007 15:36:46

$ type x.c
#include
#include

main ()
{
time_t t;

t = time((time_t)0);
printf ("The current time is: %s\n",asctime (localtime (&t)));
}