Rod, at 13:21 on Feb 14 1996, you wrote to Bill Grimsley...

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.

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

No, quite the opposite.  ATZ restores the original saved 57600 rate.

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

I've detailed the precise sequence in another message in this PKT.

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.

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

No, because unlike the USRs, they don't save the baud rate to NVRAM.  If
you don't want ATZ to restore the saved baud rate, you're basically fucked
unless you physically issue an &W while the modem is set to the current
term rate, thereby writing the new rate to NVRAM.

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,

Which it is.  That's EXACTLY what happens.

RS> then clearly the USR is doing it differently to most, if not all, modems.

Nobody has ever disputed that they do it differently (well, I certainly
haven't).  This is why it should be much better documented than it is.

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

Don't yell, you'll end up hurting your fingers.  :)

RS> If you are actually saying the now you cannot reproduce the ATZ special
RS> effect yourself at all, its even odder why you yourself did see it once.

Easily reproducible now.  Just forgot the precise sequence, that's all.

RS> That would imply that there must be some particular sequence of actions
RS> that makes it behave that odd way with ATZ thats different to all other
RS> AT commands, say a sequence of power on and DTR cycling or something.

Seems that a power-on recycle restores the modem's saved baud rate, as I
just auto-bauded the modem with ATI4 which matched Qmodem's altered rate of
38400, but with a power off/on recycle (with NO subsequent AT command, not
even ATZ) it once again fucked up the incoming RING.

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

It appears that power-on reset and ATZ are identical in that they both
restore the saved NVRAM baud-rate.  Dunno about a DTR toggle though.

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.

RS> Thats what we have always been saying is a USR wart tho. 

Which is why the manual clearly states that &W is required to save the
NEW rate to the modem's NVRAM.  Pity it's not as clear about what will
happen if you don't though (and THAT'S the problem, it should be much
clearer IMO). 

RS> 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

Not really.  The ATI4 has auto-bauded the modem to reflect the current port
rate, as you would reasonably expect.  A subsequent ATZ would restore the
original saved rate, regardless of the current term rate.

BG> The above is actually the USR's normal behaviour under those circumstances,

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

As I said before, I simply fucked up some of my recreation attempts.

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.

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

True, I hadn't consideded the frequent inits that current mailers send,
which is why it really is important to write the current baud rate to
NVRAM.  Even the manual says so (but, rather stupidly, doesn't explain
why).

BG> It is sort of necessary though.

RS> Nope, I almost never &W my modem at all.

Don't you use ATZ as your init then ?

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

As Rockwells don't save the baud rate to NVRAM, that's irrelevant.  If you
were running a USR, you'd need to &W at least once if you change the
baud rate.  And THAT is documented quite clearly (but unfortunately, not
the reason).

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

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

You can't have it both ways.  If &W didn't save the baud rate, it
wouldn't matter at all, but it does on USRs, so that needs to be
considered.

Regards, Bill

--- Msgedsq/2 3.20