10 Jan
2026
10 Jan
'26
10:47 p.m.
A couple of comments.
First of all, the implementation I did for RSX was inspired by a
previous implementation that was available from DECUS.
That version was written by Tom Wyant, and was on the sigtape from fall
1987 under [351,145]. It's written in Fortran.
The readme file there says that it was written to be compatible with the
"Columbia Finger System (DECUS Library V-SP-14)".
As such, the DECnet communication done by packets, and not some stream
paradigm. As RSX DECnet don't even have the concept of streams for
DECnet communication, it really is just completely requiring that you
get whole packets, which obviously could contain more than one line in
theory, but need to be small enough to fit into the receive buffer of
the receiving side. So any code that just collects a lot in a single
buffer and then sends that will cause problems for the RSX side of
communication.
But to continue on the origin of things - obviously then we have at
least two RSX clients/servers. Mine and the one from Tom Wyant. In
addition, since the one from Tom mentions another implementation V-SP-14
(I assume that's a VMS package), we have at least yet one more
implementation that someone might have seen or used.
This is also where object 117 comes from. That appears to have been the
object number used by those implementations.
And to make a couple of comments on the RSX version I wrote then. It is
capable of talking both on the local host, over DECnet and over TCP/IP.
It can also relay requests, if allowed by configuration. Since DECnet
addressing is different than TCP/IP, there is a bit of ambiguity if
multiple machines across both domains happen. RSX finger process the
DECnet addresses first, and IP addresses after, unless explicitly
requested to do thing in other ways.
So a request like JOCKE::bqt@MIM.SoftJAR.SE will first connect to DECnet
host JOCKE, and request a fingering of bqt(a)MIM.SoftJAR.SE at JOCKE.
JOCKE will then contact Mim.SoftJAR.SE, and request information on the
user "bqt". That should be pretty straight forward to follow, I hope.
(It is possible to have it first contact MIM.SoftJAR.SE and there
request information on JOCKE::bqt as well, with switches used the right
way...)
I would finally say that the major difference from the Internet finger
RFC is that this of course is talking over DECnet, and not TCP. Using a
known DECnet object number (117) instead of a known TCP port (79). :-)
Johnny
On 2026-01-10 21:30, Thomas DeBellis wrote:
Some time ago in 2024, while I was writing the Tops-20
Finger Server,
Johnny and I collaborated on a finger specification for Finger over
DECnet. By 'collaborate', I mean I tried putting something together and
Johnny pointed out the mistakes and things iterated from there. It is
hopefully better than an RFC.
The major difference from the Internet specification is that the
protocol more closely aligns with a record orientated paradigm which is
more appropriate for DECnet applications. It can be told to do
otherwise and stream large buffers, but the default is for the
application to limit messages to line at time of no more than about 100
characters. I don't remember if I ever publicly announced availability,
but it can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
The Tops-20 Finger server itself was effectively complete enough last
year that I felt it appropriate to write a setup guide. It can beread
as a companion piece to the DECnet specification for more background
information on how to implement the protocol.
Further, and perhaps of more interest, it shows how to set up a network
service on Tops-20 without Operator capability, which makes the server
safer to run. Think of not using Administrator (on Windows), root(on
Ultrix), or SYS:, JACCT or [1,2] (on Tops-10) if you know what those
are. I don't know what the equivalent is on other DEC operating
systems. It can also be found on VENTI2::FNGSRV-SETUP.TXT.TXT for
anonymous NFT.
If there are other DECnet finger clients on HECnet than Johnny's or
mine, I would be delighted to hear about it. It's pretty trivial;you
open a connection to a remote host on object 117 (decimal) and send
either a carriage return, a line feed (which gets you the default full
system listing) or a user name followed by one of those two characters.
You then read responses and print them until the connection closes.
That's it. That's all.
Maybe a one or two line Python program? I could probably still doa
trivial BLISS Common client, but I don't recall having learned the
DECnet API for VMS. At Marlboro, the little Bliss work that I didwas
for Tops-20 and Tops-10 and didn't do DECnet. Supposedly, it would have
been easy enough to run on VMS, but I never had the opportunity.
The only DECnet finger servers that are in full time production that I
am aware of are running on MIM:: and VENTI2::. TOMMYT:: runs it on an
experimental basis, but requires a monitor upgrade and reconfiguration
to do a full installation in order to go into production. I'll dothat
later this year, I hope.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol