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, there is 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?