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

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: 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... Ok. So confirmed an unfortunate difference in the request format here. 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. 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. 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. 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. 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. 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. 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