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

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