home *** CD-ROM | disk | FTP | other *** search
/ Hot Shareware 32 / hot34.iso / ficheros / VUBBS / ELIST804.ZIP / ELMOD804.TXT < prev    next >
Text File  |  1998-04-01  |  32KB  |  721 lines

  1.  
  2.                                 ECHOLIST
  3.                       The EchoMail Conference List
  4.                               USERS GUIDE
  5.  
  6. 01 Apr 98                                                   ELMOD804.TXT
  7.  
  8.    No Changes this edition
  9.    ************************
  10.  
  11.    This Users' Guide is intended as a brief description of the EchoList,
  12.    a summary of how to submit updates to the database, and how to obtain
  13.    information on the status of an echo from the Echolist.
  14.  
  15.    Changes since the last issue are highlighted in the left margin with
  16.    the pipe symbol '|'.
  17.  
  18. FILE CONTENTS
  19. =============
  20.  
  21.    Table of Contents of this file:
  22.  
  23.                        FILE CONTENTS
  24.                        DISTRIBUTION
  25.                        CURRENT ELIST STATUS
  26.                        PURPOSE OF THE ECHOLIST
  27.                        EXPIRY OF ELIST ENTRIES
  28.                        ACKNOWLEDGEMENTS OF UPDATES
  29.                        SENDING AN ADDITION OR UPDATE
  30.                        DELETING AN ECHO
  31.                        SENDING A RULES FILE
  32.                        SENDING A QUERY REQUEST
  33.                        OBTAINING INDIVIDUAL RULES
  34.                        AUTOMATING THE UPDATES
  35.                        HOW ECHOLIST PROCESSES MESSAGES
  36.                        CONCLUSION
  37.  
  38. DISTRIBUTION
  39. ============
  40.  
  41.    A new ELMODnnn.ZIP (User's Guide) is distributed monthly, and each
  42.    issue replaces all previous versions of ELMOD.  The 'nnn' is replaced
  43.    by 3 numbers representing the last digit of the year followed by two
  44.    digits of the month number - eg June 1997 is 706.
  45.  
  46.    This file is distributed monthly in the ECHOLIST file echo, and is
  47.    also available on the Internet at the following Web page:
  48.  
  49.              http://www.portal.ca/~awalker/elist.htm
  50.  
  51.    In addition, the file is constantly updated to reflect changes in the
  52.    Echolist software, or to improve the explanations, and the current
  53.    draft version of the file is published weekly in the ECHOLIST message
  54.    echo, distributed by Fidonet's North American Backbone.
  55.  
  56. CURRENT ELIST STATUS
  57. ====================
  58.  
  59.    In the weeks following 02 June 1995, the Echolist software was
  60.    completely rewritten to permit its use on a different platform and to
  61.    allow fully automated operation.  Most former features and formats
  62.    were retained, but since the rewriting of the software necessitated
  63.    some changes, moderators are encouraged to read this file carefully
  64.    for details of the current Elist operation.
  65.  
  66. PURPOSE OF THE ECHOLIST
  67. =======================
  68.  
  69.    The EchoList is a monthly publication produced by the Zone 1 Echolist
  70.    Coordinator at 1:153/752.  It provides a place for Moderators to
  71.    advertise their conferences regardless of distribution system or
  72.    network, both to people who would like to participate, and to those
  73.    who route echo traffic.  It is also a reference for distribution
  74.    systems wishing to contact the Moderator of an echo, or wishing
  75.    information about an echo's topics.  The Echolist is independent of
  76.    all echomail distribution systems and their rules.
  77.  
  78.    Only one restriction exists on the acceptance of entries.  We reserve
  79.    the right to decline to accept a requested entry if in our opinion
  80.    the listing of an entry appears intended to cause harm to an
  81.    individual, promotes illegal activities, or is likely to affect
  82.    adversely those involved in distribution of the Echolist or the echo.
  83.  
  84.    The listings in the EchoList are maintained by the Moderators and
  85.    Robot software, not by the Echolist Coordinator.  Additions and
  86.    updates to the database are done by submitting NetMail messages
  87.    addressed to a special name and node address.  The Subject of the
  88.    message indicates what is to be done, and the body of the message has
  89.    the data for the database entry.  The format of the message body
  90.    requires that each line have one keyword and its accompanying data.
  91.    Since the process is automated, correct formatting of both the
  92.    address and the message body is essential to having your data
  93.    recognized by the program.
  94.  
  95. EXPIRY OF ELIST ENTRIES
  96. =======================
  97.  
  98.    To ensure that the Echolist contains only up-to-date information:
  99.  
  100.    ***********************************************************************
  101.    ALL ENTRIES EXPIRE SIX MONTHS AFTER THE MODERATOR'S LAST UPDATE IS SENT
  102.    ***********************************************************************
  103.  
  104.    This means that a Moderator must send an update by netmail or
  105.    Internet email at least once every six months to maintain the
  106.    EchoList entry. Moderators and Co-Moderators should work together to
  107.    ensure that this is done.  It is suggested that the process be
  108.    automated, and many moderators send their updates monthly.
  109.  
  110.    5 months after an entry was last updated, a netmail or Internet email
  111.    advisory is sent to the person who last updated the entry, at the
  112.    node number or Internet address on record.  At the same time the
  113.    Elist entry is flagged with the following warning immediately under
  114.    the tag in the Elist:
  115.  
  116.                          !!! DELETE WARNING !!!
  117.  
  118.    6 months after an entry was last updated, if the entry is still not
  119.    updated, it is deleted from the Elist distribution files.
  120.  
  121.    7 months after an entry was last updated, it is completely purged
  122.    from the database, and all password protection of the tag is lost.
  123.  
  124.         NOTE:
  125.  
  126.         Warning, expiry and purging are performed when the Elist is
  127.         published on the first of each month, so for calculation
  128.         purposes the software assumes that an echo was updated on
  129.         the first of the month following the actual update.
  130.  
  131. ACKNOWLEDGEMENTS OF UPDATES
  132. ===========================
  133.  
  134.    Acknowledgements of receipt of update netmail messages are sent via
  135.    Fidonet's echomail-routed netmail, unless the hold option is
  136.    specified.  Update Internet email messages are acknowledged by return
  137.    Internet email. Acknowledgements to non-Fidonet nodes are available
  138.    only if the hold option is specified.  Please note that packet-header
  139.    format prevents holding mail addressed to points - it will be
  140.    necessary for points to call in as .0 to pick up such mail.
  141.    Automated expiry warning netmail is all routed.
  142.  
  143.    The Elist software is run each time inbound mail is received. Netmail
  144.    is processed immediately regardless of whether it arrives via a
  145.    passworded or an insecure session, and email is processed immediately
  146.    as well.  As a result, updates usually are processed within 60
  147.    seconds of their arrival.  Some delay is inevitable if the system is
  148.    in the middle of processing a major mail dump.  To allow for that, if
  149.    you have requested that an acknowledgment to be placed on hold, it is
  150.    suggested that you wait for one hour after delivering an update
  151.    before polling again.  Email responses are sent to the Internet
  152.    immediately after being written.
  153.  
  154.    Successful updates are also posted daily in the ECHOLIST echo.
  155.  
  156. SENDING AN ADDITION OR UPDATE
  157. =============================
  158.  
  159.    To add or update an EchoList entry, submit either a
  160.  
  161.          1.  NetMail message addressed to "ECHOLIST" at 1:153/752, or
  162.          2.  Internet email message addressed to awalker@portal.ca
  163.  
  164.          NOTE:  The return Internet email name@address MUST be 35
  165.          characters or less since Fidonet *.msg format is used by the
  166.          Robot for creating return messages.
  167.  
  168.    A separate message is required for each echo being updated.  The
  169.    message subject for both netmail and Internet email must be
  170.    "MODerator UPDate" which may also be abbreviated to "MOD UPD".  The
  171.    message header thus looks like this:
  172.  
  173.          Correct:     [Netmail]            [Internet email]
  174.  
  175.          To:          ECHOLIST             awalker@portal.ca
  176.          At:          1:153/752              [n/a]
  177.          Subject:     MOD UPD              MOD UPD
  178.  
  179.          Wrong:
  180.  
  181.          To:          Adrian Walker
  182.          At:          1:153/752
  183.          Subject:     MOD UPD
  184.  
  185.    Note:  The Echolist software will take your return address from the
  186.          MSGID, if present.  If your message originates in a Fidonet or
  187.          FTN-format network, the MSGID is expected to show an address in
  188.          a form which constitutes a valid return address for the
  189.          originating network.  An Internet-format MSGID address will
  190.          result in an error in recording of the return address.
  191.  
  192.    MESSAGE BODY FORMAT
  193.    -------------------
  194.  
  195.       The body of the message text has the data for the database entry,
  196.       formatted so that every line starts with a special keyword that
  197.       identifies the field name as detailed below, followed by at least
  198.       one space, followed by the data to be put in that field.
  199.  
  200.       The required fields for new entries are TAG, TITLE, DESCRIPTION,
  201.       and MODERATOR.  The use of PASSWORD is strongly encouraged!  The
  202.       other lines are optional, and if you do not wish to supply data
  203.       for a given field, omit that line.
  204.  
  205.       Similarly, if you wish to delete the contents of a data line, just
  206.       include the keyword with no text after it, and the 'empty string'
  207.       will replace whatever is in the database for that keyword.
  208.  
  209.       If the echo is already in the current Elist, only the TAG and (if
  210.       a password is in place ...) PASSword fields need to be included in
  211.       an update message, since the software will supply the remaining
  212.       information from the existing Elist entry.
  213.  
  214.       NOTE 1:  If an abbreviated update is sent, the netmail response
  215.                from the Robot will only contain the data provided in the
  216.                update.  All previous data in the database is left
  217.                intact, but is not shown in the netmail.  To see a copy
  218.                of the complete entry, the QUERY function described below
  219.                may be used.
  220.  
  221.       NOTE 2:  Although an abbreviated update is accepted, the public
  222.                posts of updates in the ECHOLIST echo similarly contain
  223.                only the data from the update message.  Since these posts
  224.                form a useful advertising medium for an echo, a moderator
  225.                may wish to include all data in every update to assist
  226.                users reading these public posts.
  227.  
  228.       NOTE 3:  If the echo has already been deleted from the Elist, you
  229.                can not submit an abbreviated update, since the missing
  230.                data is no longer on file, and only the tag and password
  231.                are kept until the 7-month purge date.
  232.  
  233.       Each line may appear only once, the two exceptions being DESC and
  234.       MOD lines, of which there may be as many as necessary up to the
  235.       limit shown below.  If multiple copies of other lines are
  236.       included, only the last one will be recognized by the software.
  237.  
  238.       The first data line MUST be TAG.  After that, all other lines can
  239.       come in any order.  The keyword starts at the left margin of the
  240.       line, and may be abbreviated, but the CAPITALIZED part of the
  241.       keyword is the minimum abbreviation you can use.  Put at least one
  242.       space between the keyword and the text of the line.  The To-name,
  243.       subject, keywords and passwords are NOT case sensitive.  The <>
  244.       and [] in the following lines are used here only for clarity and
  245.       should be omitted.
  246.  
  247.       In the body of the message:
  248.  
  249.       Mandatory:
  250.  
  251.       TAGname       <echo area name>                     [max 19 characters]
  252.                 AREA is also accepted for backward compatibility.
  253.       TITle         <brief description of the echo>      [max 58 characters]
  254.       DESCription   <full description of the echo>       [max 25 lines]
  255.       MODerator     <moderator name>, <moderator node>   [max 6 lines]
  256.  
  257.       Strongly encouraged:
  258.  
  259.       PASSword      <current password>, <new password>
  260.  
  261.       Optional:
  262.  
  263.       ORIGin        <originating node of the distribution>
  264.       DISTribution  <distribution systems or regions>
  265.       FEED          <main Zone-level feeds in each network>
  266.       GATEway       <gateways to other zones & networks crossed>
  267.       LANGuage      <language(s) accepted in the echo>
  268.       RESTrictions  </SYS /MOD /MEM /REA /ACC /RUL>
  269.       TOTalnodes    <number of nodes carrying this echo>
  270.       VOLume        <number of messages>/<Month, Day or Week>
  271.       RULEfile      <filename of rules file in ELRULnnn.ZIP>
  272.       OPTION        <HOLD>                               [no abbreviations]
  273.  
  274.       Note:
  275.  
  276.       1.  Fields such as SEEN-BY and PATH are no longer recognized or recorded.
  277.       2.  Packet-header format prevents holding mail addressed to points -
  278.           points should call in as .0 to pick up such mail.
  279.  
  280.    SAMPLE ENTRY
  281.    ------------
  282.  
  283.       TAG  ECHOLIST
  284.       PASS YOURGUESS
  285.       TIT  EchoList Access Conference
  286.       DESC The EchoList, or Elist, is published at the beginning of each
  287.       DESC month and is a listing of EchoMail Conferences as described
  288.       DESC and submitted by each conference's moderator.  Successful echo
  289.       DESC update requests are posted in this echo in addition to being
  290.       DESC sent in netmail to moderators.  This provides public
  291.       DESC information on updates between the monthly Elist file
  292.       DESC distribution dates. This echo also provides access to the
  293.       DESC Elist's author for questions about the database which are not
  294.       DESC answered by the ELMOD and ELFAQ help files.  For availability
  295.       DESC of files and routine questions about update formatting,
  296.       DESC participants should first contact their NEC or REC.  Discussion
  297.       DESC of echomail links and distribution systems is off topic.
  298.       ORIG 1:153/752
  299.       DIST Z1-Backbone
  300.       FEED 1:396/1, 1:140/1, 1:3615/50, 8:973/1
  301.       VOL  300/Week
  302.       RULE ECHOLIST.RUL
  303.       MOD  Adrian Walker, 1:153/752
  304.  
  305.    KEYWORD EXPLANATIONS
  306.    --------------------
  307.  
  308.                             <MANDATORY KEYWORDS>
  309.  
  310.       TAG is the one-word name used in distributing the echo, and is
  311.       also called the area name or group name.  Since the tag is used by
  312.       areas control programs to create subdirectories, is formatted into
  313.       the echo listings of distribution systems, and is processed by
  314.       various mail processing software, the following guidelines for
  315.       tags are provided:
  316.  
  317.          - No longer than 19 characters.
  318.          - The first 8 characters should not duplicate those of other tags.
  319.          - Characters should be between ASCII 33 and ASCII 126 inclusive.
  320.          - The following characters should be avoided, because the
  321.            software indicated below is known to restrict their use in
  322.            tags.  Any use of these characters in a tag name, therefore,
  323.            may cause distribution problems for the echo when passing
  324.            through systems using such software:
  325.  
  326.             *    (Imail, Fastecho)
  327.             ?    (Imail, Fastecho)
  328.             [    (Imail, Fastecho)
  329.             ]    (Imail, Fastecho)
  330.             .    (Can not be used in Tag-name-based filenames/subdirectories)
  331.  
  332.          - The first character should not be any of the above, or:
  333.  
  334.             -    (Imail, Fastecho)
  335.             +    (Imail, Fastecho)
  336.             &    (Imail, Fastecho)
  337.             ~    (Imail, Fastecho)
  338.             #    (Imail, Fastecho)
  339.             %    (Imail, Fastecho)
  340.             =    (Imail, Fastecho)
  341.  
  342.       The Echolist does not accept duplicate tag names.
  343.  
  344.       TITLE should be a one-line title for the conference, preferably 58
  345.       chars or less.  Since the title is also imported from the Elist
  346.       directly into the echolists of various distribution systems,
  347.       titles longer than 58 characters are likely to be truncated.
  348.  
  349.       DESCRIPTION is a mandatory field, and allows for a more detailed
  350.       description of the conference, since you can supply multiple DESC
  351.       lines.  In the Elist all DESC lines are combined into a single
  352.       paragraph.  Make sure that you have the keyword DESC in front of
  353.       *every* line of description text, or the Elist software will not
  354.       recognize what type of line they each are.
  355.  
  356.          Correct:
  357.  
  358.          DESC The EchoList, or Elist, is published at the beginning of each
  359.          DESC month and is a listing of EchoMail Conferences as described
  360.          DESC and submitted by each conference's moderator.
  361.  
  362.          Wrong:
  363.  
  364.          DESC The EchoList, or Elist, is published at the beginning of each
  365.               month and is a listing of EchoMail Conferences as described
  366.               and submitted by each conference's moderator.
  367.  
  368.       MODERATOR, for the purpose of the Echolist, is normally defined as
  369.       the person(s) with authority over the distribution and policies of
  370.       a conference.  For those echoes not requiring such a single
  371.       authority, the listing refers instead to the person designated as
  372.       contact person or liaison on behalf of the echo.
  373.  
  374.          There MUST be at least one Moderator listed in order to have a
  375.          valid EchoList entry.  Each Moderator line consists of a first
  376.          and last name (no initials or middle names) followed by a
  377.          comma, and then the Moderator's node address.  Only one name
  378.          and address is permitted per MOD line.
  379.  
  380.          Node addresses should provide the method of contact with the
  381.          Moderator, and since the Echolist is produced within Fidonet,
  382.          this should be an address, or a point off an address, which is
  383.          listed in a commonly available nodelist and is thus accessible
  384.          from Fidonet.  There should be no spaces in the address field.
  385.  
  386.          Correct:
  387.  
  388.             MOD  Adrian Walker, 1:153/752
  389.             MOD  Adrian Walker, 1:153/752.0
  390.             MOD  Adrian Walker, awalker@portal.ca
  391.  
  392.          Wrong:
  393.  
  394.             MOD  Adrian Walker 1:153/752         [no comma]
  395.  
  396.       The use of the PASSWORD field is strongly encouraged.  It may
  397.       protect your entry from modification by someone else.  There are
  398.       two password fields on the PASSWORD line.  The first is for the
  399.       current password.  The second is optional and is for the new
  400.       password to change it to, if you want to change it.  Here are the
  401.       formats:
  402.  
  403.             PASS  SOMEWORD                       [existing password]
  404.             PASS  SOMEWORD, NEWWORD              [change passwords]
  405.  
  406.             PASS  NEWWORD                        [add password if none]
  407.                  or
  408.             PASS  , NEWWORD                      [add password if none]
  409.  
  410.          Please note that the use of  "PASS , NEWWORD"  to update an
  411.          entry causes the Robot to expect the current password to be
  412.          non-existent (nothing before the comma), and to be replaced by
  413.          the new password provided.  If there actually *IS* a password
  414.          on record, such a format will cause the update to be bounced
  415.          for an incorrect password.
  416.  
  417.                             <OPTIONAL KEYWORDS>
  418.  
  419.       ORIGIN, DISTRIBUTION, FEEDS, GATEWAYS and LANGUAGE are just an
  420.       organized set of text fields which you can use to describe sources
  421.       and contacts that control links to the conference.  Use any of
  422.       them which you need.  If you are on a formal distribution backbone
  423.       of some kind, don't just say BACKBONE - there are lots of them.
  424.       Specifically say "Zone 1 Backbone" or "Zone-3 Backbone" or
  425.       "EchoNet Backbone"...
  426.  
  427.       RESTRICTIONS is a shorthand reference to rules applied by the
  428.       Moderator concerning admission to the conference.
  429.  
  430.          /ACC - access is limited to Read-Only status.
  431.          /MEM - you must be validated as a member of some organization.
  432.          /MOD - you may not link in without specific approval of the Moderator.
  433.          /REA - only real names are permitted - no aliases.
  434.          /RUL - a rules file is included in ELRULnnn.ZIP.
  435.          /SYS - only Sysops are allowed to participate.
  436.  
  437.          The letters following the '/'  must be in upper case.  If more
  438.          than one is needed these should be separated by a space.  A
  439.          free form Restrictions line is permitted, but ONLY if the line
  440.          does not contain the preceding '/' character.  Acceptable
  441.          formats include:
  442.  
  443.               REST /SYS
  444.               REST /MOD /SYS
  445.               REST Startrek Fans only
  446.  
  447.       TOTALNODES is for providing an estimate of the number of systems
  448.       participating in your conference.  It must be a single integer
  449.       number such as 6, 21, 190, etc..
  450.  
  451.       VOLUME is for providing an estimate of the volume of messages to
  452.       be expected by those who link-in.  It must be a single integer
  453.       number followed by a slash followed by either MONTH, WEEK or DAY
  454.       to identify the time period in which that number of messages flow.
  455.  
  456.       RULEFILE allows you to specify the name of the rules file, or
  457.       other information file or FAQ about the echo, which you submitted
  458.       for inclusion in the ELRUL archive.  If you send the rule file as
  459.       an attach, you can name it as you wish.  If the rules were
  460.       provided in message form, the Echolist software will extract them
  461.       to a file and automatically name the file with the first 8
  462.       characters of the echo tag, in which case the response message
  463.       will remind you to change your next update to show the automated
  464.       rule file name.
  465.  
  466.       Please note, this keyword is only used to display the NAME of the
  467.       rules/FAQ file in the Elist entry - to submit the rules/FAQ FILE
  468.       itself, you must use a separate message following the format
  469.       detailed in "SENDING A RULES FILE" below. All rules/FAQ files have
  470.       the extension of *.RUL. After the keyword "RULE" you should ONLY
  471.       put the rulefile name on this line - no other text:
  472.  
  473.          Correct:
  474.  
  475.             RULE  WHATEVER.RUL
  476.             RULEfile  WHATEVER.RUL
  477.  
  478.          Wrong:
  479.  
  480.             RULE WHATEVER.RUL is the file.       [extra words]
  481.  
  482.       OPTION allows you to specify the way in which your update message
  483.       should be handled by the Echolist software.  At present the only
  484.       option is HOLD which causes the acknowledgement message to be held
  485.       for you to pickup, instead of being sent to you via routed
  486.       netmail.  Allow 12 hours before polling for pickup.  The HOLD
  487.       option is ignored for Internet email responses.
  488.  
  489. DELETING AN ECHO
  490. ================
  491.  
  492.    There is at present no automated routine for deleting an echo from
  493.    the Elist.
  494.  
  495.    To have a complete entry deleted, please send netmail addressed to
  496.    Adrian Walker at 1:153/752, giving the echo tag, your password, and
  497.    requesting that the entry be deleted from the Elist database.
  498.  
  499.    On receipt, the entire entry and its password will be removed from
  500.    the Elist.  This also removes all protection for the echo tag, thus
  501.    allowing others to make use of it.
  502.  
  503. SENDING A RULES FILE
  504. ====================
  505.  
  506.    To submit an echo rules/FAQ file to the Echolist for inclusion in
  507.    ELRUL###.ZIP, the monthly collection of current echo rules/FAQs,
  508.    submit either:
  509.  
  510.          1.  NetMail message to "ECHOLIST" at 1:153/752, or
  511.          2.  Internet email message to awalker@portal.ca.
  512.  
  513.    In order to submit a Rules/FAQ File the EchoList entry must already
  514.    have been added to the Elist with a MOD UPD message.  Rules File
  515.    messages can not be used for adding or updating Elist entries.
  516.  
  517.    Depending on whether it is done by netmail or Internet email, the
  518.    rules/FAQs may be submitted using either of the following methods.
  519.  
  520.    1.  As a file attach message (only applicable to Fidonet direct Netmail):
  521.  
  522.          To:       ECHOLIST
  523.          At:       1:153/752
  524.          Subject:  <attached rules/FAQ file name (xxxxxxxx.RUL)>
  525.  
  526.          NOTE:  The file being attached must be a plain language text
  527.          file in ASCII format.  Use of extended ASCII is permitted.  The
  528.          file must NOT be a compressed file, since this poses problems
  529.          on some systems when the ELRUL archive is decompressed.
  530.  
  531.          In the body of the message:
  532.  
  533.          TAGname       <symbolic area name>
  534.          PASSword      <current password>
  535.          ---
  536.  
  537.    2.  Included in the text of the message (Netmail or Internet email):
  538.  
  539.              [Netmail]                           [Internet email]
  540.          To:       ECHOLIST                   To:       awalker@portal.ca
  541.          At:       1:153/752                    At:       [n/a]
  542.          Subject:  MOD RUL                    Subject:  MOD RUL
  543.  
  544.          In the body of the message:
  545.  
  546.          TAGname       <symbolic area name>
  547.          PASSword      <current password>
  548.          RULEtext      <Full Title of rule/FAQ file - one line only>
  549.          [insert freeform rules file into message here]
  550.          ---
  551.  
  552.          The format for the password is the same as shown in the Update
  553.          message format, above.
  554.  
  555.    Note that in both cases the 3-character string "RUL" appears as part
  556.    of the subject line, and this is the cue for the Elist software to
  557.    process the message as a Rules/FAQ submission.  All rules/FAQ
  558.    messages must end with a 3-dash tear line.
  559.  
  560.        *************************************************************
  561.        ALL RULE/FAQ FILES EXPIRE AND ARE DELETED WHEN SIX MONTHS OLD
  562.        *************************************************************
  563.  
  564.    As with database echo description entries, to ensure currency,
  565.    rule/FAQ files are removed from the archive when more than 6 months
  566.    old, and Moderators wishing their rules/FAQs to appear in ELRULnnn.ZIP
  567.    should resubmit their echo's rules/FAQs at least once every 6 months.
  568.    They are not retained in the database after this time.
  569.  
  570.    All rules/FAQ files are stamped with the date of arrival at 1:153/752,
  571.    regardless of the original file date, so as long as a Moderator
  572.    submits a rule/FAQ file every 6 months, it is not essential that the
  573.    file have a recent file date.
  574.  
  575. SENDING A QUERY REQUEST
  576. =======================
  577.  
  578.    To obtain a list of echoes and the date of their last update, file
  579.    request ELTAG from 1:153/752 or 1:153/751, and the current ELTAGnnn.TXT
  580.    will be sent (approx 110 kb).  This file is updated every time an
  581.    update arrives so it will contain up-to-the-minute information.
  582.  
  583.    To query the EchoList database, you can do one of two things.
  584.  
  585.          1.  Do an online query by file-request, or
  586.          2.  Send a netmail query.
  587.  
  588.    1.  For the first option, send a file request to 1:153/752 with the
  589.    following filename:
  590.  
  591.          ELQUERY TAGNAME
  592.  
  593.    In the above example, TAGNAME is the tag you wish.  The two words
  594.    must be on the same line in the file request, separated by a space.
  595.    This is similar to requesting a file with a password, only if you
  596.    entered it as a password, the request attach would look like:
  597.  
  598.          ELQUERY !TAGNAME
  599.  
  600.          (The '!' would have to be pulled out in such a case.)
  601.  
  602.    While you are online, the Elist Robot will search the database,
  603.    including the Zone 2 Elist, and will pull out the current entry for
  604.    that echo.  It takes about 30 seconds for the response, called
  605.    ELENTRY.TXT, to be sent to you.
  606.  
  607.    It is important to send the request to 153/752, since that system has
  608.    a 486/66 computer and can extract the data from the Elist database
  609.    before some mailers time out.  The other system is only a 286/12.
  610.  
  611.    2.  For the second option, submit a NetMail message to "ECHOLIST" at
  612.    1:153/752.  The message subject must be "ECHO QUERY" (no abbreviation).
  613.    The body of the message text has the arguments for the request.
  614.  
  615.    Only a single Query parameter is currently available with the new
  616.    Elist software, and only a single echo may be queried in a given
  617.    query message:
  618.  
  619.    /MODUPD       <Echo area name>
  620.  
  621.    This produces an updated copy of the echo's complete Elist entry
  622.    formatted as it appears in the monthly ELIST###.TXT file.  Thus the
  623.    message will look like the following:
  624.  
  625.    To:          ECHOLIST
  626.    At:          1:153/752
  627.    Subject:     ECHO QUERY
  628.  
  629.    /MODUPD SOMEECHO
  630.    ---
  631.  
  632.    It should be noted that some options for message forwarding, and
  633.    string searches other than a complete tag name are not implemented at
  634.    present.
  635.  
  636. OBTAINING INDIVIDUAL RULES
  637. ==========================
  638.  
  639.    To obtain a list of the most current rules files on record, file
  640.    request the magic name RULES from 1:153/752.  From that list you can
  641.    then file request specific rules which may be more current than those
  642.    in the last ELRULnnn.ZIP distribution file.
  643.  
  644. AUTOMATING THE UPDATES
  645. ======================
  646.  
  647.    You can automate the process of sending update messages with a batch
  648.    file like the following.  The programs I use (and there are many
  649.    others) are DOM100.ZIP (Day of the Month), and MESSGN19.ZIP (Message
  650.    Generator) and/or MKMSG21.ZIP (Makemsg).  This extract is from my
  651.    Mailer's batch file:
  652.  
  653.    :MIDNIGHT
  654.            call c:\batch\midnight.bat
  655.            dom                         {see it it is the first of the month}
  656.            if errorlevel 2 goto M2
  657.            if errorlevel 1 goto M1
  658.    :M2
  659.            goto start
  660.    :M1
  661.            c:
  662.            cd\bink\mailchek            {post policies into the echo}
  663.            copy z1_back.hdr messgn.ctl
  664.            messgn c:\max\policies\z1_back.pcy c:\msgs\z1back 153 752 All
  665.  
  666.                                        {post Elist entry into netmail}
  667.                                        {this is all one line}
  668.            makemsg -Cc:\elist\echo.upd -Dc:\msgs\netmail\ -S1:153/752
  669.               -F"Adrian Walker" -R1:153/752 -T"Echolist" -J"MOD UPD" -P
  670.               -O"Your Origin Line, Vancouver BC "
  671.  
  672.                                        {post Elist rules into netmail}
  673.                                        {again all one line}
  674.            makemsg -Cc:\elist\echo.rul -Dc:\msgs\netmail\ -S1:153/752
  675.            -F"Adrian Walker" -R1:153/752 -T"Echolist" -J"MOD RUL" -P
  676.            -O"Your Origin Line, Vancouver BC "
  677.  
  678.            goto start
  679.  
  680. HOW ECHOLIST PROCESSES MESSAGES
  681. ===============================
  682.  
  683.    Echolist is a group of programs each performing part of the function
  684.    of processing update messages and updating the database.  This group
  685.    of programs runs after every inbound mail packet is processed.  The
  686.    editing of help files, preparation of the distribution archives, and
  687.    hatching of these archives each month is performed manually.
  688.  
  689.    After mail tossing is complete, the following series of actions takes
  690.    place:
  691.  
  692.    1.  ECHOLIST.EXE runs.  This is the main Elist program, and does 3
  693.        things - it manages the password file, extracts data from
  694.        messages to a temporary update file, and it prepares netmail
  695.        responses based on the information received.  It also processes
  696.        ECHO QUERY messages based on information as it showed in the
  697.        database immediately prior to the program running.
  698.  
  699.    2.  ESORT.EXE runs.  It sorts the extracted data in the newly-created
  700.        update file in preparation for merging into the main database.
  701.  
  702.    2.  EMERGE.EXE runs.  It runs through the database looking in turn
  703.        for each echo noted in the update file.  When it finds the
  704.        matching database entry, it merges the 2 files segments.  This is
  705.        done by replacing any field which has been updated and retaining
  706.        any field which has not been updated.  Thus a new one line
  707.        description field will replace an entire previously multi-line
  708.        description field, a new title line will replace a previous title
  709.        line, and so on.
  710.  
  711. CONCLUSION
  712. ==========
  713.  
  714.    Frequently-asked questions are discussed in ELFAQnnn.TXT contained in
  715.    the distribution Elist archive.
  716.  
  717.    If you have a problem, you should consult the ELFAQ file, this ELMOD
  718.    file, and finally your NEC and REC for assistance.
  719.  
  720.                               ---ooo000ooo---
  721.