Xref: utzoo comp.dcom.modems:8938 comp.unix.questions:29727
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!uwm.edu!rutgers!devon!eds1!shpu1!dz9516
From: dz9516@shpu1.UUCP (Zechman DN)
Newsgroups: comp.dcom.modems,comp.unix.questions
Subject: Re: DSZ ZMODEM problem
Summary: Play with stty (esp. "autoflow")
Message-ID: <826@shpu1.UUCP>
Date: 22 Mar 91 19:02:47 GMT
References: <9857@jjmhome.UUCP> <1991Mar16.190010.21805@cs.wayne.edu> <59667@aurs01.UUCP>
Followup-To: comp.dcom.modems
Organization: Shippensburg Univ., Shippensburg, PA
Lines: 24


I have seen the same problem with sz/rz on the Unix system at Bucknell
University.  What FIXED the problem for me was taking a look at the
tty settings with "stty -a" and hunting for line conditions different
from what I'd have on a typical BBS connection (8-bit/no parity/one
stop bit/no XON-XOFF/etc.).

The setting "autoflow" turned out to be the one that was wreaking havoc
on ZModem.  Doing an "stty autoflow" before the transfer made it work
FLAWLESSLY.  If your particular Unix doesn't have an "autoflow" setting,
(I think it may be BSD only) check the man pages for stty for anything
having to do with flow control.

I hope this info is a help to someone.  It's no fun having transfer rates
that are slower than reading the hex dump yourself!  :-)

--Dwayne

#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#
%  ***  Dwayne N. Zechman ***   *** Shippensburg University of PA ***     %
#    May all your troubles      USENET:   dz9516 @ shpu1.UUCP      (Now)  #
%      be happy ones.           BITNET:   DNZ @ SHIP.BITNET (FINALLY!!!)  %
#             --original      InterNET:   (HAH! I can DREAM, can't I?!?)  #
%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%