[HECnet] How long has your 20 been up?

[Thomas DeBellis]

Yes.  Well, perhaps not /that/ surprising.  (see previous)

I think that lasting until the year 31000 isn't too shabby. I'll have to 
enhance uptime to handle the full 70 bit millisecond uptime limitation.  
I had recently changed it to type the years, so the code is somewhat 
fresh in my mind. Another item that might be of interest would be to 
have a DK10 based timer, which has a resolution of 10 ns and see what 
that works out to be.

I had been considering this when considering the necessary changes to 
make the timers 70 bit signed instead of 'merely' 35 bits.  The 
underlying 'hardware' is getting so fast that this might become 
appropriate or maybe a good idea.

The five digit year is an excellent point.

The problem is that software can be brittle when it encounters 
situations that were not (or could not be) considered by the authors.  
Going past 35 bits will break a lot of assumptions in system 
applications, such as Galaxy, which will start acting 'strangely', 
assuming they even function at all.  I believe the mail system may also 
not work correctly and certainly the queued shutdown code in the access 
control job will break.

It's hard to tell what functionality would remain available; again 
assuming the system did just tip over.

> ------------------------------------------------------------------------
>
> On 1/18/22 2:26 PM, Johnny Billquist 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20220120/8233f5c4/attachment.htm>