koren@hpfelg.HP.COM (Steve Koren) (05/31/90)
> Obviously, this is quite aggravating. What I can do is a sz -l 1024, which > cause UNIX's ZModem to need a acknowledgement every 1024 bytes, and then > everything works fine. However, this is only a partial solution, because (1) > it slows down the transfers a little, given an infinitely fast storage medium > on the compute r(read: I'm using a RAM disk), but takes even longer than when > the two machines bobble around when using a floppy, since JRComm writes the > entire block to disk before sending the acknowledgement. You are probably using the last freely distributable JRcomm. However, a more recent one available to registered users has the ability to do asynchronous writes to floppy; ie, it will save one block while receiving another. This should alleviate your problem. BTW, JRcomm is a *great* terminal program, especially now that it has ansi and vt100 emulation, etc. Its well worth the small price he asks for it. The lastest one (0.99) is better, faster, and more configurable than most commercial terminal programs I've seen. Way to go Jack! - steve (koren@hpfela.HP.COM)
jprad@faatcrl.UUCP (Jack Radigan) (06/01/90)
upl@gumby.cs.wisc.edu (Undergrad Projects Lab) writes: >Anyway, using JRComm's and the Unix's (yeah, the VAX is running UNIX), everything >goes fine until I get to 2048 characters. Then, I get a "Data Sub Packet too >long" message (ALWAYS!), and the machines kind of dink around until they >become re synchronized. Generally, this results in a net time of about half >an hour to transfers a 50K file! (ARGH!) ZMODEM is a full-flow or streaming protocol, which requires some sort of flow control if the sender is able to transmit data faster than the modem or receiver can accept it. Otherwise, you will need to use a window size to prevent ZMODEM from overflowing the modem and/or receiver. I'm not a UNIX head, much less so with VAX, you'll need help from someone else for that. -jack-
upl@gumby.cs.wisc.edu (Undergrad Projects Lab) (06/01/90)
Well, looks like I'm going to send my money to Jack... Jack, the money's in the mail TODAY! As far as other replies I've gotten: Two people said that they had the same problem, one with a VAX, and one with a Sun. The one with the VAX said that is just magically went away when the VAX's OS was upgraded (little chance of that happening here... :-) ). The one with the Sun is still suffering, like me. Anyway, guess I'll just forget about it and use the REAL JRComm! ---Joel Kolstad kolstad@uhura.cs.wisc.edu
phoenix@ms.uky.edu (R'ykandar Korra'ti) (06/02/90)
In a recent article, Steve (koren@hpfela.HP.COM) said: >BTW, JRcomm is a *great* terminal program, especially now that it has >ansi and vt100 emulation, etc. Its well worth the small price he asks >for it. I played with version 0.94 for a while, and had a couple of major problems with it: the telephone book interface really drove me batty (entering data was not a pleasurable experience in the least...) and the lack of double-buffering on the screen in 16 colour mode. Do you know if these have been corrected? I'd like something with better ANSI emulation than Access V1.42. Other than that, it looked good. If these have been fixed (I consider them important enough to not use the programme right now, since I've managed to make a working termcap for Access), I'll look into it again. - R'ykandar. -- | R'ykandar Korra'ti | Editor, LOW ORBIT | PLink: Skywise | CIS 72406,370 | | Elfinkind, Unite! | phoenix@ms.uky.edu | phoenix%ms.uky.edu@ukcc.bitnet | | "Careful, mom, the toys are loose!" - from The Wizard of Speed and Time |
jimb@faatcrl.UUCP (Jim Burwell) (06/02/90)
upl@gumby.cs.wisc.edu (Undergrad Projects Lab) writes: >I'm currently using JRComm at home on my A-500, and use a VAX down at the >university. I want to transfer software using ZModem, since it's much faster >than the dreaded Kermit. >Anyway, using JRComm's and the Unix's (yeah, the VAX is running UNIX), everything >goes fine until I get to 2048 characters. Then, I get a "Data Sub Packet too >long" message (ALWAYS!), and the machines kind of dink around until they >become re synchronized. Generally, this results in a net time of about half >an hour to transfers a 50K file! (ARGH!) [stuff deleted] This looks like a flow control problem. Is the dialup you're using a serial-port on the CPU, or is it a terminal server ? If the case is the former, and your Vax is running a 4.2 BSD derivitive, and the modems/cables are configured for hardware handshaking, do an "stty crtscts". Actually, the "crtscts" ioctl may be SunOS 4.x specific, so it may not exist on your system. If the case is the latter you must turn on some sort of flow control on the terminal server. Every manufacture has a different way. (on our Cisco box, it's "term flowcontrol none|hardware|software [in|out]") Of course, hardware flow control is preferable, but the modem/cable must also be set for that. The bottom line is that for Zmodem to work reliably over an MNP (or PEP, for that matter) connection, you must have some sort of flow control enabled. If you don't, the modem's buffer could overflow if the modem gets behind transmitting its data to the other modem (due to block retransmits, or if you run asymetrical data rates between the modem and DTE). If you need any help configuring Cisco boxes or Suns for hardware flow control, you can send me some mail.. C'ya, Jim -- James S. Burwell UUCP: ...!rutgers!faatcrl!jimb Internet: jimb@faatcrl.UUCP "The Maker is the one who is part of what he makes." - The Redbird, from _The Tales of Alvin Maker_
jprad@faatcrl.UUCP (Jack Radigan) (06/04/90)
phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: > I played with version 0.94 for a while, and had a couple of major >problems with it: the telephone book interface really drove me batty >(entering data was not a pleasurable experience in the least...) and >the lack of double-buffering on the screen in 16 colour mode. Do you >know if these have been corrected? I'd like something with better ANSI >emulation than Access V1.42. The phonebook is the way it is due to the flexibility it gives you, there is no *easy* way to allow you to edit each entry and still allow it to completely reconfigure JR-Comm. I have done some tweaks here and there, but it is still pretty much the same as before. If you've got some ideas for a "better" interface, I'm certainly willing to listen to them. The 16 color display has always buffered serial input, but there were a few problems that could still cause data loss which have been corrected for 1.0. You still are limited by the output rate of the display though, that can't be helped with a 16 color screen, it sucks up too much chip DMA to make it practical for unchecked input at baud rates above 2400bps. -jack-