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

abilities... yes, it is possible... there is a dependence on the order 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?

first thought is cost tables...

 RZ> And how to automate the host-route in FD in the cases where
 RZ> the host is a ION (like some in Z1, and analogous with
 RZ> hub/rc's)?

i don't host route... i've found it much easier to sent netmail to my
echomail links and let it sort out from there... FWTW: i've been doing that
for at least 12 years...

 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?

no, no violation... the way i see it, current practise was as Userflags...
then they were promoted because they were in such common use... now we find
that it was a mistype in a block copy that was never corrected and has been
in place for ~5+ years or so...

i believe that FD does understand the flags but you have to code them into
your "instructions"...

)\/(ark