Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!sun.soe.clarkson.edu!batcomputer!cornell!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: - DSZ Zmodem Rz/Sz Zcomm -
Message-ID: <23a4d0fd@ralf>
Date: 13 Dec 88 08:12:45 GMT
Sender: ralf@b.gp.cs.cmu.edu
Lines: 18
In-Reply-To: <15744@iuvax.cs.indiana.edu>

In article <15744@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
}If you're connecting to your host via a network, that network's
}involvement may be preventing successful zmodem transfers.  The "Sytek"
}coax cable that I.U. employs does this, possibly because it imposes
}XON/XOFF protocol on the connection whether the endpoints want it or not

No, XON/XOFF doesn't bother Zmodem, since it never sends those characters in
the data packets (it does send an XON at the beginning to make sure things
aren't stopped).  It can also handle the connection swallowing any control
character but ^X with the -e option.  What Zmodem absolutely can't handle is a
seven-bit connection or one that swallows ^X.  The protocol document from Omen
Technologies does indicate that seven-bit transfers may be implemented in the
future (there's a flag bit in the pre-transfer negotiations).

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school)
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/31
Disclaimer? I     |Ducharm's Axiom:  If you view your problem closely enough
claimed something?|   you will recognize yourself as part of the problem.