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

There must be a way to wait for the I/O to complete before you deassign/ disconnect/close...     Johnny On 2026-01-14 20:05, Keith Halewood wrote: > 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 goesaway. >> 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