Quick Help for Moderators

EList v5.0 - The Elist program
Copyright (c) 2019 by Vincent Coen.


Note: The information in this guide was taken from A Moderator's
Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
then customized by Vincent Coen.

This file may be designated as the file to be sent in response to
fatal errors and requests for HELP.

EList v5 is a database program that maintains a database of
echomail conference information. This particular program was
written to meet the need to maintain and distribute echomail
conference lists within FIDONet and with other networks.

The FIDONet echolists published by this program include ELIST.NA
a short, areafix uplink file format distributed monthly,
ELIST.RPT, a longer descriptive file distributed on a monthly
basis and ELIST.NO a short list of newly deleted echo's on a
monthly basis.
The last file ELIST.NO is now produced, as Ben did not
produce it, may be it has out lived it's usefulness how ever.
it will be a rolling list in that it will only contain deleted
Echos with any renewed one's at any later date being removed.

Moderators may add or update entries to the list by writing to
ELIST or via Netmail, when these options are available as
announced in ELIST.

Currently such Additions, Updates or Deletions to the Echomail
database should be sent as files as ECHOtag.RUL for any rules
file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
requests and these subjects must also be placed after the keyword
SUBJect.

Once Elist can process Netmail msgs they will be converted to a
individual ECHOtag.ECO file and processed the same way without
any more changes to the program. It is hoped that the same will
apply to Emails
The program will read these files and update the EList database,
then post a reply to the ELIST conference and via Netmail.
(Note: the Reply-to keyword overrides the FROM address if present)
otherwise the FROM is always used.

Address netmail messages

To: ECHOLIST, (2:25/21)
Subj: MOD-ADD or MOD-UPD or MOD-DEL

It is hoped that Updates via Email will be also available some
time in the future via elistmaint@dykegrove.plus.net and this
facility will be announced in the ELIST echo area once available
along with any update to the email address used as well as usage
of netmail to directly deliver such messages instead of using
files.

NOTE that only dropping off the files tag.ECO and tag.RUL to
2:25/21 or 2:250/1 is supported for the moment.

For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
MUST come as files only, along with any rules file with the
following file names :
For MOD-ADD, UPD and DEL as echotag.ECO
For rules files as echotag.RUL
Where echotag is the Echo area tag that is up to 36 characters
in length. Note that for MOD requests you can also add the subject
to the end of the extension i.e.,
MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
[ Note that there is NO space between MOO and UPD or ADD only a
hyphen. ]

Use the following keywords to set the fields of your echo list
submission and note that only the upper case characters are significant
e.g., only SUBJ is needed for SUBJect.
All keywords shown starting with * are mandatory - they MUST be provided.

For keywords FROM, MOD, COMODn and REPLY the following is the format for
your contact address where text with {} are optional extras and as needed:

Contact Address:
A1 A2 A3 Sub field class name as used below.
<name>, <node>[, <email>] Note the separating commas.
A1 name = first last names i.e., Fred Bloggs - Compulsory
[ note the space between name elements ]
A2 node = zone:net/node {@domain} i.e.,
2:345/678 - Compulsory
A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
or '=at=' in place of the at sign [@] and this will
be the one used in ELIST reporting.
You may omit the elements between [] but name is needed to respond to
an update in the ELIST echo so that a problem or not can be addressed
to the specific poster along with the netmail address for sending a
direct message as well. If omitted you a posting could be addressed to
SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
elist program the posting report is issued (helps in debugging).
None of which, aids the moderator doing a search on their name to check
the latest postings.


*SUBJect MOD-UPD or MOD-ADD or MOD-DEL
A space can be between MOD and next word instead of
the '-'. When netmail and emails submissions are accepted
MOD-ADD, MOD-UPD or MOD-DEL must be in the message subject
line - hence one of the reasons for the need of this keyword.

*FROM Details of the sender of message where any replies regarding
errors or confirmation of status of submission is made to.
<Node as a Netmail address format: zone:net/node{@domain}
Moderator node address (can be a registered echo Co-Moderator)
{} Shows a optional extension and therefore can be omitted.
Normally this address should be the Mod or a Co-Mod and can
change depending on who sent in the submission. There is no
option for an email address element but you should include
your name.
*TAGname <areatag> x36.

*TITLe <Brief area description> x72.

*DESCription <Description of the echo> 15 lines x75.

RULEs <A one line description of the rules> x75
Can also be DELETE | NONE | spaces
DELETE will remove any existing rule file and then be treated
as if NONE was supplied
NONE There are no rules for this echo.
Can be omitted, also see RULETEXT.
If both RULES and RULETEXT omitted then there are no rules.
If both are supplied, the content from RULETEXT overrides.
NOTE that the above symbol '|' means or, i.e., a choice.

*MODerator Contact Address.
This keyword MUST be submitted before any COMODn keywords.

COMODerator Contact Address. [ Use COMODn instead ]
This keyword must always appear at any point AFTER a
MOD keyword. This keyword has been replaced by COMODn
Where n = 1, 2, 3, 4. and will be removed within amonth or so.

REPLY-to Contact Address.
Usually same as one in keywords MOD or FROM
Note that usage of Email address is optional for all
Keywords that use contact address as shown above.

*PASSword <current password>, <new password> x36, x36.
[Note the required space after the comma (',')
if new password is used.]

VOLume <number of messages> nnnnn per month.
Use a realistic number. Anything after the number is
ignored as per month is automatically assumed.

RESTrictions </SYSop, /MODerator, /REAl (only first four letters
are needed) or text> x72.

ORIGin <origination net address of the distribution> x36.

DISTribution <distribution> Any text describing x72.

GATEway <gateways> Any text describing x72.

*GROUP <Abbrev. of Network; i.e. FIDO) x16.

*LANG Language used in this echo x16 (default = ENGLISH).

RULETEXT <Signifies start of appended Rules text data> MUST be
last Keyword that finishes with the end line '---'
or '-+-' x75 wide but NO line limits.
This will generate a file as TAGname.RUL
and the content will be listed in the ELIST.RPT reports.
It will be treated exactly the same as a .RUL file and will
in fact create one, replacing any existing rules file.

HELP <respond with help message>
The latest version of this file !

NEWPASSword Updated password that must be used with PASS and does
the same job as the second parameter to PASS keyword.

--- Or "-+-" terminates MOD message but needed after
a RULETEXT keyword block. This keyword was used for testing
but has been left in use if needed.
Useful as you can place other text after, such as keywords
unused as they will be totally ignored.

* Means these are compulsory - they must always be supplied.
xnn is the maximum size in characters of the field.


New keywords or changes to modes of operation:
NEWPASSword Updated password must be used with valid
PASS keyword but also see the optional second
parameter of the PASS keyword.

COMOD DELETE Will delete ALL CoModerators and can then be
followed in another submission with one or more
COMODn (see below) after you have received an
acknowledgement of the update in the echo ELIST.
Do NOT use both in the same UPD submission.
This may change in a later version of the
maintenance elist program.
This keyword is being replaced by the keyword
COMODn (where n = 1, 2, 3 and 4.

This keyword must always be used after a MOD keyword
and NEVER before. There is a maximum limit of
4 Co-Mods (and the same for applies to COMODn).

The usage of the COMOD DELETE option is to allow
a Co Mod moving over to be the new moderator
perhaps with also using NEWPASS to replace the
existing password which must be specified for
the PASS keyword. Note that the keyword PASS
can also be used as password, new-password
instead of NEWPASS.

This keyword will be removed at some point as
COMODn full replaces it but giving more control
over co-mod placement within the block of four.

COMODn Where n = 1, 2, 3 or 4. This keyword will
replace the keyword COMOD. It's usage allows
the moderator to control precisely where each
Co-Moderator sits in the list of four.
It is recommended therefore to use this
option over using just the COMOD keyword as
this option will be removed at some point.

FROM Contact Address.
Sending moderators address see above for the exact
format
Can be any registered CoMod.

A minimum sample ADD file might have this :

SUBJ MOD-ADD
TAG ECHOES
GROU FIDO
FROM Joe Sysop, 1:234/56
PASS password
LANG ENGLISH
TITL FIDONet echoes discussion
MOD Joe Sysop, 1:234/56
DESC Discussions about echoes
DESC and moderators.
---

A minimum sample UPD file with no changes is :

SUBJ MOD-UPD
TAG echo-name
GROUP FIDO
FROM Joe Sysop, 1:234/45
PASS password
---

Likewise for a DEL file just replace SUBJ with MOD-DEL
for the above sample.

The keywords are truncated prior to checking, so matching will
only be done for the capitalized portion of the keyword.
Keywords may be capitalized or lowercase. The following three
entries will have the same effect.

TAG BOARD_GAMES
Tagname BOARD_GAMES
tag BOARD_GAMES

Optionally end the message with --- or -+- (three-dashes or
dash, Plus symbol, dash) indicating the end of the message file.
With the exception of the DESCription field, only one entry is
allowed per field. If multiple entries are included in the text,
processing will continue but only the last one will be saved.
If you don't have an entry for a field, there is no need to
include the keyword (specifying JUST the keyword will
erase/blank any existing value(s).
Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
for updating.

Update submissions to the echolist that don't require any changes
may be done by including the above mentioned keywords.
Full details already in the database will remain the same. New
listings (echo) will again require the above mentioned keywords
at a minimum.

In order to delete an area from the list, you must use the
subject MOD-DEL.

When submitting an entry with the DESC field, be sure to begin
each line with DESC and end it asa with any other keywords
with a hard carriage return.

Note that there can only be one line with a RULES keyword.
For multi line rules use the keyword RULETEXT see below.
(Some editors may word wrap all messages and strip carriage
returns when saving. Some of these editors, however, may allow
you to force carriage returns by indenting.) Avoid any that use
the TAB as it is not honoured and any will be replaced by space.

NOTE: blank lines after DESC keyword will RESET everything to
null, as with all text based keywords.
For RULETEXT, every line is included as is.

You can insert the content of your Mod Rul text file (just the
body of text) on the next and following lines right AFTER the
RULETEXT keyword at the END of a MOD UPD submission (naturally
for the same Tag name). The content of RULETEXT will create a
.RUL with the same Echo tag name (as upper case) followed by the
extension .RUL, again in upper case.

For latest changes also see the document README-Elist where more
information may be present to extend these details.


Address any questions to the ELIST controller Vince Coen at
2:250/1, by choice at the echolist echo itself, [ELIST] or via
Email to vbcoen@gmail.com for a faster response.

-=:{ End of EListHlp.Txt }:=-


This document last updated :
2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
Updated content for readability, helpfully.



--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~

This document is subject to change depending system testing and the finding
of errors within.

The following notes will be incorporated in to new manuals and help files for both the program operation and for Moderators otherwise acts as additional material.

All requests via MOD-ADD, MD-UPD and MOD-DEL must have keyword PASS present followed by the password on file. This is checked for on all, and for MOD-ADD the echo data record must not exist yet. At the current moment only files are accepted by being dropped off at the Elist maintainer system i.e., ECHOtag.RUL and ECHOtag.ECO the subject for the ECO file must be present (See new keywords below). ECHOtag should match up to the content of TAG keyword.

Once processing for JAM netmail areas are set up (as used with mbse), then this
is the file that is created for each message so that the same processing can be
used.
The same will apply to the use of email for sending and receiving elist updates
or warnings.

The important issue, is to find suitable C type libraries that can be utilised for the purpose and so far none has been found.
As and when this is implemented each Email will also have a ECHOtag.ECO file created, again to use the same processes.

New keywords: Where a * preceding is a mandatory keyword - it MUST be provided.
------------ ================================================================

NEWPASS To change an existing password. PASS oldpassword, newpassword can
also be used. This keyword was used for testing and has been left
available.
*LANG Echo language where ENGLISH is the default.
*SUBJect MOD-ADD, MOD-UPD or MOD-DEL and HELP.
COMODn See below for more information.

For HELP (to be sent via netmail, no other keywords are needed other than FROM
but the file must have the .ECO extension but the name could be anything.

New sub keywords:
----------------

On keyword RESTrictions the following are accepted :
/REAl Real Names only
/SYS SYSops only

New:
/MOD Moderators (and Co-Mods) only
NONE or Blank - No restrictions - Use NONE to remove any others present
and make it NONE.
The restrictions can be cumulative, i.e., you could have /REL /SYS /MOD which implies:

Only for moderators who have a registered nodelist entry and they must use their
real names. Do not use the other additional descriptions as those get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update.

Keyword Changes:
~~~~~~~~~~~~~~~

COMOD DELETE (or NONE) will delete ALL 4 recorded Co-Moderators.
Useful if a CoMod has become a Mod and/or wishes to clear down dead
entries or specific entries.

This is being discontinued and replaced by COMODn see below.

NEW Keyword that is replacing COMOD
This keyword gives more control for the moderator to amend or delete
a specific CoModerator entry reducing the risk of mistakes.

COMODn Where n = 1, 2, 3 or 4. followed by :
DELETE or NONE will delete specific CoMod entry
or
A valid contact address which will update a specific CoMod entry.

Hopefully this is a better way of controlling Co-Moderator entries.

Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - Element three
FirstName LastName, Zmmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.

The first two are required for responses posted to ELIST and if errors
or expiry warnings direct to the network address.
Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.
Support for Email is not yet available.
Support for receiving submissions via netmail not yet available.

RULES Processing:
----------------

Rules can be provided in one of two ways

1. Recommended by send a rules file with the file name of Echo Tag as upper
case plus extension of .RUL, i.e., MBSE.RUL

It can be ANY number of lines but each line must not exceed 75 characters
but can include blank lines for readability.
(for those Bulletin Board Systems that have such restrictions).

2. Sending as part of a MOD-ADD or MOD-UPD file where the rules text lines
follow immediately after the keyword RULETEXT and before the last line
which is the terminator '---' or '-+-', or the end of the file.
Again blank lines can be embedded within the text.
Note the same text block can be transferred to a ECHOtag.RUL file as is
but without the terminator line '---' or '-+-'.

In any event all RULETEXT content is transferred to a ECHOtag.RUL file
overwriting any existing file.

All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD or
MOD-DEL.

These files must be sent as echo tag name as the filename, for example the echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.

Note that any moderator and this includes a co-moderator can submit a MOD-UPD or
MOD-DEL providing they are on record as one, in the echo being changed. This is
so that if the moderator has a major system problem or leaves the network for any reason, another can take over and send a MOD-UPD submission even as a
one off.

A moderator taking over from a previous one should get the existing moderator to send in a MOD-UPD with their contact address as a CoMODn (1 thru 4) and if all are in use just over write one of these entries.

After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contract address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.
If needed use PASS oldpassword, newpassword to change the existing password or use :
PASS oldpassword
NEWPASS anewpassword

The password, as a one word string with the letters 0 - 9, a - z, A - Z
and any standard symbol character as found on a standard keyboard using one key
stroke (shift allowed), i.e., no key sequences using the ALT or CTL keys as they
can interfere with file processing. Do NOT use a space character as that will mark the end of the password.
Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.

The password is case specific so ABCD is not the same as abcd which is not the same as AbCd.
Maximum size is 36 characters.

Note that the slash keys \ and / must not be used in case of file processing using a database such as Mysqld or Mariadb etc and no they do not like them
for some reason.

A Reminder, a change of password can also be done using the PASS keyword i.e., PASS old-password, new-password Note the space after the comma ','.

Examples for change of moderator - the current moderator sends:

SUBJ MOD-UPD
FROM 1:345/6
TAG echoname
PASS current-password {can also be current-password, new-password}
GROUP FIDO
COMOD1 new moderator Contact address, etc, Fred Blogs, 2:234/5, fboggs@gmailcom
Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged:

SUBJ MOD-UPD
FROM 1:234/5
TAG echoname
PASS password [ using the currently existing password ]
NEWPASS newpassword If needed.
or use
PASS old-password, new-password
GROUP FIDO
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]
COMOD1 DELETE [ to remove all comod details as should not have a
duplicate address if not done by previous
moderator. ]

For subsequent updates then change PASS to reflect the new password after receiving an acknowledgement message via ELIST or netmail.
Remove the NEWPASS and COMOD entries, adding any other keywords that require changes if any.

There is one abnormality in functions found in that in the event of a Moderator
leaving the network (Fido or another) without having a co-moderator then
there is no simple way of changing by a new MOD-UPD file that can be used to change the Mod to another without a security risk unless the Co-Mod has a
copy of the MOD-UPD file that acts as a back up if something occurs with the Mods hardware or leaves the network for what ever reason.

It is recommended that all Moderators have a least one co-moderator for each echo area along with a copy of the current MOD-ADD and MOD-UPD file.
Therefore the only other way is to send in a msg via ELIST echo to the
Elist maintainer to manually change her/him to another so that all Mods can see
the request and if needed, object to such a request and this will help prevent echo hi-jacking, I hope.

Again:-
This hopefully will be the only reason for using the MAINT function unless I or
some one else can come up with another solution other than all moderators have at least one CoMod who is given a copy of the current MOD-ADD and MOD-UPD files
or records, so in the event of a major problem with the current moderator such as hardware, health or left fido then another can easily take over even if only
for a few months while the problem/s are sorted out.

Yes, I have written it twice!


Expiry Warnings
---------------

Up to four are issued with the first one sent to moderator on record and in ELIST after six months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD UPDs processes
have finished close to 23:45 on the 1st of the month.

Warnings 2, 3 & 4 (the final) is sent to the moderator and all Co-Moderators on
record at their registered netmail address as well as in ELIST.
These will be issued during the WARN run, which will happen on the first of each month close to midnight and after the last run of UPDATE has completed say
by 23:50 on the same day or the last day of the month.

If an update has not arrived at the elist maintainer before the end of month 5 then the echo WILL be deleted with the tag and title transferred to the ELIST.NO
file.

Reminder:
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :

FROM
SUBJ
TAG
PASS
GROUP FIDO

Providing the contact address in the FROM keyword is one of the registered moderators then the Update will be considered valid proving there is no errors within any keyword or secondary parameters.

Note that each MOD-ADD, UPD or DEL is validated for correctness and if any errors are found the request is rejected with a message regarding the problem/s
found, sent to the sender's netmail address (as on the FROM keyword) and the ELIST echo.


System Data Limits :
==================

Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - UPPER CASE
Echo Title - 72 characters max - Mixed case.
Echo Volume - A monthly figure not exceeding 9999, please be realistic
e.g., 50.
Echo Restrictions - 72 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text.
Any other text can be mixed case.
Echo Distribution - 72 characters. Any text.
Echo Gateway - 72 characters. Any text
Echo Lang - 16 characters - any case but converted to UPPER CASE -
Default = ENGLISH
Echo PASSword - 36 characters Mixed case, A-Z, a-z, 0-9 and any symbol
using a standard 105 key keyboard, i.e., no ALT combinations
but not \ / or space.

All sizes assume that one byte equals one character so use a standard character
set as the software does !

elist Operations mini version
-----------------------------

The elist program consists of three primary processes driven by one to four parameters namely -

REPORT Run monthly on first of the month 23:50
WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been four
warnings issued over a four month period after the 6 month time period
since the last MOD-UPD (update) has been received.
This means that no echo will be auto deleted unless there has been a
minimum period of 6 + 4 + 1 months from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month 23:45
UPDATE Run one or more times per day with the last at 23:40.
There are other processes that are not described they are under test or security
or just have not got around to it until completed.

The emaint program has only one process.

Run Interactive Maintenance only as needed.

This will add, update or delete an existing echo entry as needed.

For those that are interested or not, here is the last 20 version update notes:

5.1.000 1st beta release. Change mbse Echo and netmail areas to
production areas.
.001 Forgot to remove the testing tag displays in FA105.
.002 During a Rules create/update WS-No-Care3 was not cleared
after use in FA260 when used with log-Msg.
.003 Chg ELIST-NOM rec to have ELIST delete date and if
> 365 days old delete it. EA250-Produce-NO-File
.004 CREATE A ELIST DB file clean process to :
copy file recs out to temp file and reload
Do same for Elist-NOM as well - on request.
24/03/20 vbc .005 For a sub that has extension of ECOMOD-UPD or ADD
the ws-Flg-SUB flg is not been set. Fixed. Any later
SUBJ will as always over ride any previous setting
the same as any other duplicated keyword.
Change to EL212 to include the mandatory keywords.
.006 In .005 fix forgot to remove clearing WS-Subject.
.007 Rem'd out the msgs archiving as init testing complete.
Test on skip-password with old and new record wrong
in FA170
.008 In FA122 and tests for REST added extra for any other
text after tests for /SYS /REA /MOD which hopefully
will find any other sundry information text.
.010 Not reported correctly in BA032 as forgot to add the
new code in .008 to it. Nope should be a simple move.
25/03/20 vbc .011 Changed tests for .ECO content to report when none
to log file in FA098.
26/03/20 vbc .012 Test for Missing SUBJ keyword (EL224) with the
other mandatory keywords.
.013 Extra msg EL237 & chng text for EL224 for Subject
After junk in log-msg for EL224 when subj missing
in a submission.
Change display at to a log-msg need to do the others.
.014 Adjust slightly unknown keyword del on " " as well
and check for --- or -+- at unknown keyword section.
Trim out 2nd word in FA120 skipping leading spaces.
.015 At end of unknown keyword goto was wrong (FA015)
29/03/20 vbc .016 Support for sleep time in UPDATE def = 3600 if
invalid. Delete all ECO files at end of FA000-Update
from the file list records so that any fresh ones
will get processed next step run.
30/03/20 vbc .017 Program change for elist-maint now emaint.
Additional code for:
1. Support to allow param 4 P-D as a number of seconds
to sleep for a UPDATE re-run when P4 = RERUN.
and =nnn present for a count of nnn.
02/04/20 vbc .018 2. Support for UPDATE re-run for minutes past the hour
based on value in P-D adjusted at last time finished
so that the rerun will occur at the same minutes
past the hour. Default set as 30 See AA032 & prior.
Bug found when tag.ECO does not match keyword
TAG value does not update during UPDATE run.
Changed FA122 Tag process & inserted FA107-Reload.
Added extra line in ELIST.RPT for warning count
if non zero.
if param 3 = FULL-REPORT then ELIST.RPT contains
content of the rules file if present.
.019 Bug: RERUN is working without the RERUN param.
Hopefully fixed in Tag check in FA120, FA122, FA107.
03/04/20 vbc .020 Nope still reread the same data? so clear rec before
read. THIS IS GETTING very odd!
.021 Re-opening the wrong file, der.
.022 IN BA not acting on WS-Warning-Flag-Set (1) but not
really needed. Added at end of reports Warning count
message if > 0.
.023 Error in REPORT for warnings not space filled before.
04/04/20 vbc .024 Need to open elist-log in UPDATE if closed when in
Rerun mode.
Before usage of "CC:" for emails WS-Msg-Addr-Email
WS-Net-Email was not being spaced.
.025 Clean up logic of UPdate processes in AA032 with
required extra steps and running needed scripts
along with extra tests for a Friday to run build.elst.
.026 Added elist backups to weekly Friday processing adding
to first of month.
Consider converting main file processing to RDBMS (Mysql?)
would allow more group data manipulation, i.e., in SQL.




Updated 2020/04/04 Vincent Coen. 1:25/21 & 2:250/1, vbcoen=at=gmail.com



--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)