Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!gatech!mcnc!decvax!zinn!ditka!bucket!leonard
From: leonard@bucket.UUCP (Leonard Erickson)
Newsgroups: comp.dcom.modems
Subject: Re: xyzmodem problems
Message-ID: <1399@bucket.UUCP>
Date: 15 May 89 06:00:10 GMT
References: <24404@agate.BERKELEY.EDU>
Reply-To: leonard@bucket.UUCP (Leonard Erickson)
Distribution: usa
Organization: Rick's Home Grown Unix; Portland, OR
Lines: 21

In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
<From an ATT 6310 running both SCO Xenix and MSDOS, I connect to a 9600
<baud leased line which goes to a Develnet switch and thence to various
<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
<and several different xyzmodem packages on either end.  The problem
<occurs on a 2400 baud dialin as well.
<
<Any ideas?  kermit works (with mark parity).

Sure, turn off the xon/xoff filter! Block # 17 will have a ^Q as the
block number. If you have something that is intercepting software flow
control, then your xfer will die after either block 16 or block 18.
To run [x|y|z]modem you must be using hardware flow control throughout.
Software flow control will kill the xfer.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short