24 Jul 15 22:43, you wrote to me:

 ml>> you fell into the same misunderstanding that many others also fell
 ml>> into... i did for a long time, as well... then i wised up one day
 ml>> when i was rereading some mailer and tosser documentation... the key
 ml>> is that the mailer's and tosser's netmail areas are shared between
 ml>> them but the sysop's netmail area should be elsewhere to keep his
 ml>> mail from being mixed in with that being managed by the mailer and
 ml>> tosser...

 MB> This meant running additional tool (i.e netmgr) to move those netmail
 MB> messages to/from primary?

it could, yes... if one were to place their netmail in the same areas as their
bbs users' netmail, then tosser would handle it...

 MB> I always opt for running the lightest configuration possible so had
 MB> natural adversion to doing this.   I just believe netmail should
 MB> contain only netmail.  Functional components seperate from
 MB> administrative components.

exactly and that's where the confusion stems from with AM/FA mailers... when
one first starts out, they don't know or understand the difference between the
mailer's netmail area and their own personal netmail area... at some point they
may also figure out that they can also have a netmail area within their bbs for
their users' netmails...

 ml>> not sure what files you are talking about but if they are/were mail
 ml>> bundles, they are left as zero bytes so the tosser can see that
 ml>> they've been sent and can increment the extension... using a zero
 ml>> byte file on the drive keeps the tosser from having to manage some
 ml>> sort of database with this information...

 MB> Not needed or an issue with hpt and filebox because bundle names use
 MB> timestamp by default.

this is relatively new in FTN software... tradition has the same base bundle
name per linked system... for example, here's some of the bundle names that my
fastecho used to use and the systems they are for... this before i turned off
archiving PKTs into bundles... you might recognise/remember some of the names
;)

==== Begin ====
describe 0b6dc800.* "Bob Juge               - 1:106/2000"
describe 1b0d4211.* "Joe Rigdon             - 1:151/208"
describe 20d8fb39.* "Warren Pittman         - 1:3636/505"
describe 229e4560.* "Don Neal               - 1:3636/506"
describe 22e178fb.* "Richard Webb           - 1:116/901"
describe 235c2f57.* "Devin Somerton         - 1:3636/507"
describe 3a64d789.* "Ross Cassell           - 1:123/500"
describe 65299dbd.* "Joaquim Homrighausen   - 2:201/329"
describe 400b19cb.* "Scott Little           - 3:712/848"
describe 6dee2900.* "Bill Burton            - 1:3634/15"
describe 705e2009.* "Jerry Gause            - 1:3651/9"
describe 7a14906b.* "Bill Gordon            - 1:3634/22"
describe 7bd6fa5c.* "John Kelly             - 1:3634/23"
describe 7e99ecd9.* "Richard Miles          - 1:3634/24"
describe 7e0ceac0.* "Bruce Bodger           - 1:170/400"
describe 81a83c9f.* "Dr. Pepper             - 1:10/41"
describe 8eb6db60.* "David Calafrancesco    - 1:2624/306"
describe b20ac007.* "Andy Roberts           - 1:109/921"
describe b3d37bf8.* "Bruce Morse            - 1:101/122"
describe bc136508.* "Paul Quinn             - 3:640/384"
describe be0eb7D9.* "Leonard Erickson       - 1:105/50"
describe e34ed460.* "Paul Kerr              - 1:3634/54"
describe e601c2e5.* "Keith Kottwitz         - 1:3634/53"
describe ed0ba6c0.* "Walter Tietjen         - 1:151/114"
==== End ====

 MB> More available bundle names and no overlap.

having the same bundle name makes it easier for one to tell what is going to
which system but it isn't all that important... as long as the software can
keep up with it, who cares? ;)

 MB> Additionally, smart mailers like binkd are capable of incrementing
 MB> name at receiving end even if overlap tries to occur.

only in some cases... i have seen certain binkd configurations that fail to
rename inbound files when there's a collosion... IIRC, this was related to
fileboxes and the use of an inbound temp directory... i don't know if this has
been fixed in recent versions and i haven't pushed it as it doesn't happen very
often... when it was happening, it was aggrivating but that was then...

 ml>> true but that's a little much... just send the mail first, then the
 ml>> files and finally the tics... there can be no problems with that
 ml>> ordering... or am i/we missing something else?

 MB> Less of issue these days with high bandwidth links but I remember
 MB> modem sessions lasting 30+ minutes.

some of mine were over an hour long... increasing my polling rate made the
sessions shorter but didn't lessen the connection times when they were all
tallied up :)

 MB> TIC+FILE pairs would arrive in sequence allowing processing to begin
 MB> in background.  If TIC files arrived last then processing must wait
 MB> until very end of session.

that's just a procedural thing... one could send the files first, then the tics
and lastly the mail... some prefer to get the mail first and process that in
the background while the ""less important"" files and tics come in and are
processed later... as far as files and their tics, the file really should be
sent first to that it is available when the tic processor runs... otherwise the
tic can/will be moved to a "badtics" area so that it isn't processed over and
over for a non-existent file...

 ml>> directly with its static queue but i don't use that right now... i
 ml>> don't recall if fastecho understands FD's static queue to that level
 ml>> and would know to place a system's outbound mail in its filebox as
 ml>> indicated by the STQ... what i've got works but it is a real PITA to
 ml>> add a new system because of the various config files that have to be
 ml>> adjusted... missing one breaks things in an ugly way...

 MB> What is the FD Static queue?

hunh? one might say that it is similar to the dbridge static queue... basically
it is nothing more than a binary database with the names of the files and the
systems they are destined to... with a static queue, one can also designate a
directory that is for a certain system... anything in that directory is sent
out just like a filebox... the difference is that the binary static queue can
be processed faster since it doesn't have to thrash the disk looking in various
directories... even with a disk cache, the STQ is faster but not by much and
with today's machines, probably not really as noticible as it was on a
486/20mhz system with a couple of 40meg HDs ;)

 ml>> definitely primitive... there's a difference between being primitive
 ml>> and limited... but there are limits to BSO... it is where the max
 ml>> zone number of 4095 comes from... with 8.3 limitations, the zone of
 ml>> the outbound can only go up to 0xfff ;) aside from that, BSO is
 ml>> pretty well defined and quite capable... AM/FA changed things
 ml>> slightly in that they automaticall handle packing and routing of
 ml>> netmail offering dynamic routing capabilities whereas BSO is lovingly
 ml>> know as "black hole" because the tosser has to pack everything and
 ml>> any rerouting changes mean that those packed messages have to be
 ml>> unpacked and repacked to the new destination if the current mailer
 ml>> event adjusts the routing... knowing what message(s) is in which
 ml>> PKT(s) destined to which system(s) to validate proper routing is much
 ml>> harder with BSO... AM/FA also allows for one single outbound instead
 ml>> of multiple ones... AM/FA mailers are simply a more intelligent
 ml>> mailer... nothing wrong with either...

 MB> I think zone ~100 was the highest I've ever went.

i don't recall what the highest zone number was that i saw listed in the
OTHERNETS echo back in the day... i know that there were a lot of private FTNs
around, too... before 5D FTN addressing came about, one had to be careful of
the othernets they joined because it was pretty tough to keep mail for two FTNs
using the same zone number separated if one could do it at all... 5D using FTN
domain names (eight characters in length) were the solution but they require(d)
that all BSO software (especially) be 5D aware and capable... we still see a
lot of 4D software in use today... it is noticible when your fidonet outbounds
are named (for example)

  /ftn/outbound/fidonet
  /ftn/outbound/fidonet.002
  /ftn/outbound/fidonet.003
  /ftn/outbound/fidonet.004

and you also see

  /ftn/outbound/fidonet.048   (thisnet z72)
  /ftn/outbound/fidonet.049   (thisnet z73)
  /ftn/outbound/fidonet.063   (foonet  z99)

knowing that fidonet is only zones 1-6 (z5 and z6 are defunct now, though)...
when what you'd rather see is this...

  /ftn/outbound/fidonet
  /ftn/outbound/fidonet.002
  /ftn/outbound/fidonet.003
  /ftn/outbound/fidonet.004
  /ftn/outbound/thisnet       (thisnet z72)
  /ftn/outbound/thisnet.049   (thisnet z73)
  /ftn/outbound/foonet        (foonet  z99)


 MB> Also can't recall ever having to re-route or re-pack any netmail but
 MB> could simply be fading memory.

it would be necessary if a link were to go down or one changed links to a
different one and there was still mail waiting to be sent out to the
down/previous linked system...

 MB> There were things I did not like about either.  Since I use
 MB> exclusively filebox that deprecated past is in rearview mirror.

fileboxes are good but they bring their own limitations and problems...

 MB> I suppose BSO never bothered me as I wrote my own REXX equivalent of
 MB> FIFTP when I ran OS/2.  Whipping together a tool to understand BSO was
 MB> nothing then though I suppose it would require some effort today. Once
 MB> you go filebox you never go back.  :-)

hehe, i have done some REXX stuff but generally fall back to 4DOS/4OS2 on my
OS/2 system... i have a 4DOS routine that does 5D BSO... it is kinda hefty but
it works... it is used mainly for creating poll ?LO files in the proper
outbound and checking for BSY flags so that we don't muck up a session in
progress... it could be made more generic and tweaked to handle 4D but for now,
it does what i need of it ;)

)\/(ark

... Caring for the wants and needs of the needy and the wanty.
---