Path: utzoo!attcan!uunet!husc6!bbn!apple!well!svc
From: svc@well.UUCP (Leonard Rosenthol)
Newsgroups: comp.sys.mac
Subject: Re: Xmodem uploads using MicroSoft Works ( Troubles )
Summary: Are you sure about that??
Keywords: Xmodem Works Mac
Message-ID: <11333@well.UUCP>
Date: 16 Apr 89 20:40:05 GMT
References: <1402@mimir.dmt.oz> <6777@bsu-cs.bsu.edu>
Lines: 46

In article <6777@bsu-cs.bsu.edu>, mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes:
> In article <1402@mimir.dmt.oz>, paz@mimir.dmt.oz (Paul Zemancheff) writes:
> > 
> > [Problems with MSWorks and XMODEM]
> >
> 
> I have had this same type of problem with Microsoft Works, Mac240, and a 
> copy of Zterm (0.75) when trying to upload using Xmodem to a UNIX host.
> Downloading works fine with all applications, but uploading locks up after
> the first characters on all of them.
> 
	Are you uploading MacBinary formated files or text files?  If the
former did you remember to tell the host that (ie. something like xmodem -sb
for send binary!)?  If you tried to send a binary file to a host exepecting
a text file, the host could get hosed because the binary data could contain
some ctrl-chars (and other stuff) that it might not like as text.  Check
that and see if that had anything to do with it.

> I have been told that this could have something to do with flow control.
> Apparently, the Mac can send data faster than the host can receive so the
> host sends out a control-s (binary equiv, of course) from hardware,
> causing a lockup in the protocol.  I don't know if this is true, but in our
> case here at Ball State it is a valid argument not because the host sends
> out the control-s, but because our wonderful (&*&%*) AT&T ISN network does
> its own flow control unless the system administrator explicitly disables it
> port by port.  Of course, he would not do this for just anyone (especially not
> a student...)
> 
	We were sitting aroudn the office lately discussing a similar topic
and it seemed to us that a host SHOULD NOT be sending an XOFF (Ctrl-S) in
the MIDDLE of a XMODEM/YMODEM transfer!  Since the host has to waitfor/send the
ACK/NAK to let the other side know about the status of the transfer, the slower
side could simply hold off sending/responding until it is good and ready! It
is conceivable that during a YMODEM-G transfer where not other flow control is
used (non-error correcting protocol) that XOFFs could be sent to slow down the
transfer (or other forms of flow control) but not during an XMODEM/YMODEM
tranfer.
	Seems to me that there is some other problem.  I have been doing UNIX
up and downloads for a while now and have never had any problems with X/Y or Z
MODEM.;

-- 
+--------------------------------------------------+
Leonard Rosenthol        |  GEnie : MACgician
Lazerware, inc.          |  MacNet: MACgician
UUCP: svc@well.UUCP      |  ALink : D0025