After I sent the below, I found that I couldn't get that ancient SPR response off my mind.  I was surprised that I was still mystified after nearly four decades and decided to revisit the issue.  In summary, I've realized that I had been missing some key use cases that make a 36 bit CTY special.

First of all, you didn't need to login to the front end (RSX20F), so if you did get to the CTY and typed a Control-\, you could run a program (say from floppy) that could basically do what it wanted, so my 'fix' wasn't really a complete 'cure' at all nor could it be.  This also exists in simulators and you can also deposit or examine whatever you feel like.

Under Tops-10, the situation might be considered to be worse (but I believe that term to be unfair).  That is, the operating system has no control over what might be examined or deposited from the front panel.  There, the CTY is even more special: it doesn't need a password for any login.  You can do an I [1,2] and you are now an operator (I.E., root).  However, for many years, I thought this was just neat...

What about other DEC multi-user operating systems?  Do you have 'magic' consoles?

Getting back to Tops-20, the whole MINI-EXEC issue continued to bug me enough that I started working on it again after all these years.  What I found was that I had overlooked a use case that that had become unknown at Columbia, that is, doing an installation from scratch from tape.  When you're doing that, you begin with no file system and must start the monitor at a special location to create a public structure.  After that, you start running programs from tape to eventually restore a full system build.

So since there is no EXEC for most of this time, you need something to run the programs from tape and hence the perfectly legitimate need for the Mini-EXEC and its GET and START command.  I don't remember reading that in the SPR response, perhaps I've forgotten.

My current approach is therefore more nuanced.  If the access control job is running, then Tops-20 will do whatever it is told concerning Mini-Exec access.  If the ACJ is not running, the default behavior happens.  Since SYSJOB is not running when doing MTBOOT procedures, the ACJ won't be in operation and everything works out.

More about the Mini-EXEC when I get all the code debugged and up for a few days (or weeks...)

---

On 3/2/22 3:10 PM, Thomas DeBellis wrote:

Tops-20 has two glaring defects in this regard (IMHO)

First, if, on a loaded system, you sat on ^C on the CTY--really hammered on it--you could blow the EXEC up.  Normally, this would result in an immediate logout.  However, in CTY case, you wound up in the MINI-EXEC as a logged in OPERATOR job with full OPERATOR capabilities.

There are reasons for this (say you a debugging an EXEC that gets sick before you can login).  However, for the general case, we all thought that this was 'a pretty bad thing'.  However when I SPR'ed it (with a suggested patch to only do this if), DEC's response was effectively, "Secure your machine room".

Sigh.  Anyway, it's on my list of things to fix (in MEXEC.MAC at EXEC2+25)