Conference vaxaxp::vmsnotes

    I tested the same thing on an inhouse AXP system running OVMS-V7.1 and
    I get the same error if I specify a delta time "10000-0".
    In both case it works if one specify "9999-0" as delta time.
    
    Jean-Pierre

$ help specify date delta

SPECIFY

  Date_Time

    Delta

         Delta time is an offset from the current time to a time in the
         future. Delta time has the following format:

              [dddd-] [hh:mm:ss.cc]

         You can truncate delta time after the hour field. You can also
         omit any of the fields after the hour field format as long as you
         specify the punctuation marks.



The LIBR patches do not change documented� restrictions on
specifying the number of days in a delta time.  See the FAQ 
posted in 238.59 or on URL http://www.openvms.digital.com/

� Since 1978

    OK... But call this note VAXLIBR05 rather than 10K which is less easy
    to find. I say what I've been told "use natural terms".
    "10K" means nothing for me... and ecrtainly nothing about this problem,
    and probably for other readers.
    
    Jean-Pierre

    re .4
    
    Perhaps the base noter of 238 or a moderator would add ALP/VAXLIBR05 to the 
    title. Personally I find "10k" - NB: lower case k (-: - far more useful but,
    as they say, "chacun � son go�t".
    
    Note that originally *LIBR04 was the appropriate patch and that it has
    been superceded by 05.

Hi

I'm sure this is fairly unlikely, but my customer is proving hard to convince.

Is there any chance that the vaxlbr05_070 patch could cause the system time to
go months into the future after a reboot?

HW = various 4100s 
using DECnet phase V with DTSS.

Matthew

    A long shot.
    
    Is it months, or is it a year ?
    
    If it's a year, if they haven't shut the system down this year and had
    a system crash or just hit the button, that could cause the system to
    jump forward a year.
    
    Graham

:I'm sure this is fairly unlikely, but my customer is proving hard to convince.
:
:Is there any chance that the vaxlbr05_070 patch could cause the system time to
:go months into the future after a reboot?


   There are more than a few ways that this occurs without involving the
   patch, and this is the right time of the year to see these problems.

   LIBRTL is not involved in the storage of time in the OpenVMS system.
   (VAX or Alpha).

   OpenVMS VAX stores the year in the SYS.EXE system image, and the number
   of days since that year in the TOY battery-backed-up clock.  The TOY can
   store roughly 400 days.  When the year changes, the SET TIME command
   executed during system shutdown updates the TOY and the SYS.EXE system
   image to reflect this.  If the system is hard-halted, or crashes before
   a SET TIME is executed in any given year, or system disks are swapped
   around, you'll see strange things with the time.  (This is the reason
   we now prompt for time when standalone boots, and why we now verify the
   time during VAX system upgrades -- the system image might not hold the
   current year when the kit is finally installed.)

[.6] using DECnet phase V with DTSS.
    
    Even if one of the well-known causes that .8 refers to was involved, the
    DECdts process should correct the time.. Perhaps the DECdts configuration
    is not as it should be.. (e.g. too few Servers or no Server has a
    Time Provider, or the Time Provider is faulty, etc++..)
    
    John.

:[.6] using DECnet phase V with DTSS.
:    
:    Even if one of the well-known causes that .8 refers to was involved, the
:    DECdts process should correct the time.. Perhaps the DECdts configuration
:    is not as it should be.. (e.g. too few Servers or no Server has a
:    Time Provider, or the Time Provider is faulty, etc++..)

   This text results from the percieved reasonable chance that some
   application will "detonate" from a large on-line time change... 
   (And this "fear" has nothing to do with the 10Kday delta-time patch.)
   (I'd prefer to rip this text out and replace it, as it doesn't relate
   to the problem at hand, and as a reboot is required anyway...)

    Re: .10
    
|   This text results from the percieved reasonable chance that some
    ^^^^^^^^^
    
    Steve, which text are you referring to?
    
    Thanks..
    John.

:|   This text results from the percieved reasonable chance that some
:    ^^^^^^^^^
:    
:    Steve, which text are you referring to?

   Please use the TIMEPROMPTWAIT reboot sequence I mentioned. 

   I'm trying to get the reboot sequence at the website and in the 10K
   cookbook updated to eliminate this SET-TIME-with-caveats sequence
   and thus eliminate the need for the text quoted in .0.