Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!garnet.berkeley.edu!ked
From: ked@garnet.berkeley.edu (Earl H. Kinmonth)
Newsgroups: comp.dcom.modems
Subject: Re: xyzmodem problems
Message-ID: <24440@agate.BERKELEY.EDU>
Date: 15 May 89 16:08:46 GMT
References: <24404@agate.BERKELEY.EDU> <8457@chinet.chi.il.us>
Sender: usenet@agate.BERKELEY.EDU
Distribution: usa
Organization: University of California, Berkeley
Lines: 33

In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
>>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols)
>>work for downloads, but uploads INVARIABLY stop after 16 blocks have
>>been transferred.  This is consistent over half a dozen different machines
>
>>Any ideas?  kermit works (with mark parity).
>
>Something in the link is set to use XON/XOFF flow control.  Packet 17
>in x/ymodem will use a literal 17 (control-S) as the packet number
>and hang the link.  The only control character kermit uses is
>control-A for start-of-packet, others are forced into the printable

Several people have suggested an xon/xoff problem. This may be the
case, but I haven't lucked into the right set of operations yet. I
tried stty -tandem tandem on the SUN and VAX hosts without luck. As
time permits, I'll keep trying.

I have had one success. Using

rz -e

on the host does allow uploads with Zmodem from my ATT 6310 running SCO
Xenix. According to the zmodem manual, -e causes the sender (sz) to
"quote all control characters." This works on both my leased line and
2400 baud modem.

I haven't timed zmodem vs kermit on uploads yet. On downloads, at least
with base 85 encoded files, kermit seems to win: average xfer rate on
9600 baud line of 560 chars/sec vs 340 for zmodem. Maybe there is more
tuning that needs to be done.

Thanks to all who offered help. Any further ideas still welcome.