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