[HECnet] How long has your 20 been up?

Januarius XVIII isn?t strictly correct since days were reckoned relative to three keys days in the month, so Ante diem quattuordecimum kalendas februarius Might be better. > On 19 Jan 2022, at 12:00, Johnny Billquist <bqt at softjar.se> wrote: > > ?Yeah, I love that one too. > > I'm sure it will break at some point, but I have not looked at it in quite a while, so not sure exactly what the limits are there. > > Probably might break around the year 4000. And I'm sure the moon phase calculation will eventually get out of phase. > > Johnny > >> On 2022-01-19 04:21, Mark Matlock wrote: >> Johnny, >> I got to wondering, on RSX, when in the future does my favorite Easter Egg break? >>> time /roman >> Januarius XVIII, Anno Domini MMXXII XXI:XVIII >> The moon is waning gibbous. Today is Tuesday. >> Happy New Year, >> Mark >>>> On Jan 18, 2022, at 1:26 PM, Johnny Billquist <bqt at softjar.se> wrote: >>> >>> >>> >>> On 2022-01-18 20:15, Paul Koning wrote: >>>>> On Jan 18, 2022, at 2:05 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: >>>>> >>>>> ... >>>>> I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT. >>>> Oops. >>> >>> Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me. >>> >>>>> 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. >>> >>> Johnny >>> >>> -- >>> 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 > > -- > 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