From: bqt@softjar.se   
      
   On 2025-10-28 17:15, Robert A. Brooks wrote:   
   > On 10/28/2025 09:54, Simon Clubley wrote:   
   >> On 2025-10-27, jayjwa  wrote:   
   >   
   >>> %%%%%%%%%%%  OPCOM  18-DEC-2023 20:35:37.33  %%%%%%%%%%%   
   >>> Message from user DECNET on KUSHAL   
   >>> DECnet event 0.3, automatic line service   
   >>>  From node 1.12 (KUSHAL),  1-JAN-2041 00:00:00.00   
   >>> Circuit QNA-0, Load, Successful, Node = 1.16, File = SAMPLE.SYS   
   >>> Operating system, Ethernet address = AA-00-04-00-10-04   
   >>>   
   >>   
   >> This may be because the 15-bit date offset boundary for the   
   >> DECnet Phase IV event timestamp (as defined by the specification)   
   >> was passed several years ago and therefore the system may be placing   
   >> junk in that field. Current VMS itself uses the full 16-bits available,   
   >> hence there is no problem on VMS itself.   
   >>   
   >> I came across this when I was probing EVL a few years ago and found that   
   >> contrary to the specs it was still OK on current VMS systems. I think it   
   >> was Rob who made that change to VMS but I can't remember for sure.   
   >   
   > [EVL]EVLJULIAN.B32   
   > X-4     RAB0249         Robert A. Brooks          
   17-Nov-2022   
   >          Fix for Jira DV-13/NetSuite 2057 -- "DECnet Phase IV"   
   >          NICE event date issue"   
   >   
   >          From a customer-sent mail message   
   >   
   >          "Events are time-stamped when they are generated with a   
   >          2-byte field holding the number of half julian days   
   >          since Jan-1 1977. The spec (Network Management 4.0.0,   
   >          page 170/171) implies that these 2 bytes should be treated   
   >          as a signed value (0 - 32767) which will overflow on   
   >          Nov 9th 2021. If the code treats it as unsigned, then we   
   >          are good for another 44 years."   
   >   
   >          The code in routine EVL$JULIAN appears to treat the   
   >          relevant word as unsigned, but there is an explicit   
   >          check such that any date after 1-Nov-2022 will return   
   >          an error.  Simply pushing the gating date check into   
   >          the future allows the date to be formatted and displayed   
   >          correctly.  For cuteness, I'm using my 100th birthday of   
   >          December 20, 2061 as the gating date.  Yeah, it's not   
   >          exactly 44 years past 10-Nov-2022, but hey, it's my call   
   >          to make.   
      
   So VMS only got the fix after the date had passed? Kindof interesting.   
      
   In RSX:   
      
   [320,10]EVCEVT.MAC   
    8.10  18-AUG-1998     D. Carroll   
                  DC515 - Correct event time reporting after 10-Nov-2021   
      
      Johnny   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)