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

I've put a 4 second delay between the last $QIOW and the $DASSGN. It's not brilliant... but more/most/all gets through now. The $DASSGN is brutal. K -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: 14 January 2026 17:49 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New) Another data point: .set /host Host=MIM RSX-11M-PLUS V4.6  BL87mP .fin dune:: [DUNE::] . So I'm not getting anything at all. :-)      Johnny On 14/01/2026 18.28, Keith Halewood wrote: > 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 > sendan email to hecnet-leave(a)lists.dfupdate.se > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe > sendan 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