Rod, at 09:46 on Feb 18 1996, you wrote to Bill Grimsley...

RS> The manual doesnt document the fact that USR does the ATZ differently
RS> to everyone else, and what documentation there is on the &W command
RS> is on the &B2 mode which he isnt even using Bill.

Doesn't matter if he uses it or not, their reasoning should be obvious to
anyone except the completely brain-dead.  Have a quote....

========================================================================
&B2     Fixed for ARQ calls/Variable for non-ARQ calls.  Answer mode 
        only.  When the modem goes off hook and connects in ARQ 
        mode, it shifts its serial port rate up to a user-specified 
        rate, for example, 38.4K bps.  If the connection is not 
        under error control, the modem behaves as if it were set 
        to &B0 and switches its serial port rate to match the 
        connection rate of each call.

        To implement this feature, first set your software to the 
        desired rate.  Then send the modem the AT &B2 [other 
        settings] &W command.  

        The modem stores the rate of the command in NVRAM along 
        with the settings.  Each time it makes an ARQ connection, 
        the modem checks NVRAM for the specified serial port rate. 

        When sending subsequent configurations to NVRAM, be sure 
        your software is set to your selected serial port rate, 
        so that the correct rate is maintained.
=====================================================================

From the above, it's perfectly clear to me why USRs permanently store the
bit rate in NVRAM, even if you fail to grasp the significance.  If, like
most users, one uses the default &B1, then it's advisable to configure
both the modem and the term so that their bit rates are the same.  Simple,
really.

RS> You can certainly justify doing things like that if there is a good
RS> operational reason to do that, but in this case there isnt even any
RS> good reason to do it like that.

I disagree.  There are still people using non-EC 2400 bps modems.

RS> AND if you choose to do it like that for a good reason, you MUST document 
RS> the quirk very thoroughly to minimise the risk of it repeatedly biting 
RS> people on the bum. USR doesnt.

I've already agreed that their documentation could be a little clearer, but
as the vast majority of my calls are outbound, that isn't my problem.

BG> And that is the one thing with which I'll agree, the lack of documentation.

RS> You STILL havent justified why it makes the slightest sense for
RS> USR to be doing the port speed after a ATZ differently to everyone
RS> else, PARTICULARLY when doing that can bite you unexpectedly.

The &B2 documentation covers that more than adequately IMO.

RS> It does appear that USR may well have had that quirky approach
RS> to ATZ using the NVRAM port speed for quite some time, hard
RS> to check, but it still makes no sense to do it that way.

BG> Well it's certainly done that way on my old Courier HST, vintage 1988.

RS> Yeah, wouldnt surprise me if its been there for quite some time.

I'd suggest that it's always been that way with USRs.

RS> Still makes no sense to be doing it differently to everyone else
RS> tho. PARTICULARLY when the difference is only seen in some special
RS> circumstance, using ATZ as a modem init string, needing to see RINGs,
RS> and using a port speed which isnt the one used in the last &W command.

And you still haven't explained why anybody would be stupid enough to run
their modem and terminal with mismatched serial port bit rates.

RS> FAR too quirky, robust designs are about eliminating those gotchas.
RS> Everyone else has realised that on that particular command.

Then why have I only ever seen 2 complaints re mismatched bit rates - one
from Paul, the other from some fellow in Zone 1 ?  If it was such a serious
problem, I'd expect to have heard a considerably higher number of
complaints.

RS> The autobauding on the AT letters is a brilliant concept.
RS> USR just stuffs that up on the ATZ command for no good reason.

Once again, IYO.  USR obviously disagree with you though.

RS> unlikely the chose to do it differently to everyone else on purpose.

BG> Given that they've been doing it that way for at least 9 years, I'd
BG> tend to agree.  However, I also agree that the necessity of writing
BG> the baud rate to NVRAM with &W after a change of port speed in the
BG> term should be far better documented than it is right now.

RS> Makes MUCH more sense to eliminate the NEED to do that Bill.

Not if they wish to maintain the &B2 option.

As with Paul, let's simply agree to disagree.  EOT.

Regards, Bill

--- Msgedsq/2 3.20