Looking at the Econet Advanced User Guide https://archive.org/details/econet-adva ... 3/mode/1up pages 63 and 64.On OSWORD &14 arg 0 (do fileserver operation),the client machine sets a byte in tge tx block to indicate its length so NFS sends the right number of bytes.
On return after a successful query, buf?1 is defined as the reply length.
Except it’s not. Neither NFS nir ANFS changes it from the tx length.
Location 1 is set up as “size of rest of block” for transmit.
The book then says “Locations 2 to 6 form the transmit header.”
And then “When your station receives a reply from the file server, the transmit header and the transmitted data are replaced by a receive header”
A strict reading of that would suggest location 1 is not part of the receive header and is not updated.
That's what you see in the older Econet System User Guide (p104+) https://archive.org/details/the-econet- ... 3/mode/2up. Padded fixed width, delimeters. etcPerhaps this is why the FS spec always has some sort of terminator in fs replies which are not a guaranteed fixed length - eg &0D or &80….
My guess is the TX buffer length was added so that new File Server commands could be added without the NFS rom needing to know anything about them, but with your telling it how much data to send to the FS. What comes back is yours to deal with. The EAUG does say "The program should know the maximum amount of data to expect from the current operation step".
Statistics: Posted by james — Fri Jun 21, 2024 5:17 am
