sz program in Unix 4.3

lean@sbcs.UUCP (Lean L. Loh) (09/24/87)

 I've compiled the zm/rz/sz (Xmodem,Ymodem,Zmodem) program on our Unix 4.3
running on a VAX780, and have not been able to get it to work. After
initiating a rz filename, I issued a send file from my terminal program,
but it always timeout with a message <transfer canelled by receiver>.
Doing a sx -X filename on the VAX, and then doing a receive on my terminal
program would result in nothing getting tranfered and also hanging up the
VAX side usually.  I tested this with 3 different terminal program that I have
used successfully in the past (only using Xmodem protocol).  Any advise??
 Much thanks in advance.
-- 
CSNET: lean@sbcs.csnet
ARPA: lean%suny-sb.csnet@csnet-relay.arpa
UUCP: {allegra, hocsd, philabs, ogcvax}!sbcs!lean

hakanson@mist.cs.orst.edu (Marion Hakanson) (09/28/87)

In article <612@sbcs.UUCP> lean@sbcs.UUCP (Lean L. Loh) writes:
>
> I've compiled the zm/rz/sz (Xmodem,Ymodem,Zmodem) program on our Unix 4.3
>running on a VAX780, and have not been able to get it to work. After
>initiating a rz filename, I issued a send file from my terminal program,
>but it always timeout with a message <transfer canelled by receiver>.

You didn't say what type of connection you were attempting this
across, but I have seen the identical behavior on various 4.[23]bsd
machines, and have traced the problem here to running the zmodem
protocol over telnet connections with bugs in binary modes.  The
<transfer cancelled by receiver> invariably means that there was a bad
checksum which caused the packet(s) to be retransmitted the maximum
number of times without success.  The same transfer works fine over a
direct dialin line.

What's interesting to me is the fact that I can send files from the
Unix machine to my ST, but not vice-versa.  The network connection
is capable of transferring 8-bit data and control characters in one
direction, but not the other.  If I use "rlogin <host> -8 -L" to make
the same connection, then the transfer will work in either direction.

I'm pretty certain the fault is with a Bridge CS/100 TCP connection
to our 4.[23] machines.  Connecting from one Bridge to another one
works fine.

Anyway, this may not be the cause of your problem, but likely it
is a similar problem (corrupted data and/or checksum).  Good luck.

Marion Hakanson         Domain: hakanson@cs.orst.edu
                        CSNET : hakanson%cs.orst.edu@relay.cs.net
                        UUCP  : {hp-pcd,tektronix}!orstcs!hakanson