[HECnet] How long has your 20 been up?

[Johnny Billquist]

By then, we probably also need to look at/revise how we compute leap 
years... It's well known that the current algorithm will slowly get us 
out of phase again...

   Johnny

On 2022-01-19 01:44, Mike Kostersitz wrote:
> Cool thread, reminds of many leap year issues we fixed in All-In-One a 
> long, long time ago. I think at the year 33000 there will be other 
> issues to tend with than RSX or other Digital Equipment software going 
> bonkers 😃 Unless of course the Metaverse runs on RSX then of course all 
> bets are off 😃
> 
> Mike
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
> 
> *From: *Paul Koning <mailto:paulkoning at comcast.net>
> *Sent: *Tuesday, January 18, 2022 11:43 AM
> *To: *hecnet at update.uu.se <mailto:hecnet at update.uu.se>
> *Subject: *Re: [HECnet] How long has your 20 been up?
> 
>  > On Jan 18, 2022, at 2:26 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
>  >
> 
>  >
> 
>  >
> 
>  > On 2022-01-18 20:15, Paul Koning wrote:
> 
>  >>> ..
> 
>  >
> 
>  >>> I know that XKL fixed at least part of the uptime problem, but I 
> don't remember what that limit is.  What are the limits for other systems?
> 
>  >> It's not overly strange that designers of mainframe systems, where 
> planned shutdowns (say, for preventive maintenance) were a regular 
> occurrence) would overlook silly bugs like that.  It feels like the sort 
> of thing that minicomputer software, especially real time systems, would 
> never do.  For example, RSTS has no uptime limit.
> 
>  >
> 
>  > Neither have RSX. However, I do know that VMS have an uptime problem. 
> Or rather a time problem. Because of the way time is represented, 
> everything will fail catastrophically somewhere around the year 31000. 
> VMS represents time as a signed quad. 100ns resolution, and offset from 
> 1858 (or whenever it was). Anyway, the important bit is that it is 
> signed, and it has to be positive.
> 
>  > Because negative time values are considered to be relative (delta) 
> times. And so, when the time actually wraps over, things will go totally 
> bonkers in VMS.
> 
>  > Of course, other things will probably start causing problems long 
> before then, like when years start needing 5 digits...
> 
>  >
> 
>  > With RSX, I am not aware of anything that will cause fatal problems. 
> Time representation might get a bit broken around the year 33000 or so, 
> but I don't think anything catastrophic will break. Years are just a 16 
> bit value with an offset of 1900. But very few things even use it for 
> anything, except printing it out. So signedness or not might cause 
> things to look funny depending on the code, but most software itself 
> will not care.
> 
>  >
> 
>  > Various subsystems will probably have issues long before then, like 
> time stamps on files will wrap, queue manager time handling will 
> break/wrap, and of course DECnet time representation can't deal with it. 
> But the OS itself will probably just continue chugging along, as will 
> most software.
> 
> Time stamps are interesting.  DECnet event timestamps ran out of bits 
> recently, unless you ignore the spec's statement that the 16-bit field 
> is signed.  If treated as unsigned you've got until 2038 or so.
> 
> RSTS timestamps overflow in 2035.  RT-11 ran into trouble before Y2K 
> though I think there are workarounds for that -- which are not 
> implemented everywhere.  DOS-11 format DECtape ran into trouble in April 
> of 1974 (12 bit timestamps), I remember creating a RSTS patch for that 
> in college and sending it to DEC.  :-)
> 
>                  paul
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol