Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!ncar!gatech!utkcs2!usenet
From: ljwilson@utkux1.utk.edu (L. Jack Wilson)
Newsgroups: comp.dcom.modems
Subject: (SOLVED!) GVC 9600 V.42 won't download from CIS
Message-ID: <1991Jun1.020500.2520@cs.utk.edu>
Date: 1 Jun 91 02:05:00 GMT
Sender: usenet@cs.utk.edu (USENET News Poster)
Reply-To: ljwilson@utkux1.utk.edu (L. Jack Wilson)
Distribution: na
Organization: University of Tennessee
Lines: 31

A BIG, BIG thank you to   Howard_Reed_Johnson@cup.portal.com   for a
solution that works!  The following is the complete text of what he
e-mailed to me...

**************************************************************************

When I upgraded from my Supra 2400 modem (no MNP) to a Practical
Peripherals 2400SA (with MNP), I had the same problem.  My solution
(besides calling at 2400,E,7,1) was to *disable* both compression and
buffering.  I've been able to leave the error-correction enabled.  My
dialing prefix is:

AT %C0 \N1 DT ...

The %C0 disables compression, effectively running MNP4.
The \N1 disables buffering (PP calls this "direct" mode).

My guess is that this bring the protocol timing within reach of both
sides of the file transfer software.  Now, all CompuServe needs to do
to bring their "quick" protocol up to par is to implement a streaming
protocol such as ZMODEM.

**************************************************************************

Thanks to all that responded.  I had tried each of the above separately,
but not together in the winning combination.
--
Who:	L. Jack Wilson
What:	UTK OAC Microsupport
Where:	ljwilson@utkux1.utk.edu
Why:	Standard Disclaimer fits nicely here.