24 Oct 16 08:44, you wrote to me:   
      
    AP>>>> I need to be able to purge the message bases (as they do get quite   
    AP>>>> large and slow things down) and retain more than 9999 messages.   
      
    WV>>> I've changed that to a maximum of 65535, for the next release. ;)   
      
    ml>> that's crazy... especially when JAM can have 2M messages and at least   
    ml>> MSG can store up to 99999999...   
      
    WV> Well it's better than the current 9999. And as the config file stores   
    WV> it as a 16 bits value, that's all I can do without making things   
    WV> complicated... ;)   
      
   it isn't that complicated to increase it to a 32bit or possibly a 64bit   
   number... then when the new release comes out and setup is run, setup can   
   easily detect that the config file is from an older version and update it to   
   the new format... the config file does have a format version number in it for   
   this type of detection and updating, doesn't it??   
      
    AP>>>> I also need to be able to pack the jambases without renumbering   
    AP>>>> them.   
      
    WV>>> Why do you need that?   
      
    ml>> some software doesn't take kindly to renumbering the messages   
    ml>> underneath it... JAMNNTPD comes to mind...   
      
    WV> So it stores last read pointers in it's own config? And doesn't use   
    WV> the .jlr file for that, as it is supposed to?   
      
   no... news servers don't know what the last read message is... there's no way   
   for the client software to tell them... the client software stores the last   
   read in their own configs on the user's machine... when the BBS renumbers the   
   message bases, the client has no way of knowing that and no way of knowing   
   what the new numbers... the only option is to unjoin and rejoin and then mark   
   all the old messages as read and start again... if this is done daily, users   
   won't be using that service or they will be complaining long and loud about it   
   being broken...   
      
    ml>> so why pack, you ask? to remove deleted and dead message bodies...   
    ml>> every time you edit a JAM message, the header is updated to the new   
    ml>> message body location and the old one is left floating as trash...   
    ml>> packing the message bases removes the dead wood from deletions and   
    ml>> edits...   
      
    WV> I know that. ;)   
      
   ok then... you know why to pack and now you know why to /not/ renumber...   
      
   FWIW: i've never knowingly renumbered my system since switching to JAM when we   
   were beta testing it in RA/FD/FE... it was only recently that it came to light   
   that FE would do so at a certain point... i think i've taken care of that on   
   that system but it is still a major problem on others... especially when the   
   developers mistakenly shove it in automatically... i can understand doing it   
   in certain circumstances (like when the HMB approaches its limits) but it   
   should always be an option for the operator to choose... if they break their   
   message bases because they let the numbers get too large than that's their   
   fault... even with JAM there is this possibility but the numbers are much   
   larger before something like this should handled and then it should be handled   
   by notifying the operator in the logs and letting them make the decision...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... Old BBSers don't die, they just drop their carrier.   
   ---   
    * Origin:  (1:3634/12.73)