Rod, at 09:26 on Feb 12 1996, you wrote to Bill Grimsley...

RS> Nope, the ATZ quirk is clearly a bug, and ISNT documented AT ALL.

BG> Dunno, I've played around with that some more since last time,
BG> and I can't repeat that sequence at all.  I'm sure I'm not doing
BG> anything differently either (maybe the first example was flawed?).

RS> OK. I think you really have to do the tests with plain real booted DOS,
RS> no OS2 at all. And with a very simple comms prog like Telix so you can
RS> be completely sure of what speed you are using the comms port at.

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

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.

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

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.

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

RS> Currently we have the extra layer of the OS2 comms
RS> driver which may be getting into the act or something.

Using SIO here, and no, it doesn't appear to make any difference.

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

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

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

It is sort of necessary though.  That's the whole point (provided that the
port speed change in the software is permanent), otherwise the modem will
always power up with the last port rate saved with &W, even though the
very first AT command of any description will always auto-baud the modem to
the current rate.

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

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.

Nobody has yet been able to prove categorically that ATZ's OK is being sent
at the new rate though.  In fact, I'm sure it isn't, as no AT command will
work until a CR is entered, and in the case of ATZ my opinion is that as it
won't send the OK response until the command has been processed, that OK
has been sent at the NVRAM stored baud rate.

RS> Clearly after you power up the modem, it has to use some port speed,
RS> and that has to come out of the NVRAM,

Yep, quite right.

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.

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

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.

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

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.

Exactly.  An ATZ-only string is certainly not recommended if the modem's
stored baud rate differs from the term's locked port rate.  Of course, the
first ATDT will solve that anomaly, but if the first use is an incoming
call, a problem may occur.

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.

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

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

RS> Still a VERY significant wart tho if the RING text is being used
RS> to determine that something is calling in and it needs to be answered.

I'd guess that the modem would still answer if S0=1, but ATA is definitely
the preferred method, and that's where this anomaly has the capacity to
bite, as the mailer will never see a RING upon which to act.

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

So there are two simple solutions - either issue &W to the modem once
the port is set to the preferred rate, or if the user wishes to alter the
port speed occasionally (Christ knows why though), use an init other than
ATZ.  Even ATZ~~S0=0| will do just fine (I use AT&F1| myself).  It's a
one-off fix.

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.

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

BG> Nope, I can't believe that USR aren't aware of that behaviour,
BG> as fixing it would be a trivial exercise in their flash-ROM code.

RS> Well, its far from clear if that ATZ really does have a problem now.
RS> Tho presumably it does. 

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

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

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

RS> Still makes no sense whatever to do it that quirky way for no
RS> good reason at all, and there is CERTAINLY no justification for not
RS> documenting that properly in the manual if USR insists on doing it
RS> their own way, different to the vast bulk of modems.

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

Regards, Bill

--- Msgedsq/2 3.20