Xref: utzoo comp.dcom.modems:2911 comp.sys.att:4710
Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!uflorida!ukma!tut.cis.ohio-state.edu!osu-cis!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.dcom.modems,comp.sys.att
Subject: Re: Verbose modems (Re: MORE 6386 UUCP WOES)
Message-ID: <6924@chinet.chi.il.us>
Date: 10 Nov 88 21:23:51 GMT
References: <319@argon.UUCP> <2096@cuuxb.ATT.COM> <727@wsccs.UUCP> <889@vsi.COM> <758@wsccs.UUCP> <83@prapc2.UUCP> <2174@cuuxb.ATT.COM> <5203@cbmvax.UUCP> <6916@chinet.chi.il.us> <5212@cbmvax.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 51

In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
>
>All gettys have some kind of autobaud support, and don't require anything
>nonstandard from the modem.

Not all of them work, though (AT&T's Unix PC comes to mind) and 
how many will print the "login" message at the right speed the first
try? Does your terminal like the random garbage you get from characters
sent at the wrong speed? 

>>...  ASCII strings are the only way to access the new features,
>
>Why do you think this?  I have my doubts about using a new feature that
>was added in a way that does not work with commonly used software.

I think this because it has been this way since hays started selling an
affordable 1200 baud modem back in 1980 or so.  How long is a feature
"new"?

>I think that the more sophisticated modems get, the dumber they should look
>to the computer; fixed bit rate, completely transparent flow control, etc.
>All these things should be configurable, but they don't need to change "on
>the fly".  If the modem is so smart, let IT worry about the details and

No argument here, except that many computers do not observe the CTS/DSR
leads (AT&T's 3B2 comes to mind) and xon/xoff flow control is not transparent.
Also buffering in the modem may interfere with protocol timing and makes it
extremely difficult to tell if data has gotten to the end device.  For example,
if you want to print something on a remote teletype (I do a lot of this),
you need to know if the connection is dropped before the end of data is
sent.  If the modem buffers, you don't even know when it is safe to hang
up the line.  Then there is the question of where xon/xoff flow control
should happen if the remote end needs it.  If the modem passes it through
to the host, the buffered data will still be sent - if the modem handles
xon/xoff then you need a way to turn the mode off for binary file transfers.
 
>>  Why doesn't uucp's dialer pay attention to the CONNECT message and
>>change speeds if necessary?
>
>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