DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New)
10 Jan
2026
10 Jan
'26
9:30 p.m.
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 be read
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 do a
trivial BLISS Common client, but I don't recall having learned the
DECnet API for VMS. At Marlboro, the little Bliss work that I did was
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 do that
later this year, I hope.
10 Jan
10 Jan
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
11:05 p.m.
Oh yeah. Two more things.
All RSX machines I manage on HECnet is running the finger server. Feel
free to check on anyone of them at any time.
And the RSX finger server is available as an RPM. Just fetch and install.
Johnny
On 2026-01-10 22:47, Johnny Billquist wrote:
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:
--
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
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
11:51 p.m.
??
That's /very/ interesting. We had given a number of things to DECUS,
but I was unable to get through it all what I've found and I wonder if
even most of it. I think not.
What I wanted to do was build a DECUS pack and restore at least all the
Tops-20 files I could, Tops-10 and everything else depending on how much
disk space I could fit it. These save sets are from one of the last
20's on the Internet, whose name is famous and which I now (of course)
forget.
One of the issues that I ran into is that the build formats for DLUSER
(which is what one users for preconstructing a directory tree prior to
restoring from tape), did not work. What is from DECUS is not
compatible with Tops-20 version 7, so I would imagine that this is a
late version 6.
DLUSER has an undocumented positional format using raw binary. So if you
have something in the wrong position as what appears to be the case, you
will get complete junk for directories. It's far more efficient than a
tagged format like XML, but you just can't figure out what is going on
without a debugger and the source code.
It was on my list of things to do, I'll see if I can't scare up V-SP-14.
On 1/10/26 5:05 PM, Johnny Billquist wrote:
The readme file there says that it was written to be
compatible with
the "Columbia Finger System (DECUS Library V-SP-14)
11 Jan
11 Jan
3:24 a.m.
I can't seem to find the Tops-20 DECUS archive at the usual suspects,
Bitsavers and TrailingEdge.
A great bit of googling hasn't gotten me anywhere.
Does anybody know where I can go now?
------------------------------------------------------------------------
On 1/10/26 5:51 PM, Thomas DeBellis wrote:
??
That's /very/ interesting. We had given a number of things to DECUS,
but I was unable to get through it all what I've found and I wonder if
even most of it. I think not.
What I wanted to do was build a DECUS pack and restore at least all
the Tops-20 files I could, Tops-10 and everything else depending on
how much disk space I could fit it. These save sets are from one of
the last 20's on the Internet, whose name is famous and which I now
(of course) forget.
One of the issues that I ran into is that the build formats for DLUSER
(which is what one users for preconstructing a directory tree prior to
restoring from tape), did not work. What is from DECUS is not
compatible with Tops-20 version 7, so I would imagine that this is a
late version 6.
DLUSER has an undocumented positional format using raw binary. So if
you have something in the wrong position as what appears to be the
case, you will get complete junk for directories. It's far more
efficient than a tagged format like XML, but you just can't figure out
what is going on without a debugger and the source code.
It was on my list of things to do, I'll see if I can't scare up V-SP-14.
On 1/10/26 5:05 PM, Johnny Billquist wrote:
> The readme file there says that it was written to be compatible with
> the "Columbia Finger System (DECUS Library V-SP-14)
3:36 a.m.
I’m not sure if it is what you’re looking for, but DECUS 20-LIB-1 through 20-LIB-11 can be
found at https://pdp-10.trailing-edge.com/ .
3:59 a.m.
Yep, that works. I'll go grab everything.
On 1/10/26 9:36 PM, amp1ron(a)gmail.com wrote:
I’m not sure if it is what you’re looking for, but DECUS
20-LIB-1 through 20-LIB-11 can be found at
https://pdp-10.trailing-edge.com/ .
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
10 Jan
10 Jan
11:08 p.m.
On 2026-01-10 15:30, Thomas DeBellis wrote:
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.
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 do that
later this year, I hope.
SPCVXA::, SPCVXB:: and SPC11D:: should all have working (ish)
Finger servers. The first two are VAX/VMS V7.3 systems in a
cluster with DECUS Finger (as maintained by me). SPC11D: is a
RSTS/E V10.1 system with a Finger server written from scratch
by me.
If anyone really wants it, I could bring up a PC (SPCPCA::,
not a known HECnet node) running MS-DOS Finger using PCSA/
DECnet/DOS, Pathworks, or whatever nom de jour it was using
back then). The output is pretty boring when Finger-ing into
it, but it does implement both a full client as well as pass-
thru. Locally it just says "You are the only user, of course."
when run. That one was also written from scratch by me.
Note that the SPCxxx:: Fingers can tack on an undocumented
/IAM qualifier which I need to get around to removing. Back
when the world was a kinder, gentler place and Finger might
be restricted to within an organization, /IAM told the re-
mote host your username and nodename (nodename is needed be-
cause there might be intermediate nodes) in order for the
remote Finger server to tell you if the user you were Fin-
gering had unread mail from you.
I'll be removing the generation of /IAM and will ignore
any /IAM received.
I'd like to suggest that unknown qualifiers on the received
request be silently ignored and that all implementations in-
clude support for the /help qualifier.
Likewise, support for empty lines ("list all users") and
a line with just a username should be supported. Implemen-
tations should feel free to generate appropriate errors if
they choose to not allow listing all users, not listing a
specific user, etc.
If routing is allowed (host1::host2::user@host3:: type con-
nections, intermediate hosts should pass the received com-
mand line through unchanged, even if that command line has
options that the local system doesn't understand/implement.
If you want to receive an essay, do "finger spcvxa::/help"
Some examples:
Example: SPC11D:: to SPCVXA::
$ finger spcvxa::/all
[SPCVXA.DECnet]
SPC Memorial VAXcluster
SPCVXA VAX 8650, OpenVMS V7.3, Sat, 10-Jan-2026 16:38, 0 Users, 0 Batch
Uptime 6 15:26, since Sun, 4-Jan-2026 01:12, Load: 0.00 0.00 0.00
PID Username Program Term Login CPU Location
TT Type
20E00101 <Swapper> $ System 00:00 0:00
20E0010E AUDIT$SERVER Audit_Ser System 01:13 0:00
20E00113 DECNET Netacp System 01:13 0:01
20E00114 DECNET Evl Network 01:13 0:00
20E00130 PHONE$SERVER Finger Network 16:33 0:00
20E00106 SYSTEM Csp System 01:13 0:00
20E00107 SYSTEM Configure System 01:13 0:00
20E00108 SYSTEM Lanacp System 01:13 0:00
20E0010A SYSTEM Ipcacp System 01:13 0:00
20E0010B SYSTEM Errfmt System 01:13 0:00
20E0010C SYSTEM Fileserv System 01:13 0:00
20E0010D SYSTEM Opcom System 01:13 0:00
20E0010F SYSTEM Jbc$Job_C System 01:13 0:00
20E00110 SYSTEM Qman$Queu System 01:13 0:00
20E00111 SYSTEM Security_ System 01:13 0:00
20E00112 SYSTEM Smiserver System 01:13 0:00
20E00115 SYSTEM Remacp System 01:13 0:00
20E00116 SYSTEM Server System 01:13 0:00
20E00118 SYSTEM Sshd_Mast System 01:13 0:50
20E00119 SYSTEM Ntpd System 01:13 0:00
20E0011A SYSTEM Dia Detach 01:14 1:02
20E0011C SYSTEM Latacp System 01:14 0:00
20E0011E SYSTEM $ OPA0: 01:14 0:08 System Console
VT320
$ finger spcvxa::system
[SPCVXA.DECnet]
SPCVXA OpenVMS, Sat, 10-Jan-2026 16:33
PID Username Program Term Login CPU Location
TT Type
20E0011E SYSTEM $ OPA0: 01:14 0:08 System Console
VT320
Default directory: SYS$SYSROOT:[SYSMGR]
Logged in since: Sun, 4-Jan-2026 19:51
Last non-interactive login: Sun, 4-Jan-2026 19:51
Mail: (no new mail)
Plan: (no plan file)
Examples: SPCVXB:: to SPC11D::
SPCVXB::$ f spc11d::
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Sunday, 10-Jan-1926 16:36, 8 Jobs, 63
Max.
Uptime 6 16:01:06, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
SPCVXB::$ f spc11d::terry
[SPC11D.DECnet]
SPC11D RSTS/E, Sunday, 10-Jan-1926 16:36
Job Username PPN Progrm Term Login CPU ST Location
TTType
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11 Console
VT100
Default directory: _SY0:[20,254]
Logged in since: Monday, 4-Jan-1926 01:11
Mail: (no new mail)
Plan:
Half of "The Bob & Terry Show", 1993-present
Volunteer at the LSSM (Large Scale Systems Museum), 2016-present
Volunteer at BERA (the Shore Line Trolley Museum), 2000-present
Former Senior Network Engineer, Verio NY Metro Region, 1999-2001
Official Verio Motto: "Too many databases, too few brains"
Former Operations Manager, SPC Academic Computing, 1976-1999
Official St. Peter's College Motto: "Nobody told me about this!"
Personal web page: Personal email:
http://www.glaver.org terry(a)glaver.org
Example: Getting fancy ("Escaping" from HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
[SPC11D.DECnet]
[SERVER.GLAVER.ORG via routing host SPCVAX]
[SPCVAX.DECnet]
[SERVER.GLAVER.ORG]
Unauthorized Access Strictly Prohibited
SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Sat, 10-Jan-2026 16:46, 1 User, 0
Batch
Uptime 70 00:59, since Sat, 1-Nov-2025 15:46, Load: 0.00 0.01 0.02
PID Username Program Term Login CPU Location
TT Type
0003A703 TERRY $ NTY17: 19:21 0:03 office.glaver.or
VT3xx
00034C64 TERRY $ NTY14: 00:59 0:16 bedroom.glaver.o
VT3xx
To explain that, SPCVXB opened a finger connecton to SPC11D::, asking
about server.glaver.org (the :: has to be tacked on so it isn't treated
as a username on SPC11D. SPC11D is a DECnet-only host and it doesn't
know about anything named server.glaver.org, so it kicks it to its con-
figured Finger router, SPCVAX:: (a cluster DECnet alias for SPCVXA:: and
SPCVXB::). SPCVAX:: speaks both DECnet and TCP/IP, realizes that server.
glaver.org is an Internet hostname and not a DECnet node, and opens a
TCP/IP Finger connection to server.glaver.org (you can see that the
trans-
port isn't DECnet as it didn't append ".DECnet" to the host string).
VMS
Finger also supports a bunch of obsolete transports, like .BITNET.
11:19 p.m.
On 2026-01-10 23:08, Terri Kennedy wrote:
Example: Getting fancy ("Escaping" from
HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
I find it really weird to use that kind of syntax, and it probably will
create a mess if you involve some other TCP/IP based finger server in
such a line.
In my RSX implementation, you would write
FINGER SPC11D::@server.glaver.org
The RFC for finger on TCP/IP really states that hosts should be
processed right to left, and the username is at the left end. So you can do
finger bqt@mim.softjar.se@foo.bar.host.net
Which would contact foo.bar.host.net from the local machine, and request
bqt(a)mim.softjar.se as the username to that host, which would then go and
contact mim.softjar.se, just requesting information for user "bqt".
If you pass it something with :: as a separation between hosts and/or
usernames, a RFC compliant finger server will not do what you would hope
for.
I will obviously not force anyone to rewrite any implementation, but be
aware that a proper TCP/IP RFC compliant finger server is incompatible
with this form host host name chains.
Johnny
--
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
11 Jan
11 Jan
12:41 a.m.
As far as I am aware, Johnny is completely correct.
Internet Finger expects RFC822 formatted names. An example would be
slogin(a)venti2.tommytimesharing.org, which triggers TCP/IP transport.
Identifying the same user on the same machine on HECnet uses MAIL11
format, or VENTI2::SLOGIN. Application level routing works as Johnny
describes.
So the parser works by waking up on a trailing "::" which is MAIL11
syntax to identify a node. MAIL11 format is preferred over RFC822, so
it checks that the proceeding characters are valid syntax for a DECnet
node (restricted SIXBIT, 6 characters maximum) and that the identified
node is in the HECnet database. If it fails, you get a parse error. If
you have no trailing "::" and bump into an "@" sign, then RFC822
parsing
is used.
So the "::" is used as a field terminator, whereas the "@" functions
as
a field separator. Surrounding things with "::" probably won't work. I
believe I allow complex forwarded remote specifications to be surrounded
by double quotes, which is how I handle that funny Unix 'bang' (!) syntax.
Under Tops-20, finger is integrated into the mail system and is used to
resolve personal names into user ids.
------------------------------------------------------------------------
On 1/10/26 5:19 PM, Johnny Billquist wrote:
I find it really weird to use that kind of syntax, and it probably
will create a mess if you involve some other TCP/IP based finger
server in such a line.
In my RSX implementation, you would write
FINGER SPC11D::@server.glaver.org
The RFC for finger on TCP/IP really states that hosts should be
processed right to left, and the username is at the left end. So you
can do
finger bqt@mim.softjar.se@foo.bar.host.net
Which would contact foo.bar.host.net from the local machine, and
request bqt(a)mim.softjar.se as the username to that host, which would
then go and contact mim.softjar.se, just requesting information for
user "bqt".
If you pass it something with :: as a separation between hosts and/or
usernames, a RFC compliant finger server will not do what you would
hope for.
I will obviously not force anyone to rewrite any implementation, but
be aware that a proper TCP/IP RFC compliant finger server is
incompatible with this form host host name chains.
Johnny
------------------------------------------------------------------------
On 2026-01-10 23:08, Terri Kennedy wrote:
Example: Getting fancy ("Escaping" from HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
2:30 a.m.
On 2026-01-10 18:41, Thomas DeBellis wrote:
As far as I am aware, Johnny is completely correct.
Internet Finger expects RFC822 formatted names. An example would be
slogin(a)venti2.tommytimesharing.org, which triggers TCP/IP transport.
Identifying the same user on the same machine on HECnet uses MAIL11
format, or VENTI2::SLOGIN. Application level routing works as Johnny
describes.
There's two pieces here - DECnet/HECnet addressing: node::user
and TCP/IP addressing: user(a)node.example.com
Both the DECUS ("my") VMS Finger and and RSTS/E Finger try to
handle both cases. In a reply I sent after you sent this, but
before I replied to this, I went into a lot more detail. Do a
search for "Ned Freed" in the message body to find the message
I'm talking about.
So the parser works by waking up on a trailing
"::" which is MAIL11
syntax to identify a node. MAIL11 format is preferred over RFC822, so
it checks that the proceeding characters are valid syntax for a DECnet
node (restricted SIXBIT, 6 characters maximum) and that the identified
node is in the HECnet database. If it fails, you get a parse error.
If you have no trailing "::" and bump into an "@" sign, then RFC822
parsing is used.
So the "::" is used as a field terminator, whereas the "@" functions
as
a field separator. Surrounding things with "::" probably won't work.
I believe I allow complex forwarded remote specifications to be
surrounded by double quotes, which is how I handle that funny Unix
'bang' (!) syntax.
VMS and RSTS/E Finger look at the host part and if it makes
sense to try it as a DECnet name (6 characters or less, all
legal, no periods) it silently tries it as DECnet first. If
it succeeds, then it prints the [NODE.DECnet] header and re-
ports what it got back. If none of the above conditions were
satisfied, or if the nodename doesn't exist in the DECnet data-
base, it's tried as TCP/IP hostname.
Oh, and they will also accept DECnet node numbers or IP ad-
dresses.
Under Tops-20, finger is integrated into the mail
system and is used to
resolve personal names into user ids.
Both VMS Finger and RSTS/E Finger have their own methods
of looking up users by personal names. VMS Finger gets
them from SYSUAF, RSTS/E Finger gets them from Mail-11 or
(if that isn't installed) a names file processed by a Fin-
ger utility.
-------------------------
On 1/10/26 5:19 PM, Johnny Billquist wrote:
I find it really weird to use that kind of syntax, and it probably will
create a mess if you involve some other TCP/IP based finger server in
such a line.
In my RSX implementation, you would write
FINGER SPC11D::@server.glaver.org
The RFC for finger on TCP/IP really states that hosts should be
processed right to left, and the username is at the left end. So you
can do
finger bqt@mim.softjar.se@foo.bar.host.net
Which would contact foo.bar.host.net from the local machine, and
request bqt(a)mim.softjar.se as the username to that host, which would
then go and contact mim.softjar.se, just requesting information for
user "bqt".
If you pass it something with :: as a separation between hosts and/or
usernames, a RFC compliant finger server will not do what you would
hope for.
I will obviously not force anyone to rewrite any implementation, but be
aware that a proper TCP/IP RFC compliant finger server is incompatible
with this form host host name chains.
Johnny
-------------------------
On 2026-01-10 23:08, Terri Kennedy wrote:
Example: Getting fancy ("Escaping" from HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3:36 p.m.
This became more confused and complicated than I anticipated.
So I'll try and rephrase this, and hopefully people can agree, and if
not we can take it from there.
First of all we have the TCP/IP finger protocol.
This is defined in RFC 1288.
This protocol talks over TCP, with the server listening on port 79. A
client opens the connection and sends a one line query, terminated by
CR+LF. The query as such is basically in the form user@host2@host1,
where all the parts are optional. However, note that the username is the
leftmost component before the first @, and the host to communicate to is
the rightmost component, after the last @.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed right to left, and the
optional username is the leftmost part. Any host that talks finger over
TCP really should follow this RFC. Anything else is fundamentally bad,
and I hope all would agree with that.
Next we have finger over DECnet.
There are no formal standard for this. But there have existed
implementations since the 80s. Thomas tried to summarize how it should
work, which is aligned with those old implementations, and is also what
both him and me have tried to follow.
This protocol then talks over DECnet, with the server defined as the
DECnet object 117. A client opens the connection and sends a one line
query. The query as such is basically in the form host1::host2::user,
where all the parts are optional. However, note that the username is the
rightmost component, after the last ::, and the host to communicate to
is the leftmost component, before the first ::.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed left to right, and the
optional username is the rightmost part. Any host that talks finger over
DECnet really should follow this spec. Anything else is pretty bad, and
I hope all would agree with that.
So that's the basics. It's pretty straight forward, and I hope very
uncontroversial. However, please note the complete different parsing
order of hosts and usernames in TCP/IP and DECnet. This is important!
Before I go on I want to make a small comment on the topic of streaming
connections in DECnet. DECnet is inherently packet based. Some operating
systems provide an abstraction to streams on top of this, but not all
OSes do. And this stream abstraction is not the same thing as TCP, and
it is important to understand this. If your host pretends you use a
stream, it can still arrive as packets on the peer side. There is no
explicit stream type, and the packing/unpacking of data from a stream
into packets are done at a layer above DECnet itself. This became
obvious when me and Thomas were doing some initial work on
interoperability between TOPS-20 and RSX. The problem being that Thomas
was letting TOPS-20 treat the connection as a stream, and we got into
trouble on the RSX side.
TOPS-20 were just putting all the data to send into one packet in the
end. In RSX when receiving, you give a buffer with a size where received
data should be placed. And if the packet contain more data than fits in
the buffer, the remaining data is not kept, but discarded, and you get a
data overrun status in the receive.
So it's not actually a problem with streaming as such, but the size of
packets you might end up with. If TOPS-20 streams would just limit the
actual eventual packet to no more than some certain size, RSX will play
just fine. The fact that TOPS-20 pretend it's a stream is not a problem.
The problem is identical if you use packets, and just use a packet size
that is larger than what the receiver is expecting.
So if there is a way for any streaming abstraction layer to just say
what the maximum size of the packets should be, then by all means, run
with a stream if you want to, and it will work fine (just let me know
what your upper limit is set to, and I can adjust the RSX code
correspondingly).
Ok. Final part. Things become "interesting" when you start mixing TCP/IP
and DECnet. Since TCP/IP requests do hosts and users processing right to
left, and DECnet requests do hosts and users processing left to right,
and they also use different separators between hosts and usernames, how
do you get this to mix?
Terri's example:
finger terry@spc11d::
is a complete mess. How should this be parsed. If we go by TCP/IP
standard, anything to the right of the last @ should be the host, which
is "spc11d::". But that's not a host you would find in DNS.
But it's also not useful to process according to DECnet, because then we
say that everything before the first :: is the node, which would be
"terry@spc11d", which is clearly not a DECnet node.
So, please, drop that. That is pretty obviously illegal, no matter which
way you want to look at it.
What I did in RSX is, what I think, the only reasonable way to do this
right. So the request would be:
finger spc11d::terry
Which of course is a DECnet request. If you somehow wanted to involve
TCP/IP in this, the format would be
finger spc11d::terry@mim.softjar.se
as an example. And this will work on any system on TCP/IP that talks
finger (could be any Unix host in the world). It do not need to know or
understand anything about DECnet at all. Because it talks TCP/IP, and it
picks the rightmost host after the last @ as the machine to connect to,
and it passes to that the request "spc111d::terry", which is then up to
Mim.SoftJAR.SE to understand and do anything with. Which boils down to
the same DECnet request as the first example above.
And guess what, here is how it looks on my MAC, right now:
Gromit:/Users/bqt> finger spc11d::terry@mim.softjar.se
[mim.softjar.se]
[SPC11D::]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 09:29, 8 Jobs, 63 Max.
Uptime 7 08:54:20, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:06 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:14 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
Gromit:/Users/bqt>
So I can actually finger a RSTS/E host from a MAC. How fun isn't that?
(Don't ask me why I'm not getting information about Terry, though,
because I get the exact same result if I just do a "finger
spc11d::terry" on Mim directly.
Maybe an example with VENTI2 would be more fun:
Gromit:/Users/bqt> finger venti2::slogin@mim.softjar.se
[mim.softjar.se]
[VENTI2::]
SLOGIN Thomas DeBellis 8 EMACS 9:58 44 iSnack.Jute:
Development, Larg
9 EXEC 11:55. 45 iSnack.Jute: Logging,
Wide
10 EXEC 10:58. 46 iSnack.Jute:
Secondary Testing
11 SYSDPY 10:02 47 iSnack.Jute: Testing
and Debug
12 EXEC 43:24. 50 Neptune.Jute: STAR
Testing, Sm
14 EXEC **:**. 51
IUUGAA4-Wireless.Jute: Bedroom
15 KERMIT 36:50 52 iSnack.Jute: CKermit
Testing
16 VIKING 23 Batch: Kermit
Loopback Testing
No new mail, last read on Sat 3-Jan-2026 4:12PM
Gromit:/Users/bqt>
It is pretty neat, if I ask me. :-)
If you do this on MIM, it will by default first try to process DECnet
nodes, so it will take the first node name, up to the first :: as the
node to connect to, and then pass everything after that to the server,
meaning "terry(a)mim.softjar.se" as the query. Now, if spc11d don't talk
TCP/IP, you'll get an error here. But if it do talk TCP/IP, and is
following the RFC, it will understand that query just fine, and should
do the right thing without any funniness.
If, on MIM, you actually want
spc11d::terry@mim.softjar.se to be doing the TCP/IP part first, then you
need to add a switch to make it so. And then it will be the same as any
other TCP/IP finger client, and work the same as described in that bit
above. So still all good.
Any other notations will break either the RFC or the DECnet finger spec.
Now, as I said before, I'm not going to force anyone to change their
code. But I really do find it broken to have code which tries to decide
if something is TCP/IP or DECnet by guessing and some heuristics. And
since the inherent order of hosts are in the opposite directions in
TCP/IP and DECnet, no heuristics in the world can actually make this
actually work right according to the two specs. You'll have to break
compatibility with one or the other protocol.
Up to everyone of you how you want to look at that. But I can tell you
that the RSX implementation will continue to try and follow both specs.
So TCP/IP hostnames will never be assumed for a node that ends with ::,
and DECnet nodenames will never be assumed for something that starts
with @. And this is also true for mail. And that is also how the mail
relaying on MIM is doing things, and how you can send mail from HECnet
to the internet by saying
MIM::user@host
And send mail from the internet to hosts on HECnet by
node::user@Mim.SoftJAR.SE
And please be aware that gmail reception is broken, and they don't
accept mails from HECnet because of that. Nothing I can do about it.
gmail basically do not accept mails with a from address in the form of
"node::user"@mim.softjar.se, although it is correct according to RFC
5321. Google apparently don't care that they are violating the RFC.
Johnny
--
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
12 Jan
12 Jan
4:14 a.m.
On 2026-01-11 09:36, Johnny Billquist wrote:
This became more confused and complicated than I
anticipated.
Welcome to sitting on a standards body*. I did some of that
in my DECUS days.
* It's a lot easier if the body is dead, because 1) if it's
dead, you're less likely to roll off and 2) if it's dead, it
is also likely that nobody cares because the body is dead al-
ready.
8-}
So I'll try and rephrase this, and hopefully
people can agree, and if
not we can take it from there.
Sounds like a plan.
First of all we have the TCP/IP finger protocol.
This is defined in RFC 1288.
This protocol talks over TCP, with the server listening on port 79. A
client opens the connection and sends a one line query, terminated by
CR+LF. The query as such is basically in the form user@host2@host1,
where all the parts are optional. However, note that the username is
the leftmost component before the first @, and the host to communicate
to is the rightmost component, after the last @.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed right to left, and the
optional username is the leftmost part. Any host that talks finger
over TCP really should follow this RFC. Anything else is fundamentally
bad, and I hope all would agree with that.
Agreed. I would just add that optional arguments (which the RFC hand-
waves as "Query Tokens" and only mentions in passing (but does not de-
scribe the function of) the /W token, so there are other possible arg-
uments, which a given server implementation may or may not implement.
Can we agree that one or more optional "tokens" (/foo) MAY appear in
the query, that implementations SHOULD ignore tokens they do not under-
stand/implement, SHOULD implement a /HELP token, and MUST pass the com-
plete query (after removing their own name), including any tokens, in-
cluding /HELP to the next host (if any). To clarify, if a system that
receives a Finger query is just "passing it along", it should not re-
spond to /HELP itself, but just pass it along as well.
Next we have finger over DECnet.
There are no formal standard for this. But there have existed
implementations since the 80s. Thomas tried to summarize how it should
work, which is aligned with those old implementations, and is also
what both him and me have tried to follow.
This protocol then talks over DECnet, with the server defined as the
DECnet object 117. A client opens the connection and sends a one line
query. The query as such is basically in the form host1::host2::user,
where all the parts are optional. However, note that the username is
the rightmost component, after the last ::, and the host to
communicate to is the leftmost component, before the first ::.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed left to right, and the
optional username is the rightmost part. Any host that talks finger
over DECnet really should follow this spec. Anything else is pretty
bad, and I hope all would agree with that.
Agreed, subject to my comments on RFC 1288 above.
I'd also add that "An implementation MAY decide to forward the re-
quest to another DECnet node if it does not have an node definition
for the host being queried.
So that's the basics. It's pretty straight
forward, and I hope very
uncontroversial. However, please note the complete different parsing
order of hosts and usernames in TCP/IP and DECnet. This is important!
Yup. At least since the UK moved off Grey Book (where the CS system
at Foo University was uk.ac.foou.cs instead of cs.foou.ac.uk - we used
to joke that "they drive on the wrong side of the Internet, too". 8-)
Gatewaying is implementation-specific and MAY be provided. If it is
provided, it SHOULD follow the appropriate rules for left-to-right and
right-to-left parsing as described above.
Before I go on I want to make a small comment on the
topic of
streaming connections in DECnet. DECnet is inherently packet based.
Some operating systems provide an abstraction to streams on top of
this, but not all OSes do. And this stream abstraction is not the same
thing as TCP, and it is important to understand this. If your host
pretends you use a stream, it can still arrive as packets on the peer
side. There is no explicit stream type, and the packing/unpacking of
data from a stream into packets are done at a layer above DECnet
itself. This became obvious when me and Thomas were doing some initial
work on interoperability between TOPS-20 and RSX. The problem being
that Thomas was letting TOPS-20 treat the connection as a stream, and
we got into trouble on the RSX side.
TOPS-20 were just putting all the data to send into one packet in the
end. In RSX when receiving, you give a buffer with a size where
received data should be placed. And if the packet contain more data
than fits in the buffer, the remaining data is not kept, but
discarded, and you get a data overrun status in the receive.
So it's not actually a problem with streaming as such, but the size of
packets you might end up with. If TOPS-20 streams would just limit the
actual eventual packet to no more than some certain size, RSX will
play just fine. The fact that TOPS-20 pretend it's a stream is not a
problem. The problem is identical if you use packets, and just use a
packet size that is larger than what the receiver is expecting.
So if there is a way for any streaming abstraction layer to just say
what the maximum size of the packets should be, then by all means, run
with a stream if you want to, and it will work fine (just let me know
what your upper limit is set to, and I can adjust the RSX code
correspondingly).
I'd never heard of streaming until this discussion came around the
first time (2024). I've always written lines as records in my imple-
mentation.
Ok. Final part. Things become "interesting"
when you start mixing
TCP/IP and DECnet. Since TCP/IP requests do hosts and users processing
right to left, and DECnet requests do hosts and users processing left
to right, and they also use different separators between hosts and
usernames, how do you get this to mix?
Terri's example:
finger terry@spc11d::
is a complete mess. How should this be parsed. If we go by TCP/IP
standard, anything to the right of the last @ should be the host,
which is "spc11d::". But that's not a host you would find in DNS.
But it's also not useful to process according to DECnet, because then
we say that everything before the first :: is the node, which would be
"terry@spc11d", which is clearly not a DECnet node.
So, please, drop that. That is pretty obviously illegal, no matter
which way you want to look at it.
This is entirely a matter of how the user command line is parsed
by the Finger client. It SHOULD be free to parse things however it
likes. but MUST only send a properly-formed query to a Finger server.
Back in the day, we had DECnet, BITNET, and TCP/IP (and some other
protocols). So you could say "finger user(a)node.decnet" (and use "fin-
ger user@node::" as a shortcut). Likewise for "finger user(a)node.bitnet"
- these were all treated as ".decnet" and ".bitnet" pseudo-TLDs. This
is also what PMDF (see prior references to Ned Freed) does.
Unless there were cases where DECnet host FOO::. BITNET host FOO,
and TCP/IP host foo.example.com differed, you could just say "finger
user@host" and Finger would figure out the appropriate transport by
querying the host tables / DNS in that order - DECnet, BITNET, and
TCP/IP.
This made it easy for users (who often didn't know what sort of
network connection was used to talk to their buddy Fred on host
foobar). "finger fred@foobar" would just Do The Right Thing.
But note that all this optional work MUST be done entirely on the
user's local finger client, and what gets emitted as a Finger comm-
and line MUST be appropriate for the next hop's Finger server. It
SHOULD reject a message it considers ill-formed with an appropriate
error message.
To summarize, in addition to supporting canonical DNS (user@foo.
example.com) and DECnet (FOO::USER) address forms, a client MAY
support any other syntax, including (perhaps) user- or system-wide
mappings (for example, FOO::ERNIE -> FOO::ERNEST, or even joe@
oldjob.example.com -> Joseph.Lastname(a)otherjob.blah.org). This all
happens in the client, and as a server implementer you don't need
to worry about it at all.
All I'm asking for on the server side is:
1) If acting as a smarthost, remove your node from the command
line (if it wasn't already) and pass it along to the next host.
*** Otherwise ***
2) Support whatever restrictions the server wants as to whether
lists of logged-in users can be provided, whether queries
must match a specific username or can provide a list of users,
decide to show .plan (or site equivalent) data, etc.
3) At the implementations choice, handle unknown qualifiers via
one of these methods (from most preferred to least preferred):
a) Report "Unknown command qualifier /FOO" for each unknown
qualifier, one per line, but return the requested informa-
tion (see the example below).
b) As a) above, except exit without returning any user infor-
mation after reporting errors as in a) above.
c) Silently ignore unknown qualifiers and return output for
the requested information.
4) Implement the qualifier /HELP which will provide (at a mini-
mum) the list of supported qualifiers.
Example of 3a:
$ finger terry@spc11d/wumpus/fuzzy/noxact
[SPC11D.DECnet]
?FINGER - Unrecognized command qualifier '/WUMPUS'.
?FINGER - Unrecognized command qualifier '/FUZZY'.
?FINGER - Unrecognized command qualifier '/NOXACT'.
SPC11D RSTS/E, Monday, 11-Jan-1926 21:25
Job Username PPN Progrm Term Login CPU ST Location
TTType
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
Default directory: _SY0:[20,254]
Logged in since: Monday, 4-Jan-1926 01:11
Mail: (no new mail)
Plan:
Half of "The Bob & Terry Show", 1993-present
What I did in RSX is, what I think, the only
reasonable way to do this
right. So the request would be:
finger spc11d::terry
Which of course is a DECnet request. If you somehow wanted to involve
TCP/IP in this, the format would be
finger spc11d::terry@mim.softjar.se
as an example. And this will work on any system on TCP/IP that talks
finger (could be any Unix host in the world). It do not need to know
or understand anything about DECnet at all. Because it talks TCP/IP,
and it picks the rightmost host after the last @ as the machine to
connect to, and it passes to that the request "spc111d::terry", which
is then up to Mim.SoftJAR.SE to understand and do anything with. Which
boils down to the same DECnet request as the first example above.
The user's Finger client is stripping off the first host (DECnet or
DNS, let's forget about BITNET) and so your:
finger spc11d::terry@mim.softjar.se
gets turned into "open a connection to the finger server on mim.soft-
jar.se and send it the query 'spc11d::terry'". Whether or not it de-
cides to forward that request is an implementation and/or site-specif-
ic determination. As an example, while debugging this with the folks
at FNAL, it was important that their public-facing servers not allow
unrestricted DECnet Fingering of the various internal hosts, some of
which held classified data.
And guess what, here is how it looks on my MAC, right
now:
Gromit:/Users/bqt> finger spc11d::terry@mim.softjar.se
[mim.softjar.se]
[SPC11D::]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 09:29, 8 Jobs, 63
Max.
Uptime 7 08:54:20, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:06 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:14 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
Gromit:/Users/bqt>
Are you actually seeing blank lines in the output, or is this
just the way this message was formatted?
The implementation stuff as I've described it above is how RSTS/E
Finger currently operates (modulo a few bugs, which I'll fix) and
we can have a DECnet "bake-off" at some point in the future, once
we've settled on a spec.
The point I tried (and failed miserably) to make in earlier emails
is that whatever form of address the user gives the finger client on
their system is immaterial (beyond being something that generally
makes sense to users on that system) but what actually gets send as
a command line to a remote Finger server has to match the canonical
format, as described in the DECnet/E finger draft and (hopefully) as
amended by me above.
So I can actually finger a RSTS/E host from a MAC. How
fun isn't that?
(Don't ask me why I'm not getting information about Terry, though,
because I get the exact same result if I just do a "finger
spc11d::terry" on Mim directly.
I'm going to need to implement logging (as defined in the draft
spec).
More interesting is what I get back when I try fingering MIM::
from SPCPI2:: (running the same finger as SPC11D):
SPCPI2::$ finger mim::
[MIM.DECnet]
Unknown option: /IAM="TERRY~SPCPI2"
User FINGER not found!
SPCPI2::$ finger mim::billquist
[MIM.DECnet]
User BILLQUIST/IAM="TERRY~SPCPI2" not found!
The "/IAM" business I mentioned previously and that needs to go
away (never send, ignore on receipt). But I'm not sure why the
first request is being treated as a request for user "FINGER",
unless my RSTS/E client is mistakenly sending a request that had
the string "FINGER" in it. Johnny, does your server log these
requests?
"finger spc11d::terry" works here from spcpi2:
SPCPI2::$ finger spc11d::terry
[SPC11D.DECnet]
SPC11D RSTS/E, Monday, 11-Jan-1926 21:52
Job Username PPN Progrm Term Login CPU ST Location
TTType
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
Default directory: _SY0:[20,254]
Logged in since: Monday, 4-Jan-1926 01:11
Mail: (no new mail)
Plan:
Half of "The Bob & Terry Show", 1993-present
Maybe an example with VENTI2 would be more fun:
I'm wondering if we're using different end-of-line
characters or something.
Gromit:/Users/bqt> finger
venti2::slogin@mim.softjar.se
[mim.softjar.se]
[VENTI2::]
SLOGIN Thomas DeBellis 8 EMACS 9:58 44 iSnack.Jute:
Development, Larg
9 EXEC 11:55. 45 iSnack.Jute: Logging,
Wide
10 EXEC 10:58. 46 iSnack.Jute:
Secondary Testing
11 SYSDPY 10:02 47 iSnack.Jute: Testing
and Debug
12 EXEC 43:24. 50 Neptune.Jute: STAR
Testing, Sm
14 EXEC **:**. 51
IUUGAA4-Wireless.Jute: Bedroom
15 KERMIT 36:50 52 iSnack.Jute: CKermit
Testing
16 VIKING 23 Batch: Kermit
Loopback Testing
No new mail, last read on Sat 3-Jan-2026 4:12PM
Gromit:/Users/bqt>
It is pretty neat, if I ask me. :-)
Yup. It was wilder when we could add BITNET transport and MS-DOS
Finger servers to the equation. Yes, my MS-DOS Finger server did do
next-hop. At one time I also had Netware as a transport. All long
dead and gone protocols.
If you do this on MIM, it will by default first try to
process DECnet
nodes, so it will take the first node name, up to the first :: as the
node to connect to, and then pass everything after that to the server,
meaning "terry(a)mim.softjar.se" as the query. Now, if spc11d don't talk
TCP/IP, you'll get an error here. But if it do talk TCP/IP, and is
following the RFC, it will understand that query just fine, and should
do the right thing without any funniness.
If you were "on" MIM and not just passing through the finger request,
you'd just say "finger spc11d::terry". If you said "finger
terry(a)mim.soft-
jar.se" you'd get an error unless you actually had a user named terry.
If, on MIM, you actually want
spc11d::terry@mim.softjar.se to be doing the TCP/IP part first, then
you need to add a switch to make it so. And then it will be the same
as any other TCP/IP finger client, and work the same as described in
that bit above. So still all good.
Not sure I follow. But then again, cross-network routing is a more
complicated issue. Let's get the basic DECnet interoperability done
first.
Any other notations will break either the RFC or the
DECnet finger
spec. Now, as I said before, I'm not going to force anyone to change
their code. But I really do find it broken to have code which tries to
decide if something is TCP/IP or DECnet by guessing and some
heuristics. And since the inherent order of hosts are in the opposite
directions in TCP/IP and DECnet, no heuristics in the world can
actually make this actually work right according to the two specs.
You'll have to break compatibility with one or the other protocol.
Just about all of that is in the client, in what it decides to do
with the user's command line (but which it must convert into the stan-
dard format).
"Your client's broken" reports should only pertain to the client
emitting incorrect standard-format commands (which, in the case of
RSTS/E Finger, is doing the unwanted /IAM business).
"Your server's broken" reports can cover a wider range of subjects.
Ideally, I'd like to see other DECnet servers behave about the same
as the RSTS/E one (aside from any breakage I need to fix, like why
Johnny's Finger client can't request info on a specific username and
always gets the "who is logged in" display). The enhancements I sug-
gested above in #1-4 for servers are a request for things which are
mostly optional in the existing implementations. The only MUST from
the above list is #4, implementing /HELP.
Up to everyone of you how you want to look at that.
But I can tell you
that the RSX implementation will continue to try and follow both
specs. So TCP/IP hostnames will never be assumed for a node that ends
with ::, and DECnet nodenames will never be assumed for something that
starts with @. And this is also true for mail. And that is also how
the mail relaying on MIM is doing things, and how you can send mail
from HECnet to the internet by saying
MIM::user@host
And send mail from the internet to hosts on HECnet by
node::user@Mim.SoftJAR.SE
And please be aware that gmail reception is broken, and they don't
accept mails from HECnet because of that. Nothing I can do about it.
gmail basically do not accept mails with a from address in the form of
"node::user"@mim.softjar.se, although it is correct according to RFC
5321. Google apparently don't care that they are violating the RFC.
If Ned Freed was still alive we could sic him on them, but sadly not.
Google has a zillion screwball requirements for mail, many of which are
undocumented. And they don't do anything with spam reports (I think that
abuse@ goes directly into the bitbucket).
5:17 a.m.
Just a few comments, as I really should try to get some sleep... :-)
On 2026-01-12 04:14, Terri Kennedy wrote:
That's fine. It might be considered unexpected, but this is boiling down
to implementation details that I prefer to leave to each implementation
on how to process it.
I wasn't fully aware of it either, until I noticed the truncation when
fingering a TOPS-20 node, after which Thomas brought up the whole
streaming thing. I've since also come to understand that Ultrix (and
possibly other Unix implementations) might also implement that
"feature". I guess it makes more sense on OSes where files also are more
like a stream of bytes.
But in the end, it's just a question of making sure data isn't lost,
which means avoiding data overrun errors on packets, for OSes where that
is relevant.
If someone can just tell me what the packet size this streaming layer is
using in different OSes, I can just make sure the receive buffer is
large enough to accommodate it.
For sure. But as I point out, you can't actually parse that in any sane
way. Sure, if you decide to break standards, and do some liberal
heuristics and just random guessing, you can make it work. But that
shouldn't really be the way a client is implemented, in my opinion.
Just because a host name is no more than 6 letters does not mean it is a
DECnet node. That can just as well be a perfectly fine TCP/IP host name.
Those empty lines are some effect of the cut-and-paste. Probably because
the lines got all the way to column 80.
I have a suspicion what the problem is...
You are expecting the "FINGER" keyword to come first, before the actual
thing being asked for.
Neither RSX, nor the TOPS-20 version does that. It just gives the actual
user asked for.
Which is also why the "FINGER" user error pops up in your attempts to
talk with RSX.
I'm not logging at the moment, but that can easily be thrown in when needed.
Correct.
There is the ambiguity of the line "spc11d::terry@mim.softjar.se", as
I've mentioned several times. Should it connect to spc11d using DECnet,
and send the line "terry(a)mim.softjar.se"r.se", or should it connect to
mim.softjar.se using TCP/IP, and send it the line "spc11d::terry".
Both are valid alternatives. But it can't do both. So by default it will
do one, and then I have switches if you want to force one or the other
instead of just relying on the defaults.
But yes, finger over DECnet should work first. Then we can get into
these details...
Well, no. It's partially in the client, and partially in the server.
I know. I used to work at Google... But most weird stuff at Google is
not at this level of brokenness. Really, this one takes some sort of
price in my book (I can go into the details in another thread, if
someone really wants to know...).
Johnny
--
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
On 2026-01-11 09:36, Johnny Billquist wrote:
Exactly what switches a client or server implements is something I
happily leave implementation defined. And I agree that unless it makes
sense to process a switch locally, it should be passed along with the
query to the remote node.
First of all we have the TCP/IP finger protocol.
This is defined in RFC 1288.
This protocol talks over TCP, with the server listening on port 79. A
client opens the connection and sends a one line query, terminated by
CR+LF. The query as such is basically in the form user@host2@host1,
where all the parts are optional. However, note that the username is
the leftmost component before the first @, and the host to communicate
to is the rightmost component, after the last @.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed right to left, and the
optional username is the leftmost part. Any host that talks finger
over TCP really should follow this RFC. Anything else is fundamentally
bad, and I hope all would agree with that.
Agreed. I would just add that optional arguments (which the RFChand-
waves as "Query Tokens" and only mentions in passing (but does not de-
scribe the function of) the /W token, so there are other possible arg-
uments, which a given server implementation may or may not implement. Can we agree that one or more optional
"tokens" (/foo) MAY appear in
the query, that implementations SHOULD ignore tokens they do not under-
stand/implement, SHOULD implement a /HELP token, and MUST pass the com-
plete query (after removing their own name), including any tokens, in-
cluding /HELP to the next host (if any). To clarify, if a system that
receives a Finger query is just "passing it along", it should not re-
spond to /HELP itself, but just pass it along as well.
Tokens (switches, options, or whatever you want to call them) makes
sense to pass along if they are not processed locally.
Having something like /HELP always expected to be implemented is fine. I
wouldn't be very upset if it wasn't, but I don't have a strong opinion
about it.
Next we have
finger over DECnet.
There are no formal standard for this. But there have existed
implementations since the 80s. Thomas tried to summarize how it should
work, which is aligned with those old implementations, and is also
what both him and me have tried to follow.
This protocol then talks over DECnet, with the server defined as the
DECnet object 117. A client opens the connection and sends a one line
query. The query as such is basically in the form host1::host2::user,
where all the parts are optional. However, note that the username is
the rightmost component, after the last ::, and the host to
communicate to is the leftmost component, before the first ::.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed left to right, and the
optional username is the rightmost part. Any host that talks finger
over DECnet really should follow this spec. Anything else is pretty
bad, and I hope all would agree with that.
Agreed, subject to my comments on RFC 1288 above.
I'd also add that "An implementation MAY decide to forward the re-
quest to another DECnet node if it does not have an node definition
for the host being queried. Gatewaying is implementation-specific and MAY be
provided. If it is
provided, it SHOULD follow the appropriate rules for left-to-right and
right-to-left parsing as described above.
Yes, and that in turn depends on the server understanding the context
(ie. DECnet or TCP). And so having the same notation for both is a bad idea.
Before I go on
I want to make a small comment on the topic of
streaming connections in DECnet. DECnet is inherently packet based.
Some operating systems provide an abstraction to streams on top of
this, but not all OSes do. And this stream abstraction is not the same
thing as TCP, and it is important to understand this. If your host
pretends you use a stream, it can still arrive as packets on the peer
side. There is no explicit stream type, and the packing/unpacking of
data from a stream into packets are done at a layer above DECnet
itself. This became obvious when me and Thomas were doing some initial
work on interoperability between TOPS-20 and RSX. The problem being
that Thomas was letting TOPS-20 treat the connection as a stream, and
we got into trouble on the RSX side.
TOPS-20 were just putting all the data to send into one packet in the
end. In RSX when receiving, you give a buffer with a size where
received data should be placed. And if the packet contain more data
than fits in the buffer, the remaining data is not kept, but
discarded, and you get a data overrun status in the receive.
So it's not actually a problem with streaming as such, but the size of
packets you might end up with. If TOPS-20 streams would just limit the
actual eventual packet to no more than some certain size, RSX will
play just fine. The fact that TOPS-20 pretend it's a stream is not a
problem. The problem is identical if you use packets, and just use a
packet size that is larger than what the receiver is expecting.
So if there is a way for any streaming abstraction layer to just say
what the maximum size of the packets should be, then by all means, run
with a stream if you want to, and it will work fine (just let me know
what your upper limit is set to, and I can adjust the RSX code
correspondingly).
I'd never heard of streaming until this discussion came around the
first time (2024). I've always written lines as records in my imple-
mentation. Ok. Final
part. Things become "interesting" when you start mixing
TCP/IP and DECnet. Since TCP/IP requests do hosts and users processing
right to left, and DECnet requests do hosts and users processing left
to right, and they also use different separators between hosts and
usernames, how do you get this to mix?
Terri's example:
finger terry@spc11d::
is a complete mess. How should this be parsed. If we go by TCP/IP
standard, anything to the right of the last @ should be the host,
which is "spc11d::". But that's not a host you would find in DNS.
But it's also not useful to process according to DECnet, because then
we say that everything before the first :: is the node, which would be
"terry@spc11d", which is clearly not a DECnet node.
So, please, drop that. That is pretty obviously illegal, no matter
which way you want to look at it.
This is entirely a matter of how the user command line is parsed
by the Finger client. It SHOULD be free to parse things however it
likes. but MUST only send a properly-formed query to a Finger server. Back in the day, we had DECnet, BITNET, and TCP/IP
(and some other
protocols). So you could say "finger user(a)node.decnet" (and use "fin-
ger user@node::" as a shortcut). Likewise for "finger user(a)node.bitnet"
- these were all treated as ".decnet" and ".bitnet" pseudo-TLDs.
This
is also what PMDF (see prior references to Ned Freed) does.
The "fake" .decnet domain is one way to make it (hopefully) clear that
it's a DECnet node we're talking about. But then you still have the
problem of ordering.
If you do "finger bqt@node.decnet@host.net", what address should you
connect to? And is bqt a username or a host?
Unless there were cases where DECnet host FOO::.
BITNET host FOO,
and TCP/IP host foo.example.com differed, you could just say "finger
user@host" and Finger would figure out the appropriate transport by
querying the host tables / DNS in that order - DECnet, BITNET, and
TCP/IP.
Which might be a very bad idea. Because they could differ, but all
exist. Really, if you want DECnet, say HOST::USER. Don't say USER@HOST,
because that's a TCP/IP format request.
This made it easy for users (who often didn't
know what sort of
network connection was used to talk to their buddy Fred on host
foobar). "finger fred@foobar" would just Do The Right Thing.
Except it can do the wrong thing, and you'll be very messed up.
But note that all this optional work MUST be done
entirely on the
user's local finger client, and what gets emitted as a Finger comm-
and line MUST be appropriate for the next hop's Finger server. It
SHOULD reject a message it considers ill-formed with an appropriate
error message.
For sure some part of the argument line needs to be processed by the
local host, but not all of it. Some parts you hand over to the server to
then sort out.
To summarize, in addition to supporting canonical
DNS (user@foo.
example.com) and DECnet (FOO::USER) address forms, a client MAY
support any other syntax, including (perhaps) user- or system-wide
mappings (for example, FOO::ERNIE -> FOO::ERNEST, or even joe@
oldjob.example.com -> Joseph.Lastname(a)otherjob.blah.org). This all
happens in the client, and as a server implementer you don't need
to worry about it at all.
Mapping usernames with aliases and whatnot is entirely legitimate, but
completely outside the scope of the finger protocol.
And no, that does not happen at the client. The client just sends
whatever name the user specified to the remote server, which then can do
whatever makes sense there. The local machine have no clue about what
translations, services or handling any remote machine is doing, and it
should not try to.
All I'm asking for on the server side is:
1) If acting as a smarthost, remove your node from the command
line (if it wasn't already) and pass it alongto the next host.
As pointed out in my other mail, the finger protocol should actually
strip out both the local *and* next hop from the request.
If the user types "finger mim::bqt", the client should connect to MIM
(using DECnet), and just send the string "bqt". Just as per the RFC for
TCP/IP finger.
And the same is true for a server that forwards the request to yet
another machine.
So if a user do "finger mim::jocke::bqt", the client connects to MIM,
and sends the string "jocke::bqt". The server on MIM process that line,
connects to JOCKE, and sends just the line "bqt" to it.
JOCKE in turn gets a username, and provide information about that user,
if he exists. It can translate aliases if it wants to, have spelling
correction, or other heuristics as much as it wants.
But the actual request lines sent at each step is as mentioned.
And if forwarding is not supported/allowed/whatever, give an error.
2) Support whatever restrictions the server wants
as to whether
lists of logged-in users can be provided, whether queries
must match a specific username or can providea list of users,
decide to show .plan (or site equivalent) data, etc.
Right.
3) At the implementations choice, handle unknown
qualifiers via
one of these methods (from most preferred to least preferred):
a) Report "Unknown command qualifier /FOO" for each unknown
qualifier, one per line, but return the requested informa-
tion (see the example below).
b) As a) above, except exit without returningany user infor-
mation after reporting errors as in a) above.
c) Silently ignore unknown qualifiers and return output for
the requested information.
All would be acceptable.
4) Implement the qualifier /HELP which will provide
(at a mini-
mum) the list of supported qualifiers.
Would be nice.
The user's Finger client is stripping off the
first host (DECnet or
DNS, let's forget about BITNET) and so your:
finger spc11d::terry@mim.softjar.se
gets turned into "open a connection to the finger server on mim.soft-
jar.se and send it the query 'spc11d::terry'". Whether or not it de-
cides to forward that request is an implementation and/or site-specif-
ic determination. As an example, while debugging this with the folks
at FNAL, it was important that their public-facing servers not allow
unrestricted DECnet Fingering of the various internal hosts, some of
which held classified data.
Agreed. With the added point that it's not given which takes precedence
when you have both DECnet and TCP/IP hosts on the line. Should it
connect to SPC11D and pass the line "terry(a)mim.softjar.se" or should it
connect to mim.softjar.se and pass the line "spc11d::terry"? Both are
equally valid. In my RSX code, I've decided to by default give
precedence to DECnet, and have a switch if you want the TCP/IP part to
take precedence.
And guess
what, here is how it looks on my MAC, right now:
Gromit:/Users/bqt> finger spc11d::terry@mim.softjar.se
[mim.softjar.se]
[SPC11D::]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 09:29, 8 Jobs, 63
Max.
Uptime 7 08:54:20, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:06 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:14 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
Gromit:/Users/bqt>
Are you actually seeing blank lines in the output, or is this
just the way this message was formatted? The implementation stuff as I've described it
above is how RSTS/E
Finger currently operates (modulo a few bugs, which I'll fix) and
we can have a DECnet "bake-off" at some point in the future, once
we've settled on a spec.
The point I tried (and failed miserably) to make in earlier emails
is that whatever form of address the user gives the finger client on
their system is immaterial (beyond being something that generally
makes sense to users on that system) but what actually gets send as
a command line to a remote Finger server has to match the canonical
format, as described in the DECnet/E finger draft and (hopefully) as
amended by me above.
The form is not immaterial. That's my point. Because if you give a
DECnet address, the host is the leftmost component, and if it's TCP/IP,
it's the rightmost component. Which starts to be an important difference
if there is more than one hop required, as well as when we mix DECnet
and TCP/IP.
So I can
actually finger a RSTS/E host from a MAC. How fun isn't that?
(Don't ask me why I'm not getting information about Terry, though,
because I get the exact same result if I just do a "finger
spc11d::terry" on Mim directly.
I'm going to need to implement logging (as defined in the draft
spec). "finger spc11d::terry" works here from
spcpi2:
Like I said - I suspect you're expecting the actual command line, and
not just the user to look up.
If I do ''finger "spc11d::terry terry"`` I do get the information about
user terry. So it seems clear you're looking at the second word in the
argument string, which is different to RSX and TOPS-20 (and the TCP/IP RFC).
Or you have some other additional processing/expectations on the string
that cause some similar effect.
If you do this
on MIM, it will by default first try to process DECnet
nodes, so it will take the first node name, up to the first :: as the
node to connect to, and then pass everything after that to the server,
meaning "terry(a)mim.softjar.se" as the query. Now, if spc11d don't talk
TCP/IP, you'll get an error here. But if it do talk TCP/IP, and is
following the RFC, it will understand that query just fine, and should
do the right thing without any funniness.
If you were "on" MIM and not just passing through the finger request,
you'd just say "finger spc11d::terry". If you said "finger
terry(a)mim.soft-
jar.se" you'd get an error unless you actually had a user named terry. If, on MIM,
you actually want
spc11d::terry@mim.softjar.se to be doing the TCP/IP part first, then
you need to add a switch to make it so. And then it will be the same
as any other TCP/IP finger client, and work the same as described in
that bit above. So still all good.
Not sure I follow. But then again, cross-network routing is a more
complicated issue. Let's get the basic DECnet interoperability done
first. Any other
notations will break either the RFC or the DECnet finger
spec. Now, as I said before, I'm not going to force anyone to change
their code. But I really do find it broken to have code which tries to
decide if something is TCP/IP or DECnet by guessing and some
heuristics. And since the inherent order of hosts are in the opposite
directions in TCP/IP and DECnet, no heuristics in the world can
actually make this actually work right according to the two specs.
You'll have to break compatibility with one or the other protocol.
Just about all of that is in the client, in what it decides to do
with the user's command line (but which it must convert into the stan-
dard format). "Your client's broken" reports should
only pertain to the client
emitting incorrect standard-format commands (which, in the case of
RSTS/E Finger, is doing the unwanted /IAM business).
Agreed. But if it tries to talk DECnet when I say "bqt@mim" that is also
broken, and if it connects to host2, when I say "finger bqt@host2@host1"
that is also broken.
And I can come up with more variants if you want to. But I hope you get
the point.
"Your server's broken" reports can
cover a wider range of subjects.
Ideally, I'd like to see other DECnet servers behave about the same
as the RSTS/E one (aside from any breakage I need to fix, like why
Johnny's Finger client can't request info on a specific username and
always gets the "who is logged in" display). The enhancements I sug-
gested above in #1-4 for servers are a request for things which are
mostly optional in the existing implementations. The only MUST from
the above list is #4, implementing /HELP.
There can definitely be a lot of brokenness also on the server side, and
in various ways. But if we start with just the hostname and user bits,
they should really work the same as for the client, unless the server
just don't relay.
And please be
aware that gmail reception is broken, and they don't
accept mails from HECnet because of that. Nothing I can do about it.
gmail basically do not accept mails with a from address in the form of
"node::user"@mim.softjar.se, although it is correct according to RFC
5321. Google apparently don't care that they are violating the RFC.
If Ned Freed was still alive we could sic him on them, but sadly not.
Google has a zillion screwball requirements for mail, many of which are
undocumented. And they don't do anything with spam reports (I think that
abuse@ goes directly into the bitbucket).
7:56 a.m.
On 2026-01-11 23:17, Johnny Billquist wrote:
Just a few comments, as I really should try to get
some sleep... :-)
I know the feeling...
I changed the RSTS/E finger to no longer send /IAM, which
helped.
But a subsequent change to remove "FINGER " from the command sent to
either a remote host or a local host breaks a great many things, both
in RSTS/E Finger (both fingering local users and remote node:: stuff)
as well as breaking VMS Finger in the same way you say - getting a bunch
of "oops" for qualifiers you didn't specify.
This appears to be a DECnet-only thing, as VMS finger does not pre-
fix the command lines it sends to TCP/IP hosts with "FINGER ".
I'm going to need to do a lot more investigating when I have time
to see what's going on. Removing the "FINGER " prefix also causes a
complete "Star Trek transporter failure" when trying to route through
a VMS smart host:
$ finger mim::billquist
DEBUG1a: command$ = 'FINGER MIM::BILLQUIST'.
DEBUG1b: command$ = 'MIM::BILLQUIST'.
[IM via routing host SPCVAX]
[SPCVAX.DECnet]
DEBUG2: command$ = 'MBILLQUIST@IM'.
[IM: rerouting link via SPCRTR]
[SPCRTR
2BSD finger doesn't send "finger " either, but when I say "finger
terry@server", a tcpdump on server shows that the expected command
line end isn't there (got a hex C9 instead):
01:29:18.31 spc11e.glaver.org.1028 > server.glaver.org.finger: P 1:6(5)
ack 1 win 4096
4500 002d b258 0000 4006 e834 cc8d 23e4
E..-.X..@..4..#.
cc8d 233f 0404 004f 0206 3502 cbef b2dd
..#?...O..5.....
5018 1000 a588 0000 7465 7272 79c9 P.......terry.
FreeBSD doesn't send "finger " either, but does correctly terminate
the command line with CR/LF:
01:34:19.18 gate.glaver.org.16809 > server.glaver.org.finger: P 1:8(7)
ack 1 win 1040 <,,timestamp 1548025856:-2016870400> (DF)
4500 003b 2613 4000 4006 3513 cc8d 233d
E..;&.@.@.5...#=
cc8d 233f 41a9 004f 2459 8ae5 eefc 8182
..#?A..O$Y......
8018 0410 cc3b 0000 0101 080a 5c45 87c9
.....;......\E..
00bc 1665 7465 7272 790d 0a ...eterry..
So the "must prefix with 'FINGER '" business seems to be a DECnet-
only thing. The RSTS/E version must have inherited it from DECUS
Finger, which looks like it was doing it long before I took over
the maintainership of the DECUS VMS Finger project. The reason why
is probably lost to history.
Much more investigation is needed, as I assume nobody else wants to
modify their DECnet Finger implementation to make my life easier. 8-}
How many more Finger implementations that handle DECnet are out there?
I know of my VMS Finger and RSTS/E Finger, Johnny's RSX Finger and the
TOPS-20 one (ones?) Any others? I'm curious where the "send 'FINGER
'"
in the command came from. I wonder if it has something to do with VMS
and its oddball ideas about generic DECnet objects.
Anyway, so long and thanks for all the fish - I'll report back once
I have at least a conforming RSTS/E implementation. VMS may take longer.
10:29 a.m.
A couple of quick ones again then. :-)
On 2026-01-12 07:56, Terri Kennedy wrote:
On 2026-01-11 23:17, Johnny Billquist wrote:
Well. That should just create some message about something not
understood. I might not be parsing things good enough on the RSX side,
which I might need to improve. But anyway...
Just a few comments, as I really should try to
get some sleep... :-)
I know the feeling...
I changed the RSTS/E finger to no longer send /IAM, which
helped. But a subsequent change to remove "FINGER
" from the command sent to
either a remote host or a local host breaks a great many things, both
in RSTS/E Finger (both fingering local users and remote node:: stuff)
as well as breaking VMS Finger in the same way you say - getting a bunch
of "oops" for qualifiers you didn't specify.
This appears to be a DECnet-only thing, as VMS finger does not pre-
fix the command lines it sends to TCP/IP hosts with "FINGER ".
Ok. So confirmed an unfortunate difference in the request format here.
2BSD finger doesn't send "finger "
either, but when I say "finger
terry@server", a tcpdump on server shows that the expected command
line end isn't there (got a hex C9 instead):
No. 2.11BSD is in fact sending the same thing as any other finger client
you've seen. The c9 is not even sent. Just something you "think" is there.
01:29:18.31 spc11e.glaver.org.1028 >
server.glaver.org.finger: P 1:6(5)
ack 1 win 4096
4500 002d b258 0000 4006 e834 cc8d 23e4 E..-.X..@..4..#.
cc8d 233f 0404 004f 0206 3502 cbef b2dd ..#?...O..5.....
5018 1000 a588 0000 7465 7272 79c9 P.......terry.
Note that the length of the data is actually 5 bytes. Ie. "terry". The
c9 after is just some cruft hanging around because of the minimum length
of a packet on ethernet, but is not actually a part of the actual tcp
data sent.
And if you check more, you'll see that 2.11BSD then sends another
packet, which contains just the CR+LF. Which completes the request line.
FreeBSD doesn't send "finger " either,
but does correctly terminate
the command line with CR/LF:
All TCP/IP finger clients/servers are doing this right. You just have to
remember that TCP does really do a stream of bytes. Where things might
be chopped up between underlying IP packets don't matter.
So the "must prefix with 'FINGER
'" business seems to be a DECnet-
only thing. The RSTS/E version must have inherited it from DECUS
Finger, which looks like it was doing it long before I took over
the maintainership of the DECUS VMS Finger project. The reason why
is probably lost to history.
Seems that DECnet fingers of old did that, yeah.
I just checked the old finger client/server from DECUS for RSX, and it
also did that. I hadn't checked that detail before.
Much more investigation is needed, as I assume
nobody else wants to
modify their DECnet Finger implementation to make my life easier. 8-}
It would be an option, but I would prefer to have a consistent format
and semantics across different protocols, and not start adding/removing
that extra string and possibly also consider other differences in
behavior based on transport.
How many more Finger implementations that handle
DECnet are outthere?
I know of my VMS Finger and RSTS/E Finger, Johnny's RSX Finger and the
TOPS-20 one (ones?) Any others? I'm curious where the "send 'FINGER
'"
in the command came from. I wonder if it has something to do with VMS
and its oddball ideas about generic DECnet objects.
Like I said - there is a DECUS implementation in FORTRAN for RSX. Seems
to be doing things the same way you are, from a cursory glance.
But in most ways that implementation is much less capable than the one
I've written.
Anyway, so long and thanks for all the fish -
I'll report back once
I have at least a conforming RSTS/E implementation. VMS may take longer.
Have fun. :-)
Johnny
--
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
14 Jan
14 Jan
2:36 p.m.
Regarding finger for VMS, I have no real recollection of how we used to gather idle time
for the 'job' (collection of process and subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed number of lines
connected to the Gandalf (a terminal server/switch) so we had to do something
to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10 minutes and
remember their completed I/O counts. If the count hadn't changed since the last
sweep, then the user was logged out. There may have been other considerations involving
CPU time, etc. but as I said the details are permanently paged out of my
memory. I don't think the above would be any good really for finger idle time.
I have the beginnings of a DECnet finger server for VMS in Pascal, which will produce
summary information for who's logged, when, what they're doing and where
they're doing it
from and also specific information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor man's
routing"
and I'm tempted to restrict the breadth of partial searches to a complete username
and/or complete word components of a user's real name.
It'll fit into the framework I have for a DECnet server that declares itself as an
object and remains running, handling multiple requests... but who wants a finger server
hanging around?!
I don't, so the initial version will be instantiated on incoming request.
It'll be on DUNE's default DECnet account if/when I finish it.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 12 January 2026 09:29
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
A couple of quick ones again then. :-)
On 2026-01-12 07:56, Terri Kennedy wrote:
On 2026-01-11 23:17, Johnny Billquist wrote:
Well. That should just create some message about something not understood. I might not be
parsing things good enough on the RSX side, which I might need to improve. But anyway...
Just a few comments, as I really should try to
get some sleep... :-)
I know the feeling...
I changed the RSTS/E finger to no longer send /IAM, which helped.
But a subsequent change to remove "FINGER
" from the command sent
to either a remote host or a local host breaks a great many things,
both in RSTS/E Finger (both fingering local users and remote node::
stuff) as well as breaking VMS Finger in the same way you say -
getting a bunch of "oops" for qualifiers you didn't specify.
This appears to be a DECnet-only thing, as VMS finger does not pre-
fix the command lines it sends to TCP/IP hosts with "FINGER ".
Ok. So confirmed an unfortunate difference in the request format here.
2BSD finger doesn't send "finger "
either, but when I say "finger
terry@server", a tcpdump on server shows that the expected command
line end isn't there (got a hex C9 instead):
No. 2.11BSD is in fact sending the same thing as any other finger client you've seen.
The c9 is not even sent. Just something you "think" is there.
01:29:18.31 spc11e.glaver.org.1028 >
server.glaver.org.finger: P
1:6(5) ack 1 win 4096
4500 002d b258 0000 4006 e834 cc8d 23e4 E..-.X..@..4..#.
cc8d 233f 0404 004f 0206 3502 cbef b2dd ..#?...O..5.....
5018 1000 a588 0000 7465 7272 79c9 P.......terry.
Note that the length of the data is actually 5 bytes. Ie. "terry". The
c9 after is just some cruft hanging around because of the minimum length of a packet on
ethernet, but is not actually a part of the actual tcp data sent.
And if you check more, you'll see that 2.11BSD then sends another packet, which
contains just the CR+LF. Which completes the request line.
FreeBSD doesn't send "finger " either,
but does correctly terminate
the command line with CR/LF:
All TCP/IP finger clients/servers are doing this right. You just have to remember that TCP
does really do a stream of bytes. Where things might be chopped up between underlying IP
packets don't matter.
So the "must prefix with 'FINGER
'" business seems to be a DECnet-
only thing. The RSTS/E version must have inherited it from DECUS
Finger, which looks like it was doing it long before I took over the
maintainership of the DECUS VMS Finger project. The reason why is
probably lost to history.
Seems that DECnet fingers of old did that, yeah.
I just checked the old finger client/server from DECUS for RSX, and it also did that. I
hadn't checked that detail before.
Much more investigation is needed, as I assume
nobody else wants to
modify their DECnet Finger implementation to make my life easier. 8-}
It would be an option, but I would prefer to have a consistent format and semantics across
different protocols, and not start adding/removing that extra string and possibly also
consider other differences in behavior based on transport.
How many more Finger implementations that handle
DECnet are outthere?
I know of my VMS Finger and RSTS/E Finger, Johnny's RSX Finger and
the
TOPS-20 one (ones?) Any others? I'm curious where the "send 'FINGER
'"
in the command came from. I wonder if it has something to do with VMS
and its oddball ideas about generic DECnet objects.
Like I said - there is a DECUS implementation in FORTRAN for RSX. Seems to be doing things
the same way you are, from a cursory glance.
But in most ways that implementation is much less capable than the one I've written.
Anyway, so long and thanks for all the fish -
I'll report back once
I have at least a conforming RSTS/E implementation. VMS may take longer.
Have fun. :-)
Johnny
--
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
2:41 p.m.
On 14/01/2026 14.36, Keith Halewood wrote:
Regarding finger for VMS, I have no real recollection
of how we used to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed number of lines
connected to the Gandalf (a terminal server/switch) so we had to do something
to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10 minutes and
remember their completed I/O counts. If the count hadn't changed since the last
sweep, then the user was logged out. There may have been other considerations involving
CPU time, etc. but as I said the details are permanently paged out of my
memory. I don't think the above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what can be
easily extracted. Just present users with whatever information makes
sense. THe finger protocol is meant for human consumption, so there are
no hard requirements on what information is provided, or in which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I can
tell you that much. But I can only report what RSX thinks here. (If you
were to hit enter on a terminal in RSX, you are still considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server for
VMS in Pascal, which will produce summary information for who's logged, when, what
they're doing and where they're doing it
from and also specific information for matched users if supplied as a parameter,
including plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a complete username
and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR or
not - up to each implementation. Just give some sort of error if you
don't allow it. Same with user matching.
It'll fit into the framework I have for a DECnet
server that declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
5:58 p.m.
There's a simplistic version currently running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O happens as though each end
is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has received what it
expects to receive. This expectation should be part of
the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished sending all that
it wants to send. There's no explicit high level protocol
stating end of data received by the client other than a receive succeeding with zero
length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet finger server will
$ASSIGN to the incoming connection, do a few $QIOWs and
do a $DASSGN, which is quite destructive, including cancelling all pending I/O requests.
You would think that a $QIOW would return when the I/O
completes end to end but it seems to complete when DECnet takes over. Consequently, on
slow links, a $DASSGN could cause DECnet not
to transmit data that's still pending. This is currently happening on a comparatively
slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking is exposed, offers a
synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have to react as though it
had received an EOF. In other words, it seems that both
ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide much of the complexity
unless you go for full non-transparency. Even then you
can treat the connection as record-orientated even though it's not like that
underneath, and listen for events on the attached mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of $QIOW(write), then a
wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks implemented by
command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
Regarding finger for VMS, I have no real recollection
of how we used to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed
number of lines connected to the Gandalf (a terminal server/switch) so we had to do
something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10
minutes and remember their completed I/O counts. If the count hadn't
changed since the last sweep, then the user was logged out. There may have been other
considerations involving CPU time, etc. but as I said the details are permanently paged
out of my memory. I don't think the above would be any good really for finger idle
time.
I think this is one of those topics which I would just leave as implementation specific.
It depends on what the OS does, and what can be easily extracted. Just present users with
whatever information makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I can tell you
that much. But I can only report what RSX thinks here. (If you were to hit enter on a
terminal in RSX, you are still considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server for
VMS in Pascal,
which will produce summary information for who's logged, when, what they're doing
and where they're doing it from and also specific information for matched users if
supplied as a parameter, including plan and the read/unread status of their mailbox. I
won't do "poor man's routing"
and I'm tempted to restrict the breadth of partial searches to a complete username
and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR or not - up to
each implementation. Just give some sort of error if you don't allow it. Same with
user matching.
It'll fit into the framework I have for a DECnet
server that declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming request.
That's how I do it in RSX, and that's how Unixes does it as well. I think it would
be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
6 p.m.
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line. Reads
until it gets an end-of-file/connection-closed indication when readind,
at which point the server is already gone, and the client can finish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
There's a simplistic version currently running on
DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O happens as though each end
is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has received what it
expects to receive. This expectation should be part of
the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished sending all that
it wants to send. There's no explicit high level protocol
stating end of data received by the client other than a receive succeeding with zero
length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet finger server will
$ASSIGN to the incoming connection, do a few $QIOWs and
do a $DASSGN, which is quite destructive, including cancelling all pending I/O requests.
You would think that a $QIOW would return when the I/O
completes end to end but it seems to complete when DECnet takes over. Consequently, on
slow links, a $DASSGN could cause DECnet not
to transmit data that's still pending. This is currently happening on a comparatively
slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking is exposed, offers a
synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have to react as though it
had received an EOF. In other words, it seems that both
ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide much of the complexity
unless you go for full non-transparency. Even then you
can treat the connection as record-orientated even though it's not like that
underneath, and listen for events on the attached mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of $QIOW(write), then a
wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks implemented by
command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
Regarding finger for VMS, I have no real
recollection of how we used to gather idle time for the 'job' (collection of
process and subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed
number of lines connected to the Gandalf (a terminal server/switch) so we had to do
something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10
minutes and remember their completed I/O counts. If the count hadn't
changed since the last sweep, then the user was logged out. There may have been other
considerations involving CPU time, etc. but as I said the details are permanently paged
out of my memory. I don't think the above would be any good really for finger idle
time.
I think this is one of those topics which I would just leave as implementation specific.
It depends on what the OS does, and what can be easily extracted. Just present users with
whatever information makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I can tell you
that much. But I can only report what RSX thinks here. (If you were to hit enter on a
terminal in RSX, you are still considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what they're doing
and where they're doing it from and also specific information for matched users if
supplied as a parameter, including plan and the read/unread status of their mailbox. I
won't do "poor man's routing"
and I'm tempted to restrict the breadth of partial searches to a complete username
and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR or not - up to
each implementation. Just give some sort of error if you don't allow it. Same with
user matching.
It'll fit into the framework I have for a
DECnet server that declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming request.
That's how I do it in RSX, and that's how Unixes does it as well. I think it
would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
6:08 p.m.
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations. I
wouldn't know.
With TCP/IP, when data is sent, it's going to be in the queue and be
delivered even if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data
that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide
that fact. And when you send something, you'll get an indication when
the send is completed, at which point it shouldn't be possible for it
not to be delivered, unless connection have completely been lost. With
RSX not even that is possible, since a completion of a send means that
the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect it
also have a way of telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single request
line, and then sends data until it is done, after which it closes the
connection. There must be a way to know that the data is actually being
delivered, so you don't cancel outstanding sends if they are done
asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line. Reads
until it gets an end-of-file/connection-closed indication when readind,
at which point the server is already gone, and the client can finish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O happens
as though each end is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has
received what it expects to receive. This expectation should be part of
the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol
stating end of data received by the client other than a receive
succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few $QIOWs
and
do a $DASSGN, which is quite destructive, including cancelling all
pending I/O requests. You would think that a $QIOW would return when
the I/O
completes end to end but it seems to complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not
to transmit data that's still pending. This is currently happening on
a comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have to
react as though it had received an EOF. In other words, it seems that
both
ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you
can treat the connection as record-orientated even though it's not
like that underneath, and listen for events on the attached mailbox
device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Regarding finger for VMS, I have no real
recollection of how we used
to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed
number of lines connected to the Gandalf (a terminal server/switch)
so we had to do something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10
minutes and remember their completed I/O counts. If the count hadn't
changed since the last sweep, then the user was logged out. There may
have been other considerations involving CPU time, etc. but as I said
the details are permanently paged out of my memory. I don't think the
above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what can
be easily extracted. Just present users with whatever information
makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in
which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I can
tell you that much. But I can only report what RSX thinks here. (If
you were to hit enter on a terminal in RSX, you are still considered
idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it from and also specific
information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
It'll fit into the framework I have for a
DECnet server that declares
itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming
request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
6:28 p.m.
I've put an explicit '(end)' line on the output from DUNE's finger
server.
From GUARD, a call to DUNE's finger does not show the last user's record or
'(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's finger server.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations. I wouldn't
know.
With TCP/IP, when data is sent, it's going to be in the queue and be delivered even if
the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide that fact. And when
you send something, you'll get an indication when the send is completed, at which
point it shouldn't be possible for it not to be delivered, unless connection have
completely been lost. With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect it also have a way of
telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single request line, and then
sends data until it is done, after which it closes the connection. There must be a way to
know that the data is actually being delivered, so you don't cancel outstanding sends
if they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line. Reads
until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client can finish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O
happens as though each end is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has
received what it expects to receive. This expectation should be part
of the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol stating end of data received by the client other than a
receive succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few
$QIOWs and do a $DASSGN, which is quite destructive, including
cancelling all pending I/O requests. You would think that a $QIOW
would return when the I/O completes end to end but it seems to
complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not to
transmit data that's still pending. This is currently happening on a
comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with a
$QIOW. The server would send this and the client would then have to
react as though it had received an EOF. In other words, it seems that
both ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you can treat the connection as record-orientated even though
it's not like that underneath, and listen for events on the attached
mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
Regarding finger for VMS, I have no real
recollection of how we used
to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small
fixed number of lines connected to the Gandalf (a terminal
server/switch) so we had to do something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every
10 minutes and remember their completed I/O counts. If the count
hadn't changed since the last sweep, then the user was logged out.
There may have been other considerations involving CPU time, etc.
but as I said the details are permanently paged out of my memory. I
don't think the above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what can
be easily extracted. Just present users with whatever information
makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in
which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I
can tell you that much. But I can only report what RSX thinks here.
(If you were to hit enter on a terminal in RSX, you are still
considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it from and also specific
information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
It'll fit into the framework I have for a
DECnet server that
declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming
request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
6:48 p.m.
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
I've put an explicit '(end)' line on the
output from DUNE's finger server.
From GUARD, a call to DUNE's finger does not show the last user's record or
'(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's finger server.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations. I wouldn't
know.
With TCP/IP, when data is sent, it's going to be in the queue and be delivered even
if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide that fact. And when
you send something, you'll get an indication when the send is completed, at which
point it shouldn't be possible for it not to be delivered, unless connection have
completely been lost. With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect it also have a way of
telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single requestline, and then
sends data until it is done, after which it closes the connection. There must be a way to
know that the data is actually being delivered, so you don't cancel outstanding sends
if they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line. Reads
until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client canfinish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
_______________________________________________
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 There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O
happens as though each end is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has
received what it expects to receive. This expectation should be part
of the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol stating end of data received by the client other than a
receive succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few
$QIOWs and do a $DASSGN, which is quite destructive, including
cancelling all pending I/O requests. You would think that a $QIOW
would return when the I/O completes end to end but it seems to
complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not to
transmit data that's still pending. This is currently happening on a
comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with a
$QIOW. The server would send this and the client would then have to
react as though it had received an EOF. In other words, it seems that
both ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you can treat the connection as record-orientated even though
it's not like that underneath, and listen for events on the attached
mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se Regarding finger for VMS, I have no real
recollection of how we used
to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small
fixed number of lines connected to the Gandalf (a terminal
server/switch) so we had to do something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every
10 minutes and remember their completed I/O counts. If the count
hadn't changed since the last sweep, then the user was logged out.
There may have been other considerations involving CPU time, etc.
but as I said the details are permanently paged out of my memory. I
don't think the above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what can
be easily extracted. Just present users with whatever information
makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in
which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I
can tell you that much. But I can only report what RSX thinks here.
(If you were to hit enter on a terminal in RSX, you are still
considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it from and also specific
information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
It'll fit into the framework I have for a
DECnet server that
declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming
request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
8:05 p.m.
I've put a 4 second delay between the last $QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
I've put an explicit '(end)' line on the
output from DUNE's finger server.
From GUARD, a call to DUNE's finger does not show the last user's record or
'(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's finger server.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations. I wouldn't
know.
With TCP/IP, when data is sent, it's going to be in the queue and be delivered even
if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide that fact. And when
you send something, you'll get an indication when the send is completed, at which
point it shouldn't be possible for it not to be delivered, unless connection have
completely been lost. With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect it also have a way of
telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single requestline, and then
sends data until it is done, after which it closes the connection. There must be a way to
know that the data is actually being delivered, so you don't cancel outstanding sends
if they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line.
Reads until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client canfinish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
_______________________________________________
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
There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O
happens as though each end is local, DECnet seems to suggest that
the receiver (finger client in this case) should disconnect when it
has received what it expects to receive. This expectation should be
part of the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol stating end of data received by the client other than a
receive succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few
$QIOWs and do a $DASSGN, which is quite destructive, including
cancelling all pending I/O requests. You would think that a $QIOW
would return when the I/O completes end to end but it seems to
complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not to
transmit data that's still pending. This is currently happening on a
comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have
to react as though it had received an EOF. In other words, it seems
that both ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you can treat the connection as record-orientated even though
it's not like that underneath, and listen for events on the attached
mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
Regarding finger for VMS, I have no real
recollection of how we
used to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small
fixed number of lines connected to the Gandalf (a terminal
server/switch) so we had to do something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every
10 minutes and remember their completed I/O counts. If the count
hadn't changed since the last sweep, then the user was logged out.
There may have been other considerations involving CPU time, etc.
but as I said the details are permanently paged out of my memory. I
don't think the above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what
can be easily extracted. Just present users with whatever
information makes sense. THe finger protocol is meant for human
consumption, so there are no hard requirements on what information
is provided, or in which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I
can tell you that much. But I can only report what RSX thinks here.
(If you were to hit enter on a terminal in RSX, you are still
considered idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it from and also specific
information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
It'll fit into the framework I have for a
DECnet server that
declares itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming
request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
10:25 p.m.
There must be a way to wait for the I/O to complete before you
deassign/disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
I've put a 4 second delay between the last $QIOW
and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
--
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
I've put an explicit '(end)' line on
the output from DUNE's finger server.
From GUARD, a call to DUNE's finger does not show the last user's record or
'(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's fingerserver.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations.I wouldn't
know.
With TCP/IP, when data is sent, it's going to be in the queue and be delivered even
if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide that fact. And when
you send something, you'll get an indication when the send is completed, at which
point it shouldn't be possible for it not to be delivered, unless connection have
completely been lost. With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect italso have a way of
telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single requestline, and then
sends data until it is done, after which it closes the connection. There must be a way to
know that the data is actually being delivered, so you don't cancel outstanding sends
if they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
_______________________________________________
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 Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line.
Reads until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client canfinish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
_______________________________________________
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 There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O
happens as though each end is local, DECnet seems to suggest that
the receiver (finger client in this case) should disconnect when it
has received what it expects to receive. This expectation should be
part of the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol stating end of data received by the client other than a
receive succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few
$QIOWs and do a $DASSGN, which is quite destructive, including
cancelling all pending I/O requests. You would think that a $QIOW
would return when the I/O completes end to end but it seems to
complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not to
transmit data that's still pending. This is currently happening on a
comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have
to react as though it had received an EOF. In other words, it seems
that both ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you can treat the connection as record-orientated even though
it's not like that underneath, and listen for events on the attached
mailbox device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
> Regarding finger for VMS, I have no real recollection of how we
> used to gather idle time for the 'job' (collection of process and
> subprocesses attached to the terminal).
> Back in the university days, some of the VMS systems had a small
> fixed number of lines connected to the Gandalf (a terminal
> server/switch) so we had to do something to prevent users hogging the lines.
> I think we used to enumerate allocated terminal class devices every
> 10 minutes and remember their completed I/O counts. If the count
> hadn't changed since the last sweep, then the user was logged out.
> There may have been other considerations involving CPU time, etc.
> but as I said the details are permanently paged out of my memory. I
> don't think the above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what
can be easily extracted. Just present users with whatever
information makes sense. THe finger protocol is meant for human
consumption, so there are no hard requirements on what information
is provided, or in which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I
can tell you that much. But I can only report what RSX thinks here.
(If you were to hit enter on a terminal in RSX, you are still
considered idle.
No activity happened.)
> I have the beginnings of a DECnet finger server for VMS in Pascal,
> which will produce summary information for who's logged, when, what
> they're doing and where they're doing it from and also specific
> information for matched users if supplied as a parameter, including
> plan and the read/unread status of their mailbox. I won't do "poor
> man's routing"
> and I'm tempted to restrict the breadth of partial searches to a
> complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
> It'll fit into the framework I have for a DECnet server that
> declares itself as an object and remains running, handling multiple
> requests... but who wants a finger server hanging around?!
> I don't, so the initial version will be instantiated on incoming
> request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
> It'll be on DUNE's default DECnet account if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
10:27 p.m.
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31 06:59:20No
users logged in.(end)
.
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to complete
before you deassign/
disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
--
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
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
I've put an explicit '(end)' line on
the output from DUNE's finger
server.
From GUARD, a call to DUNE's finger does not show the last user's
record or '(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's
fingerserver.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE
from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your
observations.I wouldn't know.
With TCP/IP, when data is sent, it's going to be in the queue and be
delivered even if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data
that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide
that fact. And when you send something, you'll get an indication when
the send is completed, at which point it shouldn't be possible for it
not to be delivered, unless connection have completely been lost.
With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's
very synchronous.
If some higher level library hides all of this, then I would expect
italso have a way of telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single
requestline, and then sends data until it is done, after which it
closes the connection. There must be a way to know that the data is
actually being delivered, so you don't cancel outstanding sends if
they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
_______________________________________________
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 Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line.
Reads until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client
canfinish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
> There's a simplistic version currently running on DUNE::
> I've noticed a few problems with it.
>
> For transparent DECnet I/O where channels are assigned and I/O
> happens as though each end is local, DECnet seems to suggest that
> the receiver (finger client in this case) should disconnect when it
> has received what it expects to receive. This expectation should be
> part of the client/server protocol such as an explicit end of data
> record.
> In the TCP/IP world, a finger server disconnects when it's finished
> sending all that it wants to send. There's no explicit high level
> protocol stating end of data received by the client other than a
> receive succeeding with zero length response.
>
> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
> finger server will $ASSIGN to the incoming connection, do a few
> $QIOWs and do a $DASSGN, which is quite destructive, including
> cancelling all pending I/O requests. You would think that a $QIOW
> would return when the I/O completes end to end but it seems to
> complete when DECnet takes over.
> Consequently, on slow links, a $DASSGN could cause DECnet not to
> transmit data that's still pending. This is currently happening on a
> comparatively slow link between DUNE and and a host in Australia.
>
> The non-transparent case, where a lot more of the DECnet handshaking
> is exposed, offers a synchronous disconnect which is initiated with
> a $QIOW. The server would send this and the client would then have
> to react as though it had received an EOF. In other words, it seems
> that both ends need to be non-transparent.
>
> A lot of this may be peculiar to DECnet on VMS which tries to hide
> much of the complexity unless you go for full non-transparency. Even
> then you can treat the connection as record-orientated even though
> it's not like that underneath, and listen for events on the attached
> mailbox device.
>
> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
> $QIOW(write), then a wait for an unknown amount of time before
> $DASSGN.
> Judging by some of the behaviour I've seen with user DECnet tasks
> implemented by command procedures, that appears to be what VMS does
> sometimes.
>
> Is this what networking used to be like? Weird?
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 13:42
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
> and Tops-20 Finger Setup Documentation (New)
>
> On 14/01/2026 14.36, Keith Halewood wrote:
>> Regarding finger for VMS, I have no real recollection of how we
>> used to gather idle time for the 'job' (collection of process and
>> subprocesses attached to the terminal).
>> Back in the university days, some of the VMS systems had a small
>> fixed number of lines connected to the Gandalf (a terminal
>> server/switch) so we had to do something to prevent users hogging
>> the lines.
>> I think we used to enumerate allocated terminal class devices every
>> 10 minutes and remember their completed I/O counts. If the count
>> hadn't changed since the last sweep, then the user was logged out.
>> There may have been other considerations involving CPU time, etc.
>> but as I said the details are permanently paged out of my memory. I
>> don't think the above would be any good really for finger idle time.
>
> I think this is one of those topics which I would just leave as
> implementation specific. It depends on what the OS does, and what
> can be easily extracted. Just present users with whatever
> information makes sense. THe finger protocol is meant for human
> consumption, so there are no hard requirements on what information
> is provided, or in which form.
>
> "Idle" in RSX is defined slightly different than in Unix or VMS. I
> can tell you that much. But I can only report what RSX thinks here.
> (If you were to hit enter on a terminal in RSX, you are still
> considered idle.
> No activity happened.)
>
>> I have the beginnings of a DECnet finger server for VMS in Pascal,
>> which will produce summary information for who's logged, when, what
>> they're doing and where they're doing it from and also specific
>> information for matched users if supplied as a parameter, including
>> plan and the read/unread status of their mailbox. I won't do "poor
>> man's routing"
>> and I'm tempted to restrict the breadth of partial searches to a
>> complete username and/or complete word components of a user's real
>> name.
>
> This is also something I'd happily leave to each implementation. PMR
> or not - up to each implementation. Just give some sort of error if
> you don't allow it. Same with user matching.
>
>> It'll fit into the framework I have for a DECnet server that
>> declares itself as an object and remains running, handling multiple
>> requests... but who wants a finger server hanging around?!
>> I don't, so the initial version will be instantiated on incoming
>> request.
>
> That's how I do it in RSX, and that's how Unixes does it as well. I
> think it would be the most sensible way to do it.
>
>> It'll be on DUNE's default DECnet account if/when I finish it.
>
> Would be nice to see it in operation.
>
> Johnny
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
15 Jan
15 Jan
12:07 a.m.
I think you caught it before I'd reinstalled the .exe privileged.
There's no way I'm creating a privileged object for it.... and I don't think
the DECnet object privilege settings
work like one might expect anyway.
Incidentally, from
https://docs.vmssoftware.com/vsi-openvms-decnet-networking-manual/#SEC_ERRO… (2nd
paragraph)
Also, 2nd to last paragraph in
https://docs.vmssoftware.com/vsi-openvms-decnet-networking-manual/#SEC_EXCH…
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31 06:59:20No users logged
in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to complete
before you deassign/
disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
--
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
I've put an explicit '(end)' line on
the output from DUNE's finger
server.
From GUARD, a call to DUNE's finger does not show the last user's
record or '(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's
fingerserver.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE
from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your
observations.I wouldn't know.
With TCP/IP, when data is sent, it's going to be in the queue and be
delivered even if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data
that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide
that fact. And when you send something, you'll get an indication when
the send is completed, at which point it shouldn't be possible for it
not to be delivered, unless connection have completely been lost.
With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's
very synchronous.
If some higher level library hides all of this, then I would expect
italso have a way of telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single
requestline, and then sends data until it is done, after which it
closes the connection. There must be a way to know that the data is
actually being delivered, so you don't cancel outstanding sends if
they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
_______________________________________________
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
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line.
Reads until it gets an end-of-file/connection-closed indication when
readind, at which point the server is already gone, and the client
canfinish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
> There's a simplistic version currently running on DUNE::
> I've noticed a few problems with it.
>
> For transparent DECnet I/O where channels are assigned and I/O
> happens as though each end is local, DECnet seems to suggest that
> the receiver (finger client in this case) should disconnect when it
> has received what it expects to receive. This expectation should be
> part of the client/server protocol such as an explicit end of data
> record.
> In the TCP/IP world, a finger server disconnects when it's finished
> sending all that it wants to send. There's no explicit high level
> protocol stating end of data received by the client other than a
> receive succeeding with zero length response.
>
> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
> finger server will $ASSIGN to the incoming connection, do a few
> $QIOWs and do a $DASSGN, which is quite destructive, including
> cancelling all pending I/O requests. You would think that a $QIOW
> would return when the I/O completes end to end but it seems to
> complete when DECnet takes over.
> Consequently, on slow links, a $DASSGN could cause DECnet not to
> transmit data that's still pending. This is currently happening on a
> comparatively slow link between DUNE and and a host in Australia.
>
> The non-transparent case, where a lot more of the DECnet handshaking
> is exposed, offers a synchronous disconnect which is initiated with
> a $QIOW. The server would send this and the client would then have
> to react as though it had received an EOF. In other words, it seems
> that both ends need to be non-transparent.
>
> A lot of this may be peculiar to DECnet on VMS which tries to hide
> much of the complexity unless you go for full non-transparency. Even
> then you can treat the connection as record-orientated even though
> it's not like that underneath, and listen for events on the attached
> mailbox device.
>
> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
> $QIOW(write), then a wait for an unknown amount of time before
> $DASSGN.
> Judging by some of the behaviour I've seen with user DECnet tasks
> implemented by command procedures, that appears to be what VMS does
> sometimes.
>
> Is this what networking used to be like? Weird?
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 13:42
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
> and Tops-20 Finger Setup Documentation (New)
>
> On 14/01/2026 14.36, Keith Halewood wrote:
>> Regarding finger for VMS, I have no real recollection of how we
>> used to gather idle time for the 'job' (collection of process and
>> subprocesses attached to the terminal).
>> Back in the university days, some of the VMS systems had a small
>> fixed number of lines connected to the Gandalf (a terminal
>> server/switch) so we had to do something to prevent users hogging
>> the lines.
>> I think we used to enumerate allocated terminal class devices every
>> 10 minutes and remember their completed I/O counts. If the count
>> hadn't changed since the last sweep, then the user was logged out.
>> There may have been other considerations involving CPU time, etc.
>> but as I said the details are permanently paged out of my memory. I
>> don't think the above would be any good really for finger idle time.
>
> I think this is one of those topics which I would just leave as
> implementation specific. It depends on what the OS does, and what
> can be easily extracted. Just present users with whatever
> information makes sense. THe finger protocol is meant for human
> consumption, so there are no hard requirements on what information
> is provided, or in which form.
>
> "Idle" in RSX is defined slightly different than in Unix or VMS. I
> can tell you that much. But I can only report what RSX thinks here.
> (If you were to hit enter on a terminal in RSX, you are still
> considered idle.
> No activity happened.)
>
>> I have the beginnings of a DECnet finger server for VMS in Pascal,
>> which will produce summary information for who's logged, when, what
>> they're doing and where they're doing it from and also specific
>> information for matched users if supplied as a parameter, including
>> plan and the read/unread status of their mailbox. I won't do "poor
>> man's routing"
>> and I'm tempted to restrict the breadth of partial searches to a
>> complete username and/or complete word components of a user's real
>> name.
>
> This is also something I'd happily leave to each implementation. PMR
> or not - up to each implementation. Just give some sort of error if
> you don't allow it. Same with user matching.
>
>> It'll fit into the framework I have for a DECnet server that
>> declares itself as an object and remains running, handling multiple
>> requests... but who wants a finger server hanging around?!
>> I don't, so the initial version will be instantiated on incoming
>> request.
>
> That's how I do it in RSX, and that's how Unixes does it as well. I
> think it would be the most sensible way to do it.
>
>> It'll be on DUNE's default DECnet account if/when I finish it.
>
> Would be nice to see it in operation.
>
> Johnny
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
2:42 a.m.
I think you missed that it all came out as a single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked have
privileges, because there is no way for normal programs to pull out some
of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
I think you caught it before I'd reinstalled the
.exe privileged.
There's no way I'm creating a privileged object for it.... and I don't think
the DECnet object privilege settings
work like one might expect anyway.
Incidentally, from
https://docs.vmssoftware.com/vsi-openvms-decnet-networking-manual/#SEC_ERRO… (2nd
paragraph)
Also, 2nd to last paragraph in
https://docs.vmssoftware.com/vsi-openvms-decnet-networking-manual/#SEC_EXCH…
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31 06:59:20Nousers logged
in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
--
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
There must be a way to wait for the I/O to
complete before you deassign/
disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
I've put an explicit '(end)' line on
the output from DUNE's finger
server.
From GUARD, a call to DUNE's finger does not show the last user's
record or '(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's
fingerserver.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE
from DUNE.
Weirdness... I'll come back to this later.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:09
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Maybe I should make a few more comments.
There might definitely be something VMS specific in your
observations.I wouldn't know.
With TCP/IP, when data is sent, it's going to be in the queue and be
delivered even if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data
that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide
that fact. And when you send something, you'll get an indication when
the send is completed, at which point it shouldn't be possible for it
not to be delivered, unless connection have completely been lost.
With RSX not even that is possible, since a completion of a send
means that the receiving side actually completed the receive. It's
very synchronous.
If some higher level library hides all of this, then I would expect
italso have a way of telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single
requestline, and then sends data until it is done, after which it
closes the connection. There must be a way to know that the data is
actually being delivered, so you don't cancel outstanding sends if
they are done asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
> Hum?
> I'm not sure I get it.
>
> The client does a connection to the server. Sends a single line.
> Reads until it gets an end-of-file/connection-closed indication when
> readind, at which point the server is already gone, and the client
> canfinish.
>
> Where are you thinking/seeing that you need to wait for anything?
>
> Johnny
>
> On 14/01/2026 17.58, Keith Halewood wrote:
>> There's a simplistic version currently running on DUNE::
>> I've noticed a few problems with it.
>>
>> For transparent DECnet I/O where channels are assigned and I/O
>> happens as though each end is local, DECnet seems to suggest that
>> the receiver (finger client in this case) should disconnect when it
>> has received what it expects to receive. This expectation should be
>> part of the client/server protocol such as an explicit end of data
>> record.
>> In the TCP/IP world, a finger server disconnects when it's finished
>> sending all that it wants to send. There's no explicit high level
>> protocol stating end of data received by the client other than a
>> receive succeeding with zero length response.
>>
>> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
>> finger server will $ASSIGN to the incoming connection, do a few
>> $QIOWs and do a $DASSGN, which is quite destructive, including
>> cancelling all pending I/O requests. You would think that a $QIOW
>> would return when the I/O completes end to end but it seems to
>> complete when DECnet takes over.
>> Consequently, on slow links, a $DASSGN could cause DECnet not to
>> transmit data that's still pending. This is currently happening ona
>> comparatively slow link between DUNE and and a host in Australia.
>>
>> The non-transparent case, where a lot more of the DECnet handshaking
>> is exposed, offers a synchronous disconnect which is initiated with
>> a $QIOW. The server would send this and the client would then have
>> to react as though it had received an EOF. In other words, it seems
>> that both ends need to be non-transparent.
>>
>> A lot of this may be peculiar to DECnet on VMS which tries to hide
>> much of the complexity unless you go for full non-transparency. Even
>> then you can treat the connection as record-orientated even though
>> it's not like that underneath, and listen for events on the attached
>> mailbox device.
>>
>> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
>> $QIOW(write), then a wait for an unknown amount of time before
>> $DASSGN.
>> Judging by some of the behaviour I've seen with user DECnet tasks
>> implemented by command procedures, that appears to be what VMS does
>> sometimes.
>>
>> Is this what networking used to be like? Weird?
>>
>> K
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 13:42
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
>> and Tops-20 Finger Setup Documentation (New)
>>
>> On 14/01/2026 14.36, Keith Halewood wrote:
>>> Regarding finger for VMS, I have no real recollection of how we
>>> used to gather idle time for the 'job' (collection of process and
>>> subprocesses attached to the terminal).
>>> Back in the university days, some of the VMS systems had a small
>>> fixed number of lines connected to the Gandalf (a terminal
>>> server/switch) so we had to do something to prevent users hogging
>>> the lines.
>>> I think we used to enumerate allocated terminal class devices every
>>> 10 minutes and remember their completed I/O counts. If the count
>>> hadn't changed since the last sweep, then the user was logged out.
>>> There may have been other considerations involving CPU time, etc.
>>> but as I said the details are permanently paged out of my memory.I
>>> don't think the above would be any good really for finger idle time.
>>
>> I think this is one of those topics which I would just leave as
>> implementation specific. It depends on what the OS does, and what
>> can be easily extracted. Just present users with whatever
>> information makes sense. THe finger protocol is meant for human
>> consumption, so there are no hard requirements on what information
>> is provided, or in which form.
>>
>> "Idle" in RSX is defined slightly different than in Unix or VMS. I
>> can tell you that much. But I can only report what RSX thinks here.
>> (If you were to hit enter on a terminal in RSX, you are still
>> considered idle.
>> No activity happened.)
>>
>>> I have the beginnings of a DECnet finger server for VMS in Pascal,
>>> which will produce summary information for who's logged, when, what
>>> they're doing and where they're doing it from and also specific
>>> information for matched users if supplied as a parameter, including
>>> plan and the read/unread status of their mailbox. I won't do "poor
>>> man's routing"
>>> and I'm tempted to restrict the breadth of partial searches to a
>>> complete username and/or complete word components of a user's real
>>> name.
>>
>> This is also something I'd happily leave to each implementation. PMR
>> or not - up to each implementation. Just give some sort of error if
>> you don't allow it. Same with user matching.
>>
>>> It'll fit into the framework I have for a DECnet server that
>>> declares itself as an object and remains running, handling multiple
>>> requests... but who wants a finger server hanging around?!
>>> I don't, so the initial version will be instantiated on incoming
>>> request.
>>
>> That's how I do it in RSX, and that's how Unixes does it as well. I
>> think it would be the most sensible way to do it.
>>
>>> It'll be on DUNE's default DECnet account if/when I finish it.
>>
>> Would be nice to see it in operation.
>>
>> Johnny
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3 a.m.
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the
link quite abruptly. But with the problems you describe, I'm wondering
if you are using $QIO and not $QIOW to send messages?
But honestly, you should really be using the non-transparent
functionality, and do a synchronous disconnect, which will allow all
outstanding I/O to complete before the connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
I think you missed that it all came out as a single
line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked have
privileges, because there is no way for normal programs to pull out some
of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
--
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
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I don't
think the DECnet object privilege settings
work like one might expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to
complete before you deassign/
disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
> I've put an explicit '(end)' line on the output from DUNE's finger
> server.
> From GUARD, a call to DUNE's finger does not show the last user's
> record or '(end)'
>
> Oh, that's interesting and confusing:
>
> GUARD is X86_64 VMS and in Australia.
> BUZZEL is X86_64 and on the same LAN as DUNE.
> Both are not showing the last two records of output from DUNE's
> fingerserver.
> I thought it might have been a VMS version issue but....
> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
> In short, it seems I only get a complete output when I'm calling DUNE
> from DUNE.
>
> Weirdness... I'll come back to this later.
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 17:09
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
> and Tops-20 Finger Setup Documentation (New)
>
> Maybe I should make a few more comments.
> There might definitely be something VMS specific in your
> observations.I wouldn't know.
>
> With TCP/IP, when data is sent, it's going to be in the queue and be
> delivered even if the sending process closes, finishes and goes away.
> The end-of-file is queued into the sending stream after all the data
> that was sent.
>
> With DECnet, the underlying transport is always record oriented.
> Anything that looks like anything else is always just trying to hide
> that fact. And when you send something, you'll get an indication when
> the send is completed, at which point it shouldn't be possible for it
> not to be delivered, unless connection have completely been lost.
> With RSX not even that is possible, since a completion of a send
> means that the receiving side actually completed the receive. It's
> very synchronous.
>
> If some higher level library hides all of this, then I would expect
> italso have a way of telling if all the I/O have completed.
>
> Basically, server side accepts the connection, reads the single
> requestline, and then sends data until it is done, after which it
> closes the connection. There must be a way to know that the data is
> actually being delivered, so you don't cancel outstanding sends if
> they are done asynchronous.
>
> Johnny
>
> On 14/01/2026 18.00, Johnny Billquist wrote:
>> Hum?
>> I'm not sure I get it.
>>
>> The client does a connection to the server. Sends a single line.
>> Reads until it gets an end-of-file/connection-closed indication when
>> readind, at which point the server is already gone, and the client
>> canfinish.
>>
>> Where are you thinking/seeing that you need to wait for anything?
>>
>> Johnny
>>
>> On 14/01/2026 17.58, Keith Halewood wrote:
>>> There's a simplistic version currently running on DUNE::
>>> I've noticed a few problems with it.
>>>
>>> For transparent DECnet I/O where channels are assigned and I/O
>>> happens as though each end is local, DECnet seems to suggest that
>>> the receiver (finger client in this case) should disconnect when it
>>> has received what it expects to receive. This expectation should be
>>> part of the client/server protocol such as an explicit end of data
>>> record.
>>> In the TCP/IP world, a finger server disconnects when it's finished
>>> sending all that it wants to send. There's no explicit high level
>>> protocol stating end of data received by the client other than a
>>> receive succeeding with zero length response.
>>>
>>> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
>>> finger server will $ASSIGN to the incoming connection, do a few
>>> $QIOWs and do a $DASSGN, which is quite destructive, including
>>> cancelling all pending I/O requests. You would think that a $QIOW
>>> would return when the I/O completes end to end but it seems to
>>> complete when DECnet takes over.
>>> Consequently, on slow links, a $DASSGN could cause DECnet not to
>>> transmit data that's still pending. This is currently happening ona
>>> comparatively slow link between DUNE and and a host in Australia.
>>>
>>> The non-transparent case, where a lot more of the DECnet handshaking
>>> is exposed, offers a synchronous disconnect which is initiated with
>>> a $QIOW. The server would send this and the client would then have
>>> to react as though it had received an EOF. In other words, it seems
>>> that both ends need to be non-transparent.
>>>
>>> A lot of this may be peculiar to DECnet on VMS which tries to hide
>>> much of the complexity unless you go for full non-transparency. Even
>>> then you can treat the connection as record-orientated even though
>>> it's not like that underneath, and listen for events on the attached
>>> mailbox device.
>>>
>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
>>> $QIOW(write), then a wait for an unknown amount of time before
>>> $DASSGN.
>>> Judging by some of the behaviour I've seen with user DECnet tasks
>>> implemented by command procedures, that appears to be what VMS does
>>> sometimes.
>>>
>>> Is this what networking used to be like? Weird?
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 13:42
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
>>> and Tops-20 Finger Setup Documentation (New)
>>>
>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>> Regarding finger for VMS, I have no real recollection of how we
>>>> used to gather idle time for the 'job' (collection of process
and
>>>> subprocesses attached to the terminal).
>>>> Back in the university days, some of the VMS systems had a small
>>>> fixed number of lines connected to the Gandalf (a terminal
>>>> server/switch) so we had to do something to prevent users hogging
>>>> the lines.
>>>> I think we used to enumerate allocated terminal class devices every
>>>> 10 minutes and remember their completed I/O counts. If the count
>>>> hadn't changed since the last sweep, then the user was logged out.
>>>> There may have been other considerations involving CPU time, etc.
>>>> but as I said the details are permanently paged out of my memory.I
>>>> don't think the above would be any good really for finger idle
>>>> time.
>>>
>>> I think this is one of those topics which I would just leave as
>>> implementation specific. It depends on what the OS does, and what
>>> can be easily extracted. Just present users with whatever
>>> information makes sense. THe finger protocol is meant for human
>>> consumption, so there are no hard requirements on what information
>>> is provided, or in which form.
>>>
>>> "Idle" in RSX is defined slightly different than in Unix or VMS. I
>>> can tell you that much. But I can only report what RSX thinks here.
>>> (If you were to hit enter on a terminal in RSX, you are still
>>> considered idle.
>>> No activity happened.)
>>>
>>>> I have the beginnings of a DECnet finger server for VMS in Pascal,
>>>> which will produce summary information for who's logged, when, what
>>>> they're doing and where they're doing it from and also specific
>>>> information for matched users if supplied as a parameter, including
>>>> plan and the read/unread status of their mailbox. I won't do
"poor
>>>> man's routing"
>>>> and I'm tempted to restrict the breadth of partial searches to a
>>>> complete username and/or complete word components of a user's real
>>>> name.
>>>
>>> This is also something I'd happily leave to each implementation. PMR
>>> or not - up to each implementation. Just give some sort of error if
>>> you don't allow it. Same with user matching.
>>>
>>>> It'll fit into the framework I have for a DECnet server that
>>>> declares itself as an object and remains running, handling multiple
>>>> requests... but who wants a finger server hanging around?!
>>>> I don't, so the initial version will be instantiated on incoming
>>>> request.
>>>
>>> That's how I do it in RSX, and that's how Unixes does it as well.I
>>> think it would be the most sensible way to do it.
>>>
>>>> It'll be on DUNE's default DECnet account if/when I finish it.
>>>
>>> Would be nice to see it in operation.
>>>
>>> Johnny
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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 sendan
> email to hecnet-leave(a)lists.dfupdate.se
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe sendan
> 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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
1 p.m.
I knew it was brutal, yet that's what the documentation states (other than a
client-initiated closure) as a way of closing the channel.
Anyway, I decided to let RMS handle it all by using Pascal's text file I/O,
essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a series of
writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default optimisation on VAX,
gets further with no optimisation and corrupted output.
I might look at the object code produced (VAX) at some point, when I stop crying :)
I know for a fact that there are some bugs in code generation when you do whole record
layout initialisation, ie. $GETJPI lists, etc..
We used to make fun of people who blamed the compiler for problems with their code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly.
But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW
to send messages?
But honestly, you should really be using the non-transparent functionality, and do a
synchronous disconnect, which will allow all outstanding I/O to complete before the
connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
I think you missed that it all came out as a single
line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked have
privileges, because there is no way for normal programs to pull out
some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
--
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I
don't think the DECnet object privilege settings work like one might
expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to
complete before you
deassign/ disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible
re-post) and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
> I've put an explicit '(end)' line on the output from DUNE's finger
> server.
> From GUARD, a call to DUNE's finger does not show the last
> user's record or '(end)'
>
> Oh, that's interesting and confusing:
>
> GUARD is X86_64 VMS and in Australia.
> BUZZEL is X86_64 and on the same LAN as DUNE.
> Both are not showing the last two records of output from DUNE's
> fingerserver.
> I thought it might have been a VMS version issue but....
> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
> In short, it seems I only get a complete output when I'm calling
> DUNE from DUNE.
>
> Weirdness... I'll come back to this later.
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 17:09
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible
> re-post) and Tops-20 Finger Setup Documentation (New)
>
> Maybe I should make a few more comments.
> There might definitely be something VMS specific in your
> observations.I wouldn't know.
>
> With TCP/IP, when data is sent, it's going to be in the queue and
> be delivered even if the sending process closes, finishes and goes away.
> The end-of-file is queued into the sending stream after all the
> data that was sent.
>
> With DECnet, the underlying transport is always record oriented.
> Anything that looks like anything else is always just trying to
> hide that fact. And when you send something, you'll get an
> indication when the send is completed, at which point it shouldn't
> be possible for it not to be delivered, unless connection have completely been
lost.
> With RSX not even that is possible, since a completion of a send
> means that the receiving side actually completed the receive. It's
> very synchronous.
>
> If some higher level library hides all of this, then I would
> expect italso have a way of telling if all the I/O have completed.
>
> Basically, server side accepts the connection, reads the single
> requestline, and then sends data until it is done, after which it
> closes the connection. There must be a way to know that the data
> is actually being delivered, so you don't cancel outstanding sends
> if they are done asynchronous.
>
> Johnny
>
> On 14/01/2026 18.00, Johnny Billquist wrote:
>> Hum?
>> I'm not sure I get it.
>>
>> The client does a connection to the server. Sends a single line.
>> Reads until it gets an end-of-file/connection-closed indication
>> when readind, at which point the server is already gone, and the
>> client canfinish.
>>
>> Where are you thinking/seeing that you need to wait for anything?
>>
>> Johnny
>>
>> On 14/01/2026 17.58, Keith Halewood wrote:
>>> There's a simplistic version currently running on DUNE::
>>> I've noticed a few problems with it.
>>>
>>> For transparent DECnet I/O where channels are assigned and I/O
>>> happens as though each end is local, DECnet seems to suggest
>>> that the receiver (finger client in this case) should disconnect
>>> when it has received what it expects to receive. This
>>> expectation should be part of the client/server protocol such as
>>> an explicit end of data record.
>>> In the TCP/IP world, a finger server disconnects when it's
>>> finished sending all that it wants to send. There's no explicit
>>> high level protocol stating end of data received by the client
>>> other than a receive succeeding with zero length response.
>>>
>>> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
>>> finger server will $ASSIGN to the incoming connection, do a few
>>> $QIOWs and do a $DASSGN, which is quite destructive, including
>>> cancelling all pending I/O requests. You would think that a
>>> $QIOW would return when the I/O completes end to end but it
>>> seems to complete when DECnet takes over.
>>> Consequently, on slow links, a $DASSGN could cause DECnet not to
>>> transmit data that's still pending. This is currently happening
>>> ona comparatively slow link between DUNE and and a host in Australia.
>>>
>>> The non-transparent case, where a lot more of the DECnet
>>> handshaking is exposed, offers a synchronous disconnect which is
>>> initiated with a $QIOW. The server would send this and the
>>> client would then have to react as though it had received an
>>> EOF. In other words, it seems that both ends need to be non-transparent.
>>>
>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>> hide much of the complexity unless you go for full
>>> non-transparency. Even then you can treat the connection as
>>> record-orientated even though it's not like that underneath, and
>>> listen for events on the attached mailbox device.
>>>
>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
>>> $QIOW(write), then a wait for an unknown amount of time before
>>> $DASSGN.
>>> Judging by some of the behaviour I've seen with user DECnet
>>> tasks implemented by command procedures, that appears to be what
>>> VMS does sometimes.
>>>
>>> Is this what networking used to be like? Weird?
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 13:42
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>
>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>> Regarding finger for VMS, I have no real recollection of how we
>>>> used to gather idle time for the 'job' (collection of process
>>>> and subprocesses attached to the terminal).
>>>> Back in the university days, some of the VMS systems had a
>>>> small fixed number of lines connected to the Gandalf (a
>>>> terminal
>>>> server/switch) so we had to do something to prevent users
>>>> hogging the lines.
>>>> I think we used to enumerate allocated terminal class devices
>>>> every
>>>> 10 minutes and remember their completed I/O counts. If the
>>>> count hadn't changed since the last sweep, then the user was logged
out.
>>>> There may have been other considerations involving CPU time, etc.
>>>> but as I said the details are permanently paged out of my
>>>> memory.I don't think the above would be any good really for
>>>> finger idle time.
>>>
>>> I think this is one of those topics which I would just leave as
>>> implementation specific. It depends on what the OS does, and
>>> what can be easily extracted. Just present users with whatever
>>> information makes sense. THe finger protocol is meant for human
>>> consumption, so there are no hard requirements on what
>>> information is provided, or in which form.
>>>
>>> "Idle" in RSX is defined slightly different than in Unix or VMS.
>>> I can tell you that much. But I can only report what RSX thinks here.
>>> (If you were to hit enter on a terminal in RSX, you are still
>>> considered idle.
>>> No activity happened.)
>>>
>>>> I have the beginnings of a DECnet finger server for VMS in
>>>> Pascal, which will produce summary information for who's
>>>> logged, when, what they're doing and where they're doing it
>>>> from and also specific information for matched users if
>>>> supplied as a parameter, including plan and the read/unread
>>>> status of their mailbox. I won't do "poor man's
routing"
>>>> and I'm tempted to restrict the breadth of partial searches to
>>>> a complete username and/or complete word components of a user's
>>>> real name.
>>>
>>> This is also something I'd happily leave to each implementation.
>>> PMR or not - up to each implementation. Just give some sort of
>>> error if you don't allow it. Same with user matching.
>>>
>>>> It'll fit into the framework I have for a DECnet server that
>>>> declares itself as an object and remains running, handling
>>>> multiple requests... but who wants a finger server hanging around?!
>>>> I don't, so the initial version will be instantiated on
>>>> incoming request.
>>>
>>> That's how I do it in RSX, and that's how Unixes does it as
>>> well.I think it would be the most sensible way to do it.
>>>
>>>> It'll be on DUNE's default DECnet account if/when I finish it.
>>>
>>> Would be nice to see it in operation.
>>>
>>> Johnny
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
> sendan email to hecnet-leave(a)lists.dfupdate.se
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
> sendan 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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
1:09 p.m.
The same finger server is running on BUZZEL at the moment, seemingly no issues.
-----Original Message-----
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 15 January 2026 12:01
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
I knew it was brutal, yet that's what the documentation states (other than a
client-initiated closure) as a way of closing the channel.
Anyway, I decided to let RMS handle it all by using Pascal's text file I/O,
essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a series of
writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default optimisation on VAX,
gets further with no optimisation and corrupted output.
I might look at the object code produced (VAX) at some point, when I stop crying :) I know
for a fact that there are some bugs in code generation when you do whole record layout
initialisation, ie. $GETJPI lists, etc..
We used to make fun of people who blamed the compiler for problems with their code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly.
But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW
to send messages?
But honestly, you should really be using the non-transparent functionality, and do a
synchronous disconnect, which will allow all outstanding I/O to complete before the
connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
I think you missed that it all came out as a single
line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked have
privileges, because there is no way for normal programs to pull out
some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
--
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
_______________________________________________
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
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I
don't think the DECnet object privilege settings work like one might
expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to
complete before you
deassign/ disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
I've put a 4 second delay between the last
$QIOW and the $DASSGN.
It's not brilliant... but more/most/all gets through now.
The $DASSGN is brutal.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 17:49
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible
re-post) and Tops-20 Finger Setup Documentation (New)
Another data point:
.set /host
Host=MIM RSX-11M-PLUS V4.6 BL87mP
.fin dune::
[DUNE::]
.
So I'm not getting anything at all. :-)
Johnny
On 14/01/2026 18.28, Keith Halewood wrote:
> I've put an explicit '(end)' line on the output from DUNE's finger
> server.
> From GUARD, a call to DUNE's finger does not show the last
> user's record or '(end)'
>
> Oh, that's interesting and confusing:
>
> GUARD is X86_64 VMS and in Australia.
> BUZZEL is X86_64 and on the same LAN as DUNE.
> Both are not showing the last two records of output from DUNE's
> fingerserver.
> I thought it might have been a VMS version issue but....
> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
> In short, it seems I only get a complete output when I'm calling
> DUNE from DUNE.
>
> Weirdness... I'll come back to this later.
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 17:09
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible
> re-post) and Tops-20 Finger Setup Documentation (New)
>
> Maybe I should make a few more comments.
> There might definitely be something VMS specific in your
> observations.I wouldn't know.
>
> With TCP/IP, when data is sent, it's going to be in the queue and
> be delivered even if the sending process closes, finishes and goes away.
> The end-of-file is queued into the sending stream after all the
> data that was sent.
>
> With DECnet, the underlying transport is always record oriented.
> Anything that looks like anything else is always just trying to
> hide that fact. And when you send something, you'll get an
> indication when the send is completed, at which point it shouldn't
> be possible for it not to be delivered, unless connection have completely been
lost.
> With RSX not even that is possible, since a completion of a send
> means that the receiving side actually completed the receive. It's
> very synchronous.
>
> If some higher level library hides all of this, then I would
> expect italso have a way of telling if all the I/O have completed.
>
> Basically, server side accepts the connection, reads the single
> requestline, and then sends data until it is done, after which it
> closes the connection. There must be a way to know that the data
> is actually being delivered, so you don't cancel outstanding sends
> if they are done asynchronous.
>
> Johnny
>
> On 14/01/2026 18.00, Johnny Billquist wrote:
>> Hum?
>> I'm not sure I get it.
>>
>> The client does a connection to the server. Sends a single line.
>> Reads until it gets an end-of-file/connection-closed indication
>> when readind, at which point the server is already gone, and the
>> client canfinish.
>>
>> Where are you thinking/seeing that you need to wait for anything?
>>
>> Johnny
>>
>> On 14/01/2026 17.58, Keith Halewood wrote:
>>> There's a simplistic version currently running on DUNE::
>>> I've noticed a few problems with it.
>>>
>>> For transparent DECnet I/O where channels are assigned and I/O
>>> happens as though each end is local, DECnet seems to suggest
>>> that the receiver (finger client in this case) should disconnect
>>> when it has received what it expects to receive. This
>>> expectation should be part of the client/server protocol such as
>>> an explicit end of data record.
>>> In the TCP/IP world, a finger server disconnects when it's
>>> finished sending all that it wants to send. There's no explicit
>>> high level protocol stating end of data received by the client
>>> other than a receive succeeding with zero length response.
>>>
>>> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
>>> finger server will $ASSIGN to the incoming connection, do a few
>>> $QIOWs and do a $DASSGN, which is quite destructive, including
>>> cancelling all pending I/O requests. You would think that a
>>> $QIOW would return when the I/O completes end to end but it
>>> seems to complete when DECnet takes over.
>>> Consequently, on slow links, a $DASSGN could cause DECnet not to
>>> transmit data that's still pending. This is currently happening
>>> ona comparatively slow link between DUNE and and a host in Australia.
>>>
>>> The non-transparent case, where a lot more of the DECnet
>>> handshaking is exposed, offers a synchronous disconnect which is
>>> initiated with a $QIOW. The server would send this and the
>>> client would then have to react as though it had received an
>>> EOF. In other words, it seems that both ends need to be non-transparent.
>>>
>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>> hide much of the complexity unless you go for full
>>> non-transparency. Even then you can treat the connection as
>>> record-orientated even though it's not like that underneath, and
>>> listen for events on the attached mailbox device.
>>>
>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
>>> $QIOW(write), then a wait for an unknown amount of time before
>>> $DASSGN.
>>> Judging by some of the behaviour I've seen with user DECnet
>>> tasks implemented by command procedures, that appears to be what
>>> VMS does sometimes.
>>>
>>> Is this what networking used to be like? Weird?
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 13:42
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>
>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>> Regarding finger for VMS, I have no real recollection of how we
>>>> used to gather idle time for the 'job' (collection of process
>>>> and subprocesses attached to the terminal).
>>>> Back in the university days, some of the VMS systems had a
>>>> small fixed number of lines connected to the Gandalf (a
>>>> terminal
>>>> server/switch) so we had to do something to prevent users
>>>> hogging the lines.
>>>> I think we used to enumerate allocated terminal class devices
>>>> every
>>>> 10 minutes and remember their completed I/O counts. If the
>>>> count hadn't changed since the last sweep, then the user was logged
out.
>>>> There may have been other considerations involving CPU time, etc.
>>>> but as I said the details are permanently paged out of my
>>>> memory.I don't think the above would be any good really for
>>>> finger idle time.
>>>
>>> I think this is one of those topics which I would just leave as
>>> implementation specific. It depends on what the OS does, and
>>> what can be easily extracted. Just present users with whatever
>>> information makes sense. THe finger protocol is meant for human
>>> consumption, so there are no hard requirements on what
>>> information is provided, or in which form.
>>>
>>> "Idle" in RSX is defined slightly different than in Unix or VMS.
>>> I can tell you that much. But I can only report what RSX thinks here.
>>> (If you were to hit enter on a terminal in RSX, you are still
>>> considered idle.
>>> No activity happened.)
>>>
>>>> I have the beginnings of a DECnet finger server for VMS in
>>>> Pascal, which will produce summary information for who's
>>>> logged, when, what they're doing and where they're doing it
>>>> from and also specific information for matched users if
>>>> supplied as a parameter, including plan and the read/unread
>>>> status of their mailbox. I won't do "poor man's
routing"
>>>> and I'm tempted to restrict the breadth of partial searches to
>>>> a complete username and/or complete word components of a user's
>>>> real name.
>>>
>>> This is also something I'd happily leave to each implementation.
>>> PMR or not - up to each implementation. Just give some sort of
>>> error if you don't allow it. Same with user matching.
>>>
>>>> It'll fit into the framework I have for a DECnet server that
>>>> declares itself as an object and remains running, handling
>>>> multiple requests... but who wants a finger server hanging around?!
>>>> I don't, so the initial version will be instantiated on
>>>> incoming request.
>>>
>>> That's how I do it in RSX, and that's how Unixes does it as
>>> well.I think it would be the most sensible way to do it.
>>>
>>>> It'll be on DUNE's default DECnet account if/when I finish it.
>>>
>>> Would be nice to see it in operation.
>>>
>>> Johnny
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
> sendan email to hecnet-leave(a)lists.dfupdate.se
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
> sendan 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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
1:43 p.m.
I think doing this using RMS will be a part of your headache. If you
were to explicitly do the calls to the network functions, you'd be
happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
I knew it was brutal, yet that's what the
documentation states (other than a client-initiated closure) as a way of closing the
channel.
Anyway, I decided to let RMS handle it all by using Pascal's text file I/O,
essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a series of
writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default optimisation on VAX,
gets further with no optimisation and corrupted output.
I might look at the object code produced (VAX) at some point, when I stop crying :)
I know for a fact that there are some bugs in code generation when you do whole record
layout initialisation, ie. $GETJPI lists, etc..
We used to make fun of people who blamed the compiler for problems withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly.
But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW
to send messages?
But honestly, you should really be using the non-transparent functionality, and do a
synchronous disconnect, which will allow all outstanding I/O to complete before the
connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
I think you missed that it all came out as a
single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked have
privileges, because there is no way for normal programs to pull out
some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I
don't think the DECnet object privilege settings work like one might
expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to
complete before you
deassign/ disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
> I've put a 4 second delay between the last $QIOW and the $DASSGN.
> It's not brilliant... but more/most/all gets through now.
> The $DASSGN is brutal.
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 17:49
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible
> re-post) and Tops-20 Finger Setup Documentation (New)
>
> Another data point:
>
> .set /host
> Host=MIM RSX-11M-PLUS V4.6 BL87mP
> .fin dune::
> [DUNE::]
>
> .
>
>
> So I'm not getting anything at all. :-)
>
> Johnny
>
> On 14/01/2026 18.28, Keith Halewood wrote:
>> I've put an explicit '(end)' line on the output from DUNE's
finger
>> server.
>> From GUARD, a call to DUNE's finger does not show the last
>> user's record or '(end)'
>>
>> Oh, that's interesting and confusing:
>>
>> GUARD is X86_64 VMS and in Australia.
>> BUZZEL is X86_64 and on the same LAN as DUNE.
>> Both are not showing the last two records of output from DUNE's
>> fingerserver.
>> I thought it might have been a VMS version issue but....
>> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
>> In short, it seems I only get a complete output when I'm calling
>> DUNE from DUNE.
>>
>> Weirdness... I'll come back to this later.
>>
>> K
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 17:09
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>> re-post) and Tops-20 Finger Setup Documentation (New)
>>
>> Maybe I should make a few more comments.
>> There might definitely be something VMS specific in your
>> observations.I wouldn't know.
>>
>> With TCP/IP, when data is sent, it's going to be in the queue and
>> be delivered even if the sending process closes, finishes and goesaway.
>> The end-of-file is queued into the sending stream after all the
>> data that was sent.
>>
>> With DECnet, the underlying transport is always record oriented.
>> Anything that looks like anything else is always just trying to
>> hide that fact. And when you send something, you'll get an
>> indication when the send is completed, at which point it shouldn't
>> be possible for it not to be delivered, unless connection have completely been
lost.
>> With RSX not even that is possible, since a completion of a send
>> means that the receiving side actually completed the receive. It's
>> very synchronous.
>>
>> If some higher level library hides all of this, then I would
>> expect italso have a way of telling if all the I/O have completed.
>>
>> Basically, server side accepts the connection, reads the single
>> requestline, and then sends data until it is done, after which it
>> closes the connection. There must be a way to know that the data
>> is actually being delivered, so you don't cancel outstanding sends
>> if they are done asynchronous.
>>
>> Johnny
>>
>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>> Hum?
>>> I'm not sure I get it.
>>>
>>> The client does a connection to the server. Sends a single line.
>>> Reads until it gets an end-of-file/connection-closed indication
>>> when readind, at which point the server is already gone, and the
>>> client canfinish.
>>>
>>> Where are you thinking/seeing that you need to wait for anything?
>>>
>>> Johnny
>>>
>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>> There's a simplistic version currently running on DUNE::
>>>> I've noticed a few problems with it.
>>>>
>>>> For transparent DECnet I/O where channels are assigned and I/O
>>>> happens as though each end is local, DECnet seems to suggest
>>>> that the receiver (finger client in this case) should disconnect
>>>> when it has received what it expects to receive. This
>>>> expectation should be part of the client/server protocol such as
>>>> an explicit end of data record.
>>>> In the TCP/IP world, a finger server disconnects when it's
>>>> finished sending all that it wants to send. There's no explicit
>>>> high level protocol stating end of data received by the client
>>>> other than a receive succeeding with zero length response.
>>>>
>>>> Even with explicit $QIOW (waiting for I/O to complete), a DECnet
>>>> finger server will $ASSIGN to the incoming connection, do a few
>>>> $QIOWs and do a $DASSGN, which is quite destructive, including
>>>> cancelling all pending I/O requests. You would think that a
>>>> $QIOW would return when the I/O completes end to end but it
>>>> seems to complete when DECnet takes over.
>>>> Consequently, on slow links, a $DASSGN could cause DECnet not to
>>>> transmit data that's still pending. This is currently happening
>>>> ona comparatively slow link between DUNE and and a host in Australia.
>>>>
>>>> The non-transparent case, where a lot more of the DECnet
>>>> handshaking is exposed, offers a synchronous disconnect which is
>>>> initiated with a $QIOW. The server would send this and the
>>>> client would then have to react as though it had received an
>>>> EOF. In other words, it seems that both ends need to be non-transparent.
>>>>
>>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>>> hide much of the complexity unless you go for full
>>>> non-transparency. Even then you can treat the connection as
>>>> record-orientated even though it's not like that underneath, and
>>>> listen for events on the attached mailbox device.
>>>>
>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series of
>>>> $QIOW(write), then a wait for an unknown amount of time before
>>>> $DASSGN.
>>>> Judging by some of the behaviour I've seen with user DECnet
>>>> tasks implemented by command procedures, that appears to be what
>>>> VMS does sometimes.
>>>>
>>>> Is this what networking used to be like? Weird?
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 13:42
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>> Regarding finger for VMS, I have no real recollection of how we
>>>>> used to gather idle time for the 'job' (collection of
process
>>>>> and subprocesses attached to the terminal).
>>>>> Back in the university days, some of the VMS systems had a
>>>>> small fixed number of lines connected to the Gandalf (a
>>>>> terminal
>>>>> server/switch) so we had to do something to prevent users
>>>>> hogging the lines.
>>>>> I think we used to enumerate allocated terminal class devices
>>>>> every
>>>>> 10 minutes and remember their completed I/O counts. If the
>>>>> count hadn't changed since the last sweep, then the user was
logged out.
>>>>> There may have been other considerations involving CPU time, etc.
>>>>> but as I said the details are permanently paged out of my
>>>>> memory.I don't think the above would be any good really for
>>>>> finger idle time.
>>>>
>>>> I think this is one of those topics which I would just leave as
>>>> implementation specific. It depends on what the OS does, and
>>>> what can be easily extracted. Just present users with whatever
>>>> information makes sense. THe finger protocol is meant for human
>>>> consumption, so there are no hard requirements on what
>>>> information is provided, or in which form.
>>>>
>>>> "Idle" in RSX is defined slightly different than in Unix or
VMS.
>>>> I can tell you that much. But I can only report what RSX thinks here.
>>>> (If you were to hit enter on a terminal in RSX, you are still
>>>> considered idle.
>>>> No activity happened.)
>>>>
>>>>> I have the beginnings of a DECnet finger server for VMS in
>>>>> Pascal, which will produce summary information for who's
>>>>> logged, when, what they're doing and where they're doing it
>>>>> from and also specific information for matched users if
>>>>> supplied as a parameter, including plan and the read/unread
>>>>> status of their mailbox. I won't do "poor man's
routing"
>>>>> and I'm tempted to restrict the breadth of partial searches to
>>>>> a complete username and/or complete word components of a user's
>>>>> real name.
>>>>
>>>> This is also something I'd happily leave to each implementation.
>>>> PMR or not - up to each implementation. Just give some sort of
>>>> error if you don't allow it. Same with user matching.
>>>>
>>>>> It'll fit into the framework I have for a DECnet server that
>>>>> declares itself as an object and remains running, handling
>>>>> multiple requests... but who wants a finger server hanging around?!
>>>>> I don't, so the initial version will be instantiated on
>>>>> incoming request.
>>>>
>>>> That's how I do it in RSX, and that's how Unixes does it as
>>>> well.I think it would be the most sensible way to do it.
>>>>
>>>>> It'll be on DUNE's default DECnet account if/when I finish
it.
>>>>
>>>> Would be nice to see it in operation.
>>>>
>>>> Johnny
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>> sendan email to hecnet-leave(a)lists.dfupdate.se
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>> sendan 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
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
> an email to hecnet-leave(a)lists.dfupdate.se
16 Jan
16 Jan
11:30 a.m.
In which case, at some point, I'll go non-transparent. Here's what I'm
hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to the client.
The caller will/should interpret this as EOF in the transparent case (or receive a message
in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached to the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you were to explicitly do
the calls to the network functions, you'd be happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
I knew it was brutal, yet that's what the
documentation states (other than a client-initiated closure) as a way of closing the
channel.
Anyway, I decided to let RMS handle it all by using Pascal's text file I/O,
essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a series of
writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default optimisation on VAX,
gets further with no optimisation and corrupted output.
I might look at the object code produced (VAX) at some point, when I
stop crying :) I know for a fact that there are some bugs in code generation when you do
whole record layout initialisation, ie. $GETJPI lists, etc..
We used to make fun of people who blamed the compiler for problems withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly.
But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW
to send messages?
But honestly, you should really be using the non-transparent functionality, and do a
synchronous disconnect, which will allow all outstanding I/O to complete before the
connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
I think you missed that it all came out as a
single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked
have privileges, because there is no way for normal programs to pull
out some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I
don't think the DECnet object privilege settings work like one might
expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
There must be a way to wait for the I/O to
complete before you
deassign/ disconnect/close...
Johnny
On 2026-01-14 20:05, Keith Halewood wrote:
> I've put a 4 second delay between the last $QIOW and the $DASSGN.
> It's not brilliant... but more/most/all gets through now.
> The $DASSGN is brutal.
>
> K
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 17:49
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible
> re-post) and Tops-20 Finger Setup Documentation (New)
>
> Another data point:
>
> .set /host
> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
> [DUNE::]
>
> .
>
>
> So I'm not getting anything at all. :-)
>
> Johnny
>
> On 14/01/2026 18.28, Keith Halewood wrote:
>> I've put an explicit '(end)' line on the output from DUNE's
>> finger server.
>> From GUARD, a call to DUNE's finger does not show the last
>> user's record or '(end)'
>>
>> Oh, that's interesting and confusing:
>>
>> GUARD is X86_64 VMS and in Australia.
>> BUZZEL is X86_64 and on the same LAN as DUNE.
>> Both are not showing the last two records of output from DUNE's
>> fingerserver.
>> I thought it might have been a VMS version issue but....
>> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
>> In short, it seems I only get a complete output when I'm calling
>> DUNE from DUNE.
>>
>> Weirdness... I'll come back to this later.
>>
>> K
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 17:09
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>> re-post) and Tops-20 Finger Setup Documentation (New)
>>
>> Maybe I should make a few more comments.
>> There might definitely be something VMS specific in your
>> observations.I wouldn't know.
>>
>> With TCP/IP, when data is sent, it's going to be in the queue and
>> be delivered even if the sending process closes, finishes and goesaway.
>> The end-of-file is queued into the sending stream after all the
>> data that was sent.
>>
>> With DECnet, the underlying transport is always record oriented.
>> Anything that looks like anything else is always just trying to
>> hide that fact. And when you send something, you'll get an
>> indication when the send is completed, at which point it
>> shouldn't be possible for it not to be delivered, unless connection have
completely been lost.
>> With RSX not even that is possible, since a completion of a send
>> means that the receiving side actually completed the receive.
>> It's very synchronous.
>>
>> If some higher level library hides all of this, then I would
>> expect italso have a way of telling if all the I/O have completed.
>>
>> Basically, server side accepts the connection, reads the single
>> requestline, and then sends data until it is done, after which it
>> closes the connection. There must be a way to know that the data
>> is actually being delivered, so you don't cancel outstanding
>> sends if they are done asynchronous.
>>
>> Johnny
>>
>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>> Hum?
>>> I'm not sure I get it.
>>>
>>> The client does a connection to the server. Sends a single line.
>>> Reads until it gets an end-of-file/connection-closed indication
>>> when readind, at which point the server is already gone, and the
>>> client canfinish.
>>>
>>> Where are you thinking/seeing that you need to wait for anything?
>>>
>>> Johnny
>>>
>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>> There's a simplistic version currently running on DUNE::
>>>> I've noticed a few problems with it.
>>>>
>>>> For transparent DECnet I/O where channels are assigned and I/O
>>>> happens as though each end is local, DECnet seems to suggest
>>>> that the receiver (finger client in this case) should
>>>> disconnect when it has received what it expects to receive.
>>>> This expectation should be part of the client/server protocol
>>>> such as an explicit end of data record.
>>>> In the TCP/IP world, a finger server disconnects when it's
>>>> finished sending all that it wants to send. There's no explicit
>>>> high level protocol stating end of data received by the client
>>>> other than a receive succeeding with zero length response.
>>>>
>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>> DECnet finger server will $ASSIGN to the incoming connection,
>>>> do a few $QIOWs and do a $DASSGN, which is quite destructive,
>>>> including cancelling all pending I/O requests. You would think
>>>> that a $QIOW would return when the I/O completes end to end but
>>>> it seems to complete when DECnet takes over.
>>>> Consequently, on slow links, a $DASSGN could cause DECnet not
>>>> to transmit data that's still pending. This is currently
>>>> happening ona comparatively slow link between DUNE and and a host in
Australia.
>>>>
>>>> The non-transparent case, where a lot more of the DECnet
>>>> handshaking is exposed, offers a synchronous disconnect which
>>>> is initiated with a $QIOW. The server would send this and the
>>>> client would then have to react as though it had received an
>>>> EOF. In other words, it seems that both ends need to be
non-transparent.
>>>>
>>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>>> hide much of the complexity unless you go for full
>>>> non-transparency. Even then you can treat the connection as
>>>> record-orientated even though it's not like that underneath,
>>>> and listen for events on the attached mailbox device.
>>>>
>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series
>>>> of $QIOW(write), then a wait for an unknown amount of time
>>>> before $DASSGN.
>>>> Judging by some of the behaviour I've seen with user DECnet
>>>> tasks implemented by command procedures, that appears to be
>>>> what VMS does sometimes.
>>>>
>>>> Is this what networking used to be like? Weird?
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 13:42
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>> Regarding finger for VMS, I have no real recollection of how
>>>>> we used to gather idle time for the 'job' (collection of
>>>>> process and subprocesses attached to the terminal).
>>>>> Back in the university days, some of the VMS systems had a
>>>>> small fixed number of lines connected to the Gandalf (a
>>>>> terminal
>>>>> server/switch) so we had to do something to prevent users
>>>>> hogging the lines.
>>>>> I think we used to enumerate allocated terminal class devices
>>>>> every
>>>>> 10 minutes and remember their completed I/O counts. If the
>>>>> count hadn't changed since the last sweep, then the user was
logged out.
>>>>> There may have been other considerations involving CPU time, etc.
>>>>> but as I said the details are permanently paged out of my
>>>>> memory.I don't think the above would be any good really for
>>>>> finger idle time.
>>>>
>>>> I think this is one of those topics which I would just leave as
>>>> implementation specific. It depends on what the OS does, and
>>>> what can be easily extracted. Just present users with whatever
>>>> information makes sense. THe finger protocol is meant for human
>>>> consumption, so there are no hard requirements on what
>>>> information is provided, or in which form.
>>>>
>>>> "Idle" in RSX is defined slightly different than in Unix or
VMS.
>>>> I can tell you that much. But I can only report what RSX thinks here.
>>>> (If you were to hit enter on a terminal in RSX, you are still
>>>> considered idle.
>>>> No activity happened.)
>>>>
>>>>> I have the beginnings of a DECnet finger server for VMS in
>>>>> Pascal, which will produce summary information for who's
>>>>> logged, when, what they're doing and where they're doing it
>>>>> from and also specific information for matched users if
>>>>> supplied as a parameter, including plan and the read/unread
>>>>> status of their mailbox. I won't do "poor man's
routing"
>>>>> and I'm tempted to restrict the breadth of partial searches to
>>>>> a complete username and/or complete word components of a
>>>>> user's real name.
>>>>
>>>> This is also something I'd happily leave to each implementation.
>>>> PMR or not - up to each implementation. Just give some sort of
>>>> error if you don't allow it. Same with user matching.
>>>>
>>>>> It'll fit into the framework I have for a DECnet server that
>>>>> declares itself as an object and remains running, handling
>>>>> multiple requests... but who wants a finger server hanging around?!
>>>>> I don't, so the initial version will be instantiated on
>>>>> incoming request.
>>>>
>>>> That's how I do it in RSX, and that's how Unixes does it as
>>>> well.I think it would be the most sensible way to do it.
>>>>
>>>>> It'll be on DUNE's default DECnet account if/when I finish
it.
>>>>
>>>> Would be nice to see it in operation.
>>>>
>>>> Johnny
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>> sendan email to hecnet-leave(a)lists.dfupdate.se
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>> sendan 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
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
> send an email to hecnet-leave(a)lists.dfupdate.se
11:44 a.m.
Client side is really easy. You connect, send a line, you read until the
server close the connection. That's it. Exactly which "mechanisms" are
used is up to each implementation. The whole "transparent" thing seems
rather VMS-specific.
Server side should not be a problem either. Accept the connection, read
a line, send lines, close. Just make sure the data have been sent before
you close. Exactly how you ensure that depends on the OS, and it seems
VMS with RMS does not give you proper control over that, so you should
do it some other way. VMS obviously do have the non-transparent API,
which do allow proper control.
I won't try to give the exact steps you should do in VMS. I'll just say
how it should behave from a network point of view. And I know exactly
how to achieve that in RSX...
Johnny
On 16/01/2026 11.30, Keith Halewood wrote:
In which case, at some point, I'll go
non-transparent. Here's what I'm hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to theclient.
The caller will/should interpret this as EOF in the transparent case (or receive a
message in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached to the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you were to explicitly
do the calls to the network functions, you'd be happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
I knew it was brutal, yet that's what the
documentation states (other than a client-initiated closure) as a way of closing the
channel.
Anyway, I decided to let RMS handle it all by using Pascal's text fileI/O,
essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a series of
writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default optimisation on VAX,
gets further with no optimisation and corrupted output.
I might look at the object code produced (VAX) at some point, when I
stop crying :) I know for a fact that there are some bugs in code generation when you do
whole record layout initialisation, ie. $GETJPI lists,etc..
We used to make fun of people who blamed the compiler for problems withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly.
But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW
to send messages?
But honestly, you should really be using the non-transparent functionality, and do a
synchronous disconnect, which will allow all outstanding I/O to complete before the
connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
_______________________________________________
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 I think you missed that it all came out as a
single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked
have privileges, because there is no way for normal programs to pull
out some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
I think you caught it before I'd reinstalled
the .exe privileged.
There's no way I'm creating a privileged object for it.... and I
don't think the DECnet object privilege settings work like one might
expect anyway.
Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
Doesn't bode well.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 21:28
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
Also, FYI:
.fin dune::
[DUNE::]
OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
06:59:20Nousers logged in.(end) .
Johnny
On 2026-01-14 22:25, Johnny Billquist wrote:
> There must be a way to wait for the I/O to complete before you
> deassign/ disconnect/close...
>
> Johnny
>
> On 2026-01-14 20:05, Keith Halewood wrote:
>> I've put a 4 second delay between the last $QIOW and the $DASSGN.
>> It's not brilliant... but more/most/all gets through now.
>> The $DASSGN is brutal.
>>
>> K
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 17:49
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>> re-post) and Tops-20 Finger Setup Documentation (New)
>>
>> Another data point:
>>
>> .set /host
>> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
>> [DUNE::]
>>
>> .
>>
>>
>> So I'm not getting anything at all. :-)
>>
>> Johnny
>>
>> On 14/01/2026 18.28, Keith Halewood wrote:
>>> I've put an explicit '(end)' line on the output from DUNE's
>>> finger server.
>>> From GUARD, a call to DUNE's finger does not show the last
>>> user's record or '(end)'
>>>
>>> Oh, that's interesting and confusing:
>>>
>>> GUARD is X86_64 VMS and in Australia.
>>> BUZZEL is X86_64 and on the same LAN as DUNE.
>>> Both are not showing the last two records of output from DUNE's
>>> fingerserver.
>>> I thought it might have been a VMS version issue but....
>>> TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
>>> In short, it seems I only get a complete output when I'm calling
>>> DUNE from DUNE.
>>>
>>> Weirdness... I'll come back to this later.
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 17:09
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>
>>> Maybe I should make a few more comments.
>>> There might definitely be something VMS specific in your
>>> observations.I wouldn't know.
>>>
>>> With TCP/IP, when data is sent, it's going to be in the queue and
>>> be delivered even if the sending process closes, finishes and goesaway.
>>> The end-of-file is queued into the sending stream after all the
>>> data that was sent.
>>>
>>> With DECnet, the underlying transport is always record oriented.
>>> Anything that looks like anything else is always just trying to
>>> hide that fact. And when you send something, you'll get an
>>> indication when the send is completed, at which point it
>>> shouldn't be possible for it not to be delivered, unless connection have
completely been lost.
>>> With RSX not even that is possible, since a completion of a send
>>> means that the receiving side actually completed the receive.
>>> It's very synchronous.
>>>
>>> If some higher level library hides all of this, then I would
>>> expect italso have a way of telling if all the I/O have completed.
>>>
>>> Basically, server side accepts the connection, reads the single
>>> requestline, and then sends data until it is done, after which it
>>> closes the connection. There must be a way to know that the data
>>> is actually being delivered, so you don't cancel outstanding
>>> sends if they are done asynchronous.
>>>
>>> Johnny
>>>
>>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>>> Hum?
>>>> I'm not sure I get it.
>>>>
>>>> The client does a connection to the server. Sends a single line.
>>>> Reads until it gets an end-of-file/connection-closed indication
>>>> when readind, at which point the server is already gone, and the
>>>> client canfinish.
>>>>
>>>> Where are you thinking/seeing that you need to wait for anything?
>>>>
>>>> Johnny
>>>>
>>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>>> There's a simplistic version currently running on DUNE::
>>>>> I've noticed a few problems with it.
>>>>>
>>>>> For transparent DECnet I/O where channels are assigned and I/O
>>>>> happens as though each end is local, DECnet seems to suggest
>>>>> that the receiver (finger client in this case) should
>>>>> disconnect when it has received what it expects to receive.
>>>>> This expectation should be part of the client/server protocol
>>>>> such as an explicit end of data record.
>>>>> In the TCP/IP world, a finger server disconnects when it's
>>>>> finished sending all that it wants to send. There's no explicit
>>>>> high level protocol stating end of data received by the client
>>>>> other than a receive succeeding with zero length response.
>>>>>
>>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>>> DECnet finger server will $ASSIGN to the incoming connection,
>>>>> do a few $QIOWs and do a $DASSGN, which is quite destructive,
>>>>> including cancelling all pending I/O requests. You would think
>>>>> that a $QIOW would return when the I/O completes end to end but
>>>>> it seems to complete when DECnet takes over.
>>>>> Consequently, on slow links, a $DASSGN could cause DECnet not
>>>>> to transmit data that's still pending. This is currently
>>>>> happening ona comparatively slow link between DUNE and and a host in
Australia.
>>>>>
>>>>> The non-transparent case, where a lot more of the DECnet
>>>>> handshaking is exposed, offers a synchronous disconnect which
>>>>> is initiated with a $QIOW. The server would send this and the
>>>>> client would then have to react as though it had received an
>>>>> EOF. In other words, it seems that both ends need to be
non-transparent.
>>>>>
>>>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>>>> hide much of the complexity unless you go for full
>>>>> non-transparency. Even then you can treat the connection as
>>>>> record-orientated even though it's not like that underneath,
>>>>> and listen for events on the attached mailbox device.
>>>>>
>>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series
>>>>> of $QIOW(write), then a wait for an unknown amount of time
>>>>> before $DASSGN.
>>>>> Judging by some of the behaviour I've seen with user DECnet
>>>>> tasks implemented by command procedures, that appears to be
>>>>> what VMS does sometimes.
>>>>>
>>>>> Is this what networking used to be like? Weird?
>>>>>
>>>>> K
>>>>>
>>>>> -----Original Message-----
>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>> Sent: 14 January 2026 13:42
>>>>> To: hecnet(a)lists.dfupdate.se
>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>
>>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>>> Regarding finger for VMS, I have no real recollection of how
>>>>>> we used to gather idle time for the 'job' (collection of
>>>>>> process and subprocesses attached to the terminal).
>>>>>> Back in the university days, some of the VMS systems had a
>>>>>> small fixed number of lines connected to the Gandalf (a
>>>>>> terminal
>>>>>> server/switch) so we had to do something to prevent users
>>>>>> hogging the lines.
>>>>>> I think we used to enumerate allocated terminal class devices
>>>>>> every
>>>>>> 10 minutes and remember their completed I/O counts. If the
>>>>>> count hadn't changed since the last sweep, then the user was
logged out.
>>>>>> There may have been other considerations involving CPU time,
etc.
>>>>>> but as I said the details are permanently paged out of my
>>>>>> memory.I don't think the above would be any good really for
>>>>>> finger idle time.
>>>>>
>>>>> I think this is one of those topics which I would just leave as
>>>>> implementation specific. It depends on what the OS does, and
>>>>> what can be easily extracted. Just present users with whatever
>>>>> information makes sense. THe finger protocol is meant for human
>>>>> consumption, so there are no hard requirements on what
>>>>> information is provided, or in which form.
>>>>>
>>>>> "Idle" in RSX is defined slightly different than in Unix or
VMS.
>>>>> I can tell you that much. But I can only report what RSX thinkshere.
>>>>> (If you were to hit enter on a terminal in RSX, you are still
>>>>> considered idle.
>>>>> No activity happened.)
>>>>>
>>>>>> I have the beginnings of a DECnet finger server for VMS in
>>>>>> Pascal, which will produce summary information for who's
>>>>>> logged, when, what they're doing and where they're doing
it
>>>>>> from and also specific information for matched users if
>>>>>> supplied as a parameter, including plan and the read/unread
>>>>>> status of their mailbox. I won't do "poor man's
routing"
>>>>>> and I'm tempted to restrict the breadth of partial searches
to
>>>>>> a complete username and/or complete word components of a
>>>>>> user's real name.
>>>>>
>>>>> This is also something I'd happily leave to each implementation.
>>>>> PMR or not - up to each implementation. Just give some sort of
>>>>> error if you don't allow it. Same with user matching.
>>>>>
>>>>>> It'll fit into the framework I have for a DECnet server that
>>>>>> declares itself as an object and remains running, handling
>>>>>> multiple requests... but who wants a finger server hanging
around?!
>>>>>> I don't, so the initial version will be instantiated on
>>>>>> incoming request.
>>>>>
>>>>> That's how I do it in RSX, and that's how Unixes does it as
>>>>> well.I think it would be the most sensible way to do it.
>>>>>
>>>>>> It'll be on DUNE's default DECnet account if/when I
finish it.
>>>>>
>>>>> Would be nice to see it in operation.
>>>>>
>>>>> Johnny
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>> sendan email to hecnet-leave(a)lists.dfupdate.se
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>> sendan 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
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>> send an email to hecnet-leave(a)lists.dfupdate.se
>
12:11 p.m.
By the way. Since you're using RMS. Why not use $CLOSE instead of
$DASSGN? Seems like that would be the natural way.
Johnny
On 16/01/2026 11.44, Johnny Billquist wrote:
Client side is really easy. You connect, send a line,
you read until the
server close the connection. That's it. Exactly which "mechanisms" are
used is up to each implementation. The whole "transparent" thing seems
rather VMS-specific.
Server side should not be a problem either. Accept the connection, read
a line, send lines, close. Just make sure the data have been sent before
you close. Exactly how you ensure that depends on the OS, and it seems
VMS with RMS does not give you proper control over that, so you should
do it some other way. VMS obviously do have the non-transparent API,
which do allow proper control.
I won't try to give the exact steps you should do in VMS. I'll just say
how it should behave from a network point of view. And I know exactly
how to achieve that in RSX...
Johnny
On 16/01/2026 11.30, Keith Halewood wrote:
In which case, at some point, I'll go
non-transparent. Here's what I'm
hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to
theclient.
The caller will/should interpret this as EOF in the transparent case
(or receive a message in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached to
the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you
were to explicitly do the calls to the network functions, you'd be
happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se I knew it was brutal, yet that's what the
documentation states (other
than a client-initiated closure) as a way of closing the channel.
Anyway, I decided to let RMS handle it all by using Pascal's text
fileI/O, essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before a
series of writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default
optimisation on VAX, gets further with no optimisation and corrupted
output.
I might look at the object code produced (VAX) at some point, when I
stop crying :) I know for a fact that there are some bugs in code
generation when you do whole record layout initialisation, ie.
$GETJPI lists,etc..
We used to make fun of people who blamed the compiler for problems
withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the
link quite abruptly. But with the problems you describe, I'm
wondering if you are using $QIO and not $QIOW to send messages?
But honestly, you should really be using the non-transparent
functionality, and do a synchronous disconnect, which will allow all
outstanding I/O to complete before the connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
_______________________________________________
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 I think you missed that it all came out as a
single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry any
information about privilege, but my finger task that gets invoked
have privileges, because there is no way for normal programs to pull
out some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
> I think you caught it before I'd reinstalled the .exe privileged.
> There's no way I'm creating a privileged object for it.... and I
> don't think the DECnet object privilege settings work like one might
> expect anyway.
>
> Incidentally, from https://docs.vmssoftware.com/vsi-openvms-decnet-
> networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
>
> Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
> openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
>
> Doesn't bode well.
>
> K
>
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 21:28
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
> and Tops-20 Finger Setup Documentation (New)
>
> Also, FYI:
>
> .fin dune::
> [DUNE::]
> OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
> 06:59:20Nousers logged in.(end) .
>
>
> Johnny
>
>
> On 2026-01-14 22:25, Johnny Billquist wrote:
>> There must be a way to wait for the I/O to complete before you
>> deassign/ disconnect/close...
>>
>> Johnny
>>
>> On 2026-01-14 20:05, Keith Halewood wrote:
>>> I've put a 4 second delay between the last $QIOW and the $DASSGN.
>>> It's not brilliant... but more/most/all gets through now.
>>> The $DASSGN is brutal.
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 17:49
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>
>>> Another data point:
>>>
>>> .set /host
>>> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
>>> [DUNE::]
>>>
>>> .
>>>
>>>
>>> So I'm not getting anything at all. :-)
>>>
>>> Johnny
>>>
>>> On 14/01/2026 18.28, Keith Halewood wrote:
>>>> I've put an explicit '(end)' line on the output from
DUNE's
>>>> finger server.
>>>> From GUARD, a call to DUNE's finger does notshow the last
>>>> user's record or '(end)'
>>>>
>>>> Oh, that's interesting and confusing:
>>>>
>>>> GUARD is X86_64 VMS and in Australia.
>>>> BUZZEL is X86_64 and on the same LAN as DUNE.
>>>> Both are not showing the last two records of output from DUNE's
>>>> fingerserver.
>>>> I thought it might have been a VMS version issue but....
>>>> TUPILE is VAX and on the same LAN as DUNE and is displaying even
>>>> less.
>>>> In short, it seems I only get a complete output when I'm calling
>>>> DUNE from DUNE.
>>>>
>>>> Weirdness... I'll come back to this later.
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 17:09
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> Maybe I should make a few more comments.
>>>> There might definitely be something VMS specific in your
>>>> observations.I wouldn't know.
>>>>
>>>> With TCP/IP, when data is sent, it's going to be in the queue and
>>>> be delivered even if the sending process closes, finishes and
>>>> goesaway.
>>>> The end-of-file is queued into the sending stream after all the
>>>> data that was sent.
>>>>
>>>> With DECnet, the underlying transport is always record oriented.
>>>> Anything that looks like anything else is always just trying to
>>>> hide that fact. And when you send something, you'll get an
>>>> indication when the send is completed, at which point it
>>>> shouldn't be possible for it not to be delivered, unless
>>>> connection have completely been lost.
>>>> With RSX not even that is possible, since a completion of a send
>>>> means that the receiving side actually completed the receive.
>>>> It's very synchronous.
>>>>
>>>> If some higher level library hides all of this, then I would
>>>> expect italso have a way of telling if all the I/O have completed.
>>>>
>>>> Basically, server side accepts the connection, reads the single
>>>> requestline, and then sends data until it is done, after which it
>>>> closes the connection. There must be a way to know that the data
>>>> is actually being delivered, so you don't cancel outstanding
>>>> sends if they are done asynchronous.
>>>>
>>>> Johnny
>>>>
>>>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>>>> Hum?
>>>>> I'm not sure I get it.
>>>>>
>>>>> The client does a connection to the server. Sends a single line.
>>>>> Reads until it gets an end-of-file/connection-closed indication
>>>>> when readind, at which point the server is already gone, and the
>>>>> client canfinish.
>>>>>
>>>>> Where are you thinking/seeing that you need to wait for anything?
>>>>>
>>>>> Johnny
>>>>>
>>>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>>>> There's a simplistic version currently running on DUNE::
>>>>>> I've noticed a few problems with it.
>>>>>>
>>>>>> For transparent DECnet I/O where channels are assigned and I/O
>>>>>> happens as though each end is local, DECnet seems to suggest
>>>>>> that the receiver (finger client in this case) should
>>>>>> disconnect when it has received what it expects to receive.
>>>>>> This expectation should be part of the client/server protocol
>>>>>> such as an explicit end of data record.
>>>>>> In the TCP/IP world, a finger server disconnects when it's
>>>>>> finished sending all that it wants to send. There's no
explicit
>>>>>> high level protocol stating end of data received by the client
>>>>>> other than a receive succeeding with zero length response.
>>>>>>
>>>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>>>> DECnet finger server will $ASSIGN to the incoming connection,
>>>>>> do a few $QIOWs and do a $DASSGN, which is quite destructive,
>>>>>> including cancelling all pending I/O requests. You would think
>>>>>> that a $QIOW would return when the I/O completes end to end but
>>>>>> it seems to complete when DECnet takes over.
>>>>>> Consequently, on slow links, a $DASSGN could cause DECnet not
>>>>>> to transmit data that's still pending. This is currently
>>>>>> happening ona comparatively slow link between DUNE and and a
>>>>>> host in Australia.
>>>>>>
>>>>>> The non-transparent case, where a lot more of the DECnet
>>>>>> handshaking is exposed, offers a synchronous disconnect which
>>>>>> is initiated with a $QIOW. The server would send this and the
>>>>>> client would then have to react as though it had received an
>>>>>> EOF. In other words, it seems that both ends need to be non-
>>>>>> transparent.
>>>>>>
>>>>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>>>>> hide much of the complexity unless you go for full
>>>>>> non-transparency. Even then you can treat the connection as
>>>>>> record-orientated even though it's not like that underneath,
>>>>>> and listen for events on the attached mailbox device.
>>>>>>
>>>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a
series
>>>>>> of $QIOW(write), then a wait for an unknown amount of time
>>>>>> before $DASSGN.
>>>>>> Judging by some of the behaviour I've seen with user DECnet
>>>>>> tasks implemented by command procedures, that appears to be
>>>>>> what VMS does sometimes.
>>>>>>
>>>>>> Is this what networking used to be like? Weird?
>>>>>>
>>>>>> K
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>>> Sent: 14 January 2026 13:42
>>>>>> To: hecnet(a)lists.dfupdate.se
>>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>>
>>>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>>>> Regarding finger for VMS, I have no real recollection of how
>>>>>>> we used to gather idle time for the 'job' (collection
of
>>>>>>> process and subprocesses attached to the terminal).
>>>>>>> Back in the university days, some of the VMS systems had a
>>>>>>> small fixed number of lines connected to the Gandalf (a
>>>>>>> terminal
>>>>>>> server/switch) so we had to do something to prevent users
>>>>>>> hogging the lines.
>>>>>>> I think we used to enumerate allocated terminal class
devices
>>>>>>> every
>>>>>>> 10 minutes and remember their completed I/O counts. If the
>>>>>>> count hadn't changed since the last sweep, then the user
was
>>>>>>> logged out.
>>>>>>> There may have been other considerations involving CPU time,
>>>>>>> etc.
>>>>>>> but as I said the details are permanently paged out of my
>>>>>>> memory.I don't think the above would be any good really
for
>>>>>>> finger idle time.
>>>>>>
>>>>>> I think this is one of those topics which I would just leave as
>>>>>> implementation specific. It depends on what the OS does, and
>>>>>> what can be easily extracted. Just present users with whatever
>>>>>> information makes sense. THe finger protocol is meant for human
>>>>>> consumption, so there are no hard requirements on what
>>>>>> information is provided, or in which form.
>>>>>>
>>>>>> "Idle" in RSX is defined slightly different than in
Unix or VMS.
>>>>>> I can tell you that much. But I can only report what RSX
>>>>>> thinkshere.
>>>>>> (If you were to hit enter on a terminal in RSX, you are still
>>>>>> considered idle.
>>>>>> No activity happened.)
>>>>>>
>>>>>>> I have the beginnings of a DECnet finger server for VMS in
>>>>>>> Pascal, which will produce summary information for who's
>>>>>>> logged, when, what they're doing and where they're
doing it
>>>>>>> from and also specific information for matched users if
>>>>>>> supplied as a parameter, including plan and the read/unread
>>>>>>> status of their mailbox. I won't do "poor man's
routing"
>>>>>>> and I'm tempted to restrict the breadth of partial
searches to
>>>>>>> a complete username and/or complete word components of a
>>>>>>> user's real name.
>>>>>>
>>>>>> This is also something I'd happily leave to each
implementation.
>>>>>> PMR or not - up to each implementation. Just give some sort of
>>>>>> error if you don't allow it. Same with user matching.
>>>>>>
>>>>>>> It'll fit into the framework I have for a DECnet server
that
>>>>>>> declares itself as an object and remains running, handling
>>>>>>> multiple requests... but who wants a finger server hanging
>>>>>>> around?!
>>>>>>> I don't, so the initial version will be instantiated on
>>>>>>> incoming request.
>>>>>>
>>>>>> That's how I do it in RSX, and that's how Unixes does it
as
>>>>>> well.I think it would be the most sensible way to do it.
>>>>>>
>>>>>>> It'll be on DUNE's default DECnet account if/when I
finish it.
>>>>>>
>>>>>> Would be nice to see it in operation.
>>>>>>
>>>>>> Johnny
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> sendan email to hecnet-leave(a)lists.dfupdate.se
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>>> sendan 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
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>> send an email to hecnet-leave(a)lists.dfupdate.se
>>
>
17 Jan
17 Jan
5:35 p.m.
I posted this on Discord:
Some interesting things with VMS Pascal (VAX vs. X86_64).
I've been playing with a DECnet version of Finger for VMS over the past few days and
got caught by some issues that affect the code generated by the (last) VAX version of
Pascal but have been fixed by the (current) X86_64 version.
The result has had me questioning DECnet's task to task handling (after some
self-inflicted stupidity using $DASSGN to brutally close a channel and therefore stop the
last few messages reaching the other end of the channel).
Essentially, array/record initialisation of the form:
v := arraytype[ 1: rectype[field1: val1; field2: val2]; 2: rectype[....]; ...];
causes a creeping corruption in the space allocated to variables in the vicinity of v.
The standard equivalent:
with v[1] do begin field1 := val1; field2 := val2;...... end;
with v[2] do begin ...... end;
does not and works correctly. The effects of /NOOPTIMIZE on the first example merely
increases the subtlety of the runtime corruption.
I've converted every instance of the first syntax in my code (JPI, DVI item lists
mostly) to the 2nd and things are fine with DECnet tasks
and standard RMS I/O.
I don't suppose VSI care about VAX compilers :(
So now I can complete the finger server without losing my mind with:
( f defined as f : text )
open(f,'sys$net',old);
reset(f);
readln(f,searchstring);
rewrite(f);
writeln(f,'finger output.... blah....');
close(f);
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 16 January 2026 11:12
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
By the way. Since you're using RMS. Why not use $CLOSE instead of $DASSGN? Seems like
that would be the natural way.
Johnny
On 16/01/2026 11.44, Johnny Billquist wrote:
Client side is really easy. You connect, send a line,
you read until
the server close the connection. That's it. Exactly which "mechanisms"
are used is up to each implementation. The whole "transparent" thing
seems rather VMS-specific.
Server side should not be a problem either. Accept the connection,
read a line, send lines, close. Just make sure the data have been sent
before you close. Exactly how you ensure that depends on the OS, and
it seems VMS with RMS does not give you proper control over that, so
you should do it some other way. VMS obviously do have the
non-transparent API, which do allow proper control.
I won't try to give the exact steps you should do in VMS. I'll just
say how it should behave from a network point of view. And I know
exactly how to achieve that in RSX...
Johnny
On 16/01/2026 11.30, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
In which case, at some point, I'll go
non-transparent. Here's what
I'm hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to
theclient.
The caller will/should interpret this as EOF in the transparent case
(or receive a message in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached to
the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you
were to explicitly do the calls to the network functions, you'd be
happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
I knew it was brutal, yet that's what the
documentation states
(other than a client-initiated closure) as a way of closing the channel.
Anyway, I decided to let RMS handle it all by using Pascal's text
fileI/O, essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before
a series of writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default
optimisation on VAX, gets further with no optimisation and corrupted
output.
I might look at the object code produced (VAX) at some point, when I
stop crying :) I know for a fact that there are some bugs in code
generation when you do whole record layout initialisation, ie.
$GETJPI lists,etc..
We used to make fun of people who blamed the compiler for problems
withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the
link quite abruptly. But with the problems you describe, I'm
wondering if you are using $QIO and not $QIOW to send messages?
But honestly, you should really be using the non-transparent
functionality, and do a synchronous disconnect, which will allow all
outstanding I/O to complete before the connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
_______________________________________________
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
I think you missed that it all came out as a
single line. :-)
As far as "privileged" goes... In RSX objects as such don't carry
any information about privilege, but my finger task that gets
invoked have privileges, because there is no way for normal
programs to pull out some of the information needed.
Johnny
On 2026-01-15 00:07, Keith Halewood wrote:
> I think you caught it before I'd reinstalled the .exe privileged.
> There's no way I'm creating a privileged object for it.... and I
> don't think the DECnet object privilege settings work like one
> might expect anyway.
>
> Incidentally, from
> https://docs.vmssoftware.com/vsi-openvms-decnet-
> networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
>
> Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
> openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
>
> Doesn't bode well.
>
> K
>
>
> -----Original Message-----
> From: Johnny Billquist [mailto:bqt@softjar.se]
> Sent: 14 January 2026 21:28
> To: hecnet(a)lists.dfupdate.se
> Subject: [HECnet] Re: DECnet Finger Specification (Possible
> re-post) and Tops-20 Finger Setup Documentation (New)
>
> Also, FYI:
>
> .fin dune::
> [DUNE::]
> OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
> 06:59:20Nousers logged in.(end) .
>
>
> Johnny
>
>
> On 2026-01-14 22:25, Johnny Billquist wrote:
>> There must be a way to wait for the I/O to complete before you
>> deassign/ disconnect/close...
>>
>> Johnny
>>
>> On 2026-01-14 20:05, Keith Halewood wrote:
>>> I've put a 4 second delay between the last $QIOW and the $DASSGN.
>>> It's not brilliant... but more/most/all gets through now.
>>> The $DASSGN is brutal.
>>>
>>> K
>>>
>>> -----Original Message-----
>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>> Sent: 14 January 2026 17:49
>>> To: hecnet(a)lists.dfupdate.se
>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>
>>> Another data point:
>>>
>>> .set /host
>>> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
>>> [DUNE::]
>>>
>>> .
>>>
>>>
>>> So I'm not getting anything at all. :-)
>>>
>>> Johnny
>>>
>>> On 14/01/2026 18.28, Keith Halewood wrote:
>>>> I've put an explicit '(end)' line on the output from
DUNE's
>>>> finger server.
>>>> From GUARD, a call to DUNE's finger does notshow the last
>>>> user's record or '(end)'
>>>>
>>>> Oh, that's interesting and confusing:
>>>>
>>>> GUARD is X86_64 VMS and in Australia.
>>>> BUZZEL is X86_64 and on the same LAN as DUNE.
>>>> Both are not showing the last two records of output from DUNE's
>>>> fingerserver.
>>>> I thought it might have been a VMS version issue but....
>>>> TUPILE is VAX and on the same LAN as DUNE and is displaying
>>>> even less.
>>>> In short, it seems I only get a complete output when I'm
>>>> calling DUNE from DUNE.
>>>>
>>>> Weirdness... I'll come back to this later.
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 17:09
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> Maybe I should make a few more comments.
>>>> There might definitely be something VMS specific in your
>>>> observations.I wouldn't know.
>>>>
>>>> With TCP/IP, when data is sent, it's going to be in the queue
>>>> and be delivered even if the sending process closes, finishes
>>>> and goesaway.
>>>> The end-of-file is queued into the sending stream after all the
>>>> data that was sent.
>>>>
>>>> With DECnet, the underlying transport is always record oriented.
>>>> Anything that looks like anything else is always just trying to
>>>> hide that fact. And when you send something, you'll get an
>>>> indication when the send is completed, at which point it
>>>> shouldn't be possible for it not to be delivered, unless
>>>> connection have completely been lost.
>>>> With RSX not even that is possible, since a completion of a
>>>> send means that the receiving side actually completed the receive.
>>>> It's very synchronous.
>>>>
>>>> If some higher level library hides all of this, then I would
>>>> expect italso have a way of telling if all the I/O have completed.
>>>>
>>>> Basically, server side accepts the connection, reads the single
>>>> requestline, and then sends data until it is done, after which
>>>> it closes the connection. There must be a way to know that the
>>>> data is actually being delivered, so you don't cancel
>>>> outstanding sends if they are done asynchronous.
>>>>
>>>> Johnny
>>>>
>>>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>>>> Hum?
>>>>> I'm not sure I get it.
>>>>>
>>>>> The client does a connection to the server. Sends a single line.
>>>>> Reads until it gets an end-of-file/connection-closed
>>>>> indication when readind, at which point the server is already
>>>>> gone, and the client canfinish.
>>>>>
>>>>> Where are you thinking/seeing that you need to wait for anything?
>>>>>
>>>>> Johnny
>>>>>
>>>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>>>> There's a simplistic version currently running on DUNE::
>>>>>> I've noticed a few problems with it.
>>>>>>
>>>>>> For transparent DECnet I/O where channels are assigned and
>>>>>> I/O happens as though each end is local, DECnet seems to
>>>>>> suggest that the receiver (finger client in this case) should
>>>>>> disconnect when it has received what it expects to receive.
>>>>>> This expectation should be part of the client/server protocol
>>>>>> such as an explicit end of data record.
>>>>>> In the TCP/IP world, a finger server disconnects when it's
>>>>>> finished sending all that it wants to send. There's no
>>>>>> explicit high level protocol stating end of data received by
>>>>>> the client other than a receive succeeding with zero length
response.
>>>>>>
>>>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>>>> DECnet finger server will $ASSIGN to the incoming connection,
>>>>>> do a few $QIOWs and do a $DASSGN, which is quite destructive,
>>>>>> including cancelling all pending I/O requests. You would
>>>>>> think that a $QIOW would return when the I/O completes end to
>>>>>> end but it seems to complete when DECnet takes over.
>>>>>> Consequently, on slow links, a $DASSGN could cause DECnet not
>>>>>> to transmit data that's still pending. This is currently
>>>>>> happening ona comparatively slow link between DUNE and and a
>>>>>> host in Australia.
>>>>>>
>>>>>> The non-transparent case, where a lot more of the DECnet
>>>>>> handshaking is exposed, offers a synchronous disconnect which
>>>>>> is initiated with a $QIOW. The server would send this and the
>>>>>> client would then have to react as though it had received an
>>>>>> EOF. In other words, it seems that both ends need to be non-
>>>>>> transparent.
>>>>>>
>>>>>> A lot of this may be peculiar to DECnet on VMS which tries to
>>>>>> hide much of the complexity unless you go for full
>>>>>> non-transparency. Even then you can treat the connection as
>>>>>> record-orientated even though it's not like that underneath,
>>>>>> and listen for events on the attached mailbox device.
>>>>>>
>>>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a series
>>>>>> of $QIOW(write), then a wait for an unknown amount of time
>>>>>> before $DASSGN.
>>>>>> Judging by some of the behaviour I've seen with user DECnet
>>>>>> tasks implemented by command procedures, that appears to be
>>>>>> what VMS does sometimes.
>>>>>>
>>>>>> Is this what networking used to be like? Weird?
>>>>>>
>>>>>> K
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>>> Sent: 14 January 2026 13:42
>>>>>> To: hecnet(a)lists.dfupdate.se
>>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>>
>>>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>>>> Regarding finger for VMS, I have no real recollection of how
>>>>>>> we used to gather idle time for the 'job' (collection
of
>>>>>>> process and subprocesses attached to the terminal).
>>>>>>> Back in the university days, some of the VMS systems had a
>>>>>>> small fixed number of lines connected to the Gandalf (a
>>>>>>> terminal
>>>>>>> server/switch) so we had to do something to prevent users
>>>>>>> hogging the lines.
>>>>>>> I think we used to enumerate allocated terminal class
>>>>>>> devices every
>>>>>>> 10 minutes and remember their completed I/O counts. If the
>>>>>>> count hadn't changed since the last sweep, then the user
was
>>>>>>> logged out.
>>>>>>> There may have been other considerations involving CPU time,
>>>>>>> etc.
>>>>>>> but as I said the details are permanently paged out of my
>>>>>>> memory.I don't think the above would be any good really
for
>>>>>>> finger idle time.
>>>>>>
>>>>>> I think this is one of those topics which I would just leave
>>>>>> as implementation specific. It depends on what the OS does,
>>>>>> and what can be easily extracted. Just present users with
>>>>>> whatever information makes sense. THe finger protocol is
>>>>>> meant for human consumption, so there are no hard
>>>>>> requirements on what information is provided, or in which form.
>>>>>>
>>>>>> "Idle" in RSX is defined slightly different than in
Unix or VMS.
>>>>>> I can tell you that much. But I can only report what RSX
>>>>>> thinkshere.
>>>>>> (If you were to hit enter on a terminal in RSX, you are still
>>>>>> considered idle.
>>>>>> No activity happened.)
>>>>>>
>>>>>>> I have the beginnings of a DECnet finger server for VMS in
>>>>>>> Pascal, which will produce summary information for who's
>>>>>>> logged, when, what they're doing and where they're
doing it
>>>>>>> from and also specific information for matched users if
>>>>>>> supplied as a parameter, including plan and the read/unread
>>>>>>> status of their mailbox. I won't do "poor man's
routing"
>>>>>>> and I'm tempted to restrict the breadth of partial
searches
>>>>>>> to a complete username and/or complete word components of a
>>>>>>> user's real name.
>>>>>>
>>>>>> This is also something I'd happily leave to each
implementation.
>>>>>> PMR or not - up to each implementation. Just give some sort
>>>>>> of error if you don't allow it. Same with user matching.
>>>>>>
>>>>>>> It'll fit into the framework I have for a DECnet server
that
>>>>>>> declares itself as an object and remains running, handling
>>>>>>> multiple requests... but who wants a finger server hanging
>>>>>>> around?!
>>>>>>> I don't, so the initial version will be instantiated on
>>>>>>> incoming request.
>>>>>>
>>>>>> That's how I do it in RSX, and that's how Unixes does it
as
>>>>>> well.I think it would be the most sensible way to do it.
>>>>>>
>>>>>>> It'll be on DUNE's default DECnet account if/when I
finish it.
>>>>>>
>>>>>> Would be nice to see it in operation.
>>>>>>
>>>>>> Johnny
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> sendan email to hecnet-leave(a)lists.dfupdate.se
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>>> sendan 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
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>> send an email to hecnet-leave(a)lists.dfupdate.se
>>
>
18 Jan
18 Jan
9:10 p.m.
On 2026-01-17 11:35, Keith Halewood wrote:
I posted this on Discord:
Some interesting things with VMS Pascal (VAX vs. X86_64).
I've been playing with a DECnet version of Finger for VMS over the
past few days and got caught by some issues that affect the code
generated by the (last) VAX version of Pascal but have been fixed by
the (current) X86_64 version.
Are you committed to Pascal, or would you consider C or Fortrqn?
Portability isn't an issue as Finger grovels around in VMS innards
to get the data it reports, so it's pretty much whichever language
implements direct access to $QIO[W] in the manner you find easiest.
does not and works correctly. The effects of
/NOOPTIMIZE on the first
example merely increases the subtlety of the runtime corruption.
I've converted every instance of the first syntax in my code (JPI, DVI
item lists mostly) to the 2nd and things are fine with DECnet tasks
and standard RMS I/O.
I don't suppose VSI care about VAX compilers :(
I believe the Alpha and Itanium compilers use the GEM back-end (and
also the GEM front-end). I don't know what VAX is doing. VAX did get
DEC C which replaced VAX C (for the most part) so some GEM made it to
VAX.
My understanding is that the VSI compilers for x86-64 use the GEM
front-end were appropriate, a shim, and a very modified LLVM back-end.
But that's just from what I've heard anecdotally.
I just took a look and I have PASCAL V5.8-90 on the VAX and PASCAL
V6.1-116-48H61 (that's a mouthful) on Alpha. My VAX/VMS patch collec-
tion is limited to VMS patches, not layered products, unfortunately.
If you're running something older than V5.8-90 on VAX, let me know
and I'll get you a kit.
So now I can complete the finger server without losing my mind with:
( f defined as f : text )
open(f,'sys$net',old);
reset(f);
readln(f,searchstring);
rewrite(f);
writeln(f,'finger output.... blah....');
close(f);
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 16 January 2026 11:12
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way. Since you're using RMS. Why not use $CLOSE instead of
$DASSGN? Seems like that would be the natural way.
Johnny
On 16/01/2026 11.44, Johnny Billquist wrote:
Client side is really easy. You connect, send a
line, you read until
the server close the connection. That's it. Exactly which "mechanisms"
are used is up to each implementation. The whole "transparent" thing
seems rather VMS-specific.
Server side should not be a problem either. Accept the connection,
read a line, send lines, close. Just make sure the data have been sent
before you close. Exactly how you ensure that depends on the OS, and
it seems VMS with RMS does not give you proper control over that, so
you should do it some other way. VMS obviously do have the
non-transparent API, which do allow proper control.
I won't try to give the exact steps you should do in VMS. I'll just
say how it should behave from a network point of view. And I know
exactly how to achieve that in RSX...
Johnny
On 16/01/2026 11.30, Keith Halewood wrote:
_______________________________________________
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 In which case, at some point, I'll go
non-transparent. Here's what
I'm hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to
theclient.
The caller will/should interpret this as EOF in the transparent case
(or receive a message in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached to
the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you
were to explicitly do the calls to the network functions, you'd be
happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se I knew it was brutal, yet that's what the
documentation states
(other than a client-initiated closure) as a way of closing the
channel.
Anyway, I decided to let RMS handle it all by using Pascal's text
fileI/O, essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before
a series of writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default
optimisation on VAX, gets further with no optimisation and corrupted
output.
I might look at the object code produced (VAX) at some point, when I
stop crying :) I know for a fact that there are some bugs in code
generation when you do whole record layout initialisation, ie.
$GETJPI lists,etc..
We used to make fun of people who blamed the compiler for problems
withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts the
link quite abruptly. But with the problems you describe, I'm
wondering if you are using $QIO and not $QIOW to send messages?
But honestly, you should really be using the non-transparent
functionality, and do a synchronous disconnect, which will allow all
outstanding I/O to complete before the connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
> I think you missed that it all came out as a single line. :-)
>
> As far as "privileged" goes... In RSX objects as such don't carry
> any information about privilege, but my finger task that gets
> invoked have privileges, because there is no way for normal
> programs to pull out some of the information needed.
>
> Johnny
>
> On 2026-01-15 00:07, Keith Halewood wrote:
>> I think you caught it before I'd reinstalled the .exe privileged.
>> There's no way I'm creating a privileged object for it.... and I
>> don't think the DECnet object privilege settings work like one
>> might expect anyway.
>>
>> Incidentally, from
>> https://docs.vmssoftware.com/vsi-openvms-decnet-
>> networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
>>
>> Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
>> openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
>>
>> Doesn't bode well.
>>
>> K
>>
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 21:28
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>> re-post) and Tops-20 Finger Setup Documentation (New)
>>
>> Also, FYI:
>>
>> .fin dune::
>> [DUNE::]
>> OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
>> 06:59:20Nousers logged in.(end) .
>>
>>
>> Johnny
>>
>>
>> On 2026-01-14 22:25, Johnny Billquist wrote:
>>> There must be a way to wait for the I/O to complete before you
>>> deassign/ disconnect/close...
>>>
>>> Johnny
>>>
>>> On 2026-01-14 20:05, Keith Halewood wrote:
>>>> I've put a 4 second delay between the last $QIOW and the
>>>> $DASSGN.
>>>> It's not brilliant... but more/most/all gets through now.
>>>> The $DASSGN is brutal.
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 17:49
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> Another data point:
>>>>
>>>> .set /host
>>>> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
>>>> [DUNE::]
>>>>
>>>> .
>>>>
>>>>
>>>> So I'm not getting anything at all. :-)
>>>>
>>>> Johnny
>>>>
>>>> On 14/01/2026 18.28, Keith Halewood wrote:
>>>>> I've put an explicit '(end)' line on the output from
DUNE's
>>>>> finger server.
>>>>> From GUARD, a call to DUNE's finger does notshow the last
>>>>> user's record or '(end)'
>>>>>
>>>>> Oh, that's interesting and confusing:
>>>>>
>>>>> GUARD is X86_64 VMS and in Australia.
>>>>> BUZZEL is X86_64 and on the same LAN as DUNE.
>>>>> Both are not showing the last two records of output from DUNE's
>>>>> fingerserver.
>>>>> I thought it might have been a VMS version issue but....
>>>>> TUPILE is VAX and on the same LAN as DUNE and is displaying
>>>>> even less.
>>>>> In short, it seems I only get a complete output when I'm
>>>>> calling DUNE from DUNE.
>>>>>
>>>>> Weirdness... I'll come back to this later.
>>>>>
>>>>> K
>>>>>
>>>>> -----Original Message-----
>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>> Sent: 14 January 2026 17:09
>>>>> To: hecnet(a)lists.dfupdate.se
>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>
>>>>> Maybe I should make a few more comments.
>>>>> There might definitely be something VMS specific in your
>>>>> observations.I wouldn't know.
>>>>>
>>>>> With TCP/IP, when data is sent, it's going to be in the queue
>>>>> and be delivered even if the sending process closes, finishes
>>>>> and goesaway.
>>>>> The end-of-file is queued into the sending stream after all the
>>>>> data that was sent.
>>>>>
>>>>> With DECnet, the underlying transport is always record
>>>>> oriented.
>>>>> Anything that looks like anything else is always just trying to
>>>>> hide that fact. And when you send something, you'll get an
>>>>> indication when the send is completed, at which point it
>>>>> shouldn't be possible for it not to be delivered, unless
>>>>> connection have completely been lost.
>>>>> With RSX not even that is possible, since a completion of a
>>>>> send means that the receiving side actually completed the
>>>>> receive.
>>>>> It's very synchronous.
>>>>>
>>>>> If some higher level library hides all of this, then I would
>>>>> expect italso have a way of telling if all the I/O have
>>>>> completed.
>>>>>
>>>>> Basically, server side accepts the connection, reads the single
>>>>> requestline, and then sends data until it is done, after which
>>>>> it closes the connection. There must be a way to know that the
>>>>> data is actually being delivered, so you don't cancel
>>>>> outstanding sends if they are done asynchronous.
>>>>>
>>>>> Johnny
>>>>>
>>>>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>>>>> Hum?
>>>>>> I'm not sure I get it.
>>>>>>
>>>>>> The client does a connection to the server. Sends a single
>>>>>> line.
>>>>>> Reads until it gets an end-of-file/connection-closed
>>>>>> indication when readind, at which point the server is already
>>>>>> gone, and the client canfinish.
>>>>>>
>>>>>> Where are you thinking/seeing that you need to wait for
>>>>>> anything?
>>>>>>
>>>>>> Johnny
>>>>>>
>>>>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>>>>> There's a simplistic version currently running on DUNE::
>>>>>>> I've noticed a few problems with it.
>>>>>>>
>>>>>>> For transparent DECnet I/O where channels are assigned and
>>>>>>> I/O happens as though each end is local, DECnet seems to
>>>>>>> suggest that the receiver (finger client in this case)
should
>>>>>>> disconnect when it has received what it expects to receive.
>>>>>>> This expectation should be part of the client/server
protocol
>>>>>>> such as an explicit end of data record.
>>>>>>> In the TCP/IP world, a finger server disconnects when
it's
>>>>>>> finished sending all that it wants to send. There's no
>>>>>>> explicit high level protocol stating end of data received by
>>>>>>> the client other than a receive succeeding with zero length
>>>>>>> response.
>>>>>>>
>>>>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>>>>> DECnet finger server will $ASSIGN to the incoming
connection,
>>>>>>> do a few $QIOWs and do a $DASSGN, which is quite
destructive,
>>>>>>> including cancelling all pending I/O requests. You would
>>>>>>> think that a $QIOW would return when the I/O completes end
to
>>>>>>> end but it seems to complete when DECnet takes over.
>>>>>>> Consequently, on slow links, a $DASSGN could cause DECnet
not
>>>>>>> to transmit data that's still pending. This is currently
>>>>>>> happening ona comparatively slow link between DUNE and and a
>>>>>>> host in Australia.
>>>>>>>
>>>>>>> The non-transparent case, where a lot more of the DECnet
>>>>>>> handshaking is exposed, offers a synchronous disconnect
which
>>>>>>> is initiated with a $QIOW. The server would send this and
the
>>>>>>> client would then have to react as though it had received an
>>>>>>> EOF. In other words, it seems that both ends need to be non-
>>>>>>> transparent.
>>>>>>>
>>>>>>> A lot of this may be peculiar to DECnet on VMS which tries
to
>>>>>>> hide much of the complexity unless you go for full
>>>>>>> non-transparency. Even then you can treat the connection as
>>>>>>> record-orientated even though it's not like that
underneath,
>>>>>>> and listen for events on the attached mailbox device.
>>>>>>>
>>>>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a
series
>>>>>>> of $QIOW(write), then a wait for an unknown amount of time
>>>>>>> before $DASSGN.
>>>>>>> Judging by some of the behaviour I've seen with user
DECnet
>>>>>>> tasks implemented by command procedures, that appears to be
>>>>>>> what VMS does sometimes.
>>>>>>>
>>>>>>> Is this what networking used to be like? Weird?
>>>>>>>
>>>>>>> K
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>>>> Sent: 14 January 2026 13:42
>>>>>>> To: hecnet(a)lists.dfupdate.se
>>>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>>>
>>>>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>>>>> Regarding finger for VMS, I have no real recollection of
how
>>>>>>>> we used to gather idle time for the 'job'
(collection of
>>>>>>>> process and subprocesses attached to the terminal).
>>>>>>>> Back in the university days, some of the VMS systems had
a
>>>>>>>> small fixed number of lines connected to the Gandalf (a
>>>>>>>> terminal
>>>>>>>> server/switch) so we had to do something to prevent
users
>>>>>>>> hogging the lines.
>>>>>>>> I think we used to enumerate allocated terminal class
>>>>>>>> devices every
>>>>>>>> 10 minutes and remember their completed I/O counts. If
the
>>>>>>>> count hadn't changed since the last sweep, then the
user was
>>>>>>>> logged out.
>>>>>>>> There may have been other considerations involving CPU
time,
>>>>>>>> etc.
>>>>>>>> but as I said the details are permanently paged out of
my
>>>>>>>> memory.I don't think the above would be any good
really for
>>>>>>>> finger idle time.
>>>>>>>
>>>>>>> I think this is one of those topics which I would just leave
>>>>>>> as implementation specific. It depends on what the OS does,
>>>>>>> and what can be easily extracted. Just present users with
>>>>>>> whatever information makes sense. THe finger protocol is
>>>>>>> meant for human consumption, so there are no hard
>>>>>>> requirements on what information is provided, or in which
>>>>>>> form.
>>>>>>>
>>>>>>> "Idle" in RSX is defined slightly different than in
Unix or
>>>>>>> VMS.
>>>>>>> I can tell you that much. But I can only report what RSX
>>>>>>> thinkshere.
>>>>>>> (If you were to hit enter on a terminal in RSX, you are
still
>>>>>>> considered idle.
>>>>>>> No activity happened.)
>>>>>>>
>>>>>>>> I have the beginnings of a DECnet finger server for VMS
in
>>>>>>>> Pascal, which will produce summary information for
who's
>>>>>>>> logged, when, what they're doing and where
they're doing it
>>>>>>>> from and also specific information for matched users if
>>>>>>>> supplied as a parameter, including plan and the
read/unread
>>>>>>>> status of their mailbox. I won't do "poor
man's routing"
>>>>>>>> and I'm tempted to restrict the breadth of partial
searches
>>>>>>>> to a complete username and/or complete word components of
a
>>>>>>>> user's real name.
>>>>>>>
>>>>>>> This is also something I'd happily leave to each
>>>>>>> implementation.
>>>>>>> PMR or not - up to each implementation. Just give some sort
>>>>>>> of error if you don't allow it. Same with user matching.
>>>>>>>
>>>>>>>> It'll fit into the framework I have for a DECnet
server that
>>>>>>>> declares itself as an object and remains running,
handling
>>>>>>>> multiple requests... but who wants a finger server
hanging
>>>>>>>> around?!
>>>>>>>> I don't, so the initial version will be instantiated
on
>>>>>>>> incoming request.
>>>>>>>
>>>>>>> That's how I do it in RSX, and that's how Unixes does
it as
>>>>>>> well.I think it would be the most sensible way to do it.
>>>>>>>
>>>>>>>> It'll be on DUNE's default DECnet account if/when
I finish
>>>>>>>> it.
>>>>>>>
>>>>>>> Would be nice to see it in operation.
>>>>>>>
>>>>>>> Johnny
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> sendan email to hecnet-leave(a)lists.dfupdate.se
>>>>> _______________________________________________
>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>>>> sendan 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
>>>> _______________________________________________
>>>> 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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se 
10:41 p.m.
On Mon, Jan 19, 2026 at 7:10 AM Terri Kennedy <terri-hecnet(a)glaver.org>
wrote:
[snip]
If you're running something older than V5.8-90
on VAX, let me know
and I'll get you a kit.
$ pasc/ver
HP Pascal VAX V6.0-114 on OpenVMS VAX V7.3
I've put a ZIP file comtaining the VMSINSTAL kit on HECnet at
VOGON::[.PASCAL060]PASCAL-VAX-V60-114.ZIP
Tony
--
Tony Nicholson <tony.nicholson(a)computer.org>
11:12 p.m.
On 2026-01-18 16:41, Tony Nicholson wrote:
On Mon, Jan 19, 2026 at 7:10 AM Terri Kennedy
<terri-hecnet(a)glaver.org>
wrote:
[snip]
Got it, thanks! Do you have any other newer product kits?
I have:
ADA035
BASIC039
BLS32047
CC064
CMS039
COBOL057
CRT060
CXX056
DBG060
DECSET122A
DECW$MOTIFU6012
DIA034
DOC033
DTM038
ENVMGR012
FORT066
LSE045
MMS032
MULTINET056
PASCAL060
PCA045
PLI038
PLIRTL057
SCA045
TNT030
VAXAUDS01_073
VAXDRIV03_073
VAXDTSS01_073
VAXDWMOTMUP01_073
VAXF11X01_073
VAXF11X02_073
VAXMAIL01_073
VAXMIME01_073
VAXMONT01_073
VAXMOUN01_073
VAXMSCP01_073
VAXRMS01_073
VAXRPC02_073
VAXSHAD02_073
VAXSHAD03_073
VAXSMGRMUP01_073
VAXSYS01_073
VAXSYSL01_073
VAXTZ01_073
VAXTZ02_073
VAXVMSMUP01_073
Do you need any of those? I also have a complete set of
DECserver stuff at https://www.glaver.org/DECserver
The VAX* stuff at the bottom of the above list _should_
be all the patches for VMS V7.3, even the ones after they
moved behind HP's paywall.
If you're running something older than
V5.8-90 on VAX, let me know
and I'll get you a kit.
$ pasc/ver
HP Pascal VAX V6.0-114 on OpenVMS VAX V7.3
I've put a ZIP file comtaining the VMSINSTAL kit on HECnet at
VOGON::[.PASCAL060]PASCAL-VAX-V60-114.ZIP
19 Jan
19 Jan
12:15 a.m.
On Mon, Jan 19, 2026 at 9:13 AM Terri Kennedy <terri-hecnet(a)glaver.org>
wrote:
[snip]
Got it, thanks! Do you have any other newer product kits?
I have:
Terri et al,
Most of the latest VAX kits I have are from the HP OpenVMS VAX Consolidated
Distribution CD-ROM Set dated Dec-2007. There's images online for them at
https://vaxhaven.com/CD_Image_Archive
In addition, I have all the patches you mention from back when the Hobbyist
program
gave access to the Software Products Library online and via my employer's
access to this behind the paywall via their maintenance agreements with HPE.
The PASCAL V6.0-114 came from HPE software support when it was in India.
I also have DCPS V2.7 as a PCSI kit for VAX for printing to newer (now
ancient)
HP LaserJet series and other Postscript printers (like my home office
Fuji-Xerox
DocuPrint M355df laser). I'll put this and the install guide at
VOGON::[.DCPS027]
Martin Vorlaender's site at https://de.openvms.org/martinv/VMS_CD_KITS.html
is a
good reference to locating products on the various Software Products
library update
CD-ROMs.
My Alpha and x86_64 systems now run VSI OpenVMS with Ambassador licenses,
hence I have access to all their latest products and patches via their
download portal.
Tony
--
Tony Nicholson <tony.nicholson(a)computer.org>
18 Jan
18 Jan
11:21 p.m.
Thanks Tony,
I’ll do some experiments with record initialisation tomorrow.
K
From: Tony Nicholson [mailto:tony.nicholson@computer.org]
Sent: 18 January 2026 21:41
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
On Mon, Jan 19, 2026 at 7:10 AM Terri Kennedy
<terri-hecnet@glaver.org<mailto:terri-hecnet@glaver.org>> wrote:
[snip]
If you're running something older than V5.8-90 on VAX, let me know
and I'll get you a kit.
$ pasc/ver
HP Pascal VAX V6.0-114 on OpenVMS VAX V7.3
I've put a ZIP file comtaining the VMSINSTAL kit on HECnet at
VOGON::[.PASCAL060]PASCAL-VAX-V60-114.ZIP
Tony
--
Tony Nicholson
<tony.nicholson@computer.org<mailto:tony.nicholson@computer.org>>
11:25 p.m.
The release notes for 6.0 don’t mention the issue specifically. Fingers crossed that it
may be fixed as a consequence
of something else.
K
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 18 January 2026 22:22
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
Thanks Tony,
I’ll do some experiments with record initialisation tomorrow.
K
From: Tony Nicholson [mailto:tony.nicholson@computer.org]
Sent: 18 January 2026 21:41
To: The Hobbyist DECnet mailing list
<hecnet@lists.dfupdate.se<mailto:hecnet@lists.dfupdate.se>>
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
On Mon, Jan 19, 2026 at 7:10 AM Terri Kennedy
<terri-hecnet@glaver.org<mailto:terri-hecnet@glaver.org>> wrote:
[snip]
If you're running something older than V5.8-90 on VAX, let me know
and I'll get you a kit.
$ pasc/ver
HP Pascal VAX V6.0-114 on OpenVMS VAX V7.3
I've put a ZIP file comtaining the VMSINSTAL kit on HECnet at
VOGON::[.PASCAL060]PASCAL-VAX-V60-114.ZIP
Tony
--
Tony Nicholson
<tony.nicholson@computer.org<mailto:tony.nicholson@computer.org>>
11:16 p.m.
I am indeed using Pascal V5.8-90. I have always found Pascal easier to use for system
services stuff etc.. A few decades
ago, I might have considered Bliss32 but the fluency has gone. A bit of Ada '83
fluency has gone too, so
Pascal it remains. I don't like C or Fortran.
I'll tidy the code up, make it act as both client and server depending on whether the
mode is 'network' or not. The
poor man's routing is easy enough.
Interesting thing about VAX Ada is opening a file on sys$net using TEXT_IO. Unlike Pascal,
once opened as mode IN_FILE,
to get the finger parameter from the client side, the Ada RTL won't permit a change of
mode to OUT_FILE, in order to
send the client the data requested. So the sequence which works in Pascal:
open(f,'sys$net',old);
reset(f);
readln(f,finger_param);
rewrite(f);
writeln('OpenVMS',.....);
....
close(f);
fails in Ada at the rewrite() equivalent.
K
-----Original Message-----
From: Terri Kennedy [mailto:terri-hecnet@glaver.org]
Sent: 18 January 2026 20:11
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger
Setup Documentation (New)
On 2026-01-17 11:35, Keith Halewood wrote:
I posted this on Discord:
Some interesting things with VMS Pascal (VAX vs. X86_64).
I've been playing with a DECnet version of Finger for VMS over the
past few days and got caught by some issues that affect the code
generated by the (last) VAX version of Pascal but have been fixed by
the (current) X86_64 version.
Are you committed to Pascal, or would you consider C or Fortrqn?
Portability isn't an issue as Finger grovels around in VMS innards to get the data it
reports, so it's pretty much whichever language implements direct access to $QIO[W] in
the manner you find easiest.
does not and works correctly. The effects of
/NOOPTIMIZE on the first
example merely increases the subtlety of the runtime corruption.
I've converted every instance of the first syntax in my code (JPI, DVI
item lists mostly) to the 2nd and things are fine with DECnet tasks
and standard RMS I/O.
I don't suppose VSI care about VAX compilers :(
I believe the Alpha and Itanium compilers use the GEM back-end (and also the GEM
front-end). I don't know what VAX is doing. VAX did get DEC C which replaced VAX C
(for the most part) so some GEM made it to VAX.
My understanding is that the VSI compilers for x86-64 use the GEM front-end were
appropriate, a shim, and a very modified LLVM back-end.
But that's just from what I've heard anecdotally.
I just took a look and I have PASCAL V5.8-90 on the VAX and PASCAL
V6.1-116-48H61 (that's a mouthful) on Alpha. My VAX/VMS patch collec- tion is limited
to VMS patches, not layered products, unfortunately.
If you're running something older than V5.8-90 on VAX, let me know and I'll get
you a kit.
So now I can complete the finger server without losing my mind with:
( f defined as f : text )
open(f,'sys$net',old);
reset(f);
readln(f,searchstring);
rewrite(f);
writeln(f,'finger output.... blah....'); close(f);
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 16 January 2026 11:12
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
By the way. Since you're using RMS. Why not use $CLOSE instead of
$DASSGN? Seems like that would be the natural way.
Johnny
On 16/01/2026 11.44, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
Client side is really easy. You connect, send a
line, you read until
the server close the connection. That's it. Exactly which "mechanisms"
are used is up to each implementation. The whole "transparent" thing
seems rather VMS-specific.
Server side should not be a problem either. Accept the connection,
read a line, send lines, close. Just make sure the data have been
sent before you close. Exactly how you ensure that depends on the OS,
and it seems VMS with RMS does not give you proper control over that,
so you should do it some other way. VMS obviously do have the
non-transparent API, which do allow proper control.
I won't try to give the exact steps you should do in VMS. I'll just
say how it should behave from a network point of view. And I know
exactly how to achieve that in RSX...
Johnny
On 16/01/2026 11.30, Keith Halewood wrote:
_______________________________________________
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
In which case, at some point, I'll go
non-transparent. Here's what
I'm hoping.
The caller (client) can do transparent or non-transparent.
The task (server) can do non-transparent, $QIO a sync'd DEACCESS to
theclient.
The caller will/should interpret this as EOF in the transparent case
(or receive a message in its attached mailbox) and close the channel.
The task will/should receive a MSG$_DISCON in the mailbox attached
to the channel.
The task can then do a $DASSGN.
I'll see what I can do.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 12:44
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
I think doing this using RMS will be a part of your headache. If you
were to explicitly do the calls to the network functions, you'd be
happier...
Johnny
On 15/01/2026 13.00, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
I knew it was brutal, yet that's what the
documentation states
(other than a client-initiated closure) as a way of closing the
channel.
Anyway, I decided to let RMS handle it all by using Pascal's text
fileI/O, essentially:
open() on 'sys$net', reset() before readln(), then rewrite() before
a series of writeln()s then a close().
Works fine on x86_64 pascal - including the handling of EOF.
Fails on the first writeln() with an access violation with default
optimisation on VAX, gets further with no optimisation and
corrupted output.
I might look at the object code produced (VAX) at some point, when
I stop crying :) I know for a fact that there are some bugs in code
generation when you do whole record layout initialisation, ie.
$GETJPI lists,etc..
We used to make fun of people who blamed the compiler for problems
withtheir code.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 15 January 2026 02:00
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible
re-post) and Tops-20 Finger Setup Documentation (New)
By the way, reading through the VMS manual I note two things:
$DASSIGN is basically cancelling any outstanding I/O, and aborts
the link quite abruptly. But with the problems you describe, I'm
wondering if you are using $QIO and not $QIOW to send messages?
But honestly, you should really be using the non-transparent
functionality, and do a synchronous disconnect, which will allow
all outstanding I/O to complete before the connection is closed.
Johnny
On 2026-01-15 02:42, Johnny Billquist wrote:
> I think you missed that it all came out as a single line. :-)
>
> As far as "privileged" goes... In RSX objects as such don't carry
> any information about privilege, but my finger task that gets
> invoked have privileges, because there is no way for normal
> programs to pull out some of the information needed.
>
> Johnny
>
> On 2026-01-15 00:07, Keith Halewood wrote:
>> I think you caught it before I'd reinstalled the .exe privileged.
>> There's no way I'm creating a privileged object for it.... and I
>> don't think the DECnet object privilege settings work like one
>> might expect anyway.
>>
>> Incidentally, from
>> https://docs.vmssoftware.com/vsi-openvms-decnet-
>> networking-manual/#SEC_ERROR_REPORT (2nd paragraph)
>>
>> Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi-
>> openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES
>>
>> Doesn't bode well.
>>
>> K
>>
>>
>> -----Original Message-----
>> From: Johnny Billquist [mailto:bqt@softjar.se]
>> Sent: 14 January 2026 21:28
>> To: hecnet(a)lists.dfupdate.se
>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>> re-post) and Tops-20 Finger Setup Documentation (New)
>>
>> Also, FYI:
>>
>> .fin dune::
>> [DUNE::]
>> OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime 31
>> 06:59:20Nousers logged in.(end) .
>>
>>
>> Johnny
>>
>>
>> On 2026-01-14 22:25, Johnny Billquist wrote:
>>> There must be a way to wait for the I/O to complete before you
>>> deassign/ disconnect/close...
>>>
>>> Johnny
>>>
>>> On 2026-01-14 20:05, Keith Halewood wrote:
>>>> I've put a 4 second delay between the last $QIOW and the
>>>> $DASSGN.
>>>> It's not brilliant... but more/most/all gets through now.
>>>> The $DASSGN is brutal.
>>>>
>>>> K
>>>>
>>>> -----Original Message-----
>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>> Sent: 14 January 2026 17:49
>>>> To: hecnet(a)lists.dfupdate.se
>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>
>>>> Another data point:
>>>>
>>>> .set /host
>>>> Host=MIM RSX-11M-PLUS V4.6 BL87mP .fin dune::
>>>> [DUNE::]
>>>>
>>>> .
>>>>
>>>>
>>>> So I'm not getting anything at all. :-)
>>>>
>>>> Johnny
>>>>
>>>> On 14/01/2026 18.28, Keith Halewood wrote:
>>>>> I've put an explicit '(end)' line on the output from
DUNE's
>>>>> finger server.
>>>>> From GUARD, a call to DUNE's finger does notshow the last
>>>>> user's record or '(end)'
>>>>>
>>>>> Oh, that's interesting and confusing:
>>>>>
>>>>> GUARD is X86_64 VMS and in Australia.
>>>>> BUZZEL is X86_64 and on the same LAN as DUNE.
>>>>> Both are not showing the last two records of output from
>>>>> DUNE's fingerserver.
>>>>> I thought it might have been a VMS version issue but....
>>>>> TUPILE is VAX and on the same LAN as DUNE and is displaying
>>>>> even less.
>>>>> In short, it seems I only get a complete output when I'm
>>>>> calling DUNE from DUNE.
>>>>>
>>>>> Weirdness... I'll come back to this later.
>>>>>
>>>>> K
>>>>>
>>>>> -----Original Message-----
>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>> Sent: 14 January 2026 17:09
>>>>> To: hecnet(a)lists.dfupdate.se
>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>
>>>>> Maybe I should make a few more comments.
>>>>> There might definitely be something VMS specific in your
>>>>> observations.I wouldn't know.
>>>>>
>>>>> With TCP/IP, when data is sent, it's going to be in the queue
>>>>> and be delivered even if the sending process closes, finishes
>>>>> and goesaway.
>>>>> The end-of-file is queued into the sending stream after all
>>>>> the data that was sent.
>>>>>
>>>>> With DECnet, the underlying transport is always record
>>>>> oriented.
>>>>> Anything that looks like anything else is always just trying
>>>>> to hide that fact. And when you send something, you'll get an
>>>>> indication when the send is completed, at which point it
>>>>> shouldn't be possible for it not to be delivered, unless
>>>>> connection have completely been lost.
>>>>> With RSX not even that is possible, since a completion of a
>>>>> send means that the receiving side actually completed the
>>>>> receive.
>>>>> It's very synchronous.
>>>>>
>>>>> If some higher level library hides all of this, then I would
>>>>> expect italso have a way of telling if all the I/O have
>>>>> completed.
>>>>>
>>>>> Basically, server side accepts the connection, reads the
>>>>> single requestline, and then sends data until it is done,
>>>>> after which it closes the connection. There must be a way to
>>>>> know that the data is actually being delivered, so you don't
>>>>> cancel outstanding sends if they are done asynchronous.
>>>>>
>>>>> Johnny
>>>>>
>>>>> On 14/01/2026 18.00, Johnny Billquist wrote:
>>>>>> Hum?
>>>>>> I'm not sure I get it.
>>>>>>
>>>>>> The client does a connection to the server. Sends a single
>>>>>> line.
>>>>>> Reads until it gets an end-of-file/connection-closed
>>>>>> indication when readind, at which point the server is already
>>>>>> gone, and the client canfinish.
>>>>>>
>>>>>> Where are you thinking/seeing that you need to wait for
>>>>>> anything?
>>>>>>
>>>>>> Johnny
>>>>>>
>>>>>> On 14/01/2026 17.58, Keith Halewood wrote:
>>>>>>> There's a simplistic version currently running on
DUNE::
>>>>>>> I've noticed a few problems with it.
>>>>>>>
>>>>>>> For transparent DECnet I/O where channels are assigned and
>>>>>>> I/O happens as though each end is local, DECnet seems to
>>>>>>> suggest that the receiver (finger client in this case)
>>>>>>> should disconnect when it has received what it expects to
receive.
>>>>>>> This expectation should be part of the client/server
>>>>>>> protocol such as an explicit end of data record.
>>>>>>> In the TCP/IP world, a finger server disconnects when
it's
>>>>>>> finished sending all that it wants to send. There's no
>>>>>>> explicit high level protocol stating end of data received by
>>>>>>> the client other than a receive succeeding with zero length
>>>>>>> response.
>>>>>>>
>>>>>>> Even with explicit $QIOW (waiting for I/O to complete), a
>>>>>>> DECnet finger server will $ASSIGN to the incoming
>>>>>>> connection, do a few $QIOWs and do a $DASSGN, which is quite
>>>>>>> destructive, including cancelling all pending I/O requests.
>>>>>>> You would think that a $QIOW would return when the I/O
>>>>>>> completes end to end but it seems to complete when DECnet
takes over.
>>>>>>> Consequently, on slow links, a $DASSGN could cause DECnet
>>>>>>> not to transmit data that's still pending. This is
currently
>>>>>>> happening ona comparatively slow link between DUNE and and a
>>>>>>> host in Australia.
>>>>>>>
>>>>>>> The non-transparent case, where a lot more of the DECnet
>>>>>>> handshaking is exposed, offers a synchronous disconnect
>>>>>>> which is initiated with a $QIOW. The server would send this
>>>>>>> and the client would then have to react as though it had
>>>>>>> received an EOF. In other words, it seems that both ends
>>>>>>> need to be non- transparent.
>>>>>>>
>>>>>>> A lot of this may be peculiar to DECnet on VMS which tries
>>>>>>> to hide much of the complexity unless you go for full
>>>>>>> non-transparency. Even then you can treat the connection as
>>>>>>> record-orientated even though it's not like that
underneath,
>>>>>>> and listen for events on the attached mailbox device.
>>>>>>>
>>>>>>> I really don't feel like doing $ASSIGN, $QIOW(read), a
>>>>>>> series of $QIOW(write), then a wait for an unknown amount of
>>>>>>> time before $DASSGN.
>>>>>>> Judging by some of the behaviour I've seen with user
DECnet
>>>>>>> tasks implemented by command procedures, that appears to be
>>>>>>> what VMS does sometimes.
>>>>>>>
>>>>>>> Is this what networking used to be like? Weird?
>>>>>>>
>>>>>>> K
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Johnny Billquist [mailto:bqt@softjar.se]
>>>>>>> Sent: 14 January 2026 13:42
>>>>>>> To: hecnet(a)lists.dfupdate.se
>>>>>>> Subject: [HECnet] Re: DECnet Finger Specification (Possible
>>>>>>> re-post) and Tops-20 Finger Setup Documentation (New)
>>>>>>>
>>>>>>> On 14/01/2026 14.36, Keith Halewood wrote:
>>>>>>>> Regarding finger for VMS, I have no real recollection of
>>>>>>>> how we used to gather idle time for the 'job'
(collection
>>>>>>>> of process and subprocesses attached to the terminal).
>>>>>>>> Back in the university days, some of the VMS systems had
a
>>>>>>>> small fixed number of lines connected to the Gandalf (a
>>>>>>>> terminal
>>>>>>>> server/switch) so we had to do something to prevent users
>>>>>>>> hogging the lines.
>>>>>>>> I think we used to enumerate allocated terminal class
>>>>>>>> devices every
>>>>>>>> 10 minutes and remember their completed I/O counts. If
the
>>>>>>>> count hadn't changed since the last sweep, then the
user
>>>>>>>> was logged out.
>>>>>>>> There may have been other considerations involving CPU
>>>>>>>> time, etc.
>>>>>>>> but as I said the details are permanently paged out of my
>>>>>>>> memory.I don't think the above would be any good
really for
>>>>>>>> finger idle time.
>>>>>>>
>>>>>>> I think this is one of those topics which I would just leave
>>>>>>> as implementation specific. It depends on what the OS does,
>>>>>>> and what can be easily extracted. Just present users with
>>>>>>> whatever information makes sense. THe finger protocol is
>>>>>>> meant for human consumption, so there are no hard
>>>>>>> requirements on what information is provided, or in which
>>>>>>> form.
>>>>>>>
>>>>>>> "Idle" in RSX is defined slightly different than in
Unix or
>>>>>>> VMS.
>>>>>>> I can tell you that much. But I can only report what RSX
>>>>>>> thinkshere.
>>>>>>> (If you were to hit enter on a terminal in RSX, you are
>>>>>>> still considered idle.
>>>>>>> No activity happened.)
>>>>>>>
>>>>>>>> I have the beginnings of a DECnet finger server for VMS
in
>>>>>>>> Pascal, which will produce summary information for
who's
>>>>>>>> logged, when, what they're doing and where
they're doing it
>>>>>>>> from and also specific information for matched users if
>>>>>>>> supplied as a parameter, including plan and the
read/unread
>>>>>>>> status of their mailbox. I won't do "poor
man's routing"
>>>>>>>> and I'm tempted to restrict the breadth of partial
searches
>>>>>>>> to a complete username and/or complete word components of
a
>>>>>>>> user's real name.
>>>>>>>
>>>>>>> This is also something I'd happily leave to each
>>>>>>> implementation.
>>>>>>> PMR or not - up to each implementation. Just give some sort
>>>>>>> of error if you don't allow it. Same with user
matching.
>>>>>>>
>>>>>>>> It'll fit into the framework I have for a DECnet
server
>>>>>>>> that declares itself as an object and remains running,
>>>>>>>> handling multiple requests... but who wants a finger
server
>>>>>>>> hanging around?!
>>>>>>>> I don't, so the initial version will be instantiated
on
>>>>>>>> incoming request.
>>>>>>>
>>>>>>> That's how I do it in RSX, and that's how Unixes does
it as
>>>>>>> well.I think it would be the most sensible way to do it.
>>>>>>>
>>>>>>>> It'll be on DUNE's default DECnet account if/when
I finish
>>>>>>>> it.
>>>>>>>
>>>>>>> Would be nice to see it in operation.
>>>>>>>
>>>>>>> Johnny
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> sendan email to hecnet-leave(a)lists.dfupdate.se
>>>>> _______________________________________________
>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe
>>>>> sendan 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
>>>> _______________________________________________
>>>> 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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
15 Jan
15 Jan
12:24 a.m.
On 2026-01-14 12:28, Keith Halewood wrote:
I've put an explicit '(end)' line on the
output from DUNE's finger
server.
From GUARD, a call to DUNE's finger does not show the last user's
record or '(end)'
Oh, that's interesting and confusing:
GUARD is X86_64 VMS and in Australia.
BUZZEL is X86_64 and on the same LAN as DUNE.
Both are not showing the last two records of output from DUNE's finger
server.
I thought it might have been a VMS version issue but....
TUPILE is VAX and on the same LAN as DUNE and is displaying even less.
In short, it seems I only get a complete output when I'm calling DUNE
from DUNE.
Weirdness... I'll come back to this later.
I'm late to the party, but when I do a finger to DUNE:: from
my RSTS/E implementation, I get:
SPC11D::$ fing @dune
[DUNE.DECnet]
OpenVMS V7.3 on node DUNE 14-JAN-2026 23:09:20.70 Uptime 31 08:42:04No
users logged in.(end)
<long pause>
: link failed]
?FINGER - Link timeout for node DUNE.
OTOH, when the same client asks VMS DECnet node SPCVXA::,
I get:
SPC11D::$ fing @spcvxa
[SPCVXA.DECnet]
SPC Memorial VAXcluster
SPCVXA VAX 8650, OpenVMS V7.3, Wed, 14-Jan-2026 18:15, 0 Users, 0 Batch
Uptime 10 17:02, since Sun, 4-Jan-2026 01:12, Load: 0.00 0.00 0.00
PID Username Program Term Login CPU Location
TT Type
20E0011E SYSTEM $ OPA0: 01:14 0:11 System Console
VT320
Note that I have some non-compliant* parts in my RSTS/E
and VMS Finger implementations which means you may get some
odd output if you try to Finger those nodes, as well as some
local extensions (leading @ is accepted as well as trailing
::).
* Non-compliant with the modern (2024) informal DECnet Finger
spec. "Historic" clients always sent "FINGER " before the user's
request, apparently so a "catch-all" DECnet object could send
requests to the appropriate protocol handler. I'm in the pro-
cess of fixing this (in RSTS/E Finger first, by not sending the
"FINGER " prefix and silently discarding it on receipt. But this
is behind a bunch of paying work and a 2BSD project.
12:54 a.m.
On 2026-01-14 08:41, Johnny Billquist wrote:
On 14/01/2026 14.36, Keith Halewood wrote:
My RSTS/E Finger server allows customization of this via
its configuration file's "W" option:
! W - The minimum number of non-wildcard characters allowed for lookups.
A
! value of 0 will allow any match, 1 needs at least one non-wild
char-
! acter, etc.
If you don't meet the setting, you get "?No such user"
unless your request exactly matches a username.
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it
from and also specific information for matched users if supplied as a
parameter, including plan and the read/unread status of their mailbox.
I won't do "poor man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real
name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
12:48 a.m.
On 2026-01-14 08:36, Keith Halewood wrote:
Regarding finger for VMS, I have no real recollection
of how we used
to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
The current DECUS VMS finger uses the last input from the
terminal (or maybe last input our output, I'd have to check).
This data isn't maintained for a lot of remote (network)
terminal sessions by default, but Brian Schenkenbrger wrote
a handler that gets loaded during boot to enable it for those
devices.
11 Jan
11 Jan
2:06 a.m.
On 2026-01-10 17:19, Johnny Billquist wrote:
On 2026-01-10 23:08, Terri Kennedy 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.
Example: Getting fancy ("Escaping" from
HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
I find it really weird to use that kind of syntax, and it probably
will create a mess if you involve some other TCP/IP based finger
server in such a line.
In my RSX implementation, you would write
FINGER SPC11D::@server.glaver.org The RFC for finger on TCP/IP really states that hosts
should be
processed right to left, and the username is at the left end. So you
can do
finger bqt@mim.softjar.se@foo.bar.host.net
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.
Which would contact foo.bar.host.net from the local
machine, and
request bqt(a)mim.softjar.se as the username to that host, which would
then go and contact mim.softjar.se, just requesting information for
user "bqt".
If you pass it something with :: as a separation between hosts and/or
usernames, a RFC compliant finger server will not do what you would
hope for.
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.
I will obviously not force anyone to rewrite any
implementation, but
be aware that a proper TCP/IP RFC compliant finger server is
incompatible with this form host host name chains.
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.
12:24 a.m.
Hi Terry,
Hey, that is some pretty cool stuff! Very deluxe! While my initial
attempts didn't lead to thoroughly joyful experience, I at least got
some error messages, so that's a start.
The DECnet Finger protocol as defined sets the USER attribute to the
local (Tops-20) user so the remote system can log it. It also sets the
optional parameter to STREAM in case the remote system can support that,
but otherwise, it is ignored. Here is what I got with the constructed
connection string which should be understandable, given the above
The first attempt is me on a Tops-20 machine (VENTI2::) saying I can do
streaming, viz: DCN:SPCVXA-117;USER:SLOGIN;DATA:STREAM, which yielded:
FINGER>spcvxa::
?STREAM: Access not permitted, Device or data error
The next attempt was obviously not to send the STREAM parameter, viz:
DCN:SPCVXA-117;USER:SLOGIN, which got:
FINGER>spcvxa::
?Access not permitted, Device or data error
Finally, I tried not setting any attributes at all, viz: DCN:SPCVXA-117,
which got:
FINGER>spcvxa::
%FINGER-E-OOPS, error parsing 'FINGERNAME'
%FINGER-E-OOPS, error parsing 'IAM'
%FINGER-E-OOPS, error parsing 'INTERACTIVE'
%FINGER-E-OOPS, error parsing 'BATCH'
%FINGER-E-OOPS, error parsing 'SUBPROCESS'
%FINGER-E-OOPS, error parsing 'NETWORK'
%FINGER-E-OOPS, error parsing 'SYSTEM'
%FINGER-E-OOPS, error parsing 'ALL'
%FINGER-E-OOPS, error parsing 'NETHELP'
%FINGER-E-OOPS, error parsing 'HELP'
%FINGER-E-EXLIMIT, Message limit exceeded, aborting.
%FINGER-E-OOPS, unwind currently in progress
%FINGER-E-EXLIMIT, Message limit exceeded, aborting.
The first two attempts appeared to have been rejected out of hand, so
those are Tops-20 error messages. The third attempt appears to have
succeeded in connecting, but then produced a bunch of what I see are
application level VMS type error messages.
------------------------------------------------------------------------
On 1/10/26 5:08 PM, Terri Kennedy wrote:
SPCVXA::, SPCVXB:: and SPC11D:: should all have working (ish) Finger
servers. The first two are VAX/VMS V7.3 systems in a
cluster with DECUS Finger (as maintained by me). SPC11D: is a RSTS/E
V10.1 system with a Finger server written from scratch by me.
If anyone really wants it, I could bring up a PC (SPCPCA::, not a
known HECnet node) running MS-DOS Finger using PCSA/
DECnet/DOS, Pathworks, or whatever nom de jour it was using back
then). The output is pretty boring when Finger-ing into
it, but it does implement both a full client as well as pass-thru.
Locally it just says "You are the only user, of course."
when run. That one was also written from scratch by me.
Note that the SPCxxx:: Fingers can tack on an undocumented /IAM
qualifier which I need to get around to removing. Back
when the world was a kinder, gentler place and Finger might be
restricted to within an organization, /IAM told the re-
mote host your username and nodename (nodename is needed because there
might be intermediate nodes) in order for the
remote Finger server to tell you if the user you were Fingering had
unread mail from you.
I'll be removing the generation of /IAM and will ignore any /IAM
received.
I'd like to suggest that unknown qualifiers on the received request
be silently ignored and that all implementations include support for
the /help qualifier.
Likewise, support for empty lines ("list all users") and a line with
just a username should be supported. Implementations should feel free
to generate appropriate errors if they choose to not allow listing all
users, not listing a specific user, etc.
If routing is allowed (host1::host2::user@host3:: type connections,
intermediate hosts should pass the received command line through
unchanged, even if that command line has options that the local system
doesn't understand/implement.
If you want to receive an essay, do "finger spcvxa::/help"
Some examples:
Example: SPC11D:: to SPCVXA::
$ finger spcvxa::/all
[SPCVXA.DECnet]
SPC Memorial VAXcluster
SPCVXA VAX 8650, OpenVMS V7.3, Sat, 10-Jan-2026 16:38, 0 Users, 0 Batch
Uptime 6 15:26, since Sun, 4-Jan-2026 01:12, Load: 0.00 0.00 0.00
PID Username Program Term Login CPU Location
TT Type
20E00101 <Swapper> $ System 00:00 0:00
20E0010E AUDIT$SERVER Audit_Ser System 01:13 0:00
20E00113 DECNET Netacp System 01:13 0:01
20E00114 DECNET Evl Network 01:13 0:00
20E00130 PHONE$SERVER Finger Network 16:33 0:00
20E00106 SYSTEM Csp System 01:13 0:00
20E00107 SYSTEM Configure System 01:13 0:00
20E00108 SYSTEM Lanacp System 01:13 0:00
20E0010A SYSTEM Ipcacp System 01:13 0:00
20E0010B SYSTEM Errfmt System 01:13 0:00
20E0010C SYSTEM Fileserv System 01:13 0:00
20E0010D SYSTEM Opcom System 01:13 0:00
20E0010F SYSTEM Jbc$Job_C System 01:13 0:00
20E00110 SYSTEM Qman$Queu System 01:13 0:00
20E00111 SYSTEM Security_ System 01:13 0:00
20E00112 SYSTEM Smiserver System 01:13 0:00
20E00115 SYSTEM Remacp System 01:13 0:00
20E00116 SYSTEM Server System 01:13 0:00
20E00118 SYSTEM Sshd_Mast System 01:13 0:50
20E00119 SYSTEM Ntpd System 01:13 0:00
20E0011A SYSTEM Dia Detach 01:14 1:02
20E0011C SYSTEM Latacp System 01:14 0:00
20E0011E SYSTEM $ OPA0: 01:14 0:08 System Console
VT320
$ finger spcvxa::system
[SPCVXA.DECnet]
SPCVXA OpenVMS, Sat, 10-Jan-2026 16:33
PID Username Program Term Login CPU Location
TT Type
20E0011E SYSTEM $ OPA0: 01:14 0:08 System Console
VT320
Default directory: SYS$SYSROOT:[SYSMGR]
Logged in since: Sun, 4-Jan-2026 19:51
Last non-interactive login: Sun, 4-Jan-2026 19:51
Mail: (no new mail)
Plan: (no plan file)
Examples: SPCVXB:: to SPC11D::
SPCVXB::$ f spc11d::
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Sunday, 10-Jan-1926 16:36, 8 Jobs, 63
Max.
Uptime 6 16:01:06, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
SPCVXB::$ f spc11d::terry
[SPC11D.DECnet]
SPC11D RSTS/E, Sunday, 10-Jan-1926 16:36
Job Username PPN Progrm Term Login CPU ST Location
TTType
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11 Console
VT100
Default directory: _SY0:[20,254]
Logged in since: Monday, 4-Jan-1926 01:11
Mail: (no new mail)
Plan:
Half of "The Bob & Terry Show", 1993-present
Volunteer at the LSSM (Large Scale Systems Museum), 2016-present
Volunteer at BERA (the Shore Line Trolley Museum), 2000-present
Former Senior Network Engineer, Verio NY Metro Region, 1999-2001
Official Verio Motto: "Too many databases, too few brains"
Former Operations Manager, SPC Academic Computing, 1976-1999
Official St. Peter's College Motto: "Nobody told me about this!"
Personal web page: Personal email:
http://www.glaver.org terry(a)glaver.org
Example: Getting fancy ("Escaping" from HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
[SPC11D.DECnet]
[SERVER.GLAVER.ORG via routing host SPCVAX]
[SPCVAX.DECnet]
[SERVER.GLAVER.ORG]
Unauthorized Access Strictly Prohibited
SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Sat, 10-Jan-2026 16:46, 1 User,
0 Batch
Uptime 70 00:59, since Sat, 1-Nov-2025 15:46, Load: 0.00 0.01 0.02
PID Username Program Term Login CPU Location
TT Type
0003A703 TERRY $ NTY17: 19:21 0:03 office.glaver.or
VT3xx
00034C64 TERRY $ NTY14: 00:59 0:16 bedroom.glaver.o
VT3xx
To explain that, SPCVXB opened a finger connecton to SPC11D::,
asking about server.glaver.org (the :: has to be tacked on so it isn't
treated as a username on SPC11D. SPC11D is a DECnet-only host and it
doesn't know about anything named server.glaver.org, so it kicks it to
its configured Finger router, SPCVAX:: (a cluster DECnet alias for
SPCVXA:: and SPCVXB::). SPCVAX:: speaks both DECnet and TCP/IP,
realizes that server. glaver.org is an Internet hostname and not a
DECnet node, and opens a TCP/IP Finger connection to server.glaver.org
(you can see that the transport isn't DECnet as it didn't append
".DECnet" to the host string). VMS Finger also supports a bunch of
obsolete transports, like .BITNET.
------------------------------------------------------------------------
On 2026-01-10 15:30, Thomas DeBellis wrote:
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.
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 do that later this year, I hope
.
2 a.m.
I double checked whether Tops-20 might be doing something strange by
doing finger forwarding through MIM::, viz:
FINGER>mim::"spcvxa::system"
[Fork FINGER opening DCN:MIM-117;DATA:STREAM;USERID:SLOGIN for
reading, writing]
[SPCVXA::]
%FINGER-E-OOPS, unrecognized command verb - check validity and spelling
%FINGER-E-OOPS, error parsing 'FINGERNAME'
[Etc., Etc., Etc.]
So MIM:: does the right forwarding and doesn't reject the USER and
ignores the optional DATA specification, as per protocol. Naturally, I
also signed on to MIM:: directly and tried it there, too. Same result.
Maybe your VMS finger server got into a funny state and needs to be
reset? Let me know.
On the other hand, your RSTS/E finger server seems to work like a champ,
yippee!!
FINGER>spc11d::
[Fork FINGER opening DCN:SPC11D-117;DATA:STREAM;USERID:SLOGIN for
reading, writing]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Sunday, 10-Jan-1926 19:56, 8 Jobs,
63 Max.
Uptime 6 19:21:45, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11
Console VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
------------------------------------------------------------------------
On 1/10/26 6:24 PM, Thomas DeBellis wrote:
Hi Terry,
Hey, that is some pretty cool stuff! Very deluxe! While my initial
attempts didn't lead to thoroughly joyful experience, I at least got
some error messages, so that's a start.
The DECnet Finger protocol as defined sets the USER attribute to the
local (Tops-20) user so the remote system can log it. It also sets
the optional parameter to STREAM in case the remote system can support
that, but otherwise, it is ignored. Here is what I got with the
constructed connection string which should be understandable, given
the above
The first attempt is me on a Tops-20 machine (VENTI2::) saying I can
do streaming, viz: DCN:SPCVXA-117;USER:SLOGIN;DATA:STREAM, which yielded:
FINGER>spcvxa::
?STREAM: Access not permitted, Device or data error
The next attempt was obviously not to send the STREAM parameter, viz:
DCN:SPCVXA-117;USER:SLOGIN, which got:
FINGER>spcvxa::
?Access not permitted, Device or data error
Finally, I tried not setting any attributes at all, viz:
DCN:SPCVXA-117, which got:
FINGER>spcvxa::
%FINGER-E-OOPS, error parsing 'FINGERNAME'
%FINGER-E-OOPS, error parsing 'IAM'
%FINGER-E-OOPS, error parsing 'INTERACTIVE'
%FINGER-E-OOPS, error parsing 'BATCH'
%FINGER-E-OOPS, error parsing 'SUBPROCESS'
%FINGER-E-OOPS, error parsing 'NETWORK'
%FINGER-E-OOPS, error parsing 'SYSTEM'
%FINGER-E-OOPS, error parsing 'ALL'
%FINGER-E-OOPS, error parsing 'NETHELP'
%FINGER-E-OOPS, error parsing 'HELP'
%FINGER-E-EXLIMIT, Message limit exceeded, aborting.
%FINGER-E-OOPS, unwind currently in progress
%FINGER-E-EXLIMIT, Message limit exceeded, aborting.
The first two attempts appeared to have been rejected out of hand, so
those are Tops-20 error messages. The third attempt appears to have
succeeded in connecting, but then produced a bunch of what I see are
application level VMS type error messages.
------------------------------------------------------------------------
On 1/10/26 5:08 PM, Terri Kennedy wrote:
SPCVXA::, SPCVXB:: and SPC11D:: should all have working (ish)
Finger servers. The first two are VAX/VMS V7.3 systems in a
cluster with DECUS Finger (as maintained by me). SPC11D: is a RSTS/E
V10.1 system with a Finger server written from scratch by me.
If anyone really wants it, I could bring up a PC (SPCPCA::, not a
known HECnet node) running MS-DOS Finger using PCSA/
DECnet/DOS, Pathworks, or whatever nom de jour it was using back
then). The output is pretty boring when Finger-ing into
it, but it does implement both a full client as well as pass-thru.
Locally it just says "You are the only user, of course."
when run. That one was also written from scratch by me.
Note that the SPCxxx:: Fingers can tack on an undocumented /IAM
qualifier which I need to get around to removing. Back
when the world was a kinder, gentler place and Finger might be
restricted to within an organization, /IAM told the remote host your
username and nodename (nodename is needed because there might be
intermediate nodes) in order for the
remote Finger server to tell you if the user you were Fingering had
unread mail from you.
I'll be removing the generation of /IAM and will ignore any /IAM
received.
I'd like to suggest that unknown qualifiers on the received request
be silently ignored and that all implementations include support for
the /help qualifier.
Likewise, support for empty lines ("list all users") and a line
with just a username should be supported. Implementations should feel
free to generate appropriate errors if they choose to not allow
listing all users, not listing a specific user, etc.
If routing is allowed (host1::host2::user@host3:: type connections,
intermediate hosts should pass the received command line through
unchanged, even if that command line has options that the local
system doesn't understand/implement.
If you want to receive an essay, do "finger spcvxa::/help"
Some examples:
Example: SPC11D:: to SPCVXA::
$ finger spcvxa::/all
[SPCVXA.DECnet]
SPC Memorial VAXcluster
SPCVXA VAX 8650, OpenVMS V7.3, Sat, 10-Jan-2026 16:38, 0 Users, 0 Batch
Uptime 6 15:26, since Sun, 4-Jan-2026 01:12, Load: 0.00 0.00 0.00
PID Username Program Term Login CPU Location
TT Type
20E00101 <Swapper> $ System 00:00 0:00
20E0010E AUDIT$SERVER Audit_Ser System 01:13 0:00
20E00113 DECNET Netacp System 01:13 0:01
20E00114 DECNET Evl Network 01:13 0:00
20E00130 PHONE$SERVER Finger Network 16:33 0:00
20E00106 SYSTEM Csp System 01:13 0:00
20E00107 SYSTEM Configure System 01:13 0:00
20E00108 SYSTEM Lanacp System 01:13 0:00
20E0010A SYSTEM Ipcacp System 01:13 0:00
20E0010B SYSTEM Errfmt System 01:13 0:00
20E0010C SYSTEM Fileserv System 01:13 0:00
20E0010D SYSTEM Opcom System 01:13 0:00
20E0010F SYSTEM Jbc$Job_C System 01:13 0:00
20E00110 SYSTEM Qman$Queu System 01:13 0:00
20E00111 SYSTEM Security_ System 01:13 0:00
20E00112 SYSTEM Smiserver System 01:13 0:00
20E00115 SYSTEM Remacp System 01:13 0:00
20E00116 SYSTEM Server System 01:13 0:00
20E00118 SYSTEM Sshd_Mast System 01:13 0:50
20E00119 SYSTEM Ntpd System 01:13 0:00
20E0011A SYSTEM Dia Detach 01:14 1:02
20E0011C SYSTEM Latacp System 01:14 0:00
20E0011E SYSTEM $ OPA0: 01:14 0:08 System
Console VT320
$ finger spcvxa::system
[SPCVXA.DECnet]
SPCVXA OpenVMS, Sat, 10-Jan-2026 16:33
PID Username Program Term Login CPU Location
TT Type
20E0011E SYSTEM $ OPA0: 01:14 0:08 System
Console VT320
Default directory: SYS$SYSROOT:[SYSMGR]
Logged in since: Sun, 4-Jan-2026 19:51
Last non-interactive login: Sun, 4-Jan-2026 19:51
Mail: (no new mail)
Plan: (no plan file)
Examples: SPCVXB:: to SPC11D::
SPCVXB::$ f spc11d::
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Sunday, 10-Jan-1926 16:36, 8 Jobs, 63
Max.
Uptime 6 16:01:06, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST
Location TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11
Console VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
SPCVXB::$ f spc11d::terry
[SPC11D.DECnet]
SPC11D RSTS/E, Sunday, 10-Jan-1926 16:36
Job Username PPN Progrm Term Login CPU ST
Location TTType
7 TERRY 20,254 DCL KB0: 01:10 21:35 ^C PiDP-11
Console VT100
Default directory: _SY0:[20,254]
Logged in since: Monday, 4-Jan-1926 01:11
Mail: (no new mail)
Plan:
Half of "The Bob & Terry Show", 1993-present
Volunteer at the LSSM (Large Scale Systems Museum), 2016-present
Volunteer at BERA (the Shore Line Trolley Museum), 2000-present
Former Senior Network Engineer, Verio NY Metro Region, 1999-2001
Official Verio Motto: "Too many databases, too few brains"
Former Operations Manager, SPC Academic Computing, 1976-1999
Official St. Peter's College Motto: "Nobody told me about this!"
Personal web page: Personal email:
http://www.glaver.org terry(a)glaver.org
Example: Getting fancy ("Escaping" from HECnet):
SPCVXB::$ f spc11d::server.glaver.org::
[SPC11D.DECnet]
[SERVER.GLAVER.ORG via routing host SPCVAX]
[SPCVAX.DECnet]
[SERVER.GLAVER.ORG]
Unauthorized Access Strictly Prohibited
SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Sat, 10-Jan-2026 16:46, 1
User, 0 Batch
Uptime 70 00:59, since Sat, 1-Nov-2025 15:46, Load: 0.00 0.01 0.02
PID Username Program Term Login CPU Location
TT Type
0003A703 TERRY $ NTY17: 19:21 0:03
office.glaver.or VT3xx
00034C64 TERRY $ NTY14: 00:59 0:16
bedroom.glaver.o VT3xx
To explain that, SPCVXB opened a finger connecton to SPC11D::,
asking about server.glaver.org (the :: has to be tacked on so it
isn't treated as a username on SPC11D. SPC11D is a DECnet-only host
and it doesn't know about anything named server.glaver.org, so it
kicks it to its configured Finger router, SPCVAX:: (a cluster DECnet
alias for SPCVXA:: and SPCVXB::). SPCVAX:: speaks both DECnet and
TCP/IP, realizes that server. glaver.org is an Internet hostname and
not a DECnet node, and opens a TCP/IP Finger connection to
server.glaver.org (you can see that the transport isn't DECnet as it
didn't append ".DECnet" to the host string). VMS Finger also supports
a bunch of obsolete transports, like .BITNET.
------------------------------------------------------------------------
On 2026-01-10 15:30, Thomas DeBellis wrote:
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.
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 do that later this year, I hope
.
2:36 a.m.
[For some reason, your email arrived here with odd HTML
quoting that wouldn't format properly as plain text, so
I'm just doing manual selective quoting:]
On 2026-01-10 20:00, Thomas DeBellis wrote:
On the other hand, your RSTS/E finger server seems to
work like a
champ, yippee!!
That's because I wrote that one from scratch instead
of inheriting a decade-plus-old stew where everyone
threw something into the pot. 8-}
3:04 a.m.
We've gotten pretty far off track here, dealing with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?
3:09 a.m.
You are restating part of what is in the DECnet Finger specification
that Johnny and I put together.
Have a look at it and let me know what you think. This is what the
RSX11 and Tops-20 implementations code against.
It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for anonymous
NFT.
That should be the basis for the discussion as I will be happy to keep
it up to date, but I believe it addresses most of what you refer to, below.
On 1/10/26 9:04 PM, Terri Kennedy wrote:
We've gotten pretty far off track here, dealing
with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3:50 a.m.
On 2026-01-10 21:09, Thomas DeBellis wrote:
You are restating part of what is in the DECnet Finger
specification
that Johnny and I put together.
Have a look at it and let me know what you think. This is what the
RSX11 and Tops-20 implementations code against.
It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
That should be the basis for the discussion as I will be happy to keep
it up to date, but I believe it addresses most of what you refer to,
below.
A few observations:
1) How is a request for streaming output on an otherwise-
empty request differentiated from a request for info
on a user named STREAM? I suggest /STREAM for this rea-
son.
2) I suggest allowing explicit area.node:: syntax.
3) "Application Level Routing" - neither RSTS/E nor VMS
DECnet allow HOST1::HOST2::USER syntax. There is also
the issue of passing the complete command line or edit-
ing it. If we are HOST1::, do we remove HOST1:: from
the command line before passing it along? I think so,
but this also complicates interoperability as discussed
in the following paragraph:
This also gets into DECnet / TCP/IP interoperability,
which I think should be deferred to a second revision
to the spec, or an addendum to it.
4) I'd like to see my bit on optional "/foo" command line
options added, including silently ignoring unknown ones,
except for /HELP which should return a list of the op-
tions the Finger server supports. We may decide that op-
tions must be at the end of the line after any username,
nodename, etc. All received arguments must be passed
along intact to any subsequent host when doing multi-
hop Finger processing, either via a locally-configured
smart host or application level routing.
That's all I see for now, but I have spent way too much time
on this already today, my housemate is upset with me, and I
still have tons of other stuff to do and likely won't get to
sleep until 5 AM again.
I'll be glad to discuss the items I raised above, but I am
going to need to limit the back-and-forth to two 60-minute
periods per day, or I won't get anything else done.
On 1/10/26 9:04 PM, Terri Kennedy wrote:
We've gotten pretty far off track here,
dealing with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?
_______________________________________________
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
5:11 a.m.
See my responses, below. They are just opinions, as a 'ruling' kind of
defeats the purpose of being friendly which is what finger was supposed
to be about. At least, that's what we thought at Columbia.
So I don't mind putting this aside for now. It is a hobby after all and
I will be busy getting the latest Kermit-20 release up on the Internet,
anyway.
------------------------------------------------------------------------
On 1/10/26 9:50 PM, Terri Kennedy wrote:
A few observations:
1) How is a request for streaming output on an otherwise empty
request differentiated from a request for info on a user named STREAM?
I suggest /STREAM for this reason.
The difference lays in considering what is application data and what is
meta-data. A server is under no obligation to do anything with the
meta-data, which is to be found in the connection attributes. So the
optional DATA attribute is only used to condition buffering for the
client. The USER attribute is to log the remote user making the query,
not the local user. The user information being requested is always
passed in on the connection as application data. So user STREAM would
show up to the client's input buffer as "STREAM^M" (or ^J).
A potential concern with a /STREAM switch is that the user could then
issue it and break an RSX connection. Unless debugging is on, the
connection attributes will not be seen and cannot be invoked from the
command line.
2) I suggest allowing explicit area.node:: syntax.
I think that could be made an option, but what is it buying you? The
whole point of the symbolic host name is to not have to remember that stuff.
Tops-20, in particular, is pretty fascist about not allowing a user
issued numeric DECnet specification. The mail system will parse
numerics, but this is only to allow visual compatibility with IP
syntax. It must use a PANDA modification to turn the number into a
DECnet host name which is the only thing the monitor will allow.
But you really don't get anything out of it. You still can't identify a
node that hasn't be defined in the HECnet data base and recently loaded
from MIM:: (which I do on a regular basis). I think I could change the
parser to allow area.node, but like VMS, the finger client is an
accumulation of decades of changes. And stuff for PUP: Ethernet and MIT
CHAOS-NET. Like you, I am tempted to give it the old heave ho and start
from scratch like I've done with the FTP server and the node management
utility (SETND2)
3) "Application Level Routing" - neither
RSTS/E nor VMS DECnet allow
HOST1::HOST2::USER syntax. There is also the issue of passing the
complete command line or editing it. If we are HOST1::, do we remove
HOST1:: from the command line before passing it along? I think so, but
this also complicates interoperability as discussed in the following
paragraph:
The paradigm is that you remove whatever you action. So if from
TOMMYT::, I do a FINGER MIM::VENTI2::SLOGIN, then the MIM:: is removed
from the application data stream and MIM:: only sees VENTI2::SLOGIN.
This also gets into DECnet / TCP/IP
interoperability, which I
think should be deferred to a second revision to the spec, or an
addendum to it.
Application level routing is optional. Should this be stated more
emphatically? For Tops-20, it mainly exists for debugging odd cases to
determine robustness. Poor man's routing is a holdover from previous
versions of Tops-20 DECnet that didn't have it. Tops-20 removed Poor
man's routing for the terminal server. Hooks exist for FAL, but I have
those turned off.
4) I'd like to see my bit on optional
"/foo" command line options
added, including silently ignoring unknown ones, except for /HELP
which should return a list of the options the Finger server supports.
We may decide that options must be at the end of the line after any
username, nodename, etc. All received arguments must be passed along
intact to any subsequent host when doing multi- hop Finger processing,
either via a locally-configured smart host or application level routing.
Transparent 'smart host' or Poor Man's routing was actually implemented
for Tops-20, I believe by Larry Campbell. It's all off now. Regarding
switches, the paradigm is that you are talking to the finger client on
the remote host. All finger clients will reject switches they don't
know about and I think they are supposed to do that.
That's all I see for now, but I have spent way
too much time on this
already today, my housemate is upset with me, and I still have tons of
other stuff to do and likely won't get to sleep until 5 AM again.
Funny you
should say that, I have a number of domestic chores stacked
up, but strangely the Mrs. isn't angry with me, /yet/. Then again, she
may be one of the most patient individuals I've ever seen. Not like me;
I'm your typical southern Italian (Naples)
I'll be glad to discuss the items I raised
above, but I am going to
need to limit the back-and-forth to two 60-minute
periods per day, or I won't get anything else done.
We can all push back and have a think. That's really fine. Again, it's
a hobby, so no rush. I also stumbled over some bugs while doing all
this, but that's not any news...
------------------------------------------------------------------------
On 2026-01-10 21:09, Thomas DeBellis wrote:
You are restating part of what is in the DECnet Finger specification
that Johnny and I put together.
Have a look at it and let me know what you think. This is what the
RSX11 and Tops-20 implementations code against.
It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
That should be the basis for the discussion as I will be happy to
keep it up to date, but I believe it addresses most of what you refer
to, below.
------------------------------------------------------------------------
On 1/10/26 9:04 PM, Terri Kennedy wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se We've gotten pretty far off track here,
dealing with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?
_______________________________________________
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
9:53 a.m.
On 2026-01-10 23:11, Thomas DeBellis wrote:
Ok, so you're talking about putting "STREAM" in the "magic 16
bytes"
or whatever it is that can be set by an application using DECnet? I had
thought you meant it should be on the command line.
True, but that requires the host database to be populated and for
sites to keep it up-to-date.
Seems reasonable. Dual-stack (or more-stack) implementations just have
to
recognize their own name in whatever it might be. Like the previous
item,
not mandatory, not prohibited.
IPv6 and its use of :: is also going to be a can of worms. I'm hoping
to
avoid IPv6 until I'm beyond caring. 8-}
One of us had our terminology confused. I blame X11 semantics. Or some
antics.
To me, "finger client" is the thing that the user is using to ask a
remote
"finger server" about user(s) on it.
Since we have multiple implementations, we don't know what options a
remote
finger server might implement (or not).
This is similar to both FTP and SMTP, where the client can ask the
server
what commands it supports. Grated, those are back-and-forth interactive
dia-
logs, compare to the "write a line and get a response back" operation of
Finger. But it is still good to know the capabilities of the remote
host.
Here's a simple example, from VMS to
RSTS/E:
SPCVXA::$ finger @spc11d
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:22, 9 Jobs, 63
Max.
Uptime 7 02:47:29, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
9 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
SPCVXA::$ finger @spc11d/nocputime
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:22, 8 Jobs, 63
Max.
Uptime 7 02:47:38, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login ST Location TTType
1 SYSTEM 1,2 ERRCPY Det SR - Detached -
2 SYSTEM 1,2 MAILQ Det SR - Detached -
3 SYSTEM 1,2 OMS Det SL - Detached -
4 SYSTEM 1,2 PBS... Det SL - Detached -
5 SYSTEM 1,2 EVTLOG Det SL - Detached -
6 SYSTEM 1,2 MESMAN Det SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 ^C PiDP-11 Console VT100
8 SYSTEM 1,2 FINSRV Det RN - Detached -
SPCVXA::$ finger @spc11d/wumpus
[SPC11D.DECnet]
?FINGER - Unrecognized command qualifier '/WUMPUS'.
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:23, 8 Jobs, 63
Max.
Uptime 7 02:48:04, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
In the case of RSTS/E Finger, it warns you about unknown qualifiers
but
then proceeds to give you what it thought you asked for. In my draft
spec
it was "return an error and close the connection".
Again, returning a useful error and continuing vs. returning a useful
error
and closing the connection is an implementation-specific issue. However,
if
poor-man's routing is being used, other than removing its own host info
from
the command line, it should pass the rest of the command line (including
qualifiers it doesn't know about) to the next host.
My implementations don't care about positions of qualifiers -
"finger/wumpus @spc11d" and "finger @spc11d/wumpus" are treated
the same. This is the "be liberal in what you accept, be con-
servative in what you send" philosophy. But the draft could state
that qualifiers have to appear to the right of any other items on
the line sent to the Finger server. I can certainly rewrite my
clients to always put them at the end, but still accept them if
they appear elsewhere.
BTW, VMS finger interoperates with Unix Finger, and will also
act as a smarthost for DECnet-only clients like RSTS/E. Unix has
its own set of configuration options. Here's 2BSD with its default
rule of "Refuse to list all users":
SPCVXA::$ finger @spc11e.glaver.org
[SPC11E.GLAVER.ORG]
must provide username
SPCVXA::$ finger terry(a)spc11e.glaver.org
[SPC11E.GLAVER.ORG]
Login: terry Name: Terri Kennedy
Directory: /home/terry Shell: /bin/tcsh
On since Thu Jan 8 23:48 on console, idle 1 day 3:17
Last login Thu Jan 8 23:51 on ttyp0 from gate.glaver.org
No Plan.
And I think that should be an implementation option as well, whether a
host will list all users or only by username.
Right now, while both VMS and RSTS/E Finger support /HELP, they go and
get
the help file info from another process that is doing "help finger" as a
DCL
command, and it is quite slow.
That is something my implementations need to fix, as at the time they
were
written, 56Kbit or slower links were common. I'll probably change
"/help" to
just send basic help information, and at the end either say "use
/help=foo to
get additional information about the /foo option", or just say "use
/fullhelp
to get the whole help data".
It has certainly exposed some interoperability issues in my code. I
don't
know why both RSX and -20 are getting that spew from spcvxa:: or
spcvxb::
listing all of the qualifiers when they just sent a blank line. I
suspect
the VMS implementation may not treat all 3 line endings in your draft as
valid line endings.
I definitely want to fix these issues in my code (starting with RSTS/E
Finger as it's better-behaved already and it's all code I wrote).
However, I'd like to see what agreement we can come to on the use of
qualifiers, leaving certain things up to the implementation, and
whatever
other points I raised above (3:35 AM now, so time for bed). Feel free to
cogitate and let me know what you think, and I'll look at it sometime
tomorrow, likely at night.
BTW, here's the configuration file for my current RSTS/E Finger. It is
parsed by the Finger server. On VMS Finger, the parts of this that are
supported are handled by conditional compilation (ick!). The only
Byzantine
part of this are the 1/2/3 lines which contain a coded value for the de-
faults when neither /foo nor /nofoo is supplied by a Finger client.
These
are documented in the .doc file (will likely be a PDF for new releases)
and I'll attach that part below the sample config file.
$ type finger.cnf
! Configuration file for finger. See additional comments at end.
H SPC11D PDP-11/70
O SPC Memorial PDP-11/70
R SPCVAX
M @FINGER$:FINGER.MSG
W 0
N 0
L 0
1 143
2 3575
3 15
Q
!
! Sample finger configuration file. You *must* follow this format or you
! will get errors. The first column must be either an exclamation point
! (!) or one of the characters H, O, R, M, W, N, L, 1, 2 or 3, in any
or-
! der. The file scan is terminated when a line starting with Q is found.
!
! The usage of the letters is as follows:
!
! H - The string beginning in column 3 is the local host name, with any
! other comments (such as CPU type) desired.
! O - The name of the local organization (your company or department
name).
! R - The node name of a host to service requests for nodes not known
lo-
! cally. Note: This is used for DECnet lookup, and must be in a
format
! considered valid by DECnet. It is rejected if it is either "0" or
the
! local host name, but subtle errors can occur by having two nodes
each
! configured to be the router for the other.
! M - Message of the day, either a text string or a filename prefaced
with
! an @-sign to type the contents of that file.
! W - The minimum number of non-wildcard characters allowed for lookups.
A
! value of 0 will allow any match, 1 needs at least one non-wild
char-
! acter, etc.
! N - Flag for whether nodename is considered in the mail From: match.
0=no,
! 1=yes.
! L - Flag whether finger should disable reporting mail information.
0=report
! unread count and subjects from sender, 1=report unread count,
disable
! subjects, 2=disable both count and subjects. Why is this flag
called
! 'L'? If you know the way LJK feels about mail read receipts, you'd
know.
! 1 - The default command qualifiers, part 1 of 3
! 2 - The default command qualifiers, part 2 of 3
! 3 - The default command qualifiers, part 3 of 3
! Q - End of configuration file (quit)
----
1 - Value for command defaults, part 1. This keyword is the sum of
the
following values:
/interactive 1
/batch 2
/network 4
/system 8
/version 32
/message 128
Example: 1 143
2 - Value for command defaults, part 2. This keyword is the sum of
the
following values:
/job 1
/username 2
/ppn 4
/personalname 8
/imagename 16
/terminal 32
/logintime 64
/cputime 128
/state 256
/size 512
/location 1024
/tttype 2048
/priority 4096
/runtimesystem 8192
Example: 2 3575
3 - Value for command defaults, part 3. This keyword is the sum of
the
following values:
/bypass 1
/plan 2
/mail 4
/area 8
Example: 3 15
See my responses, below. They are just opinions, as a
'ruling' kind of
defeats the purpose of being friendly which is what finger was supposed
to be about. At least, that's what we thought at Columbia.
I agree. I really want to interoperate happily with as much as I can,
although I think Bitnet is a lost cause at this time. 8-}
It's funny that VMS Finger took the long away around from Columbia to
me,
while a bunch of other projects (like C-Kermit) came directly. Columbia
did "flim-flam" me once, when they asked if I would "provide a
UUCP-over-IP
connection to another site in Colombia".
I didn't read that carefully enough and thought they were asking for a
duplicate UUCP feed (I was running a top-10 Usenet server at the time)
for
themselves, not for Colombia the country. I'd said I would do it, so I
did.
So I don't mind putting this aside for now. It is
a hobby after all
and I will be busy getting the latest Kermit-20 release up on the
Internet, anyway.
It's just been a really bad day, with a bunch of software projects all
clamoring for my time as well as the other stuff that is Retired Life
that
saps all your free time (and then some).
-------------------------
On 1/10/26 9:50 PM, Terri Kennedy wrote: A few observations:
1) How is a request for streaming output on an otherwise empty request
differentiated from a request for info on a user named STREAM? I
suggest /STREAM for this reason.
The difference lays in considering what is application data and what is
meta-data. A server is under no obligation to do anything with the
meta-data, which is to be found in the connection attributes. So the
optional DATA attribute is only used to condition buffering for the
client. The USER attribute is to log the remote user making the query,
not the local user. The user information being requested is always
passed in on the connection as application data. So user STREAM would
show up to the client's input buffer as "STREAM^M" (or ^J). A potential concern with a /STREAM switch is that the
user could then
issue it and break an RSX connection. Unless debugging is on, the
connection attributes will not be seen and cannot be invoked from the
command line.
If it's in the metadata, then it isn't an issue. My misunderstanding.
Although in the case you're describing, sending /STREAM to an RSX sys-
tem from a -20 would just be ignored. Or are you describing what could
happen if a user on RSX said "finger node::somebody /stream" to a -20,
in which case the situation you describe might happen. Although if the
-20 tried to stream to RSX, wouldn't RSX abort the connection?
2) I suggest
allowing explicit area.node:: syntax.
I think that could be made an option, but what is it buying you? The
whole point of the symbolic host name is to not have to remember that
stuff. Tops-20, in particular, is pretty fascist about not
allowing a user
issued numeric DECnet specification. The mail system will parse
numerics, but this is only to allow visual compatibility with IP
syntax. It must use a PANDA modification to turn the number into a
DECnet host name which is the only thing the monitor will allow.
But you really don't get anything out of it. You still can't identify
a node that hasn't be defined in the HECnet data base and recently
loaded from MIM:: (which I do on a regular basis). I think I could
change the parser to allow area.node, but like VMS, the finger client
is an accumulation of decades of changes. And stuff for PUP: Ethernet
and MIT CHAOS-NET. Like you, I am tempted to give it the old heave ho
and start from scratch like I've done with the FTP server and the node
management utility (SETND2)
Both VMS and RSTS/E allow it:
VMS:
SPCVXA::$ dir 41.503"system topsecret"::
Directory 41.503"system password"::SYS$SYSROOT:[SYSMGR]
ACCOUNTNG.DAT;5 CLUE$HISTORY.DATA;1 CLUE$LAST_SPCVXB.LIS;1
CXX_REPOSITORY.DIR;1 EVL.LOG;114
FMG_LOCAL_PARAM_LIBRARY.KNL;1 FTP_SERVER.LOG;5
LAN$ACP.LOG;123
RSTS/E:
SPC11D::$ dir 41.503"system topsecret"::
Directory 41.503::SYS$SYSROOT:[SYSMGR]
Name .Typ Size Prot Access Date Time UIC
ACCOUNTNG.DAT;5 177/270 < 56> 17-Sep-24 17-Sep-24 00:01
[000001,000004]
CLUE$HISTORY.DATA;11/9 < 56> 04-Jan-26 31-Dec-23 16:55
[000001,000004]
CLUE$LAST_SPCVXB.LIS;1 2/9 < 56> 04-Jan-26 04-Jan-26 01:18
[000001,000004]
CXX_REPOSITORY.DIR;1 1/9CP < 40> 01-Jan-24 01-Jan-24 00:54
[000001,000004]
So I think it should be optional in implementations - not mandatory*,
not prohibited.
* "Fruity Oaty Bar", if you get the reference.
3)
"Application Level Routing" - neither RSTS/E nor VMS DECnet allow
HOST1::HOST2::USER syntax. There is also the issue of passing the
complete command line or editing it. If we are HOST1::, do we remove
HOST1:: from the command line before passing it along? I think so, but
this also complicates interoperability as discussed in the following
paragraph:
The paradigm is that you remove whatever you action. So if from
TOMMYT::, I do a FINGER MIM::VENTI2::SLOGIN, then the MIM:: is removed
from the application data stream and MIM:: only sees VENTI2::SLOGIN. This also gets
into DECnet / TCP/IP interoperability, which I think
should be deferred to a second revision to the spec, or an addendum to
it.
Application level routing is optional. Should this be stated more
emphatically? For Tops-20, it mainly exists for debugging odd cases to
determine robustness. Poor man's routing is a holdover from previous
versions of Tops-20 DECnet that didn't have it. Tops-20 removed Poor
man's routing for the terminal server. Hooks exist for FAL, but I have
those turned off. 4) I'd
like to see my bit on optional "/foo" command line options
added, including silently ignoring unknown ones, except for /HELP
which should return a list of the options the Finger server supports.
We may decide that options must be at the end of the line after any
username, nodename, etc. All received arguments must be passed along
intact to any subsequent host when doing multi- hop Finger processing,
either via a locally-configured smart host or application level
routing.
Transparent 'smart host' or Poor Man's routing was actually
implemented
for Tops-20, I believe by Larry Campbell. It's all off now. Regarding
switches, the paradigm is that you are talking to the finger client on
the remote host. All finger clients will reject switches they don't
know about and I think they are supposed to do that. That's all
I see for now, but I have spent way too much time on this
already today, my housemate is upset with me, and I still have tons of
other stuff to do and likely won't get to sleep until 5 AM again.
Funny you
should say that, I have a number of domestic chores stacked
up, but strangely the Mrs. isn't angry with me, _yet_. Then again, she
may be one of the most patient individuals I've ever seen. Not like
me; I'm your typical southern Italian (Naples)
I'll be glad to discuss the items I raised
above, but I am going to
need to limit the back-and-forth to two 60-minute
periods per day, or I won't get anything else done.
We can all push back and have a think. That's really fine. Again,
it's a hobby, so no rush. I also stumbled over some bugs while doing
all this, but that's not any news... -------------------------
On 2026-01-10 21:09, Thomas DeBellis wrote: You are restating part of
what is in the DECnet Finger specification that Johnny and I put
together.
Have a look at it and let me know what you think. This is what the
RSX11 and Tops-20 implementations code against.
It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
That should be the basis for the discussion as I will be happy to keep
it up to date, but I believe it addresses most of what you refer to,
below.
-------------------------
On 1/10/26 9:04 PM, Terri Kennedy wrote:
We've gotten pretty far off track here, dealing with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?
_______________________________________________
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
_______________________________________________
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
4:24 p.m.
A couple of small comments on some additional bits...
On 2026-01-11 09:53, Terri Kennedy wrote:
RSX just gets packets. TOPS-20 just stuffed multiple lines into one
packet. At some point, it created packets larger than my receive buffer,
at which point I got truncated data.
True, but that requires the host database to be populated and for
sites to keep it up-to-date.
Please be aware that RSX does not allow you to specify node numbers in
any APIs. So basically, not an option on that side. You always need a name.
Seems reasonable. Dual-stack (or more-stack) implementations just
have to
recognize their own name in whatever it might be. Like the previous item,
not mandatory, not prohibited.
Following RFC 1288, the next hop *should* be removed.
So if the user types "finger user@foo", the client should connect to
host foo, and only provide "user" as the request. And by extension, if
the user types "finger user@foo@bar", the client connects to host bar,
and gives the request "user@foo" to the finger server.
Please read through the RFC if you want more clarity around this. And I
truly think we should just behave the same with DECnet.
So if someone types "finger mim::venti2::slogin", the client should
connect to MIM, and give the request "venti2::slogin".
IPv6 and its use of :: is also going to be a can of worms. I'm hoping to
avoid IPv6 until I'm beyond caring. 8-}
This shouldn't really cause any problems. Any IPv6 :: thingy would occur
after an '@', while any DECnet node would appear before.
I don't know what the VAX code is doing. But I can tell you that the RSX
client is really just sending a CR+LF here. And yeah, I'm getting a
whole lot of strange errors just like Thomas.
On 2026-01-10 23:11, Thomas DeBellis wrote:
Ok, so you're talking about putting "STREAM" in the "magic 16
bytes"
or whatever it is that can be set by an application using DECnet? I had
thought you meant it should be on the command line.
I guess with the "magic 16 bytes", we're talking about the optional data
that can be provided with a connect call. They have no predefined
meaning, and each application can do whatever in there. There is no
"stream" interpretation in it. Streams under TOPS-20 is basically just
that multiple writes gets combined together into a single DECnet packet.
And I guess on the receiving side, you can read "lines", and the
unpacking from packets is happening in an intermediate layer.
On
1/10/26 9:50 PM, Terri Kennedy wrote: A few observations:
1) How is a request for streaming output on an otherwise empty
request differentiated from a request for info on a user named
STREAM? I suggest /STREAM for this reason.
The difference lays in considering what is application data and what
is meta-data. A server is under no obligation to do anything with the
meta-data, which is to be found in the connection attributes. Sothe
optional DATA attribute is only used to condition buffering for the
client. The USER attribute is to log the remote user making the
query, not the local user. The user information being requested is
always passed in on the connection as application data. So user
STREAM would show up to the client's input buffer as "STREAM^M" (or ^J).
A potential
concern with a /STREAM switch is that the user could then
issue it and break an RSX connection. Unless debugging is on, the
connection attributes will not be seen and cannot be invoked from the
command line.
If it's in the metadata, then it isn't an issue. My misunderstanding.
Although in the case you're describing, sending /STREAM to an RSX sys-
tem from a -20 would just be ignored. Or are you describing what could
happen if a user on RSX said "finger node::somebody /stream" to a -20,
in which case the situation you describe might happen. Although if the
-20 tried to stream to RSX, wouldn't RSX abort the connection? 2) I suggest allowing explicit area.node:: syntax.
I think that could be made an option, but what is it buying you? The
whole point of the symbolic host name is to not have to remember that
stuff. 3) "Application Level Routing" - neither
RSTS/E nor VMS DECnet allow
HOST1::HOST2::USER syntax. There is also the issue of passing the
complete command line or editing it. If we are HOST1::, do we remove
HOST1:: from the command line before passing it along? I think so,
but this also complicates interoperability as discussed in the
following paragraph:
The paradigm is that you remove whatever you action. So if
from
TOMMYT::, I do a FINGER MIM::VENTI2::SLOGIN, then the MIM:: is removed
from the application data stream and MIM:: only sees VENTI2::SLOGIN. This also gets into DECnet / TCP/IP interoperability,
which I think
should be deferred to a second revision to the spec, or an addendum
to it.
Application level routing is optional. Should this be stated more
emphatically? For Tops-20, it mainly exists for debugging odd cases
to determine robustness. Poor man's routing is a holdover from
previous versions of Tops-20 DECnet that didn't have it. Tops-20
removed Poor man's routing for the terminal server. Hooks exist for
FAL, but I have those turned off. To me, "finger client" is the thing that
the user is using to ask a
remote
"finger server" about user(s) on it.
Since we have multiple implementations, we don't know what options a
remote
finger server might implement (or not).
This is similar to both FTP and SMTP, where the client can ask the
server
what commands it supports. Grated, those are back-and-forth interactive
dia-
logs, compare to the "write a line and get a response back" operation of
Finger. But it is still good to know the capabilities of the remote host.
Agreed. Pass any switches on which aren't obviously something to deal
with locally.
And yes, my RSX implementation should be doing ok there. But let me know
if you spot any issues.
And I think that should be an implementation option
as well, whether a
host will list all users or only by username.
I think that's not unreasonable, but I think that's up to each
implementation how they want to do things.
We can all
push back and have a think. That's really fine. Again,
it's a hobby, so no rush. I also stumbled over some bugs while doing
all this, but that's not any news...
It has certainly exposed some interoperability issues in my code. I
don't
know why both RSX and -20 are getting that spew from spcvxa:: or spcvxb::
listing all of the qualifiers when they just sent a blank line. I suspect
the VMS implementation may not treat all 3 line endings in your draft as
valid line endings. However, I'd like to see what agreement we can
come to on the use of
qualifiers, leaving certain things up to the implementation, and whatever
other points I raised above (3:35 AM now, so time for bed). Feel free to
cogitate and let me know what you think, and I'll look at it sometime
tomorrow, likely at night.
I think passing unknown, as well as qualifiers that obviously makes more
sense to process remotely over on the request line is very reasonable,
and the same thing I'm doing.
Johnny
--
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
2
days inactive
10
days old
55 comments
6 participants
participants (6)
-
amp1ron＠gmail.com -
Johnny Billquist -
Keith Halewood -
Terri Kennedy -
Thomas DeBellis -
Tony Nicholson