[HECnet] How long has your 20 been up?

[Thomas DeBellis]

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 
>> <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/95581526/attachment.htm>