At 11:36 AM +0100 8/6/06, Martin J. Evans wrote:
>Thanks. I've been trying to build 5.8.8 for 2 days now. Each time I run
>mms it gets a little further but I have to wait between runs obviously
>because there is something wrong with my time. The first mms fails with:
>
>Set Default [.c]
>MMS /Descrip= Descrip.MMS all
>%MMS-W-GMFUTURE, Time for [-.BLIB.BIN].EXISTS is in the future:
>6-AUG-2006 12:29:11.00
>Note the .EXISTS is in the future.
That's quite strange. You should be able to reproduce this by doing:
$ perl -"MExtUtils::Command" -e touch foo.tmp
$ dir/full foo.tmp
and seeing if the revision date on foo.tmp is in the future. You
might also see if you get incorrect results from one or both of the
following:
$ perl -e "print scalar localtime;"
Sun Aug 6 13:42:32 2006
$ perl -e "print scalar gmtime;"
Sun Aug 6 18:42:41 2006
You can see if Perl thinks you are really on daylight saving with:
$ perl -e "@t=localtime(); print $t[8];"
1
If that doesn't print a true value, then it's not recognizing that
DST is in effect. If it's wrong, a 5-line C program that does the
same thing should verify whether the problem is in Perl or in the
CRTL.
A hack that might get you past this issue is:
--- lib/ExtUtils/Command.pm;-0 Fri Oct 21 03:55:12 2005
+++ lib/ExtUtils/Command.pm Sun Aug 6 13:30:45 2006
@@ -149,12 +149,11 @@ Makes files exist, with current timestam
=cut
sub touch {
- my $t = time;
expand_wildcards();
foreach my $file (@ARGV) {
open(FILE,">>$file") || die "Cannot write $file:$!";
close(FILE);
- utime($t,$t,$file);
+ utime(undef,undef,$file);
}
}
[end of patch]
What that will do in your version of Perl is basically reduce utime()
to a SYS$GETTIM call immediately followed by a tweak to the revision
date in the file header with no intervening UTC offset calculations.
In future versions of Perl, the CRTL's utime() will be involved.
>I've reset my time and timezone so now I have:
>
>$ sho time
> 6-AUG-2006 11:19:55
>
>which is correct.
>
>$ @SYS$MANAGER:UTC$TIME_SETUP SHOW
>
>AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use.
>You will have to manually change to/from Daylight Saving Time.
>
>You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,
>or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.
>
>
> LOCAL TIME ZONE = GB -- DAYLIGHT TIME
> LOCAL SYSTEM TIME = 6-AUG-2006 11:20:11.58 (BST)
> TIME DIFFERENTIAL FACTOR = 1:00
> TIME ZONE RULE = GMT0BST-1,M3.4.0/01,M10.5.0/02
> Change GMT to BST on the Fourth Sunday of March (26-Mar-2006) at
>01:00
> Change BST to GMT on the Last Sunday of October (29-Oct-2006) at
>02:00
>
>(LNM$SYSTEM_TABLE)
>
> "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB."
> "SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
> "SYS$TIMEZONE_DIFFERENTIAL" = "3600"
> "SYS$TIMEZONE_NAME" = "BST"
> "SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.4.0/01,M10.5.0/02"
> "TCPIP$BIND_TIMEOUT" = "...."
>
>but still no luck.
>
>I don't understand why auto_dlight_sav is set to 0 but I don't think it
>is relevant.
I don't think it is either. It's disabled because it's a system parameter
and that's the default setting. Here's what mine looks like:
$ mcr sysgen show auto_dlight_sav
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
AUTO_DLIGHT_SAV 1 0 0 1 Boolean
>Does anything look wrong my with time settings to you?
No, but that doesn't mean much as I have no great expertise in this area.
I notice that there are a number of ECOs available for OpenVMS I64
v8.2-1, including TDF, TZ, and CRTL patches, any or all of which
might be relevant here. The CRTL patch in particular addresses
problems in the tm struct used by localtime and gmtime. I would
suggest getting your system up-to-date with ECOs and seeing if that
makes a difference.
You can find the relevant ECOs here (registration required):
http://www2.itrc.hp.com/service/patch/search.do?BC=main|&pageOsid=openvms
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
