BG> I've since done the same thing under native DOS as well, and it's identical 
BG> to the behaviour under OS/2 or MDOS, which I can now reproduce at will.  
BG> Must have had a brain fart re the correct command sequence.  Also makes me 
BG> wonder if it's THAT hard to do intentionally, how many users would ever see 
BG> such behaviour?

Users are unlikely to ever see it.  I don't know how many other
sysops see it.

RS> There is a certain fractured logic in the ATZ command alone
RS> using the port speed out of the stored value in the NVRAM, the
RS> speed thats visible there immediately after a modem power cycle.

BG> I believe USR's ATZ (which works exactly the same as ALL Hayes-type modems) 
BG> to be perfectly correct.  It simply restores ALL &W defaults as expected.

No, that is NOT what is expected.  What is expected is that it will
auto-baud on the AT command.  That's what auto-baud is all about.
Unless USR have documented "Our modems do auto-baud, except on ATZ
where we have totally fucked it up"?

RS> If you can demonstrate that ATZ alone behaves differently to say just
RS> AT, on the speed at which the RING is sent, with the port speed changed
RS> from the one used in the &W, and its completely reproducible, then
RS> clearly the USR is doing it differently to most, if not all, modems.

BG> A quick squiz through my USR_Modems database has shown that a few people 
BG> have indeed been bitten, mainly due to their not storing the new baud rate 
BG> to NVRAM with AT&W.  That has been the only complaint though.  Nobody has 
BG> ever mentioned anything about the RING not coming through correctly, due to 
BG> a baud rate mismatch.  Maybe Paul's software is set up slightly differently 
BG> from other people's, who knows?

You saw it too, Bill.  And if David D changes his binkley.cfg and
mode to a different baud rate, he will see it too.  Unless he does
the EXTRA step in changing the baud rate in NVRAM to work around
the USR bug.

BG> The only time I get gibberish on an incoming RING is if I change
BG> the port speed in my comms app without issuing an AT command (other
BG> than ATZ) to the modem.  I can't even use ATI4 to check the modem's
BG> port speed, as that immediately auto-bauds the modem and then shows
BG> the same as the app's altered speed.

RS> Yeah, thats odd, and doesnt explain what Paul said he saw, or

BG> The above is actually the USR's normal behaviour under those circumstances, 
BG> and whilst I'll acknowledge that it does have the capacity to bite, that 
BG> particular sequence of events is likely so rare as to be insignificant.

How significant you or I consider it to be is irrelevant to the
FACT that it is a bug/design fault.

RS> the emphasis people put on &Wing on a port speed change either.

BG> It is sort of necessary though.  That's the whole point (provided that the 
BG> port speed change in the software is permanent), otherwise the modem will 
BG> always power up with the last port rate saved with &W, even
though the very 

I ran for years with my Spirit never having to worry about the
speed of last &W.  Remember I changed the speed to 19200 for
some reason when trying to help you with your connects?  I
didn't need to go &W.

BG> first AT command of any description will always auto-baud the modem to the 
BG> current rate.

Any description except ATZ.  That's the whole point of the discussion.

BG> I don't accept that the failure of ATZ to auto-baud the modem is a fault or 
BG> a bug at all.

Uh oh, Ostrich Impersonations!

RS> It basically makes no sense whatever to be sending the OK back at the
RS> speed determined from that AT on that command, and THEN switching the
RS> port speed to the speed in the NVRAM. Nuts. If that actually happens.

BG> Nobody has yet been able to prove categorically that ATZ's OK is being sent 
BG> at the new rate though. 

Which is pretty clever of everybody then, since it doesn't.

BG> In fact, I'm sure it isn't, as no AT command will 

Yay, he got it right too!

BG> work until a CR is entered, 

Oh dear.

BG> and in the case of ATZ my opinion is that as it 
BG> won't send the OK response until the command has been processed, that OK 
BG> has been sent at the NVRAM stored baud rate.

It doesn't Bill.  Otherwise the "OK" would be as unintelligable as
"RING".  

RS> but it makes no sense to use that speed after you have got an AT command 
RS> that allows you to work out what the port speed is from the AT letters 
RS> themselves.

BG> But that's the whole point, Rod;  if the term's port speed is different 
BG> from the modem's stored rate, the modem will indeed match rates with the 
BG> very first AT command of any description (ATZ excluded, of course).  As 
BG> it's meant to.

It's the ATZ exception we're talking about, Bill.

RS> It makes a HELL of a lot more sense for the modem to just send the RING
RS> at the speed of the last AT command, whatever the AT command was.

BG> But that's EXACTLY what happens now.  The only time a problem occurs is if 
BG> the term's rate has been changed, and NO AT command issued to the modem.  
BG> The very next incoming RING will fail.

OR the last AT command was ATZ.  That's what we're discussing, Bill.

RS> And since it only affects ATZ, even those who do use
RS> a port speed thats not the one that was used in the &W
RS> wont see it unless they only have an ATZ modem init string.

BG> Exactly.  An ATZ-only string is certainly not recommended if the modem's 
BG> stored baud rate differs from the term's locked port rate.  Of course, the 

Not recommended by who?  You?  A better recommendation would be for
USR to not have bugs in their modem.

RS> And presumably most of those dont use their modem for incoming
RS> calls so wont notice the RING effect even if they do either.

BG> I'd suggest that the absolute vast majority of users, and especially 
BG> sysops, would have their serial port permanently locked to a specific 
BG> value, and will likely never need to alter it, so they'll never see that 
BG> problem either.

You and David D have this misconception about what a locked serial
port is.  To lock the serial port, what you do is set &B1 instead
of &B0.  THAT causes the modem to use a fixed rate, ie LOCKED.  You
then go and set your comms program to WHATEVER baud rate you want,
AND you tell your comms program to LOCK the baud rate.  THEN you
must do one of two things:

1. Either you should have made sure your comms program and your
modem have matched speeds.

2. Or you should issue an AT command to your modem, assuming it
supports auto-baud detect.

NOW, you will find that after a connect (regardless of whether you
answer with ATA or S0=1, or dialled out with ATDT) the modem, 
thanks to &B1, will NOT adjust the speed it communicates with the
computer, even if the connect was at 300 bps.  The software will
NOT adjust the speed of the com port either.  THIS is what is
called "running a locked com port".  I have seen both you and
David allude to "Why would you make the com port speed different
to what you locked it at".  Setting the speed and going AT&W is
***NOT*** "locking" your modem.  It's the &B1 that is locking 
your modem.  Even if the last save to NVRAM had &B0 at 300 bps, 
if you issue an AT&B1 at startup at 38400, you have THEN locked 
your modem at 38400.  The 300 above is merely "storing the 
default baud rate in NVRAM", it is NOT locking your baud rate
at 300.

BG> Aside from the gibberish response, the mode still works though.

Yes, it is only the gibberish we are talking about.  Also
presumably if you had set S0=1, the connect string and subsequent
data would come through as gibberish, although that needs to be
tested to be sure.

RS> PARTICULARLY when someone has to notice that it doesnt answer at all.

BG> So there are two simple solutions - either issue &W to the modem once the 

No, there are two simple workarounds.  A simple solution is for
USR to fix their bug.

BG> port is set to the preferred rate, or if the user wishes to alter the port 
BG> speed occasionally (Christ knows why though), use an init other than ATZ.  

I've already told you why I change port speed.  I'm sure you would
change your port speed to 115200 if you wanted to test out how good
your V42bis was too.

BG> Even ATZ~~S0=0| will do just fine (I use AT&F1| myself).  It's a one-off 
BG> fix.

It's a "one-off" (every comms program you ever use needs to be
configured as such) WORKAROUND.  Personally, I prefer the 
WORKAROUND of doing an &W whenever I change baud rate.

RS> The VERY simple approach of sending the RING at the speed of the
RS> last AT command completely eliminates that risk of fangs in bum.

BG> But it DOES, unless the last AT command was ATZ.  

And that's what we're talking about Bill, in case you haven't
noticed.

BG> Yeah, ATZ does not auto-baud the port rate, which is what I'd expect 
BG> anyway.

And here's a man who would fuck a modem up by DESIGN.  Now tell me
Bill, why would you do that in YOUR design?  What possible benefit
is there to send an "OK" back at 38400, and then up the speed to
57600?  Do you know of any terminals that do this (WYSE, VT100,
VT200, VT220, VT300, etc etc)?  Do you know of any comms programs
that issue an ATZ, and then, realising that the last save to
NVRAM to THIS modem, REGARDLESS of whether the AT&W was even done
from another comms program, or even another computer, quickly
adjusts the baud rate from 38400 to 57600?  I'd like to see that
program.  I'd like to see that terminal too.  I'd also like to
see the egg that's all over your face.  But first of all, you need
to pull it out of the ground.

RS> Its quite possible that USR is just mindlessly insisting that thats how 
RS> they 
RS> have always done ATZ and they aint gunna change.

BG> USR's use of ATZ is no different from any other modem manufacturer's though 
BG> - it simply restores all NVRAM values to the current profile.

Wow!  We're on to ANY OTHER manufacturer now?  Well you've lost
immediately, since the Spirit didn't have that problem.  And Rod
will likely confirm that his modem doesn't either.

BG> Wish I had a spare Rockwell to play with here, as I'm not in a position to 
BG> categorically state how theirs does an ATZ when the modem's port rate 
BG> differs from the term's.  I'd fully expect the same thing to occur though.

Silly man.  You have been very quiet about naming a single terminal
that behaves by adjusting baud rate after issuing an ATZ.  As quiet
as Ian Smith and David Drummond in fact.  BFN.  Paul.
@EOT:

---