On Thu, 24 Apr 2014, Nicholas Boel wrote to mark lewis:

 ml> we don't know and we don't (yet) have any clue as to why it 
 ml> happened... with my live archivial (3 years retention) setup, i 
 ml> definitely would not want to switch my main system from FE to 
 ml> FMail if it meant losing 3 years of posts...

 NB> Do you actually benefit from anything 2-3 years old?

as i said before, it is a living archive... yes, when i need to jump back
through a thread, it comes in very nice to be able to do so and not having
to go digging through some other archivial format that is not compatible
with my reader...

with that said, i've been slowly working on a tool that does actually
archive messages to another database... it replaces the existing pack and
purge options offered by most existing tools... it operates by copying the
message from the current live area to an archived version of the area...
then it marks the message in the live area as removed so that it will be
packed out when the message base is cleaned up... in its barely alpha
stage, it works and works well but i don't know if i'll ever take it to the
full implementation that i've had in mind for years...

 NB> If I were to switch tossers, I would most likely create all new 
 NB> JAM areas and pull a rescan from my uplink. That gets me WELL 
 NB> over what I care to read, but populates the message areas anyways.

in many cases it is necessary to start with new message bases... it should
not be but since there are so many variations on implementations, it is
inevitable :/

as far as what one reads, it isn't all about that... not for me... it is
about archiving and documenting... there are several areas that i wish i
had not lost over the years... NET_DEV being one of the main ones with all
of the discussions between practically all of the developers of FTN
software in the 80s and 90s...

 NB> Maybe a warning label in recent tossers' documentation stating "IT
 NB> IS STRONGLY  ADVISED TO *NOT* USE THIS SOFTWARE WITH JAM AREAS
 NB> ANOTHER TOSSER HAS CREATED  AND MAINTAINED," is in order? :)

 NB> It's not only FMail either. I just had an issue trying to take over
 NB> some JAM  areas that were created and maintained by HPT with
 NB> another tosser. If one minor  thing is out of place or differs
 NB> between the two softwares, there won't be good  results.

exactly... HPT uses a different implementation of JAM than what the
creators released... the creators released C and Pascal code... a few
others created their own implementations... mark may's code, which i use in
all my tools on my main system, works with no problems other than a few
things left out or not taken far enough (eg: zeroing seconds on posts
instead of using the current seconds)... i've fixed and expanded numerous
items in the code and it works extremely well with RA, FD, FE (the baseline
implementations)... JAMNNTPd, on the other hand, uses another
implementation and since i don't "do" C, it is hard for me to
look at its implementation and compare it with the original and the MM code
to see that it is also working properly... FMail and FE should easily be
able to work the other's JAM bases just the same way that Mystic, RA,
EleBBS and any others using JAM bases should all be able to share the same
JAM bases at the same time and cause no problems for users or message
numbers or multiple postings at a time...

)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

--- FMail/Win32 1.60