On Mar 1, 2022, at 3:50 PM, Wilm Boerhout <wboerhout(a)gmail.com> wrote: Great news Paul! I'm looking forward to running the beta, but it will probably be sometime next week before I will get around to implement it. I'll let you know beforehand. Wilm -----Original Message----- From: Paul Koning <paulkoning(a)comcast.net> Sent: Tuesday, March 1, 2022 7:48 PM To: HECnet <hecnet(a)lists.dfupdate.se> Subject: [HECnet] PyDECnet T1.1 beta 2 Gentlepeople, I have put together a second beta for DECnet/Python 1.1. It's currently running on a HECnet backbone router (PYTHON) and on the HECnet map server (28NH). This beta update adds DAP support and "login" type objects (such as FAL). The first beta has significant performance improvements over V1.0, and a new and expanded API. You can look at CHANGES.txt in the source tree for more detail. It seems to be stable; the first beta has been running for a while now with no obvious problems. I'd like to hear if anyone currently running PyDECnet is interested in trying out this beta. If so, you can find kits here: http://akdesign.dyndns.org:8080/resources/public/index.html . I didn't have kits posted before, now they are available. You can also download them using DAP on HECnet, at PYTHON:: . :-) If you install the beta could you let me know so I know who is using it? Thanks. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

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?

On Mar 2, 2022, at 12:58 AM, Dave McGuire <mcguire(a)neurotica.com> wrote: On 3/1/22 20:16, Paul Koning wrote: I'm not a PyDECnet user yet, but I will say this, remote manageability is almost always a good thing.

On Mar 2, 2022, at 11:48 AM, Mike Kostersitz <mikekostersitz(a)gmail.com> wrote: From my POV having NCP only on a node where pyDECNET runs is not a huge limitation. As it is in line with what we have today, I can only run NCP on RSX, VMS, etc. where I have DECNET running as well so that matches the current behavior for me. Mike

'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. _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

------------------------------------------------------------------------ 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)

> 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?

I think these observations are basically correct; you can only go so far with software based security until you really have to start thinking about hardening the physical environment. Columbia was perhaps kind of an odd case in that a rather large number of people could come waltzing through the machine room and some didn't really understand, "Don't Touch".  We systems programmers REALLY didn't feel comfortable with this. But the security question really was, once you are in normal operation, just how 'normal' should the console be?  Tops-10's console was pretty normal except for the INITIA automatic nice things.  Tops-20's is closer as you normally can't get to the auto-magic.  My recollection is that on at least at least some IBM mainframes, you couldn't use the console for a foreground session.  I think this was the case for OS/360 (which we ran on our 91) and maybe for MVS.  I can't remember about VM. What part of the KA10 console are you talking about, actually?  I thought a few switches did work even with run on.  My 1971 version of SYSREF (from the Orange Book, pages 138 to 143) states that some switches, such as READ IN, START, EXAMINE NEXT and DEPOSIT NEXT don't work if run is on.  However, EXAMINE THIS and DEPOSIT do work with run on, which is what I remember. I can't remember where I put the later version of SYSREF that has KI operations.  What do you remember? The switch register (obviously) works and WPI used it for a fun application.  We have less than 37 operations personnel assigned to our KA, and each operator had their own bit.  When they came in to work, they pressed the switch for their 'bit'.  You could run a program which would read the switch register and tell you how many operators were on duty and who they were. _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Mar 7, 2022, at 3:56 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> wrote: ... What about other DEC multi-user operating systems? Do you have 'magic' consoles?

------------------------------------------------------------------------ On Mar 7, 2022, at 3:56 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> What about other DEC multi-user operating systems?  Do you have 'magic'

I was finishing up with the Access Control Job (ACJ) modifications for MINI-EXEC Access (SC%MEA capability) when I got to thinking more about the console. For 36 bit machines, there has been some historical inconsistency about messages that come up on the console but only on the console and nowhere else.  Under Tops-20, one example was BUGINF and BUGCHK messages, which you had to be near the console to see.  Enhancements were eventually made to Tops-20 distribute these via Orion to all Galaxy operators, which is a nice idea as it also puts them in them into the OPERATOR-SYSTEM-LOG in PS:<SPOOL>. It's also essential in a cluster. However, there are still those other pesky messages, which maybe you need to do something about.  One example is "*DDMP swap space low action*", which can occur if you happen to have a number of multi-section programs executing and don't have enough swapping defined (I.E., you took the defaults).  You can wind up with a crashed machine if you don't release some memory. Under Tops-20, there is a program called CTYPEEK that uses the TLINK% JSYS to allow terminals to 'spy' on the console via one way links.  For a number of reasons, I am uncomfortable with spying.  You certainly need to spy when you are debugging protocols; I've used it for both the Extended Mode FTP server and Tops-20 Kermit.  Think of it like a Tops-20-centric Wireshark without the formatting. On the other hand, when you get too many people with SC%WHL or SC%OPR and too many 'personalities', you start to need _accountability_. In short, I'd rather have it logged someplace that somebody is */spying/*. CTYPEEK is unusual because it's one of the few programs that MRC put on the PANDA distribution that has no source code immediately available. That is unfortunate because having a program—/any/ program—that must run with SC%WHL or SC%OPR enabled with no source code has been bothering me. Some sleuthing turned up an email that Kirk Lougheed posted to Tops-20 Wizards in August 2nd, 1982 2316-PDT, nearly four decades ago (!!).  It was short enough that I did a complete rewrite, getting some additional functionality.  That actual list of enhancements is as follows: 1.     More effective error reporting, debugging and some recovery.     Debugging entry which will not do the actual link.     Exported entry for symbol table fix up for EXEC (when debugging). 2.     Granular capability management. 3.     Standard CTY discovery via STDEV% JSYS (original monitor SNOOP% and PEEK% probing kept as fall back) 4.     Logging to CTY standard to inform of monitoring by whom.     Notification of batch logging given to CTY (see below)     Silent reentry point to not advise console of said monitoring. 5.     Checking of existing CTY links and not re-link if already linked.     Cuts down on GETOK%'s to ACJ     Advise user of preexisting link (and do not log on CTY) 6.     If CTY links are full, advise of terminals doing monitoring 7.     Clears pause-on-command and pause-on-end-of-page on CTY and user's TTY 8.     Standard use of 'modern' program data vectors (PDV's) 9.     Write-protected PDV, CODE and SYMBOL .PSECT's (analogous to Tops-10 high segment) 10.     Detection of whether running in a batch stream.     If running in a batch stream, waits in a THIBR% JSYS for 18:38:28.864     Allows use of a batch stream to log to a file;     Batch log duration time and finish time in batch log    Allow early wake up via TWAKE% (so don't have to cancel the job) _Some sample output_: 28-Mar-2022 20:33:53 Console terminal (TTY5:) being monitored by SLOGIN, TTY46:, Job 11 % Console terminal (TTY5:) is already being monitored by you: SLOGIN, TTY45:, Job 10 20:23:19 USER   [Console terminal (TTY5:) being monitored by SLOGIN, TTY21:, Batch Job 9] 20:23:19 USER   % Will monitor a maximum of 18 Hours, 38 Minutes, 28 Seconds and 864 Milliseconds. 20:23:19 USER     Monitoring will be discontinued on Sunday, March 13, 2022 4:01:48PM-EDT Which is how I logged the EST to EDT transition (possibly the last one!) How do other DEC timesharing systems handle this? _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Mar 29, 2022, at 7:02 PM, Thomas DeBellis &lt;tommytimesharing(a)gmail.com&gt; wrote: You mean like hook the terminal driver to grab output for a particular line and stash it someplace? Sounds dangerous... Maybe something a SWS dude would do for you. Terminal spying is vastly useful when you need it.

'almost'? I found myself curious as to when it wouldn't be.  Could you elaborate?