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   
    * Origin:  (1:3634/12.71)