Rod, at 07:43 on Feb 14 1996, you wrote to Paul Edwards...

PE> What are you talking about?  What Bill said above is correct.

RS> Only if you delete what he said earlier in that message, I have put it 
RS> back. It appeared to be saying that he could no longer reproduce the effect 
RS> where ATZ ONLY gave that effect of gibberish RING text with a port speed 
RS> change.

That was my fault.  I was checking the baud rate with ATI4, forgetting that
the AT was auto-bauding the modem, and changing it to the term's new rate.

RS> When I was reading another message from him in that bundle I thought he
RS> was saying the reverse, and meant to ask him to clarify it, but forgot to.

To clarify (modem and term both set to 57600 [saved to NVRAM with &W])...

After starting the app, alter the term's baud rate to say 38400.  Then,
without issuing ANY AT commands, dial the modem from an external source. 
The expected RING now comes through as gibberish due to the port mismatch. 
Any AT command will auto-baud the modem so the rates match (and RING
displays normally), but if ATZ is issued, the incoming RING is once again
displayed as gibberish, due to the modem's rate of 57600 being restored.

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

The only "problem" per se is that the USR stores the baud rate in
NVRAM, which means that ATZ will restore it, regardless of the term's baud
rate.  Despite the fact that the manual actually tells you to &W any
change to the modem's baud rate, it doesn't adequately explain why this is
necessary.  Ergo, it ain't a bug at all IMO, just a failure on the part of
USR to adequately explain that their modems work differently in that
regard.

And on _that_ point, I'm sure Paul and I are in full agreement.  :)

Regards, Bill

--- Msgedsq/2 3.20