mjs1@nvuxg.UUCP (Michael Sonnier) (02/10/88)
I have experienced some problems using "Send File" from Versaterm 3.1 under Multi-finder. The file transfer works ok and I can switch back to multifinder or to another application while the transfer is in progress. However if I have not returned to Versaterm when the transfer ends I get the beep notice that transfer is finished (if that option is on) and then Versaterm dies! When I return to Versaterm there is an error window with message that Versaterm has unexpectedly quit (or some such garbage...). Has this happened to anyone else? Any ideas why? My equipment: Mac Plus Here are the settings I use: Text XModem 9600 Baud Xon/Xoff active 8 bits 1 stop no parity Direct connect to UNIX Sys V (no modem) DEC VT100 emulation Signal End of File Transfer On Fast XModem w/o errors On Communications - Modem Port Thanks Michael Sonnier Bell Communications Research Red Bank NJ ...!ihnp4!bellcore!nvuxg!mjs1
clive@drutx.ATT.COM (Clive Steward) (02/15/88)
From article <204@nvuxg.UUCP>, by mjs1@nvuxg.UUCP (Michael Sonnier): > > I have experienced some problems using "Send File" from Versaterm 3.1 under > Multi-finder. The file transfer works ok and I can switch back to multifinder > or to another application while the transfer is in progress. However if I > have not returned to Versaterm when the transfer ends I get the beep > notice that transfer is finished (if that option is on) and then Versaterm > dies! When I return to Versaterm there is an error window with message that > Versaterm has unexpectedly quit (or some such garbage...). Has this happened > to anyone else? Any ideas why? Yes, it happens, and yes, ideas why. Xon-Xoff flow control is dependent on the shutoff response happening before the receive buffer actually overflows. On many (especially Unix) systems with front-end processors (which includes the archtecture of many minis and super-micros, as well as mainframes), this timing can be long, if the fep isn't carefully designed to prevent it. Many dumbish terminals (some you doubtless know very well) don't really flow-control successfully at 9600 baud or above. Versaterm does seem to have a problem, specifically during that moment when the window display is changing from the 'file transfer' setup back to normal terminal screen. For those of you without, the main window shrinks, and a non-modal dialog comes up with a ruler, both small enough that you can click things behind easily to do something else while the transfer happens in the background). I have the problem, only at the beginning of a transfer, if I try to switch under Multifinder before the transition occurs. When it happens, same unexpected quit situation. I think flow control failed, and that Versaterm or its stack then gets overwritten. I haven't observed the problem, even at 19.2kbaud, so long as I let the windows change before changing to another task. I also haven't seen it ever at the end of a transfer, so wonder if you're really getting the 'begin'. As to why, or how to fix -- Versaterm either needs a longer internal buffer for those of us who run it fast (it works so well, otherwise, at speed -- really fast xmodem decoding), or there is a fix needed for something about the window transition period. It's a great program, just has a bug. Still highly recommended. Clive Steward
buckley@dalcs.UUCP (Bert Buckley) (02/17/88)
To be brief: Running Versaterm 3.1 with MF at 19.2, background file transfers have worked fine for me, except that I get "File transfer failed" if I am not back in VT when the end is reached. I will look forward to a fix: I am reluctant to do background transfers in case I don't get back in time.
straka@ihlpf.ATT.COM (Straka) (02/17/88)
In article <6753@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: |From article <204@nvuxg.UUCP|, by mjs1@nvuxg.UUCP (Michael Sonnier): || || I have experienced some problems using "Send File" from Versaterm 3.1 under || Multi-finder. The file transfer works ok and I can switch back to multifinder || or to another application while the transfer is in progress. However if I || have not returned to Versaterm when the transfer ends I get the beep | |Yes, it happens, and yes, ideas why. | |Xon-Xoff flow control is dependent on the shutoff response happening before |the receive buffer actually overflows. On many (especially Unix) systems with |front-end processors (which includes the archtecture of many minis and |super-micros, as well as mainframes), this timing can be long, if the |fep isn't carefully designed to prevent it. I talked to Lonnie Abelbeck,(the primary author, for those of you who don't know) and he sheepishly admitted that he had put some hooks in for a future feature, and a small bug crept in. He stated that the currently (this was around 1/1/88) shipping version is fixed. This version is still called 3.1, but look at the date in the "Welcome Box" when you fire up the program to discern actual release date. I haven't gotten around to upgrading yet. It doesn't bother me THAT much. |As to why, or how to fix -- Versaterm either needs a longer internal |buffer for those of us who run it fast (it works so well, otherwise, |at speed -- really fast xmodem decoding), or there is a fix needed for |something about the window transition period. I don't know what the bug actually was. |It's a great program, just has a bug. Still highly recommended. Agreed. (SDA) -- Rich Straka ihnp4!ihlpf!straka Advice for the day: "MSDOS - just say no."
preese@dewey.soe.berkeley.edu (Phil Reese) (02/18/88)
In article <2779@dalcs.UUCP> buckley@dalcs.UUCP (Bert Buckley) writes: >To be brief: Running Versaterm 3.1 with MF at 19.2, background file >transfers have worked fine for me, except that I get "File transfer >failed" if I am not back in VT when the end is reached. I will look >forward to a fix: I am reluctant to do background transfers in case >I don't get back in time. While I haven't tried the specific situation that you describe I think it is important to point out that there has been TWO upgrades to VersaTerm since version 3.1. I believe the current version is 3.20, Jan 10, 1988. Lonnie has the interesting policy of making small changes to the program but not bumping the version number. Thus there was a version 3.2 in October and now there is still version 3.2 but a release date of Jan 10. He is very tuned to using MultiFinder so I would expect better performance all around if you use the current version. Phil Reese SESAME Group School of Ed, UC Berkeley preese@garnet.berkeley.edu {decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!garnet!preese