Paul, at 09:02 on Feb 02 1996, you wrote ...

. . .[chomp]. . .

DD>> The locked speed stored is the speed of the _LAST_ AT&W 
DD>> command.  That is 

PE> NO IT ISN'T.  Try dialling out at 38400 (as above).  You got
PE> the "CONNECT" back at 38400 too, didn't you?  And lo and
PE> behold, you got your DATA back at 38400 ALSO.  Despite the
PE> fact that 57600 is what did the AT&W.  Even if you get a 
PE> 2400 bps connection, the &B1 will keep the com port locked 
PE> (at the speed of the last AT command) even AFTER a connect.  
PE> See now? You might want to try reading this again, with the 
PE> possibility in mind that I might be right (because I am 
PE> right).

DD>> how one sets the LOCKED speed.

It is how one locks the speed TO BE USED WHEN ANSWERING CALLS.

PE> It's CERTAINLY not the way you set the locked speed on an
PE> outgoing call.  It's CERTAINLY not the way you set the 
PE> locked speed for responses to AT commands.  The ONLY thing 
PE> that I have seen that uses the speed from the AT&W is the 
PE> RINGs.  It is a bug.

If your software managed to answer the phone you would find that that was
the speed that all the data was comming in at.

Is your BBS answering the phone if you tell it to use the baudrate that is
stored in the NVRAM (by an AT&W or equiv)?

Isn't a bug an error in the programming where the software does not behave
as documented?  Where in the documentation does it say that incomming calls
will communicate with the computer/terminal at the speed set by the last AT
command?

Is there any mention of the speed reverting to that set by the last NVRAM write?

David
@EOT:

--- Msgedsq/2 3.10