pathworks time not moving to DST

[Dean McGorrill]

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

[Martin Hughes]

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.

[Dean McGorrill]

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

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

[Ian Miller.]

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

[Dean McGorrill]

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]

>"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]

MST7 should = -24200

Oops. Make that -25200

[Dean McGorrill]

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]

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

[Dean McGorrill]

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?

[Ian Miller.]

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.

[Hoff]

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

[Sebastian Bazley]

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

[Dean McGorrill]

>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

[Ian Miller.]

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

[Dean McGorrill]

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.

[Hoff]

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.

[Dean McGorrill]

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

[Hoff]

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)));
}

[Dean McGorrill]

Yes, I did the changes like Ians pointer
to your page. Yours comes out ok, because
you probably have the correct TDF. from your post time, I'll guess your on central time. run utc$time_setup and change from -5
to -6 and see what the time says.

[Hoff]

Post up the output from:

@SYS$MANAGER:UTC$TIME_SETUP SHOW

Does this box have DECnet-Plus and DTSS? (Is the file $ SYS$STARTUP:DTSS$UTC_STARTUP.COM around?) If so, there's a related section in the FAQ.

If you have that file around, then invoke @SYS$MANAGER:UTC$TIME_SETUP.COM, then invoke @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM. (There are some details on this in the FAQ.)

I'm not in a position to change the time on a local server right now to test this with MST/MDT. (Somebody might get cranky.)

[Dean McGorrill]

>@SYS$MANAGER:UTC$TIME_SETUP SHOW

that must be a newer function. the machines
here run 7.2-. its an older file..
SYS$MANAGER:UTC$TIME_SETUP.COM 8/18 27-FEB-1998 10:43:07.85

p1 is a target root to update.

theres various left overs from dtss, a decnet install, but its not being used. no
startups run. no processes or entities
supported..

NCL>sho dtss
%NCL-E-CMLSENDFAILED, error sending command request
-CML-E-EMAAPROB, error returned from VMS EMA agent
-NCL-E-ENTCLSNOTSUPP, entity class not supported
NCL>

I wonder if theres a pathworks forum like
this, I'll have to look

[Dean McGorrill]

is the canada changes the same as US? we have a site in BC. Is so I can edit the
canada tz rules like the usa.

[Hoff]

The rules and the timezone definition changes I posted are for the US rules.

Canada has its own rules.

My understanding is that Canada has decided to follow the US rules, and any timezone "handle" matching the local rules can be selected. You could select an Argentinian no-DST timezone rule, for instance, if the system was to stay on the equivalent of standard time and matching Buenos Aires.

There are a couple of options including getting somebody to look at this system and its configuration somewhat more formally, or consideration around an upgrade to a release with the TZ and DST kits, or ignoring the differences between the old DST and new DST rules twice a year.

(And regardless, it would not surprise me to learn that some remnant of DECnet-Plus or other oddity is "visiting" here.)

Stephen Hoffman
HoffmanLabs