Hello All!


I am now happy, well as far as I can be that elist v5.0.117 is working to a reasonable level :)

It is now being re-issued as elist v5.1.000 for a live run very shortly.

I will be running it against echo ELIST which will show auto updates creating the database (file).
It will show the original dates of the last update as from ELIST.RPT dated May 2019, and this means that moderators will need to update their entries.

It could be after all this time that there are moderator change that have occurred.

If you have a problem doing an update please advise but the simple way is to do
a UPD submission with the new mod as COMOD1 before passing the submission files
to them.
The system will allow any moderator including a co-moderator to do a UPD submission.
This is to allow any of the recorded moderators to submit an update if the moderator has left Fido etc.

At the moment the system is set to issue expiry Warnings after six months and is pre programmed to do so on every WARN run which is set to be every month but
this means that a echo will not get deleted until month 11 after the date of the last update.

Strikes me as some what too long, so is it reasonable to do it weekly which will give 4+ weeks after the first warning is is that short ?

The reporting has been changed to allow for the generation of the ELIST.NO file
that shows deleted echo's and will also be up to date, i.e., any newly added Echo's will be removed from the master NO file.

All submissions (as echo tag name.ECO and echotagname.RUL files) must, at least
for the moment be sent only as files and dropped off direct, to my netmail addresses of 2:250/1 or 2:25/21. For example the files for echo MBSE are MBSE.ECO and MBSE.RUL

Of course the rules can be inserted in the submission file between keyword RULETEXT

and
-!- or
-+-

and must be the last block in the submission files as anything after, will be ignored.

I intend to revisit the elisthlp file that will be included in with the ELST monthly archive along (as it has in the past) with ELIST.RPT, ELIST.NA and the new ELIST.NO if there is any content as well as a archve containing the directory (rules) containing all current rules files (as updated by moderator submissions as upper case files names).

The use of upper case files names is to support any sysop running a BBS that requires it.

There might also be additional text files such as a README to prvide additional
help over than the normal elisthlp.txt file at least until I can refresh it in a easy to read format. Any questions asked regarding usage will also mean a re-look at the supplied help file to fix the need to ask such questions where ever possible.


Vincent

--- Mageia Linux v7.1 X64/Mbse v1.0.7.13/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Re: Elist maintanence program
By: Vincent Coen to All on Sat Mar 21 2020 20:17:13

At the moment the system is set to issue expiry Warnings after six
months and is pre programmed to do so on every WARN run which is
set to be every month but this means that a echo will not get
deleted until month 11 after the date of the last update.

Strikes me as some what too long, so is it reasonable to do it
weekly which will give 4+ weeks after the first warning is is
that short ?

something to think about regarding deletions and purges:

there are/were some people that gamed the system and would attempt to hijack echo listings after they were marked for deletion and before they were actually deleted... they hoped to get their mod upd in place as soon after the actual deletion happened and before the moderator got their update in... this is one of the reasons why, in the past, the actual purge was run manually instead of being automated... for one thing, this allowed the list keeper to run the updates before the purge... plus with the purge being done randomly on an unknown not broadcast schedule, it made it a lot harder for someone to game the system and hijack an echo's listing...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hello mark!

Sunday March 22 2020 09:58, you wrote to me:

Re: Elist maintanence program
By: Vincent Coen to All on Sat Mar 21 2020 20:17:13

At the moment the system is set to issue expiry Warnings after
six months and is pre programmed to do so on every WARN run which
is set to be every month but this means that a echo will not get
deleted until month 11 after the date of the last update.

Strikes me as some what too long, so is it reasonable to do it
weekly which will give 4+ weeks after the first warning is is
that short ?

something to think about regarding deletions and purges:

there are/were some people that gamed the system and would attempt to
hijack echo listings after they were marked for deletion and before
they were actually deleted... they hoped to get their mod upd in place
as soon after the actual deletion happened and before the moderator
got their update in... this is one of the reasons why, in the past,
the actual purge was run manually instead of being automated... for
one thing, this allowed the list keeper to run the updates before the purge... plus with the purge being done randomly on an unknown not
broadcast schedule, it made it a lot harder for someone to game the
system and hijack an echo's listing...

Updates will ALWAYS be done before the WARN process at least every night but more likely every hour with a master sweep at 23:30.

Will have to do it often because my systems bbs software (mbse) does not over write an existing file with a newly downloaded one.


Note my time zone is UTC or in old money GMT and of course next Sunday will be UTC+1. Computer time is always local here as adjusted for summer etc.

HAving had a few comment regarding I will maintain the 6 months plus 4 at one month plus the final up to 1 month last minute sort it out!

In any event the deleted Echo tag, Title and date deleted is maintained in the NO master file where it stays unless it gets a MOD-ADD for 365 days before being deleted. I assume some one would like to re-activate it in that time
but that does not mean if it is it would generate any more posts :)

So a reminder the Warnings of expiry start after 6 months have past since the last update with one warning per month there after for four months then a final
warning of being deleted. This will give the moderator or a co-moderator 11 months to issue an update.

Can I remind every one that these warnings are issued to:
The moderator via ELIST and direct by netmail
After the first warning these warnings are also sent to all co-Moderators on record and any one of these can send in a update (MOD-UPD) request.

This process will allow a co-mod to keep a echo going if a moderator leaves FIDO for any reason including death.

They can then discuss with any other co-mods who will take it over.

It does of course assume that all Moderators have at least one Co-Mod to act as
a back up and that they co-mods have been given a copy of the original MOD-ADD & MOD-UPD files along with a .RUL file if applicable.

Hopefully this will cut down most of the problems of the past.

If a co-mod does have to take over they can change the MOD details to that of themselves then on the next UPD run delet their entry in the Co-Mod entry table
of four, hense the use of the keyword COMODn where n = 1,2, 3 or 4.

I am sure there will be a short time of ironing out any snags just as there will be finding any bugs in the software as there is no such animal as bug free
software, even Hello World.

My posting to ELIST and via netmail will for the moment be from myself but I will be looking at trying to change the mbse mbmsg post program to support 2 extra parameters for Name and Netnail from address. This is because the one's used are as set up in the BBS for the Sysop. Which for most purposes is ok, unless . .

One of the next jobs, heck got enought time as I cannot leave the house being over 72 and the CV19 issue!

Plus my wife will not let me and even in the car I have an argument despite having new 30+ day half face masks at 300 microns filtering and brand new pollen air filter fitted after a 10 year major service (Jaguar X-Type) and no not new. I should be that wealthy!


Vincent

--- Mageia Linux v7.1 X64/Mbse v1.0.7.13/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)