14 Jan
2026
14 Jan
'26
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