RS> This ams call was fine, perfect infact, high thruput, no Zmodem errors
 RS> at all. Gat an MNP4 call this time, presumably as a result of you
 RS> fiddling with modem init strings at your end. I did nothing special
 RS> except left compression off.

 RS> Doesnt prove a hell of a lot yet, after all I did get one perfect call
 RS> last night too. With a dud call immediately after it.

I haven't been playing with my init string at all.  "Left compression
off" must have inadvertently left V42+V24bis off and got MNP4 instead
on your end.  This morning you connected at a multitude of speeds (why?)
and finally ended up at V42bis and my MR light started flashing again. 
Also the CTS light.  I have a theory that says that because the CTS light
is flashing, OS/2 is defintely sending data fast enough (too fast, in
fact). Now the only thing that could be happening is that my PC is ignoring
the dropping of CTS.  When the MR light was flashing this morning (in fact
most times), I didn't get any Zmodem errors. BTW, my Init string is based
on the T. Rodyhouse authorized settings.  I used that as the basis at any
rate.  Now, if my PC was not recognizing CTS, that would mean the Spirit
overflowed, right?  But that would mean it would not be able to instigate
error correction, and instead would mean Zmodem errors, because data was
being lost "by the modem".  Since I have used two Spirits, and
other people are working OK, this means that the error correction going on
either has to be a terrible STD line (thus genuine error correction is
happening), or I have my init string set wrong, and it isn't allowing
enough time for error recovery.  A lot of my thinking has involved delays
in STD, but they don't really exist, do they?  I mean, you calling STD is
IDENTICAL to someone calling locally, right?  And I am now uploading fine
(since changing com port).  Admittedly I am initiating the call.

Do you agree that the problem HAS to be either the Spirit or the phone line? BFN.

Paul

--- GoldED 2.40