On 2019 Feb 16 12:04:48, you wrote to Ozz Nixon:   
      
    ON>> I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but,   
    ON>> assumed that was a RA 2.x feature and didn't want to go back through   
    ON>> their STRUCT files to find it... thus, I asked. ;-)   
      
    WV> It's not in the fmail of golded docs. And my guess is, it's a RA thing...   
      
   no... RA/FD/FE implemented it since they added it as part of a feature   
   request... it was taken up by many others as well... the problem is that there   
   are two or three similar files that provide the information but in slightly   
   different ways... echomail.jam and netmail.jam are for _outbound_ local posts   
   that need to be scanned out of the message base... some try to use this file   
   for inbound which is the exact opposite of what it is intended for...   
      
   the other files have another name and may be more generally used for "sole   
   occupant" type setups like single user BBSes or point systems... especially   
   those that use local sysop reader/editor setups like golded, timed, msged and   
   similar... those can use those inbound files to sort those areas to the top of   
   the mail listing if you want to see them first... i don't see them working   
   very well for multi-user setups like a BBS with multiple users... the last   
   read pointers of the users still need to be consulted no matter what mail   
   arrived recently...   
      
   on searching for new messages since a user's last visit, it should be easy   
   enough for any JAM capable package to maintain the two lastread pointers for   
   each user... it should also be able to quickly scan through the JLR files   
   picking up and comparing the lastread pointers for each user with the number   
   of messages in the area the JLR file is for... if a system is too slow doing   
   that, they may want to examine their algorithm and/or system setup...   
      
   i do recall, on DOS systems, that there was a major slowdown of scanning files   
   which JAM brought to the forefront... the problem was actually in the file   
   system and the way that the OS managed FAT* areas with large numbers of   
   files... folks thought they were putting (eg) 400 message areas in one   
   directory but they didn't realize they were really putting 1600 files in one   
   directory... splitting the areas into directories with less than 255 _files_   
   (63 JAM areas) per directory sped the processing up by at least a magnitude...   
      
   access speed problems may also be seen on networked drive shares... JAM really   
   should be used from local fast HDs, IMHO...   
      
   i like the OOP aspect of the pascal JAM library i used in my code... it was   
   fast and did everything i needed... i don't know how non-OOP linear procedural   
   code would work... if it would gather the needed information from the message   
   base files as quickly or if additional requests would need to be made which   
   could slow the scanning process down...   
      
   FWIW: when i was using JAM, i was splitting my areas into a structured   
   directory tree something like this...   
      
     \FTNs\   
     \FTNs\Fidonet\   
     \FTNs\Fidonet\messages\   
     \FTNs\Fidonet\messages\netmail\   
     \FTNs\Fidonet\messages\echomail\   
     \FTNs\Fidonet\messages\echomail\backbone\   
     \FTNs\Fidonet\messages\echomail\backbone\1\   
     \FTNs\Fidonet\messages\echomail\backbone\1\10th_amd.j*   
     \FTNs\Fidonet\messages\echomail\backbone\A\   
     \FTNs\Fidonet\messages\echomail\backbone\A\Alaska\Chat.j*   
     \FTNs\Fidonet\messages\echomail\backbone\A\All\Politics.j*   
     \FTNs\Fidonet\messages\echomail\backbone\A\Allfix\File.j*   
     \FTNs\Fidonet\messages\echomail\backbone\A\Allfix\Help.j*   
     [...]   
     \FTNs\Fidonet\messages\echomail\backbone\B\   
     \FTNs\Fidonet\messages\echomail\backbone\B\Bash.j*   
     \FTNs\Fidonet\messages\echomail\backbone\B\Binkd.j*   
     [...]   
     \FTNs\Fidonet\messages\echomail\backbone\C\   
     [...]   
     \FTNs\Fidonet\files\FDNs\NODELIST\NODELIST.*   
     \FTNs\Fidonet\files\FDNs\DAILYLIS.T\DAILYLST.*   
     [...]   
     \FTNs\Foobar\messages\netmail\   
     \FTNs\FooBar\messages\echomail\backbone\A[...]   
     \FTNs\FooBar\messages\echomail\backbone\B[...]   
     \FTNs\FooBar\messages\echomail\backbone\C[...]   
     \FTNs\FooBar\messages\echomail\backbone\D[...]   
      
   it made things faster and also easier to maintain... autoadded areas were   
   placed into a special directory for them until their record was updated in the   
   tosser configuration program at which time it was moved to the proper   
   directory in the above tree... i used whatever splitter was used between words   
   as a divider... the ALLFIX_FILE and ALLFIX_HELP areas are good examples of   
   that above... same with gated news groups where you use the dots between the   
   portions of the group name as the directory splitter...   
      
     eg: alt.bbs.ads -> [...]\alt\bbs\ads   
         alt.comp.anti.virus -> [...]\alt.comp.anti.virus   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... You say I'm a bastard like it's a bad thing.   
   ---   
    * Origin:  (1:3634/12.73)