[HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New)

On 2026-01-10 17:19, Johnny Billquist wrote: You wouldn't need to do that (assuming server.glaver.org accepts Finger requests from outside TCP/IP hosts). But if you're coming in through HECnet, I understand the logic. Any of "finger user@node", "finger node::user" or "finger user@node::" should work, for the case where node is a DECnet node (since Finger always tries DECnet first, at least for names that could be DECnet ones (no periods, 6 characters or less): SPCPI2::$ finger terry@spc11d [SPC11D.DECnet] SPC11D RSTS/E, Sunday, 10-Jan-1926 19:35 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 ...NCP KB0: 01:10 21:38 KB PiDP-11 Console VT100 Default directory: _SY0:[20,254] SPCPI2::$ finger spc11d::terry [SPC11D.DECnet] SPC11D RSTS/E, Sunday, 10-Jan-1926 19:35 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 ...NCP KB0: 01:10 21:38 KB PiDP-11 Console VT100 Default directory: _SY0:[20,254] However, this goes off into the weeds badly: $ finger terry@spc11d:: [TERRY@SPC11D via routing host SPCVAX] [SPCVAX.DECnet] [SPC11D.DECnet] [TERRY via routing host SPCVAX] [SPCVAX.DECnet] [TERRY: rerouting link via SPCRTR] [SPCRTR We got to SPC11D::. but it didn't recognize that "terry@" was a username on SPC11D:, and instead treated terry as a nodespec, didn't know it, gave it to its default finger gateway (SPCVAX::), which then said "I don't know of a node named TERRY, so I'm giving it to my external gateway, SPCRTR::, in the hope that it has a node table that knows what TERRY:: is. But SPCRTR is run- ning PyDECnet and doesn't proxy object 117. This is RSTS/E finger, although VMS Finger behaves the same way: SPCVXA::$ finger spcpi2::terry [SPCPI2.DECnet] SPCPI2 RSTS/E, Sunday, 10-Jan-1926 19:34 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 DCL KB0: 19:26 00:08 ^C PiDP-11 Console VT100 Default directory: _SY0:[20,254] SPCVXA::$ f terry@spcpi2 [SPCPI2.DECnet] SPCPI2 RSTS/E, Sunday, 10-Jan-1926 19:35 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 DCL KB0: 19:26 00:08 ^C PiDP-11 Console VT100 Default directory: _SY0:[20,254] VMS Finger also goes off into the weeds badly with user@node:: (hey, at least the implementations are consistent): SPCVXA::$ f terry@spcpi2:: [SPCPI2::: link failed] %NONAME-F-NOMSG, Message number 08018724 Accepting all 3 possible syntax flavors is to prevent conf- usion for users in a DECnet-only, TCP/IP-only or mixed environ- ments. Doing "Poor man's routing" in Finger is a "best effort". And some- times not good enough. Yes, and DECnet is NODE::USER (or NODE1::NODE2::USER). So mixing DECnet and TCP/IP hosts on the command line produces "interesting" results, even though the Finger implementations try to infer and do the right thing. However, the NODE1::NODE2::USER syntax isn't accepted by DECnet/E: SPCPI2:$ dir spcvxa::spc11d::terry ?NFT -- More than one Input node specification or VMS: SPCVXA::$ dir spcvxb::spcvxa::terry %DIRECT-E-OPENIN, error opening SPCVXB::SPCVXA::TERRY.*;* as input -RMS-E-FND, ACP file or directory lookup failed So this is likely a DECmail-11 construct, and if there's no general DECnet support then I guess Finger doesn't have to care, although it could generate better error messages. Since AFAIK there are no RFCs for DECnet, DECnet nodespecs are outside the scope of the RFCs. If you really wanted to hash this out (and be insulted in the process), we could call up the spirit of Ned Freed (who unfortunately passed away a few years ago) but was the authority on this sort of thing, first as the author of the PMDF mail software and member of most Internt standards bodies: https://en.wikipedia.org/wiki/Ned_Freed A lot of the more obscure treatment of mixed DECnet and TCP/IP host- names is being done to match what PMDF does. DECUS VMS Finger (for which I was the maintainer from March 1989 through July 2000, essentially the end of DECUS, although I still consider myself its maintainer and started cleaning it up again in late 2024. Note that this version of FINGER started as the Columbia Finger. It jumped from version 5.64 to V40.5.7, where V40 is for VMS version 4.0, and 5.7 was the Finger major and minor version. Rand hall took it over at V46.1.01 and had it through V50.1.00, at which point I took it over. It is a disgusting mess of legacy cruft for things like protocols that no longer exist, code paths no longer used, byzantine code structure, etc. Where things get "interesting" is where you hop from node to node, going from BITNET -> TCP/IP -> DECnet -> something. This was gone over with repeatedly by Frank and Laurie from FNAL, who were kind enough to allow experimentation with select hosts in- side FNAL, and often involved chaining BITNET, DECnet, and TCP/IP together on the same command line. The simple cases work as expected: SPC11D::$ finger bqt(a)mim.softjar.se [MIM.SOFTJAR.SE via routing host SPCVAX] [SPCVAX.DECnet] [MIM.SOFTJAR.SE] BILLQUIST Real name: Johnny Billquist Office: None, +41 79 xxx xxxx Home phone: +41 43 xxx xxxx Default directory: US00:[BQT] CLI: MCR SID: BQT SPC11D:: is a DECnet-only RSTS/E host. It got something it didn't recognize as a hostname, so handed the whole thing off to its default host (SPXVAX::) for unknown nodes. SPCVAX:: speaks both DECnet and TCP/IP, realized the node in question was a TCP/IP node and passed the request along, which mim answered. There's a number of issues that have only surfaced once I started working with a larger DECnet (beyond a small number of hosts in a single DECnet area) while at the same time most Internet hosts no longer support Finger. RSTS/E Finger falls on its face in a number of exciting ways when it tries to directly contact MIM: username@DECnet-nodename:: (technically invalid): $ finger bqt@MIM:: [BQT@MIM via routing host SPCVAX] [SPCVAX.DECnet] [MIM.DECnet] Unknown option: / Error connecting to BQT (Timeout on request) %FINGER-E-OOPS, error during read unit 11 file MIM::"117=" user PC 0001687C DECnet-nodename::username (should work): $ finger mim::bqt [MIM.DECnet] ?Disk block is interlocked at line 28070. I need to investigate both of those, though I think the first is caused by MIM not liking an option and not tell- ing me what the whole option is. But at least I wrote RSTS/E Finger from scratch, and it is better organized - 5 lines (total!) of Macro-11 and 1594 lines of Basic- Plus 2.