On Thu, 26 Feb 2015, Michiel van der Vlist wrote to mark lewis:

 MvdV>> It can, but thatis the exception.

 ml> really? when most systems use XXXXYYYY.mo1 naming for their mail
 ml> bundles?

 MvdV> ArcMail naming convention? That's as archaic as ARC itself.

really? that is the basis of BSO file names... flo files are named in this
manner as are .req files... files that do not follow this naming method must be
listed inside the flo file...

 ml>>  only if there is something to be sent that is not in
 ml>> XXXXYYYY.??? naming does that something need to be listed in the
 ml>> flo file...

 MvdV>> Which is the normal situation. 99.99% of the *.?lo files
 MvdV>> created are not empty.

 ml> you get your statistics from which gov't agency?

 MvdV> I see what goes in and out of my system.

ok... so 99.99% of the traffic on /your/ system...

 ml>> then you loose the timing capability...

 MvdV>> I can not loose what I never had.

 ml> you've always had it...

 MvdV> Not for anyof my BSO mailers.

yes you have... it is inherent in the naming of the flo files...

 ml>  dynamic mailers built on it in their feature capabilities...

 MvdV> We are not discussing dynamic mailers. We are discussing the BSO
 MvdV> mailer binkd. 

no shit, sherlock... we're also discussing mailers in general... that make
three topics going on in here...

 ml>  just because you didn't know you had it doesn't mean that you haven't
 ml> had it the whole time...

 MvdV> I know that the dynamic mailers that I have used had it. But
 MvdV> dybnamic mailers is not what we are discussing here.

 MvdV> Binkd does not have it and it is the only BSO mailer that I ever
 MvdV> used. 

binkd /does/ have it... it has it in the same manner that all BSO mailers have
had it since opus and binkleyterm were birthed into this network...

 ml> binkleyterm based operations are a real throwback to the stone age
 ml> when one comes from dynamic mailers with their intelligent behavior...

 MvdV> I am aware of the differences bewteen dynamic mailers and BSO
 MvdV> style mailers. It is one of the reasons why I hesitated so long
 MvdV> in converting my system from dynamic to BSO. I made the plunge
 MvdV> anyway because it was the only way to get Fido over IP6.

i know the feeling on converting... it is the reason why i run a hybrid
setup...

 MvdV> It was a steep learning curve, but now that I took that hurdle I
 MvdV> do not regret it. It was an opportinuty to clean out a lot of no
 MvdV> longer needed ballast. 

you are still learning, though... BSO has more fiddling and messing about
behind the scenes than you are apparently aware of... this "timing" thing is
one of those... how does it work? a flo file is set as hlo /or/ its extension
is changed to something other than standard flo file extensions... that causes
the associated files to sit on the system until such time as the hlo or non-?lo
extension is changed... this can be done via a .bat file or possibly by the use
of some BSO management tool... bonk and son of bonk come to mind... also
ifqman... there are others, too... these tools are needed for these
capabilities whereas dynamic mailers do this for you... 

 ml> behavior that has to be scripted or otherwise externally managed in
 ml> the binkley-style environment...

 MvdV> Or simply dropped as no longer needed...

maybe in your case but not for all others... some still see the need and use
for such tools...

 MvdV>> As it is and always has been on my system, binkd does not
 MvdV>> differentiate bewteen flo, dlo, ilo and clo. Except fpr hold,
 MvdV>> it just initiates the connect ans sends the files at the next
 MvdV>> scan of the oubound. On my system, within the next 60 seconds.

 ml> exactly... the timing is controlled by the naming of the flo file...
 ml> direct, immediate and crash are affected by the event manager...

 MvdV> Binkd has no event manager.

you still have some sort of event manager there... if you didn't you couldn't
schedule polls or know when to toss mail...

 ml> so the timing is performed by having a hlo until the desired time is
 ml> reached when it is renamed to flo, dlo, ilo, or clo...

 MvdV> That is needlessly complicated.

needlessly complicated??!? bite your tongue, man! /that's/ specifically why
dynamic mailers were so popular!! there is no other way to do this in a BSO
environment... it is inherent in the design...

 MvdV> When one uses an event manager, one might as well have it place 
 MvdV> the .req in the outbound when the time arises. hat is if one has 
 MvdV> a need to do that for .req files at all.

that's another way to do it... it falls in line with a tool that i one used
with binkleyterm that copied files into and out of the BSO directory
structure... this so that it could manage what the mailer saw and when it saw
it... when i realized that BSO stuff was more primitive than frontdoor, i
laughed heartily and backed off from it a bit instead of continuing to work to
hybridize my system with both as i was doing... mainly for the binkley
experiance so as to be able to assist others as well as seeing what all the
ooohs and aaahs were about from those oogling it...

 ml>> you cannot create a req file with hold, normal or crash
 ml>> status... there's no such thing as a ?eq file where the '?' may
 ml>> be 'h', 'f', or 'c'...

 MvdV>> A omission due to an illogical choice.

 ml> assumption based on opinion...

 MvdV> No, not an assumption, a CONCLUSION.

based on OPINION.

 MvdV>> I do not miss it, I never had it anyway.

 ml> another assumption... you always had it...

 MvdV> No, none of my BSO mailers ever had it.

/ALL/ BSO mailers have it... they always have and they always will...

 MvdV>> But that does not alter the fact that whoever created this made
 MvdV>> an illogical choice.

 ml> opinion...

 MvdV> So? Are you the only one entitled to have an opinion?

i've not stated opinions in this...

 MvdV>> What we now have is that *.req files are an illogical mix of a
 MvdV>> flow control file and an ordinary file that needs an
 MvdV>> accompanying flow control file in order to be send.

 ml> req files are not any kind of flo file... they cannot be... what makes
 ml> you think that they are? their name? how else are you supposed to keep
 ml> them separated if there's more than one in your outbound?

 MvdV> No need for two or moder with teh same name to be in the
 MvdV> outbound. If a new request is added for the same destination,
 MvdV> just update the req file. Just like it is done with *.out

uuummm... i meant two or more .reqs for /different/ destination systems... of
course you would modify an existing .req file to add or remove files being
requested :roll eyes:

 MvdV>> It isn't the first time time that we are stuck with illogical
 MvdV>> choices made in the past, but that does not remove the fact
 MvdV>> that is WAS an illogical choice.

 ml> again, opinion...

 MvdV> A considered opinion I may add. Again, so what? Are you the only
 MvdV> one entitled to have an opinion?

everyone is but when their conclusions are based on erroneous data or some
opinion, they should expect others to correct them and they should be willing
to accept such without arguing or insisting that their methods, opinions or
logic are the only proper way of doing things ;) 

)\/(ark