this may assist you in your quest...


 * Forwarded from "FTSC_PUBLIC"
 * Original by Peter Knapper (3:772/1.10)
 * Original to Mark Lewis
 * Original dated Sun 1 Feb 2004 15:02

 -+- Forwarded message follows: -+-

Hi Mark,

 ml> maybe i'm not making the case clear...

 ml> 1. you are a dual connected system.
Yep...
 ml> 2. you have a connection with a dual connected system.
Yep, I most certainly do, seveal of them...
 ml> 3. mail for that system is in FLO files
Yep...

 ml> which ever mailer is the first to grab and start the
 ml> connection process is the one that does the delivery...

Yes that is true, but thats how I WANT it to work. However the PSTN mailer
wont send a .HLO file anywhere, until I change that file to either CRASH or
NORMAL. And my IP mailer wont send it anywhere until I create a matching
.ILO file. Quite simply, traffic for ALL my connections is always placed on
HOLD and NEVER gets sent as NORMAL or CRASH unless an appropriate Binkley
Schedule catches it, OR I manually force it. My background mail processing
task will detelect .HLO traffic for any KNOWN IP node, and automatically
generate the matching .ILO file, and the outbound then goes via IP...

 ml> now, how does one determine which mailer
 ml> is /the/ one to handle a connection for this destination?

I use natural selection. IE, I dont allow the PSTN Mailer to take any
outbound actions until that action fits within the timeframes I desire (IE
ZMH or other user specified intervals). These are a very limited number of
periods during the day. In my case this is a standard Binkley
configuration.

Because I have a 24 x 7 internet connection, my background mail processing
task (it runs about once per minute or whenever an event triggers some sort
of mail processing action), will check for .HLO files for any of my regular
IP connections, and automatically schedule an outbound IP call by creating
a .ILO file. Because this means outbound IP can happen any time, 99.99% of
the time, such outbound goes via IP.

Both Binkley and BinkD implement .BSY files, so there is never a clash of
node doing the processing.

Cheers............pk.


-!- Maximus/2 3.01
 ! Origin: Another Good Point About OS/2 (3:772/1.10)

 -+- End of forwarded message -+-

)\/(ark