DD> For a bug it seems well documented.

BG> Furthermore, only Paul Edwards thinks it's a bug,

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?).

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

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

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

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

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.

Yeah, thats odd, and doesnt explain what Paul said he saw, or
the emphasis people put on &Wing on a port speed change either.

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

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

Clearly after you power up the modem, it has to use some port speed,
and that has to come out of the NVRAM, but it makes no sense to use
that speed after you have got an AT command that allows you to work
out what the port speed is from the AT letters themselves.

BG> In fact, I'm more inclined to suspect that it's been done that way
BG> intentionally for some obscure reason (but yes, it should be documented).

I still cant see any point in doing it like that.

BG> whilst the other 5 million Courier owners
BG> are obviously too thick to realise it...

RS> Well, if you never change the port from the speed used for
RS> the &W you wont see the bug, so thats hardly very surprising.

BG> Can you give me just one valid reason for even needing to alter
BG> the port speed on the fly?  Not these days, although USRs have
BG> been around since the days that EC (i.e. bit-stripping) was the
BG> exception rather than the rule (my own Courier is date-coded 1988).

Thats not the point Bill. I could equally ask you if you can give
me just one valid reason for the ATZ command to NOT leave the port
at the speed it sent the OK out at, and use that for a RING. There
is just no point in having such quirky behaviour unless there is a
damned good reason for doing it the quirky way.

And its not so much changing the port speed as what speed was used
to &W the modem at. I can see that in some circumstances that it
can make sense to configure modems in a particular way and &W them,
and hand them out to the users to use. Its a total pain in the arse
to have to ensure they use them at the speed they were &Wed at. It
makes a HELL of a lot more sense for the modem to just send the RING
at the speed of the last AT command, whatever the AT command was.

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.
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> Aside from the gibberish response, the mode still works though.

Still a VERY significant wart tho if the RING text is being used
to determine that something is calling in and it needs to be answered.
PARTICULARLY when someone has to notice that it doesnt answer at all.

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

Thats what decently designed systems are all about, minimising
the risk of fangs in bum, particularly due to quirky behaviour.

RS> Its an absolutely classic genuine bug, not documented AT ALL.

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.

Well, its far from clear if that ATZ really does have a problem now.
Tho presumably it does. Its quite possible that USR is just mindlessly
insisting that thats how they have always done ATZ and they aint gunna
change. Still makes no sense whatever to do it that quirky way for no
good reason at all, and there is CERTAINLY no justification for not
documenting that properly in the manual if USR insists on doing it
their own way, different to the vast bulk of modems.
@EOT:

---