Operating System - OpenVMS
1748275 Members
3720 Online
108761 Solutions
New Discussion юеВ

pathworks time not moving to DST

 
Dean McGorrill
Valued Contributor

pathworks time not moving to DST

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
24 REPLIES 24
Martin Hughes
Regular Advisor

Re: pathworks time not moving to DST

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.
For the fashion of Minas Tirith was such that it was built on seven levels, each delved into a hill, and about each was set a wall, and in each wall was a gate. (J.R.R. Tolkien). Quote stolen from VAX/VMS IDSM 5.2
Dean McGorrill
Valued Contributor

Re: pathworks time not moving to DST

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?
Ian Miller.
Honored Contributor

Re: pathworks time not moving to DST

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).

____________________
Purely Personal Opinion
Ian Miller.
Honored Contributor

Re: pathworks time not moving to DST

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
____________________
Purely Personal Opinion
Dean McGorrill
Valued Contributor

Re: pathworks time not moving to DST

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.



Dave Gudewicz
Valued Contributor

Re: pathworks time not moving to DST

>"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.
Dave Gudewicz
Valued Contributor

Re: pathworks time not moving to DST

MST7 should = -24200

Oops. Make that -25200

Dean McGorrill
Valued Contributor

Re: pathworks time not moving to DST

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)?

Hoff
Honored Contributor

Re: pathworks time not moving to DST

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