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

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