I finally put something together that is analogous to the RSX NFT /ID switch.  Basically, it grabs a copy of the configuration message before negotiation and displays it later.  So for VENTI2::, one sees:

Maximum buffer size: 4096
Operating System: Tops-20, File System: Tops-20
DAP: 5.6.0
DECnet: 2.0
Supports sequential file organization
Supports sequential file access
Supports Random Access by Virtual Block number
Supports command file Submission/execution
Supports blocking of DAP messages up to response
Supports unrestricted blocking of DAP messages
Supports two byte operand length in message header
Supports file checksum option
Supports directory list function
Supports Date-and-Time extended Attributes message
Supports File Protection extended Attributes message
Supports spooling as specified by File Operation field (FOP)
Supports command file submission as specified by FOP
Supports file deletion as specified by FOP
Supports use of BITCNT field in Data message
Supports Wildcard operations
Supports the Name message

which matches part of RSX NFT is saying about VENTI2::.  For MIM::, I get

Maximum buffer size: 2086
Operating System: RSX11-M PLUS, File System: RMS-11
DAP: 7.1.0
DECnet: 8.0
Supports file preallocation
Supports sequential file organization
Supports relative file organization
Supports indexed file organization
Supports sequential file access
Supports random access by record number
Supports Random Access by Virtual Block number
Supports Random Access by Key
Supports Random Access by Record File Address (RFA)
Supports multi-key index file organization
Supports switching access mode
Supports append to file access
Supports command file Submission/execution
Supports status return
Supports blocking of DAP messages up to response
Supports two byte operand length in message header
Supports file checksum option
Supports Key Definition extended Attributes message
Supports Allocation extended Attributes message
Supports Summary extended Attributes message
Supports directory list function
Supports Date-and-Time extended Attributes message
Supports File Protection extended Attributes message
Supports spooling as specified by File Operation field (FOP)
Supports command file submission as specified by FOP
Supports file deletion as specified by FOP
Supports sequential record access
Supports the File Rename Operation
Supports Wildcard operations
Supports the Go/No-go option
Supports the Name message

Gee, MIM:: does a lot of stuff, so I regrettably remain with a pretty bad case of data envy...  And I really have to get off my butt and implement rename.

Is there an ASCII version of DAP 7.1 anywhere on HECnet that I could download?  I was curious about file preallocation whose bit is defined in the 5.6 document, but not really explained, as far as I saw.

On 4/25/23 9:59 AM, Thomas DeBellis wrote:

Thanks!!  The RSX NFT /D switch reminds me that the list of features that I want to lift from RSX NFT and put into Tops-20 NFT just keeps getting longer...

Right now, I'm in the middle of changing the buffering mechanism for Tops-20 DAP to use correctly allocated sizes from a post-build static buffer header instead of a maximally allocated and trimmed dynamic buffer and then compacted post-build.

The latter current method only allows me to buffer up 170 messages, most of which are not very large at all.  I would assume that I should be seeing far more than that given that I have 448 pages of buffer memory to play with.  Admittedly, some of that is being taken up by linked list overhead, but it still seems like a flagrant waste of memory.

Of course, using that much main storage either way back in the day would almost certainly have gotten me 'a good talking to' (I.E., yelled at) for being a memory hog and paging the system into oblivion.  One assumes that there would be a configurable parameter to use instead of what I'm doing (grabbing as much as I can get my hands on in the section zero address space).
On 4/24/23 9:51 PM, Johnny Billquist wrote:

A quick check on some different systems that are online on HECnet at the moment didn't reveal any with a bufsiz of 0 or greater than 4096.

I checked TOPS-20, Ultrix (a few different versions), VMS (including V9.2), RSTS/E and RSX.

With RSX, it's fairly easy to check:

.nft venti2::/id
NFT -- Version V9.0
Local NFARs V8   DAP V7.1 Buffer size=  2064. OS=RSX-11M+  FS=FCS-11 DC=Yes
Remote FAL  V2   DAP V5.6 Buffer size=  4096. OS=TOPS-20   FS=TOPS-20 DC=Yes


  Johnny
On 2023-04-25 00:13, Thomas DeBellis wrote:

After I got done 'enough' with the auto-mounting code for FAL (meaning, I didn't make the modifications to the access control job because I bumped into .MSIMF), I turned to fixing a bug that I bumped into a few years ago. While Tops-20 does not support wildcarding devices, it does support wildcarding all structures that the system currently has online via the DSK*: moniker.

So, let's say you're a 60+ who is having those occasional lapses of memory and you /really/ can't remember a single thing about something you think you might have somewhere.  This is, of course, completely forgetting that you wanted to find something in the first place... you can ask the EXEC to do something like, DIRECT DSK*:<*>*SOMETHING*.*.0.  You can also hand that to FIND to have it look in all those files.

Some experimentation with NFT shows that Tops-20 FAL supports structure wildcarding.  BUT!!  If you're being nosy or are just plain hacking and do DIRECT DSK*:<*>*.*.*, it crashes with a GLXLIB out of memory error (ASE, Out of Address Space)...

Researching this shows that Tops-20 DAPLIB tries to buffer messages before dumping them over the wire and that the decision it makes to dump is file count based.  That appeared to not work properly because of two issues.  First, each file was actually generating four separate messages: a Name, an Attributes, a Date/Time Attributes and a File Protection Attributes.  Second, the buffer builder was always allocating a buffer for the maximum size message, 4090 characters (1032 thirty-six bit words).

That's pretty excessive, considering the typical sizes. Some instrumentation shows the below:

    Message     Allocated     Actual     %Excess
    Name           4,090       18         99.56%
    Attributes     4,090       17         99.58%
    Date/Time      4,090       40         99.02%
    Protection     4,090        7         99.83%

I changed the buffering algorithm to dump based on available memory.  The starting available memory is 448 pages, so I take ¾ of that to devote to DAP buffers and ¼ (122 pages) to do the dumping.  That fixed the problem.  Then I changed the memory allocation to trim unused words from the end of messages.  That's not working as well as I expected, probably because I need compact (or 'burp') the memory.  Another alternative would be to build all messages in a single area and then only allow a chunk in the linked list for what I need.  No burping.

A concern is what happens with the Configuration BUFSIZ operator and what to do if it is 0 (unlimited).  The DAP specification specifies that an operand of zero means that if one of the two systems has  an  unlimited buffer size, it sends a 0 and the two systems  will use  the  nonzero buffer size as the maximum.  If both systems send 0, thereis no limit on the length  of messages which may be sent.

My question is whether zero is absurd.  Does any implementation send that?

It probably doesn't matter that much for sending, but I'm also thinking that I might hypothetically have a similar problem on receive.  Obviously I don't because the current Tops-20 DAP won't negotiate a size larger than 4096 bytes.  Is anything running larger than that? Would it be silly to?



_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se