On 06-Aug-2006 Craig A. Berry wrote:
> 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:
The only semi-working perl I have is HP compiled binary unless I could somehow
use miniperl. I've included both results:
time is 8:40am approx.
With HP's perl:
===============
$ perl -"MExtUtils::Command" -e touch foo.tmp
$ dir/full foo.tmp
Directory DKA0:[NICK.MARTIN]
FOO.TMP;1 File ID: (24832,28,0)
Size: 0/0 Owner: [200,1]
Created: 7-AUG-2006 08:40:44.67
Revised: 7-AUG-2006 09:40:44.00 (1)
***************************************
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: <None specified>
Attributes: <None specified>
Modified: <None specified>
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 0, Extend: 0, Global buffer count: 0, No
version limit
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None
Total of 1 file, 0/0 blocks.
> $ perl -e "print scalar localtime;"
> Sun Aug 6 13:42:32 2006
$ perl -e "print scalar localtime;"
Mon Aug 7 08:42:30 2006
Correct.
> $ perl -e "print scalar gmtime;"
> Sun Aug 6 18:42:41 2006
$ perl -e "print scalar gmtime;"
Mon Aug 7 07:42:52 2006
Correct.
> You can see if Perl thinks you are really on daylight saving with:
>
> $ perl -e "@t=localtime(); print $t[8];"
> 1
$ perl -e "@t=localtime(); print $t[8];"
1
With miniperl:
==============
I obviously cannot do some of the tests you provided.
$ miniperl -e "print scalar localtime;"
Mon Aug 7 08:47:38 2006
$ miniperl -e "print scalar gmtime;"
Mon Aug 7 07:48:04 2006
$ miniperl -e "@t=localtime(); print $t[8];"
1
All look OK.
> 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.
So other than the revision time it looks OK.
CRTL for gmtime and localtime return the correct values - I checked.
> 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.
Applied and reran perl make and it completed OK - Thank you.
mms test had a few issues (some perhaps because of above):
t/io/fs...................................FAILED at test 5
t/op/stat.................................FAILED at test 33
ext/Devel/PPPort/t/ppphtest...............FAILED--unexpected output at test 0
ext/List/Util/t/p_tainted.................FAILED--no leader found
ext/List/Util/t/weak......................FAILED--unexpected output at test 7
lib/ExtUtils/t/basic......................FAILED at test 67
lib/ExtUtils/t/Command....................FAILED at test 8
lib/ExtUtils/t/Constant...................FAILED at test 23
lib/ExtUtils/t/FIRST_MAKEFILE.............FAILED at test 4
lib/ExtUtils/t/PL_FILES...................FAILED at test 3
lib/vmsish................................FAILED at test 22
Failed 13 test scripts out of 892, 98.54% okay.
### Since not all tests were successful, you may want to run some of
### them individually and examine any diagnostic messages they produce.
### See the INSTALL document's section on "make test".
### You have a good chance to get more information by running
### ./perl harness
### in the 't' directory since most (>=80%) of the tests succeeded.
u=40.80 s=0.00 cu=0.00 cs=0.00 scripts=892 tests=114061
The install then failed to install - just hung with:
$ mms install
%DCL-I-SUPERSEDE, previous value of PERL_ROOT has been superseded
%DCL-I-SUPERSEDE, previous value of PERLSHR has been superseded
If F$TrnLnm("Sys") .nes. "" Then Deass SYS
MCR Sys$Disk:[]miniperl.exe "-I[.lib]" installperl
Deep recursion on subroutine "File::Path::mkpath" at lib/File/Path.pm line 162.
I found the thread started by Peter Prymmer at
http://www.nntp.perl.org/group/perl.vmsperl/13873 and the followups in
http://www.nntp.perl.org/group/perl.vmsperl/13873
http://www.nntp.perl.org/group/perl.vmsperl/13883
http://www.nntp.perl.org/group/perl.vmsperl/13884
http://www.nntp.perl.org/group/perl.vmsperl/13885
http://www.nntp.perl.org/group/perl.vmsperl/13891
which got me past this by creating my install dir first (although I saw the
second, better method of removing the \00000).
>
>>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
>
and mine:
$ mcr sysgen show auto_dlight_sav
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
AUTO_DLIGHT_SAV 0 0 0 1 Boolean
which explains that.
>>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
I found VMS821I_UPDATE-V0300.ZIPEXE which seems to include most if not all of
that and will have another go after installing it.
Thank you very much for all the help.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
