BG> Apparently it's only Paul who considers it a major problem anyway.

RS> He didnt say it was a major problem, just that it was a bug or stuffed
RS> by design. I agree with him, its just too quirky and counter intuitive.

BG> Then why has he been carrying on as if civilisation was about to end ?

He hasnt, just been poking holes in your claims that its user error, or not
reading the manual, or that USR is doing it the only sensible way, when in
fact every other modem manufacturer does it the sensible way on the port
speed and the ATZ command and USR does it the mad way for no good reason at
all and that that can bite you. I happen to agree with him, if there is no
good reason for USR to do it that quirky way, and there isnt, it makes no
sense to do it that way. Let alone not document the fact that USR does the
ATZ port speed differently to all the other modem manufacturers.

BG> If he'd bothered reading the manual as I suggested a couple
BG> of weeks ago, most of these problems would never have occurred.

The manual doesnt document the fact that USR does the ATZ differently
to everyone else, and what documentation there is on the &W command
is on the &B2 mode which he isnt even using Bill.

RS> You can certainly justify doing things like that if there is a good
RS> operational reason to do that, but in this case there isnt even any
RS> good reason to do it like that. AND if you choose to do it like that
RS> for a good reason, you MUST document the quirk very thoroughly to
RS> minimise the risk of it repeatedly biting people on the bum. USR doesnt.

BG> And that is the one thing with which I'll agree, the lack of documentation.

You STILL havent justified why it makes the slightest sense for
USR to be doing the port speed after a ATZ differently to everyone
else, PARTICULARLY when doing that can bite you unexpectedly.

Documentation aint enough, it make MUCH more sense
not to have the quirk there in the first place.

RS> It does appear that USR may well have had that quirky approach
RS> to ATZ using the NVRAM port speed for quite some time, hard
RS> to check, but it still makes no sense to do it that way.

BG> Well it's certainly done that way on my old Courier HST, vintage 1988.

Yeah, wouldnt surprise me if its been there for quite some time.
Still makes no sense to be doing it differently to everyone else
tho. PARTICULARLY when the difference is only seen in some special
circumstance, using ATZ as a modem init string, needing to see RINGs,
and using a port speed which isnt the one used in the last &W command.

FAR too quirky, robust designs are about eliminating those gotchas.
Everyone else has realised that on that particular command.

The autobauding on the AT letters is a brilliant concept.
USR just stuffs that up on the ATZ command for no good reason.

BG> Aside from Paul, who still considers it to be a bug.  :)

RS> Well, its arguable if its a bug or designed like that. And if only USR does
RS> that, its only not a bug if the explicitly chose to implement the ATZ like
RS> that. Its not clear if they did that on purpose or it just happened like
RS> that. In fact, since its not documented unambiguously, it seems rather
RS> unlikely the chose to do it differently to everyone else on purpose.

BG> Given that they've been doing it that way for at least 9 years, I'd
BG> tend to agree.  However, I also agree that the necessity of writing
BG> the baud rate to NVRAM with &W after a change of port speed in the
BG> term should be far better documented than it is right now.

Makes MUCH more sense to eliminate the NEED to do that Bill.
@EOT:

---