Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!purdue!decwrl!pyramid!prls!mips!sultra!dtynan
From: dtynan@sultra.UUCP (Der Tynan)
Newsgroups: comp.dcom.modems
Subject: Re: Verbose modems (Re: MORE 6386 UUCP WOES)
Summary: Not true - fix uucp.
Message-ID: <2653@sultra.UUCP>
Date: 12 Nov 88 03:27:30 GMT
References: <319@argon.UUCP> <2096@cuuxb.ATT.COM> <727@wsccs.UUCP> <889@vsi.COM> <6924@chinet.chi.il.us>
Organization: Tynan Computers, Sunnyvale, CA
Lines: 39

In article <6924@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes:
> In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
> >When would it be necessary to change speeds when dialing?  Why should
> >a modem accept dialing commands at one speed and then suddenly start
> >speaking another speed?  Yes, I know there are modems that do this,
> >but that doesn't mean it's a good idea.
> 
> It's a better idea than making the connection and not being able to
> do anything, which is what happens now.  A little extra code in
> the dialing routine would be all it takes to fix it, and if it were
> controlled by tokens in the dialer string it wouldn't bother the
> EIA purists.
> 
> Les Mikesell

Not true.  It's not the dialer that makes this decision.  I know, because I
ran into this VERY problem last night.  I'd make a call @ 2400baud, and for
some reason get dumped on a rotary which would only answer @ 1200.  So, the
modem sends back a CONNECT 1200, and now changes it's speed.  The dialer
program returns SUCCESS to uucico, which then cannot access the system, because
it thinks the line speed is 2400.  So, it fails while executing the 'chat'
script.  As if this wasn't bad enough, when uucico fails to make the
connection, it once again calls the dialer to hang up the phone.  Well, guess
what.  The modem won't respond to the '+++' escape, because it's talking
1200 baud now.  How autocratic!  Anyway, the line stays off-hook, until the
other end times out (if ever!).  At which stage, the modem returns NO CARRIER.
Like I cared at that point.  Don't tell me to fix uucico, because the problem
runs deeper than that.  Let's say that I want to transfer X-windows from
UUNET.  OK, so lets say for arguments sake, it is 10Mb of code.  This is
12 hours of transfer at 2400 baud.  Or, $120 in UUNET fees.  Now, if I get
dumped onto a 1200 baud line (or worse, a 300 baud line!), I'd prefer that
uucico forget it, than double the transfer fee.  If anything, this should
be an S-register option.
						- Der
-- 
	dtynan@sultra.UUCP  (Dermot Tynan @ Tynan Computers)
	{mips,pyramid}!sultra!dtynan

 ---  God invented alcohol to keep the Irish from taking over the planet  ---