[HECnet] TOPS-10 D-Day, DECnet failure on November 9th is less than six days away

[Thomas DeBellis]

I have been finding myself getting curious about the COM911 patch.  It's 
received little to no response on alt.sys.pdp10, which is perhaps 
unsurprising as Tops-10 (sadly) never had an officially DEC sanctioned 
IP stack.

On HECnet, there are 15 registered Tops-10 systems, viz: ATLE (1.605), 
AURORA (1.606), BITXT1 (7.80), EYN    (18.105), FREJ (1.608), LOKE   
(1.607), NOMAD  (1.610), NYE    (18.103), PANDA (35.629), TIPSY  
(1.604), TOPSY  (1.601), TWONKY (31.37), VENTI (2.20), YMER   (1.609) 
and MARLEY (9.10).

Unless you happen to be a lucky user on VENTI, you are going to *crash* 
in about four days, at which point, you can do a patch or set the wrong 
date.

That would bother the /HEC/ out of me...  So, I haven't heard a peep; 
what are you all doing, anyhow?
> ------------------------------------------------------------------------
>
> On 11/5/21 2:21 PM, Thomas DeBellis wrote:
>
> Tops-20 gives you essentially the same functionality being able to 
> launch the monitor of your choice, having (I believe) the similar 
> restriction that the monitor in question has to be on a locally 
> attached disk (I.E., no CFS).
>
> Personally, I prefer Tops-10's syntax format because I have to type 
> less at BOOT time.  Historically, a system being out of operation was 
> a time of extremely high pressure to get it back online (data center 
> phones would glow white hot...)
>
> And then there was the sneezing which could fat key you. Although we 
> had four 20's in one room, we had some 55 tons of glycol chiller plus 
> environmental HVAC; Translation: the machine room was /arctic/.  
> Pre-global warming.
>
>     So the less you type, the better...
>
> One problem I have (if you want to call it that) is forgetting that 
> I've booted a different monitor.  So my 'production' 20 (TOMMYT) has 
> been up some 7,021 hours whilst the development machine (VENTI2) is 
> currently at a relative paltry 3,279 hours.
>
> So in certain cases, I've gone and completely forgotten what the heck 
> I've been running...  Consequently, on a reboot, the previous monitor 
> comes up and I'm clueless, the result being I start asking myself, 
> "Gee, why am I seeing this failure mode?  I wonder what I missed when 
> I fixed this?"
>
> As far as I can remember, the only way you can tell what monitor 
> you're running is by updating the version, typically the edit level, 
> so that INITIA, SYSTAT or INFO MON can see it.  I only remember to do 
> that when everything is debugged.  Most of the time...
>
> One assumes that Bob will bump the edit number sometime after the 9^th .
>
> On 11/5/21 6:59 AM, G. wrote:
>>>    FWIW, you don't actually need to do a MONGEN in this case, 
>>> assuming you've previously done one and you're not changing any 
>>> selections.  Just skip straight to relinking...
>>
>> Yup! Those instructions were originally written for someone doing a new
>> installation, hence the need to run a MONGEN too as they had to setup 
>> several
>> parameters. For example, I have used it to configure DECnet and LAT, 
>> change
>> the default buffer size and hello timer, and so on... :)
>>
>>>> 12. Copy the new monitor to the system directory giving it some 
>>>> unique name:
>>>>
>>>>      .COPY SYS:MYMON.EXE=DSK:SYSTEM.EXE
>>>
>>>    This works fine, however the other common option is to copy your 
>>> new monitor to [1,5].  On TOPS-10, [1,5] is NEW:, [1,4] is SYS: and 
>>> [1,3] is OLD:.  At the BOOT> prompt you can simply type "[1,5]" 
>>> (assuming you used the name SYSTEM.EXE) and BOOTS will load the new 
>>> one.  If all is well, then you rename the [1,4]SYSTEM.EXE to [1,3], 
>>> and then [1,5]SYSTEM.EXE to [1,4].  In the future BOOTS will load 
>>> the one from [1,4] by default, and if you ever find that you need to 
>>> go back then you can tell BOOTS "[1,3]" and it'll load the old one.
>>
>> Indeed, both solutions work perfectly. :)
>>
>> Personally I find it more practical to type some monitor name rather 
>> than
>> brackets because I'm not a native English speaker hence my keyboard 
>> is mapped
>> differently. Now that I think of it, maybe having several monitors with
>> different "speaking" names may come handy in some experimental 
>> situations...
>>
>> Thanks for your thanks, :)
>> G.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211105/c169c22c/attachment.htm>