On 11/21/22 5:47 PM, John Forecast wrote:

I wanted to quickly find out how much, if  any, code was dependent on the OS type. One other area of incompatibility is that TOPS-10 and the Linux dndir require a DAP-level ACK after the attributes during directory listings.

Johnny and I did a lot of work and testing to get Tops-20 DAP/FAL to perform better.  Some were Tops-20, others not.  One Tops-20 bug was that an eight bit file would cause a directory listing to stop.  My favorite RSX issue was that it wants UPPERcase month names; I fixed that by UPPERcasing the result of ODTIM%.  I can't remember what Johnny did (if anything).

I don’t know. I think several people were talking about making a system available.

Well, when if one is ever available on HECnet, I'll be delighted to test against it.

Meanwhile, now that I am finally able to assemble and LINK a working NFT and FAL and have fixed the incorrect OS type number issue, I bumped into another problem.  Naturally, it's doing directories.  When doing an ANONYMOUS directory of MIM:: (I.E., DIR MIM::*.*), I got:

MIM::DU1:[DECNET]

....

[Parsing Name message]
[Parsing Attributes message]
[Parsing Date/time Attributes message]
[Parsing File Protection Attributes message]
[Parsing Name message]
DTRCOM.LST;115;P775656          10 18944(8)   24-Oct-2021 15:06:46
[Parsing Name message]
[Allocated Receive buffer (Words=225 Len=1056)]
?Logical link reception error - Record is longer than user requested
Logical link abort reason(0) - No error

So it died on whatever the file is that follows MIM::DU1:[DECNET]DTRCOM.LST;115

Sigh...