18 Jan
2022
18 Jan
'22
8:43 p.m.
On Jan 18, 2022, at 2:26 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2022-01-18 20:15, Paul Koning wrote:
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
> ...
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.