[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