Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.dcom.modems
Subject: Re: Verbose modems (Re: MORE 6386 UUCP WOES)
Message-ID: <6936@chinet.chi.il.us>
Date: 12 Nov 88 23:33:02 GMT
References: <319@argon.UUCP> <2096@cuuxb.ATT.COM> <727@wsccs.UUCP> <889@vsi.COM> <6924@chinet.chi.il.us> <2653@sultra.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 20

In article <2653@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes:

>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.

It is possible to do slightly better here by making separate dialer scripts
for 1200 and 2400 baud.  If you make the chat script expect 1200 or 2400
in the connect string it will at least give up fairly quickly but you are
still going to pay for a call and not transfer any data.  Most of my traffic
is time-sensitive and I would prefer to have it go at any speed the other
system will accept instead of failing, though. That can be accomplished
at the expense of a second call by making duplicate entries in the
Systems file for 1200 and 2400 baud.

Les Mikesell