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
mju@mudos.ann-arbor.mi.us (Marc Unangst) (04/25/89)
In article <6292@sdcsvax.UCSD.Edu>, hartung@amos.ling.ucsd.edu (Jeff Hartung) writes: >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. ... >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.) My guess would be either (d) or (b). Since you didn't mention a version number, I can't be sure if you have the latest version (v3.11), which fixes a bug in the Zmodem protocol. If you don't have v3.11, you can probably get it from most any IBM BBS, or, failing that, Compuserve or GEnie. grape.ecs.clarkson.edu might have it, but it probably doesn't. You mention that you have to use 7 data bits in order to connect. Because any binary protocol (other than when you use 8th bit quoting with Kermit) needs an 8 bit data path, Zmodem will try to change the line parameters before starting the transfer. If the actual physical pathway is only 7 bits wide, then it won't be able to do this. Since you say that you've used Ymodem successfully, then I'd guess that it IS possible to switch the connection to N-8-1. I really don't know what more to say. I've successfully used Telix's Zmodem to transfer files to and from an Altos System III system (with specially-modified versions of s[xyz] and r[xyz]), and to and from most IBM BBSs. One thing you might try is getting the DSZ package, from Chuck Forsberg. It is a standalone file transfer program that supports Xmodem, Xmodem-1k, Ymodem, Zmodem, plus Ymodem-G and some other stuff if you register it. It's usually used by shelling out to DOS from Telix (via Alt-J), and then invoking it from the command line ("DSZ sz c:/dir1/dir2/file", for example). It installs its own communications drivers, does the transfer(s), and then replaces the existing ones. It's meant especially for use on already-established connections. If DSZ works and Telix doesn't, then the problem fairly obviously lies with Telix's implimentation of Zmodem. If neither of the two work, then I'd start questioning the VAX sz/rz, or the actual connection itself. Tell me, does (1) The file download okay, but end up as gibberish when you try to read it; or (2) Does the download totally fail to complete? If it's (1), I'd start looking into subtle bugs in the VAX sz/rz, or into the connection itself; if it's (2), then I'd bet that you either have a corrupted copy of Telix (unlikely; the archive would have shown the damage when you tried to unarc it), or a buggy version of sz/rz (more likely). Check them both. -- Marc Unangst UUCP : mju@mudos.ann-arbor.mi.us UUCP bang : ...!uunet!sharkey!mudos!mju UUCP bang alt.: ...!{ames, rutgers}!mailrus!clip!mudos!mju Internet : mju@mudos.ann-arbor.mi.us
burleigh@silver.bacs.indiana.edu (frank burleigh) (04/25/89)
As long as people are discussing Telix 3.11 file transfers, here's another problem -- with UPloads. Although I can reliably DOWNload files with sz/Telix 3.11, I cannot UPload them with Telix/rz. X and Y-modems UPloads also fail. It's as though they never start. This is on an Ultrix system through an Ungermann-Bass terminal server. BINARY is set ON (which is why downloads work). If anyone has suggestions and similar experiences, please e-mail. -- Frank Burleigh burleigh@silver.bacs.indiana.edu USENET: ...rutgers!iuvax!silver!burleigh BITNET: BURLEIGH@IUBACS.BITNET Department of Sociology, Indiana University, Bloomington, Indiana 47405
rwh@me.utoronto.ca (Russell Herman) (04/25/89)
You may have to play around a bit with ZMODEM. If you're using some sort of packet-switching, or something that interferes with reasonably real-time flow-control, try using the "-l nnn" on sz. I got puzzled by this one for awhile. Also turn on the various debugging output to generate the szlog file; that may give you some clues. I'm using TELIX and ZMODEM with complete success communicating with PC/DOS-based BBSs and a SUN3. There's a new version out (RZSZ300) that has some very specific VMS code which I can't vouch for as fortunately I don't have to deal with it... ______ Russ Herman / \ INTERNET:rwh@me.utoronto.ca UUCP:utgpu!utme!rwh @( ? ? )@ (416) 978-4987 ( || ) University of Toronto, Dept. of Mech. Eng. ( \__/ ) 5 King's College Road \____/ Toronto, Ont. CANADA M5S 1A4
paine@rust.dec.com (Willy Paine) (04/26/89)
Cc: I don't have no problem downloading/uploading with dsz if I login directly to Unix machine. Calling Unix/VMS machine through network from modem is a really different problem. I notice if I do rlogin/dlogin to another system, uploading works fine but download never work at all. I use rlogin alot because it has NFS (Network File System) and sometime one cpu is too busy so I go to another cpu. It may sound complex. Try to avoid using rlogin. Getting dsz source code is best bet because some Unix and VMS don't update zmodem clone well. Telix is my favorite but Procomm is better than Telix on vt100 emulation. I have alot of problem with vi/emacs editor using with Telix. Willy
rwh@me.utoronto.ca (Russell Herman) (04/26/89)
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).
gejohann@uokmax.UUCP (Gene Edward Johannsen) (04/26/89)
In article <6292@sdcsvax.UCSD.Edu> hartung@amos.ucsd.edu (Jeff Hartung) writes: > {Stuff about Telix downloads failing deleted} I had a big problem with Telix Z-modem downloads, too. They would keep getting TIMEOUT errors that would abort the download. A friend of mine suggested using 'sz -w 1024 filename[s]' at the UNIX end and I haven't had a single problem since. Wonder why -w 1024 isn't the default. Gene from the Home Office in Oklahoma
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
porter@caip.rutgers.edu (Adam Porter) (04/29/89)
Strange. I have the reverse problem. rz works fine between Telix on XT and Pyramid running Berkeley 4.3. However, I can't get sz to work. I keep getting error, exit code 99. Every time, I get a 'tranfer aborted' on the PC end before any packets are transferred. I tried the -w and -l options, and changed stty to 2400 but no luck. Any ideas? Adam
ttp@beta.lanl.gov (T T Phillips) (04/29/89)
In article <3816@silver.bacs.indiana.edu>, burleigh@silver.bacs.indiana.edu (frank burleigh) writes: > > Although I can reliably DOWNload files with sz/Telix 3.11, I cannot > UPload them with Telix/rz. X and Y-modems UPloads also fail. It's as > though they never start. > > This is on an Ultrix system through an Ungermann-Bass terminal server. In our setup, I connect to a VAX 7800 runing Ultrix 3.?. However, for security reasons, we go thru a multiplexer, an encryptor, a decryptor, an unmultiplexer, a so called keyboard concentrator, a distributed processor server, and finally to the VAX. On uploads this whole system chokes on the problem of sending long packets up followed by some kind of acknowledgement down. However, if I bypass our "high-speed" link, and use, instead, a "slow" 2400 baud dial up line direct to the keyboard concentrator, the Zmodem upload works just fine. The moral is don't have too much hardware between you and the host computer.