Date   : Wed, 18 Jan 1984 00:27:00 EST
From   : Robert L. Plouffe <PLOUFF@mit-mc>
Subject: mdm716/717 buffer size

The following message from Keith Petersen correctly and
completely explains the reason for the 2k file transfer
buffer.  He assumed as I did that the data capture buffer
(even if started at the same point) and the file transfer
buffer had independent size limits - i.e, one set by the
BUFSIZ equate for file transfer, and the other set by
checking to see if either the CCP or BDOS (optionally) was
about to be overwritten so that the whole TPA can be used
on a dynamic basis for data capture.  This is the way that
the program always used to work. HOWEVER, it was changed
somewhere along the line and it now allows the printer
buffer to use the TPA dynamically and fixes both the file 
transfer and data capture buffers to BUFSIZ. THIS NEEDS TO BE
STRAIGHTENED OUT SO THAT THE FILE TRANSFER BUFFER CAN BE
SET TO 2K (THE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH),
AND THE DATA CAPTURE BUFFER ALLOWED TO USE THE TPA WITH
A COMPROMISE SIZED PRINTER BUFFER (FIXED) [4K OUGHT TO BE 
ENOUGH].  If I understand the mail correctly, Ron Fowler
is working on this, or some variation, and it will hopefully
be in MDM718.

In the mean time, the only thing that can be done is to leave
the BUFSIZ equate set at 16 as Hoff has done in MDM717.


Do make sure to SAVE 69 after patching with DDT as Keith has
repeatedly warned because ever since MDM715, the program has
been larger than indicated in the overlay patch files.


Forwarded message:
Date: Wed, 11 Jan 84 21:40:07 EST
From: Keith Petersen <w8sdz at brl-bmd>
To:   Charlie Strom (NYU) <strom at brl-bmd>
cc:   Chan.CST at hi-multics, INFO-CPM at brl-vgr
Re:   buffer size in mdm716

Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717
"in progress" and we should have something forthcoming from them with
these fixes in about a week.  I'd hate to see all that good stuff that
Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't
agree with it" or "doesn't like it".  That's how we lost the "retry
after ten errors" option, amoung other things.

On the subject of the 2k buffer size.  This is true ONLY for the
protocol file transfer mode.  It does not affect the terminal
capture mode.  It was done after NUMEROUS complaints from people
with slower disk systems which took so long writing the 16k buffer
out (and consequently closing that extent and opening the next
in the directory) that they lost the next sector and several tries
from the sender.  In many cases this caused the transfer to abort.
The 2k buffer was chosen MANY versions back (when the program was
MODEM2) as an acceptable compromise between disk access speed
and the improvement in receiving speed by putting the characters
into the buffer instead of writing every sector (which was the
way Ward Christensen's old origithe
disk.
End of forwarded message..