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

I knew it was brutal, yet that's what the documentation states (other than a client-initiated closure) as a way of closing the channel. Anyway, I decided to let RMS handle it all by using Pascal's text fileI/O, essentially: open() on 'sys$net', reset() before readln(), then rewrite() before a series of writeln()s then a close(). Works fine on x86_64 pascal - including the handling of EOF. Fails on the first writeln() with an access violation with default optimisation on VAX, gets further with no optimisation and corrupted output. I might look at the object code produced (VAX) at some point, when I stop crying :) I know for a fact that there are some bugs in code generation when you do whole record layout initialisation, ie. $GETJPI lists,etc.. We used to make fun of people who blamed the compiler for problems withtheir code. K -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: 15 January 2026 02:00 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New) By the way, reading through the VMS manual I note two things: $DASSIGN is basically cancelling any outstanding I/O, and aborts the link quite abruptly. But with the problems you describe, I'm wondering if you are using $QIO and not $QIOW to send messages? But honestly, you should really be using the non-transparent functionality, and do a synchronous disconnect, which will allow all outstanding I/O to complete before the connection is closed.      Johnny On 2026-01-15 02:42, Johnny Billquist wrote: > I think you missed that it all came out as a single line. :-) > > As far as "privileged" goes... In RSX objects as such don't carry > any information about privilege, but my finger task that gets > invoked have privileges, because there is no way for normal > programs to pull out some of the information needed. > >      Johnny > > On 2026-01-15 00:07, Keith Halewood wrote: >> I think you caught it before I'd reinstalled the .exe privileged. >> There's no way I'm creating a privileged object for it.... and I >> don't think the DECnet object privilege settings work like one >> might expect anyway. >> >> Incidentally, from >> https://docs.vmssoftware.com/vsi-openvms-decnet- >> networking-manual/#SEC_ERROR_REPORT (2nd paragraph) >> >> Also, 2nd to last paragraph in https://docs.vmssoftware.com/vsi- >> openvms-decnet-networking-manual/#SEC_EXCHNG_MESSAGES >> >> Doesn't bode well. >> >> K >> >> >> -----Original Message----- >> From: Johnny Billquist [mailto:bqt@softjar.se] >> Sent: 14 January 2026 21:28 >> To: hecnet(a)lists.dfupdate.se >> Subject: [HECnet] Re: DECnet Finger Specification (Possible >> re-post) and Tops-20 Finger Setup Documentation (New) >> >> Also, FYI: >> >> .fin dune:: >> [DUNE::] >> OpenVMS V7.3 on node DUNE 14-JAN-2026 21:26:37.03 Uptime  31 >> 06:59:20Nousers logged in.(end) . >> >> >>       Johnny >> >> >> On 2026-01-14 22:25, Johnny Billquist wrote: >>> 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 notshow 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 >>>>>>> thinkshere. >>>>>>> (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 >>> >> >