Article 152334 of comp.os.vms:
In article <32046456.6285475@news.demon.co.uk>,
Steve Rowland <steve@srowland.demon.co.uk> wrote:
: We support a remote MicroVax3100 system from our MicroVax3100 over a
: 14,400 modem using Kermit for file transfers. The modem connection
: works fine using set lat/modem to connect to the remote site but as
: soon as kermit is invoked to transfer files the connection seems to
: slow to a snails pace. Even the smallest of files take minutes and
: some -times hours.
: 
: We know we are doing somethng wrong but hours of head-scratching and
: looking through the on-line help files has failed to alleviate our
: problem.
: 
I assume you know how to use Kermit commands to control the packet length,
window size, etc, to increase throughput.  However, transferring files INTO
a LAT connection is not something that LAT was ever designed to allow.  LAT
can send stuff from the computer to the "terminal" at a hellish rate, but it
expects, and was designed for, only occasional keystrokes from the terminal,
not continuous streams of data.  Theoretically "set flow xon/xoff" in VMS
C-Kermit (which translates to "set terminal /ttsync/hostsync") should take
care of any overruns due to the small LAT buffers involved, but experience
shows this is not usually the case.  The VMS C-Kermit "beware" file,
CKVKER.BWR, talks about this:

"Reportedly, when transferring files TO a VMS system over a LAT connection
(for example, from a PC equipped with PATHWORKS and MS-DOS Kermit), packet
sizes greater than 255 (some reports say 70!) cannot be used, irrespective
of the VMS SYSGEN parameters regarding MAXBUF, etc.  The problem seems to
lay in the LAT protocol itself, or the particular implementation of it,
whereby applications are not informed of -- and cannot find out -- limits on
transmission."

Anybody who has better information, please speak up.

Thanks.

- Frank