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.
---