paz@mimir.dmt.oz (Paul Zemancheff) (04/14/89)
Help, Help, Help......
A colleague of mine has been having problems with MicroSoft Works
Xmodem uploads. I have described the problem below. Any comments about solving
these problems would be willingly accepted.
Problem Description: Xmodem facility in Microsoft Works ( MAC ) will not upload.
====================
Investigative tests carried out.
1/ Attempt to upload and download using Microsoft Works to other systems
using Xmodem.
2/ Perform same tests as above on an IBM PC version of Microsoft Works.
IN DETAIL.
The Xmodem facility in MS Works demonstrates a consistent and repeatable
failure when attempting to upload to a remote system. We have tried to upload
to our in house system and a number of bulletin booards. In all attempts
the upload fails at the commencement of the FIRST block transfer. When the
MAC receives the first NAK from the remote system, it correctly responds
with the block number and its compliment. Then after transmitting one
character the failure surfaces. See below for a blow by blow description.
This failure occurrs regardless of mode, eg text, data or binary.
NOTE, MS works on the MAC will DOWNLOAD successfully! ( curious ).
We repeated the transfer tests on IBM PC with Microsoft Works. XModem uploads
from the PC to a remote host were consistently successful. An obvious conclusion
is that this problem is peculiar to the MAC/WORKS combination.
================================================================================
MAC/WORKS xmodem upload to inhouse system. (via modem)
++++++++ Wed Apr 5 10:56:09 1989
XMODEM Version 3.6
Command line: xmodem -rbdx junk
Line speed = 2400 bits per second
----
XMODEM File Receive Function
DEBUG: sendbyte 15h
DEBUG: sendbyte 15h
DEBUG: sendbyte 15h
DEBUG: sendbyte 15h
DEBUG: sendbyte 15h
DEBUG: readbyte 01h
DEBUG: readbyte 01h
DEBUG: readbyte feh
DEBUG: packet 0 started
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 3 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
Timeout while reading sector 1
DEBUG: sendbyte 15h
DEBUG: readbyte 01h
DEBUG: readbyte 01h
DEBUG: readbyte feh
DEBUG: packet 0 started
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 3 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
Timeout while reading sector 1
DEBUG: sendbyte 15h
DEBUG: readbyte 01h
DEBUG: readbyte 01h
DEBUG: readbyte feh
DEBUG: packet 0 started
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 3 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
Timeout while reading sector 1
DEBUG: sendbyte 15h
DEBUG: readbyte 01h
DEBUG: readbyte 01h
DEBUG: readbyte feh
DEBUG: packet 0 started
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 3 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 2 characters
DEBUG: napping for 375 ms
DEBUG: readbuf--read 1 characters
DEBUG: napping for 375 ms
Timeout while reading sector 1
DEBUG: sendbyte 15h
DEBUG: readbyte 18h
DEBUG: readbyte 18h
Fatal error reception cancelled by remote.
Paul Zemancheff PHONE: +61 3 487 9271 FAX: +61 3 484 0878
CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz
Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net
Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!pazmithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (04/15/89)
In article <1402@mimir.dmt.oz>, paz@mimir.dmt.oz (Paul Zemancheff) writes: > > Help, Help, Help...... > > A colleague of mine has been having problems with MicroSoft Works > Xmodem uploads. I have described the problem below. Any comments about solving > these problems would be willingly accepted. ... > is that this problem is peculiar to the MAC/WORKS combination. > > Paul Zemancheff PHONE: +61 3 487 9271 FAX: +61 3 484 0878 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. 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...) So I'm stuck. For uploading I use Kermit; for downloading I use either Xmodem or Zmodem. If anyone has any other commemts or suggestions, feel free to e-mail me. Thanks, -Michael -- Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)
svc@well.UUCP (Leonard Rosenthol) (04/17/89)
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
aberg@math.rutgers.edu (Hans Aberg) (04/17/89)
> 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. If your session is going through a Cisco box, and you forget setting this box by 'term download', you can't upload using xmodem. Hans Aberg, Mathematics aberg@math.rutgers.edu
alexis@ccnysci.UUCP (Alexis Rosen) (04/23/89)
The Vax 11/780 that I use here just upgraded to XMODEM 3.6 from V3.5.
Prior to then there was no trouble uploading, but now I can't get uploads
to work no matter what I do. (I use Kermit instead.) Downloads continue
to work fine. So something broke across the upgrade, which is weird,
considering that the only noticeable change is specific support for the
Mac. Very odd.
The man entry for XMODEM 3.6 says:
AUTHOR
Steve Grandi, National Optical Astronomy Observatories.
Based on xmodem by Brian Kantor, University of California at
San Diego. This, in turn, was based on umodem by Lauren
Weinstein, Richard Conn and others.
It is dated 4/14/88.
---
Alexis Rosen
alexis@ccnysci.{uucp,bitnet}
alexis@rascal.ics.utexas.edu (last resort)