Hylafax Developers Mailing List Archives

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

[hylafax-devel] Re: ["Dr. Harald Pollack" <Harald.Pollack@datanews.at>] Re: Re: My RTN patch and many other changes/enhancements, thOR



Steve Williams <steve@genie96.com> writes:

> First, I can see that this is almost a "religious" topic, but I am not an
> "evangalist".
> 
> I agree 100 % that doing an AT&W in an application is a horrible thing.  
> But, sometimes we don't have choices in the software we run ( read
> government supplied...) I did learn something in that I WAS NOT aware that
> there is any physical limit to the number of "saves" to the NVRAM.  This
> is GOOD information to know.

Harald is right but AFAIR is a bit pessimistic. :-) I believe 10^5 write
cycles should be the right figure.

> Question Dmitry/Harald, , do you have any experience on what happens when
> the NVRAM "wears out"?

You just throw your modem(s) to the trash can :-)

[...]

> 
> Now....
> 
> I agree that ATZ is an adequate ( my words, not yours ) to resetting the
> modem if there is ONLY ONE APPLICATION accessing the modem.  ( sorry to
> shout!!).
> 
> In a mixed data/fax/human fingers environment, where the status of the
> modem is completely unknown, ATZ just doesn't cut it.

It does. After

ATZ            - init string (ModemResetCmds)
ATE0           - disable echo                   \
AT+CLASS=2.0   - enter Class 2.0 (or other)      \ done by hylafax itself
AT+FLO=2       - set hardware flow control       / (see appropriate parameters)
                 for fax mode                   /

the modem will be properly initialized regardless of the current
NVRAM settings. This is the exact scenario (although a bit simplified)
which Hylafax uses (patched or not).

> I don't really see
> any command that does the job adequately.  As far as I am concerned, in a
> mixed environment, where you can't depend on the state of the modem, the
> only way is to set the modem to factory defaults and then program the
> whole thing from scratch.... AT&F is the only SURE BET for resetting the
> modem!!

*No*. ATZ not only loads user profile from NVRAM, it also *resets* the
modem's data pump, performs unconditional hangup etc., while AT&F only
reloads S-registers with factory defaults. Should I explain why resetting
the modem is absolutely necessary? You'll see, when your modem goes stuck, 
and nothing but power button will help.

Once again, I proposed ModemResetCmds: "ATZ" and ModemFlowControl:
"XONXOFF" as *defaults* (man config)! If you specify different values in
your config.modem, it's your own choice. But I believe that all these
endless talks in flexfax mailing list about "supported" modems, "right"
configs etc. are useless. Most modems should work out of the box with the
default settings (no Class* and Modem* entries in config.modem at all,
except maybe ModemType!). And the proposed changes are just the first step to
get the goal. faxaddmodem is completely broken, but it is quite different
story...

> That is a rather drastic approach ( which HylaFAX does not take ), but it
> does program most of the IMPORTANT things each time before it sets the
> modem status to "Running and Idle".  HylaFAX is FANTASTIC in it's
> reliability in our environment, and I feel that a large part of it is not
> making too many assumptions about status of the modem.
> 
> Enough about ATZ...it's not that important in my book, but I just wanted
> to clarify my personal experiences.

I think I also have explained why you are wrong :-)))

> As for flow control...
> 
> Most modems have the ability to have different flow control schemes for
> data and for fax.
> 
> I agree that more modems work with xon flow control IN FAX MODE.
> 
> xon flow control in DATA MODE causes NO END OF GRIEF with file transfers.

1. Flow control in fax mode has nothing to do with flow control in data
mode.
2. Any application you use sets neccessary flow control itself (if it does
not, it should be wiped out from the disk :-)). Thus the fact that Hylafax
uses software flow control does *not* mean that your data applications do
the same.
3. It's absolutely does not matter which type of flow control is stored into
user profile with AT&W (and restored with ATZ). If you specify
ModemFlowControl: rtscts
Hylafax will work correctly even if your NVRAM contains software flow
control settings for data mode or vice versa.

> Which is more important I guess depends on the environment....
> 
> But, HylaFAX does have the flexibility to switch to xon flow control when a
> fax connection is established.
> 
> Some of the config skeleton files have:
> ModemAnswerFaxBeginCmd: "<19200><xon>" # lock line rate & switch flow control

Nobody is going revoke this. Use it if you need. We are talking of
*defaults*.

> Again, it's not a big issue, but I really think that things should default
> to what is going to cause the LEAST amount of problems, and in data mode,
> hardware flow control causes WAY FEWER problems than xon/xoff flow
> control.

Do you realise that the current default is *no* flow control at all? (man
config over and over again!)

> Harald appears to have INTENSE experience with the fax side of things,

Yes, he has written his own very stable and feature-rich Class 1/2/2.0 fax
application for OS/2 (and was going to port it to Linux, but the work is
still in progress :-)). BTW, his software supports ECM in Class 1, which
Hylafax lacks. Does anybody wants to implement it? :-)))

> and
> I do acknowledge that things that have been talked about are WAYYYYY above
> my head.  However, there are two of us supporting over 350 cpu's across
> Canada, each one with a modem on them, and I know what works ( from the
> seat of pants approach...hence, I didn't know about AT&W having limited
> #'s of use ).  My statements are based on trial and error over the last 15
> years, ( 300 baud accoustical coupled on CP/M!!) and ALOT of bruises on my
> forehead trying to get some pretty complicate environments working.
> 
> 
> Thanks for reading... and have a great weekend!!

Have a nice weekend too!

Hope to hear from you soon,
Dmitry



____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services