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.

BG> I've since done the same thing under native DOS as well, and it's
BG> identical to the behaviour under OS/2 or MDOS, which I can now reproduce
BG> at will.  Must have had a brain fart re the correct command sequence.

You've lost me completely now. Are you seriously saying that if
you do a &W at say 56K, and change the port speed to 38K and JUST
issue an ATZ, that the ring will come in at 38K fine now ?

You appeared to say quite the reverse in another message somewhere else
which I received at the same time I got this one, but I didnt get around
to carefully checking out the dates on the two messages, that other one
may been sent earlier in Aust_modems and took some time to get to TML etc.

BG> Also makes me wonder if it's THAT hard to do intentionally,
BG> how many users would ever see such behaviour?

I'm not convinced it is actually that hard,
when Paul saw it first off with the USR himself.

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
BG> as ALL Hayes-type modems) to be perfectly correct.
BG> It simply restores ALL &W defaults as expected.

Welp, most dont revert to the speed that was used in the &W on an
ATZ. I've yet to see any evidence that ANYTHING except a USR does.
Certainly a real Hayes doesnt. Neither do the Rockwells or the Spirit.

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

BG> A quick squiz through my USR_Modems database has shown
BG> that a few people have indeed been bitten, mainly due to
BG> their not storing the new baud rate to NVRAM with AT&W.

Yes, I even saw one in USR_Modems myself just in the last week
or so after I turned it on who appeared to be having that problem.

BG> That has been the only complaint though.

Thats the wart we are talking about tho, that you need to &W when
you change your port speed. The whole POINT of the invention of
the autobauding on the AT letters is so you DONT HAVE TO DO THAT.

BG> Nobody has ever mentioned anything about the RING not
BG> coming through correctly, due to a baud rate mismatch.

That one I saw in USR_MOdems said precisely that, that he could
see that he was getting an incoming call on the front of the modem,
but that RING was never sent to the PC at all. I havent noticed his
response to the suggestion that he ensure he &Ws at the port speed
in use, but it sure looks like that is what was his problem.

BG> Maybe Paul's software is set up slightly
BG> differently from other people's, who knows?

Thats clutching at straws, like the claim about his line, and
the various people who claimed that my problems calling him were
due to his line or his setup or even a dud particular USR.

If you are actually saying the now you cannot reproduce the ATZ special
effect yourself at all, its even odder why you yourself did see it once.
That would imply that there must be some particular sequence of actions
that makes it behave that odd way with ATZ thats different to all other
AT commands, say a sequence of power on and DTR cycling or something.

In which case it really is a classic bug in the USR.

BG> The only time I get gibberish on an incoming RING is
BG> if I change the port speed in my comms app without
BG> issuing an AT command (other than ATZ) to the modem.

Thats what we have always been saying is a
USR wart tho. This is an older quote of yours.

BG> I can't even use ATI4 to check the modem's port
BG> speed, as that immediately auto-bauds the modem
BG> and then shows 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,

So what the fuck are you saying at the top that you cant reproduce now ?

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.

I cant see its rare at all. Start a mailer with the modem init string as
ATZ, and before it tickles the modem every 10 minutes or so, it will indeed
produce a garbled RING if you arent using the speed the &W was done at.

You are allowing for the fact that most mailers allow more than
one modem init string arent you ?  Tho that should be irrelevant
if you are testing with Telix on plain booted DOS anyway.

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

BG> It is sort of necessary though.

Nope, I almost never &W my modem at all. Once I have got
the modem config I want it stays like that for many months
or years and its not at all unlikely that I may well change
the port speed in the mean time when say trying a different
OS or comms prog. Or different machine for that matter.

AND there is no point whatever in doing it the USR way which can apply its
fangs to your arse, it makes a hell of a lot more sense to do it the way all
the other modems do the ATZ, keep the port speed at the speed the AT was
sent at after the ATZ command has been executed. It has to do that anyway to
send the OK, and the USR mindless then uses the &W speed AFTER THAT. Nuts.

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

Yes, but almost no modern stuff ever just sits there looking at the modem
after the modem has been powered up, never ever sending any AT command at all.

And for those there is no practical alternative anyway, the
port speed has to come from somewhere, the &W speed. BUT its
nuts to demand that the use store the speed with an &W JUST for
use after an ATZ and not for use after all other AT commands.

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

Yes, and it makes no sense whatever to have the ATZ behave differently.

BG> I don't accept that the failure of ATZ to

(Continued to next message)
@EOT:

---