Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!rutgers!att!mtune!petsd!pedsga!tsdiag!scr1!pechter
From: pechter@scr1.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Procomm in vt-100 mode
Summary: Use kermit
Message-ID: <312@scr1.UUCP>
Date: 14 Apr 89 18:46:06 GMT
References: <2672@garth.UUCP> <4917@tekgvs.LABS.TEK.COM>
Reply-To: pechter@scr1.UUCP (Bill Pechter)
Organization: CONCURRENT COMPUTER,OCEANPORT NJ
Lines: 31

In article <4917@tekgvs.LABS.TEK.COM> keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes:
>Our siroal communication system at work cupports only printable
>ASCII: packet 19 (13 hex) chokes the connecter boxes because they
>process ^S's from the "terminal" (utilizing their own internal
>buffers).
>
>We had similar problems trying to do binary transfers.  See if
>infact you're getting the first 18 packets and the thing chokes when
>the 19th (the "^Sth") packet tries to get through.
>
>kEITHe

This is a problem with Xmodem inspired protocols.  Kermit allows Xon-Xoff
handshaking and sends the packet headers in ascii, not binary.  This way you
never get this deadlock xoff condition.

I've had the exact same problem with Sytek Local-Net 20 boxes at a system
at Fort Monmouth, NJ..  I needed xon-xoff flow at 9600 and the network 
units lost characters going to Unix without it.  The fix was going 
to MS-Kermit on the PC (or Procomm's Kermit) and Unix  Kermit on the Vax.
No problems after the switch to Kermit from an Xmodem based in-house protocol.
(The software guys never tested their stuff on the network and no one
at the site could figure out what the problem was).

Bill 
(ex-hardware guy)
-- 
Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709
Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 
Phone -- (201)870-4780    Usenet  . . .  rutgers!pedsga!tsdiag!scr1!pechter
**    Why is it called software when it's so hard to install. RTF what?      **