'almost'?

I found myself curious as to when it wouldn't be.  Could you elaborate?  Did you have something in mind, perhaps having SNMP on all the time?

We expended substantial effort to make our 20's effectively 'lights out'; nobody in the machine--EVER--except to mount tapes and disks or to boot and that was during third shift.  They could even be configured for remote management in the boot regard if you had local (wired) terminals on the first DH11.

You could set the switches of the front end that indicated which terminal would become the CTY.  One of these terminals happened to be TTY7:, which was several blocks away (in my office).  Saved me walking and the howling cold of the machine room...

As far as I am aware, at Big Bank, we will not install any machines that don't do complete lights out.  That policy is at least two decades old.

---

On 3/2/22 12:58 AM, Dave McGuire wrote:

  I'm not a PyDECnet user yet, but I will say this, remote manageability is almost always a good thing.

          -Dave

---

On 3/1/22 20:16, Paul Koning wrote:

Question for PyDECnet users: as I mentioned, there's a new API, cleaner than the old one.  A major addition is access to the Session Control layer, in other words external programs can talk to the API to use DECnet communication services, inbound or outbound.  This is how I implemented a simple subset NCP and NFT.

That API runs over a Unix domain socket, in connection mode.  It's quite similar to TCP but inherently local to the machine where PyDECnet is running.  That's nice for security, of course.  But on the other hand, it means that there isn't a way for a PyDECnet running on one machine to offer a portal into DECnet for nearby machines.  If you keep a DECnet router in the basement, your laptop can't run NCP since it has no access to that socket.

It would not be all that difficult to add an option for running that same API over a TCP port, possibly with some sort of access filtering.  Is there interest in such a thing?