Path: ns-mx!hobbes.physics.uiowa.edu!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!news-server.csri.toronto.edu!helios.physics.utoronto.ca!aurora.physics.utoronto.ca!neufeld From: neufeld@aurora.physics.utoronto.ca (Christopher Neufeld) Newsgroups: comp.sys.apple2 Subject: Followup on ZModem transfers on ProTerm 3.0 Summary: Here's a fix, don't know why it works. Also, buy PT3! Message-ID: <1992Jan19.185452.14802@helios.physics.utoronto.ca> Date: 19 Jan 92 18:54:52 GMT Sender: news@helios.physics.utoronto.ca (News Administrator) Organization: University of Toronto Physics/Astronomy/CITA Lines: 56 Well, thanks to everybody who followed up on my original posting, and thanks especially to Greg Schaefer, the author of ProTerm 3.0, who went to a lot of trouble to help me through email in getting ZModem working properly. Anybody out there who hasn't bought the program yet should send away for it _now_. Within 24 hours of getting ProTerm 3.0 I had archived off my hard disk all my other comm programs, and I'll probably never extract those archives again. Well, the problem, for those who've forgotten, was that when PT3 did its disk writes at the 43kB mark in a ZModem transfer, the UNIX host's 'sz' program got tired of waiting all of three seconds for the hard disk at my end to finish, and terminated the transfer. So I had to manually resume each transfer after each 43kB. The first thing I did was to get the most recent version of 'sz'. That is version 1.36. People who are experiencing troubles might try typing 'sz' alone on the command line and checking the bottom line of the help screen this produces for the version number. If you want the zmdoem 1.36 sources, in /bin/sh format, email me, I'll keep them in my account for a week or two. Now, v1.36 still did the same thing as v1.26 when invoked without switches. It looks like somebody goofed when they packaged 1.36 in the FTP archives, because the man page included with it is the one from 1.26. Well, one of the switches which is not described in the manual, but is new to v1.36, is the -w switch. Now, I don't know why this works, but when you invoke: sz -w 44032 , or, for that matter, invoke: sz -w 16384 , the transfer works properly. That is, PT3 buffers 43kB of data (even when the window switch is set to 16384) and then writes it to disk, and 'sz' waits patiently for that to happen, and resumes the transfer when PT3 is ready for it. So, the fix, and I'd bet this works also for that Mac transfer problem somebody posted, is the following: Ensure v1.36 is installed. If it isn't, FTP the source or email me for it. If your sysadmin doesn't want to install it, build it in your account and then install it in your ~/bin subdirectory. In your .login file, insert the command: alias sz "sz -w 44032" if v1.36 is in the /usr/bin directory, otherwise use: alias sz "~/bin/sz -w 44032" if it's in your own ~/bin subdirectory. Now, everything should work properly under PT3. Note that this fix is for a rare problem. Most people will be able to use PT3 without all this fiddling. It's just a quirk of my UNIX host, something about the way the shell gets port characteristics or some similar arcane nonsense. Many people have posted to say that they had no trouble with PT3, and Greg was unable to reproduce my problem, though he ran the same version of 'sz' on the same type of UNIX CPU, transferring back to his computer under PT3. If, however, you're getting the timeout error messages after the disk write at 43kB, try this fix. Again, sincere thanks to Greg Schaefer. Thanks also to unknown for giving me Greg's email address. -- Christopher Neufeld....Just a graduate student | "I've learned never to neufeld@aurora.physics.utoronto.ca Ad astra | become too attached to cneufeld@{pnet91,pro-cco}.cts.com | a house." "Don't edit reality for the sake of simplicity" | Johnny Carson Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!ihnp4.ucsd.edu!news.service.uci.edu!orion.oac.uci.edu!thoang From: thoang@orion.oac.uci.edu (Trangdaithi Hoang) Newsgroups: comp.sys.apple2.comm Subject: Re: LineLink 144e Date: 10 Mar 1994 05:09:28 GMT Organization: University of California, Irvine Lines: 18 Message-ID: <2lma28$n3m@news.service.uci.edu> References: <2llh73$b9q@usenet.INS.CWRU.Edu> <2llimr$80f@nkosi.well.com> NNTP-Posting-Host: orion.oac.uci.edu In article <2llimr$80f@nkosi.well.com>, Joe Kohn wrote: >When I ordered the LineLink, I asked specificially whether the cable is a >handshaking cable. They said it's unneccessary, as handshaking is built into >the modem. So, I tried using my old cable with it, and everything seems >fine. I asked Jerry Cline about that, and he said the true test was to see >if I could do a Zmodem download with no loss of data. I downloaded a 220K >file using Zmodem, and it arrived just fine. So, apparently, a hardware >handshaking cable is not always required. Interesting... The real true test is to see if you can upload without errors. The RTS handshaking line required for error free downloading seems to be standard on all modem cables. On the other hand, the CTS handshaking line required for uploading is connected differently from cable to cable. If it's not connected the way ProTERM v3.1 requires it then you will have problems uploading when using streaming protocols such as Ymodem-G or Zmodem.