[HECnet] How long has your 20 been up?

[Peter Lothberg]

GMT is solar time! (and not used...) 

The world uses UTC that is TAI with compensation with leap seconds 
to deal with earth rotation speed not being constant. 

While you are on it, make Tops20 do leap-seconds correctly. 

And then we want "syn-cookies". 

-Peter 

> From: "tommytimesharing" <tommytimesharing at gmail.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Thursday, January 20, 2022 12:02:53 PM
> Subject: Re: [HECnet] How long has your 20 been up?

> Yes, I understand what you're saying and it can be frustrating. Yet, I find
> myself being uncomfortable with the wording, "silly bug".

> Here's what happened: while MRC was still alive, I would send him PANDA 'bug
> reports' of things that I had either fixed or enhanced using the exact same
> format that we had used to send SPR's in from Columbia. Since we were a source
> site and strove to fix things beforehand, the report was in a standard stanza
> format of: Symptom, Problem, Cure, Workaround, that sort of thing.

> The Tops-20 application display module, DPY , had a limitation in that it didn't
> handle arbitrary window sizes. It looked at the terminal type and used
> hardwired length and height based on that. This was a completely reasonable
> thing to do back in the day, however the VT100 132 column mode and other
> factors changed that and no code had been written to account for this. So I
> made a change to use the MTOPR% .MORLL (read terminal length) and .MORLW (read
> width) functions instead, the older RFMOD% fields being limited to 127
> (decimal) and dutifully wrote it up which MRC then published on the (now sadly
> defunct) Tops-20-Wizards mailing list.
> Unknown to me, the posting was read by the Tops- 10 author of a similar package
> and he assumed I was criticizing his efforts. He got pretty peeved by my
> calling it 'a bug', when it really wasn't for the time. So, he took me to task
> about it, MRC smoothed things over by pointing out that it was the Tops-20 code
> being enhanced (different author) and I gained a valuable perspective about
> critiquing of thirty year old software. I'm more careful about what I call a
> bug as opposed to an unimplemented feature or even a misfeature. I'd like to
> call them 'unfeatures'.

> With the exception of the perhaps KS10, with which I have no direct experience,
> the entire 36 bit line (from the 166 to the KL) just never had the kind of
> reliability that you'd see in the minicomputers, even a PDP-8/E. Our service
> contract with DEC required regularly scheduled downtime for preventive
> maintenance (PM); I think the interval was somewhere between two weeks and a
> month. One time we had been up nearly two months, which was unheard of. And DEC
> threatened to cancel the contract if we didn't schedule downtime...

>> The machines simply never stayed up that long.
> That being said, Yes, there are some things that have struck me as surprising or
> perhaps unfortunate. Or perhaps it is more accurate to say that they just annoy
> me. For example, the TIMER module has the so-called limitation of clamping
> elapsed time and specific time requests to 35 bits, giving you the previously
> mentioned issue with millisecond uptimes, but also limiting time of day
> requests to 27-Sep-2217 23:59:59 GMT, instead of the actual ending time of
> 7-Aug-2576 23:59:59 GMT, some 358 years later.

> I do plan some enhancements to TIMER%, such as retrieving the open timer
> requests for a fork, so perhaps I will revisit my feelings about the matter.
> Some of the code for CPU limits suggest some interesting enhancements.

>> On 1/18/22 2:15 PM, Paul Koning wrote:
>>> On Jan 18, 2022, at 2:05 PM, Thomas DeBellis [ mailto:tommytimesharing at gmail.com
>>> | <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.
>>> 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.

>> ...

>> paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20220120/c7c12e3e/attachment-0001.htm>