I'd be quite happy to run a DECnet version of finger server on the VMS instances I have running here but not the TCP/IP version because they are generally not available to the internet. I've tended to use PHONE DIR when attempting to see if someone is logged in but that's mainly for a nostalgic excluse to use VMS mail or phone. Keith -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: 07 June 2024 15:32 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] FINGER survey... I've been busy with my silly things as usual, and lately implemented a FINGER client and server for RSX, and I realized there are a couple of things to maybe check with other people on HECnet. First of all - finger as such is a (sortof) well known tool/service on the TCP/IP internet. And I've had a finger server and client for TCP/IP under RSX for a long time, but have never really shared it, since it was a bit "odd". But even before this, I knew of a FINGER implementation available from DECUS for RSX. I've known that I wanted to make FINGER available for others for a long time, but recently I started thinking of also adding in DECnet capability in my finger implementation. So the last few weeks I've been tinkering with this, and I've finally completed the work and made my new finger implementation available as a package. The FINGER from DECUS mentions the following: FINGER is a utility to display information about a selected user or group of users. It can be invoked for users on the local node or on a remote node over DECnet, and is com- patible with the VMS implimentation of FINGER. Full function- ality requires an RSX-11M+ system with resource accounting and DECnet. So, not only have there been this RSX implementation from DECUS, there apparently also exist(ed) an implementation from somewhere for VMS. FINGER over TCP uses the well known TCP port 79, while the DECUS RSX (and I assume VMS) DECnet implementation uses object number 117. My implementation then responds to both these access paths, as well as being able to query locally, and also try to connect to remote systems using either of these methods. And I now have this running on MIM:: So my questions are: . Do anyone else have any finger service running on any HECnet node? . Do anyone else know what other implementations even exist, and for which OSes? I do think FINGER is somewhat useful to find who might be logged in and active, as well as finding out more information about people on different systems in general. On the internet, finger servers are nowadays unusual to see, since privacy and security concerned people just feel that finger gives out way too much information anonymously. So I am not encouraging people to run this if they have such concerns. But like I said, personally, I do find it useful, and will keep it available on any RSX system that I am running. Johnny

Johnny, I’d be very interested in your RSX version of FINGER. Will you be adding it to your RPM repository or in the TCP/IP distribution. I use your RWHO quite a bit for local things but to see if someone is thereon a remote machine who be quite helpful. Currently I use PHONE DIR for such things but it is pretty limited. Thanks for all the great additions to RSX! Mark

bqt(a)softjar.se wrote:

Is it TCP only then?

I still wonder what FINGER server the RSX DECUS package is referring to, which talks DECnet...

Columbia did an DECnet finger server for Tops-20.  As I recall, wefirst used the same numeric object type as TCP (I.E., 79), although 117 does not sound unfamiliar for some strange reason... We certainly could have changed it, but I don't remember why.  Is something else on 79?

The finger server simply listened on a particularly port and when a connect was accepted, it was handed off to a fork with finger mapped and the primary I/O JFN's were set to the network connection.  I don'tsee that it is on the PANDA distribution, but it's an easy thing to write.

PANDA Tops-20 handles terminal idle time in a somewhat obvious way: the system uptime (in milliseconds) is stored in the terminal block whenever input is detected.  Idle time is computed by subtracting that uptime from the current uptime.  This gives you a nice exact number.

As I recall, it doesn't quite work right with a batch job, but since there is nobody there, this doesn't really matter.  Idle time in that case is detected by CPU consumption.

It was an internal tool for testing the various DECNet communication services. I wonder if RSX used 63 for Datatrieve because the registration for object 63 names it "DTR". That's "DECnet Test Receiver" but of course it also happens to be the RSX three-letter acronym for Datatrieve.

I have a document that seems to be part of the Phase V set, in a folder marked "from Antonio Carlini". Here's a text version.

Actually Tops-20 finger does functions exactly the same whether you are local or network; that is, a line of text is parsed from primary input (.PRIIN) and the resulting output is typed on the terminal or primary output (.PRIOU).  What happens in the network case is that the backing JFN's for .PRIIN and .PRIOU are changed from the controlling terminal (I.E., .CTTRM) to the network JFN with the SPJFN% JSYS. When running as such in 'server mode', Finger has no idea of what is going on.  It literally can not tell the difference in input source unless it does some terminal specific things, which it largely doesn't do.  This is how the NETSRV daemon implements the Finger TCP service. Similarly, when finger is run as a client and asks for a network connection, the protocol is deduced by a table lookup and the line it has is simply shoved over the connection.  The only difference is in the syntax for the constructed JFN.  Code exists for TCP and Pup and it's simple enough to put in a DECnet entry.  I might do that to try it out. Regarding Batch, it would be difficult to imagine a valid use case for IDLE%.  CPU time is probably fine as it takes processor time to consume characters.  That being said, it's possible that you could have a background task that pops every so often to do some minor thing while the main fork could be wedged.  It all seems a little contrived. I bring it up because the Tops-20 pseudo-terminal implementation is accurate enough so that I can test certain arcane features such as parity with Kermit-20.  When I use Kermit-20 to establish a local connection over a PTY, it works fine, viz:  User    Personal name       Job Subsys Idle TTY Console location SLOGIN   Thomas DeBellis       8 EMACS   1:21  44 iSnack.Laurel: Development, Large                       -->     10 FINGER        46 iSnack.Laurel: Secondary Testing, Kermit-20                       -->     12 EXEC      14. 21 Job 10, SLOGIN, FINGER You can see that I haven't typed anything into job 12 for fourteen minutes since I pushed to an EXEC to run the finger. This doesn't happen with the Batch controller, so I've wondered what it might be doing that clears idle. ------------------------------------------------------------------------ On 6/17/24 3:57 PM, Johnny Billquist wrote: > On 2024-06-17 21:37, Thomas DeBellis wrote: >> The finger server simply listened on a particularly port and when a >> connect was accepted, it was handed off to a fork with finger mapped >> and the primary I/O JFN's were set to the network connection.  I >> don'tsee that it is on the PANDA distribution, but it's an easy >> thing to write. > > From a DECnet perspective it's definitely easy. Connection > estavlished, client sends one line in the same format as the command > line, server responds, just like if you'd get a line and process > locally. > > I would expect that either the TOPS-20 version also does things > slightly differently for DECnet than local, or else it's not > compatible with the RSX (and I assume VMS) version. > > For a local processing, the command line is provided as a part of > starting the process, while over DECnet it will need to read a > command line from the DECnet connection. But from there on, it's > pretty much the same story either way. > >> As I recall, it doesn't quite work right with a batch job, but since >> there is nobody there, this doesn't really matter.  Idle time in >> that case is detected by CPU consumption. > > Idle for batch jobs would be weird. As soone as one thing is > completed, the next thing should be started. Where would any idle > time be? Unless there is something like a sleep at the CLI prompt level. > >   Johnny >

------------------------------------------------------------------------ On 6/17/24 9:22 PM, Johnny Billquist wrote: Ugh. That notions seems risky... How do you know you should be using DECnet and not IP if you say @mim? After all, @mim is a perfectly valid IP address as well. > ------------------------------------------------------------------------ > > On 2024-06-18 00:47, Thomas DeBellis wrote: > > Updating the Tops-20 Finger client was simple enough, a table entry > for DECnet and a small routine to build the JFN string, viz:

I finally remembered the syntax to force transport.  After you aredone with whatever the host name is, you append a ".#" suffix followed by the name of the transport protocol.  Let's suppose there is a nickname defined in the SYSTEM:HOSTS.TXT file for MIM:: as follows: HOST : 192.108.202.74 : MIM : PDP11 : RSX : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : So we can force a finger of user DEBELLIS to use a particular transport, as below.  In the output, the DCN: device is the DECnet active component (or client) and the TCP: device is for IP, where client or service are specified in the GTJFN% string. *DECNET*     FINGER>debellis(a)mim.#decnet     [Fork FINGER opening DCN:MIM-117 for reading, writing]     DEBELLIS     Default directory: US00:[DEBELLIS]    CLI: DCL    SID: TDB     Last seen May 21 2024 23:56:54 on RT0: from VENTI2::     Logged on 8 times.     No plan. *INTERNET*     FINGER>debellis(a)mim.#internet     [Fork FINGER opening TCP:.30033145112-79;PERSIST:30;CONNECTION:ACTIVE for reading, writing]     DEBELLIS     Default directory: US00:[DEBELLIS]    CLI: DCL    SID: TDB     Last seen May 21 2024 23:56:54 on RT0: from VENTI2::     Logged on 8 times.     No plan. I did notice that the user and host name data appear to be written in fixed length fields, resulting in trailing spaces that were not trimmed.  This is unlike the other lines in the output. Not that it really matters; who is running 300 baud these days except for museums? _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

Probably I am now the worst person in the world to ask as to what is intuitive on Tops-20, what with being saturated with it and all. Are you referring to the programming part or the user part?

If the latter, then what is so bad about _@finger debellis@mim_?  It's the same thing you'd use for email... I don't recall that our users complained about finger.  They did, however, find plenty of other things to point out.

If you want complicated, unintuitive and  bad to use, may I suggest trying to create a directory on ITS or deleting a file on MVS with JCL?

------------------------------------------------------------------------ On 7/21/24 6:42 AM, Johnny Billquist wrote: _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

Actually Tops-20 finger does functions exactly the same whether you are local or network; that is, a line of text is parsed from primary input (.PRIIN) and the resulting output is typed on the terminal or primary output (.PRIOU).  What happens in the network case is that the backing JFN's for .PRIIN and .PRIOU are changed from the controlling terminal (I.E., .CTTRM) to the network JFN with the SPJFN% JSYS.

When running as such in 'server mode', Finger has no idea of what is going on.  It literally can not tell the difference in input source unless it does some terminal specific things, which it largely doesn't do.  This is how the NETSRV daemon implements the Finger TCP service.

Similarly, when finger is run as a client and asks for a network connection, the protocol is deduced by a table lookup and the line it has is simply shoved over the connection.  The only difference is in the syntax for the constructed JFN.  Code exists for TCP and Pup and it's simple enough to put in a DECnet entry.  I might do that to try itout.

Regarding Batch, it would be difficult to imagine a valid use case for IDLE%.  CPU time is probably fine as it takes processor time to consume characters.  That being said, it's possible that you could have a background task that pops every so often to do some minor thing while the main fork could be wedged.  It all seems a little contrived.

I bring it up because the Tops-20 pseudo-terminal implementation is accurate enough so that I can test certain arcane features such as parity with Kermit-20.  When I use Kermit-20 to establish a local connection over a PTY, it works fine, viz:  User    Personal name       Job Subsys  Idle TTY Console location SLOGIN   Thomas DeBellis       8 EMACS   1:21  44 iSnack.Laurel: Development, Large                       -->     10 FINGER        46 iSnack.Laurel: Secondary Testing, Kermit-20                       -->     12 EXEC      14. 21 Job 10, SLOGIN, FINGER You can see that I haven't typed anything into job 12 for fourteen minutes since I pushed to an EXEC to run the finger. This doesn't happen with the Batch controller, so I've wondered what it might be doing that clears idle.

------------------------------------------------------------------------ On 6/17/24 3:57 PM, Johnny Billquist wrote: _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

Hmm? How does command line processing work under TOPS-20? If you type: @ FINGER MIM:: would the finger program be started, and it would do a read from the terminal to read a line, and it would actually get the command line "FINGER MIM::", or actually, would it get "MIM::" in that case? Because that is how it would need to be in order to work the same if it came via DECnet.