-=> Quoting mark lewis to Renato Zambon <=-

 RZ>>> A POTS only system can't dial it anyway, host/hub routing with
 RZ>>> an ION don't work in that cases. How can FD handle these cases?
 
 ml>> set up an entry in FDSETUP->Manager->modem something like
 
 ml>> string to match        string to send/action
 ml>>   ITN                   (do not dial)
 ml>>   IVM                   (do not dial)
 ml>>   IBN                   (do not dial)
 
 RZ> Seems that would make undialable systems with both
 RZ> habilities...

 ml> abilities... yes, it is possible... there is a dependence on the order
 ml> in which those rules exist in that list... 
 RZ> How to make in FD undialable those systems without pvt
 RZ> indication but with 000-, 1-000- or similar "phone" fields?

 ml> first thought is cost tables...

Same here. Though I think there may be another way, but a quick scan of
the docs doesn't find it.
 
 ml>> those *Cs not allowing (or otherwise not accepting) Tyz flags on
 ml>> the left of a 'U' entry are in error and violating FTS-5001...
 
 RZ> Or the FTSC did violate current practices when documented them
 RZ> as flags?  :-)  BTW, does FD understand these T?? [user]flags?

 ml> no, no violation... the way i see it, current practise was as
 ml> Userflags... then they were promoted because they were in such common
 ml> use... now we find that it was a mistype in a block copy that was
 ml> never corrected and has been in place for ~5+ years or so... 
 ml> i believe that FD does understand the flags but you have to code them
 ml> into your "instructions"... 

I have yet to find a way to use them that wouldn't involve creating an
insane event list as well as other things. 

Basicly, FD would need a "keyword" for ROUTE.FD that was similar to the
CM & !CM ones, but that used the Txy flags *and* the #xx flags.

Even then it'd be a major hassle. 


--- FMailX 1.60