Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!mtgzz!drutx!clive
From: clive@drutx.ATT.COM (Clive Steward)
Newsgroups: comp.sys.mac
Subject: Re: Versaterm 3.1 background "send file"
Message-ID: <6753@drutx.ATT.COM>
Date: 15 Feb 88 02:08:17 GMT
References: <204@nvuxg.UUCP>
Organization: resident visitor
Lines: 48

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