(Continued from previous message)

BG> auto-baud the modem is a fault or 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.

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

Sure it is, all mailers check for the OK after the modem
init string and keep banging on the modem till they get one.

And I'm damned sure that mine does coz I use ATZ as a modem init string
with stuff like Telemate, and do check that I can see the OK on the terminal
screen, coz its a clear indication of everything is basically working fine.
Clearly the modem must be plugged into the port and powered on etc. Its very
clearly visible in Telemate, it says its initialising the modem with a popup
box which allows you to see the traffic to the modem on the terminal screen.
You can see the ATZ go out, and the OK come back. It then loads up the
dialing directory screen AFTER thats been clearly visible.

With Frodo you see it saying its initialising the modem, you dont actually
see the ATZ go out, but you do see the OK returned from the modem.

And I've just checked that after an ATZ after a port speed
change, you do indeed see the OK at the new speed, and RINGs too.

BG> In fact, I'm sure it isn't,

Sure is on a non USR modem.

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

Welp, non USR modems have enough sense to not load the port speed out
of the NVRAM on an ATZ. Which is the only sensible thing to do too.

Pointless using the NVRAM port speed when you have just
worked out what the port speed is from the AT letters on
the ATZ command and have put the OK out at that speed too.

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

BG> Yep, quite right.

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

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

Yes, but it makes no sense for ATZ to no do
that TOO Bill. USR has had a massive brain fart.

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

BG> But that's EXACTLY what happens now.

Nope, not with an ATZ on a USR modem.

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

Yes, but we aint talking about that. THAT is clearly an unsolvable problem.
If there aint no AT command, there is no way the modem can work out what
the port speed is. It doesnt make the slightest sense to be doing that
for *ALL* AT command EXCEPT the ATZ tho, and thats the USR brain fart.

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.

Still doesnt make the slightest sense to treat ATZ differently. USR does.

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

And it makes a HELL of a lot more sense to have the ATZ behave PRECISELY
the same as the other AT commands, so there aint that capacity for fangs
in the arse in JUST THAT situation. FAR too quirky for no good reason.

BG> Of course, the first ATDT will solve that anomaly,

Yes, but many systems never make outgoing calls at
all on a particular modem. So thats fucked by design.

BG> but if the first use is an incoming call, a problem may occur.

And if you only ever get incoming calls, thats totally fucked.

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
BG> especially sysops, would have their serial port permanently
BG> locked to a specific value, and will likely never need to
BG> alter it, so they'll never see that problem either.

Pity that decent design is about minimising the chance of
fangs in the arse, not just working for the common configs.

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 to
RS> determine that something is calling in and it needs to be answered.

BG> I'd guess that the modem would still answer if S0=1,

Corse it would.

BG> but ATA is definitely the preferred method,

Yep, its fucked to have the modem answer itself unless you have no choice.

BG> and that's where this anomaly has the capacity to bite,
BG> as the mailer will never see a RING upon which to act.

Yes, USR has had a brain fart, as we said.

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
BG> modem once the port is set to the preferred rate, or if the
BG> user wishes to alter the port speed occasionally (Christ knows
BG> why though), use an init other than ATZ.  Even ATZ~~S0=0| will
BG> do just fine (I use AT&F1| myself).  It's a one-off fix.

And a FAR better fix is what all the other modems do, send
the RING out at the speed of the last AT command, EVEN IF
thats an ATZ. Infinitely cleaner. And no good reason not to.

Weirdo modem init strings are nuts.

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.


(Continued to next message)
@EOT:

---