hartung@amos.ling.ucsd.edu (Jeff Hartung) (04/25/89)
Hello, In the recent discussions about Procomm, someone mentioned Telix, so I decided to look around for it. I found it at SIMTEL20, so I downloaded the files (sorry, I don't have the version handy!) and tried it out. In many ways, I liked it quite a bit, especially as compared to Procomm, but there were some problems with file transfers that I encountered and I can't seem to solve them. Because I didn't have X, Y or Z modem available here, I FTP'd the source for X/Y/Zmodem from uunet.uu.net and compiled it. (The problem *might* be with sz, rz, etc. and not Telix.) Anyhow, the first thing I tried was downloading a small file from the VAX. The download failed with the Zmodem protocol, but worked fine with Xmodem and Ymodem (sx & sb) just fine. Kermit also failed to download. I then tried to upload a file, and found that Zmodem and Kermit would work, but Ymodem and Xmodem didn't work. Since then, I've found that there are exceptions to the above rules when only Kermit will upload, or *nothing* will download, but if I use Kermit 2.32/A, then the file transfers work great. However, they also take up more than twice the time that they would with Zmodem, which is what I really want to use. Is this: (a) A problem with Telix? (b) A problem with the X/Y/ZModem source code from UUNET? (c) A problem with the protocols themselves (i.e. this frequently happens with Z-modem transfers...)? (d) A combination of the above? (e) None of the above (e.g. I'm doing something wrong, some other factor is the source of my problems, etc.) Thanks in advance for any help that anyone might have. I'd *REALLY* like to speed up my file transfers. Oh, by the way, I have to use parity set to space, 7 data bits, one stop bit, or my screen prints garbage when I login. Is this the problem? Some binary files *have* downloaded with the Y-modem protocol successfully, but others get stuck about halfway. --Jeff Hartung-- Disclaimer: My opinions only, etc., etc., BLAH! BLAH! BLAH!... ARPA - hartung@amos.ucsd.edu UUCP - ucsd!amos.ucsd.edu!hartung
pathak@s.cs.uiuc.edu (04/26/89)
I would suggest you check out the parity settings. I use Telix t [up/down] load from both local BBSi and UNIX hosts and it works great for me. I have used all the protocols that you have mentioned, so I do not think the problem is in Telix. Heeren Pathak s.cs.uiuc.edu zaphod.ncsa.uiuc.edu
hartung@amos.ling.ucsd.edu (Jeff Hartung) (04/27/89)
In article <89Apr25.225050edt.19728@me.utoronto.ca> rwh@me.utoronto.ca (Russell Herman) writes: >I had similar problems, and the solution may be relevant to you as well. >Use "-l 1024" in your SZ calls. I suspect the problem relates to not >doing flow-control in realtime when connected over a network (in my case, >a T1 link). Thanks, everyone, for all the help with Telix (which was version 3.11 from SIMTEL20, by the way). What I had to do to get the Zmodem transfers to work correctly in both directions was: (1) Put 'stty pass8' in my .login to accept 8 bit data from the standard input on the VAX. (2) Use parity set to none with 8 data bits, one stop bit when I logged in from home. (3) Use the '-l' option with sz. (Since it worked, I added the line: alias sz 'sz -l 1024 \!*' to my .cshrc file.) Everything works great, now. Thanks again. I, too, highly recommend this package. --Jeff Hartung-- Disclaimer: My opinions only, etc., etc., BLAH! BLAH! BLAH!... ARPA - hartung@amos.ucsd.edu UUCP - ucsd!amos.ucsd.edu!hartung