     Volume 6, Number  8                              20 February 1989
     +---------------------------------------------------------------+
     |                                                  _            |
     |                                                 /  \          |
     |                                                /|oo \         |
     |        - FidoNews -                           (_|  /_)        |
     |                                                _`@/_ \    _   |
     |        International                          |     | \   \\  |
     |     FidoNet Association                       | (*) |  \   )) |
     |         Newsletter               ______       |__U__| /  \//  |
     |                                 / FIDO \       _//|| _\   /   |
     |                                (________)     (_/(_|(____/    |
     |                                                     (jm)      |
     +---------------------------------------------------------------+
     Editor in Chief                                       Dale Lovell
     Editor Emeritus:                                   Thom Henderson
     Chief Procrastinator Emeritus:                       Tom Jennings
     Contributing Editors:                                   Al Arango
     
     FidoNews  is  published  weekly  by  the  International   FidoNet
     Association  as  its  official newsletter.  You are encouraged to
     submit articles for publication in FidoNews.  Article  submission
     standards  are contained in the file ARTSPEC.DOC,  available from
     node 1:1/1.  1:1/1 is available  for network  mail between  NMH-1
     hour to NMH+1 hour.  At all other times,  netmail is not accepted
     although submissions can be uploaded.
     
     Copyright 1989 by  the  International  FidoNet  Association.  All
     rights  reserved.  Duplication  and/or distribution permitted for
     noncommercial purposes only.  For  use  in  other  circumstances,
     please contact IFNA at (314) 576-4067. IFNA may also be contacted
     at PO Box 41143, St. Louis, MO 63141.
     
     Fido  and FidoNet  are registered  trademarks of  Tom Jennings of
     Fido Software,  164 Shipley Avenue,  San Francisco, CA  94107 and
     are used with permission.
     
     The  contents  of  the  articles  contained  here  are  not   our
     responsibility,   nor   do   we   necessarily  agree  with  them.
     Everything here is  subject  to  debate.  We  publish  EVERYTHING
     received.


                        Table of Contents
     1. ARTICLES  .................................................  1
        Adding GroupMail to a BinkleyTerm/ConfMail System  ........  1
        SEA Letter: XlatList  ..................................... 14
        New Echo for WATSON Users  ................................ 17
     2. COLUMNS  .................................................. 18
        The Old Frog's Almanac - Part the Three (and last)  ....... 18
     3. LATEST VERSIONS  .......................................... 21
        Latest Software Versions  ................................. 22
     4. NOTICES  .................................................. 23
        The Interrupt Stack  ...................................... 23
     5. REPORTS  .................................................. 24
     And more!
     FidoNews 6-08                Page 1                   20 Feb 1989


     =================================================================
                                 ARTICLES
     =================================================================

     Jack Decker
     Fidonet 1:154/8  LCRnet 77:1011/8  NetWork 8:70/8


     ADDING GROUPMAIL TO A BINKLEYTERM/CONFMAIL SYSTEM

     [This article is NOT copyrighted and may be freely distributed.
     Use of the information contained herein is at your own risk,
     and just might cause your hard drive to be reformatted, your
     modem to transfer the contents of your bank account to the
     Gnomes of Zurich (whoever they are), or your dog to meet up
     with a family of skunks underneath your computer room window,
     or even worse.  What you see here is the result of a few days
     of intense hacking (I'm using the original meaning of that
     noble word), which may or may not have led me to accurate and
     insightful conclusions.  Don't say I didn't warn you...]

     Lots of misinformation has been going around in regard to
     GroupMail, and the considerations involved in making GroupMail
     coexist on the same system with BinkleyTerm and ConfMail.  I
     suspect that much of this has nothing to do with GroupMail per
     se, but rather with emotions and personal feelings about the
     developers of GroupMail.  I won't even attempt to speak to
     those, but I can at least give you some solid information on
     how to implement GroupMail on a system that is already
     successfully running BinkleyTerm and confmail.

     This information is going to be presented more or less in
     "cookbook" format.  I am going to make a few assumptions to
     start with... that you are not a "top star" for any conference,
     that you're not going to feed GroupMail conferences to any
     non-MSDOS systems that can't run the GroupMail software, and
     that you're not going to try and convert any GroupMail
     conference to Echomail or vise-versa.  If any of these
     assumptions don't apply to you, read on anyway, I'll cover one
     of the exceptions later, and the rest of the information will
     still be useful to you.

     This is NOT a substitute for the GroupMail documentation.  Read
     it, too!  Also, please count on this information containing at
     least one glaring error and at least a couple of things that
     could have been done more easily in some other way.  I don't
     claim to be perfect.  But I would like to know of any errors
     that you do find.

     Here are the changes you will need to make to your system:

     1) CONFIG.SYS - Group requires some new environment variables
     to be set.  If you haven't already done so, you can reserve
     extra space for environment variables by inserting the
     following line into your CONFIG.SYS file:

     FidoNews 6-08                Page 2                   20 Feb 1989


          shell=command.com /p /e:512

     2) AUTOEXEC.BAT - Here is where you add some lines to set the
     new environment variables that will be used by GroupMail:

          SET GROUP=C:\GROUP
          SET GRPHOLD=C:\GRPHOLD
          SET SEADOG=C:\OPUS

     If you want your GroupMail message areas on a different drive,
     change the drivespec for the GROUP variable.  If you are going
     to hold GroupMail bundles for pickup by other nodes, and want
     those on a different drive, change the drivespec for the
     GRPHOLD variable.  The SEADOG variable should point to the
     directory that you normally run BinkleyTerm from.

     3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc.
     Here are the changes you need to make:

     a) If you test for the existence of mail bundles in your net
     files area before running ConfMail Import, either delete these
     tests (you don't really need them anyway) or add tests for the
     GroupMail bundles you expect to receive.  GroupMail bundles are
     named with the area name (up to eight characters) plus an
     unpredictable three-character extension.  So, for example, if
     you are expecting to receive GroupMail bundles for the COOKING
     area, you could test for files named COOKING.* (or COOKING.???)
     in your net files area.  I again emphasize that such tests are
     normally not necessary, but some people like to use them to
     shave a few seconds off of batch file processing time.

     b) your line that calls ConfMail Import should *NOT* include
     the -M option, but *SHOULD* include the -K option.  I use the
     following line:

          confmail import areas.bbs -K -N -F confmail.out

     Now a bit of explanation... if you really want to use the -M
     option, you can probably do so as long as you are not
     converting any GroupMail bundles to echomail prior to passing
     them downstream.  I suggest removing the -M option now (if you
     have been using it) because sooner or later you may wish to
     convert a GroupMail conference to echomail, and it won't work
     if -M is set.

     The -K option will automatically kill all the null file attach
     messages that your GroupMail feed generates.  If you don't mind
     skipping through all the null file attach messages when you
     read your netmail (you WILL mind eventually), leave out the -K.

     c) You should place the following line immediately AFTER your
     call to ConfMail Import, BEFORE you do anything else:

          GROUP IN /L

     This does two things... first, it unpacks any GroupMail bundles
     FidoNews 6-08                Page 3                   20 Feb 1989


     you may have received, and second, it scans your netmail area
     for any GroupMail messages that need to be readdressed to your
     uplink.  That is why it needs to be run AFTER ConfMail
     Import... if you run it BEFORE ConfMail Import, any messages
     you've received from your downstream nodes may not get properly
     forwarded to the Top Star via your GroupMail feeds.  And you
     need to run Group In BEFORE running ReMapper, oMMM, or any
     other program that may change the headers of those messages.
     So play it safe, and run Group In right AFTER ConfMail Import.

     By the way, the /L tells GROUP to relink the message threads.
     It does basically the same thing for GroupMail conferences that
     ReplyLnk (or ConfMail Maint in older versions of ConfMail) does
     for your echomail conferences.

     d) Just prior to calling oMMM, you should place the following
     line:

          GROUP OUT

     This will check all your GroupMail areas for new messages, and
     send out anything you have waiting.

     Now, if you have read the GroupMail documentation, you may be a
     little confused at this point, since the docs tell you to run
     GROUP on certain schedules (GROUP OUT in the evening before
     your mail hours, and GROUP IN in the morning after all mail has
     been received).  But keep in mind that the folks writing the
     documentation are using SEADOG, which runs on schedules.  You
     probably aren't running schedules in that way.  If by chance
     you do run ConfMail Import only at certain specified times,
     just do GROUP IN immediately afterward.  But, if like most of
     us, you run ConfMail Import every time mail is received, you
     should run GROUP IN immediately afterward.  If you then do a
     ConfMail Export, you should run GROUP OUT prior to calling
     oMMM.  GROUP runs very fast (faster than ConfMail when tossing
     messages, in my opinion) so you needn't worry about it
     consuming an inordinate amount of time while executing on your
     system.

     4) AREAS.BBS - There are two important considerations here.
     First, if you are using a BAD_MSGS area, GET RID OF IT NOW!!!!
     This is *EXTREMELY* important.  If you don't do this, some or
     all of the GroupMail messages originating on your system (or on
     systems that you feed) will be tossed to the BAD_MSGS area by
     ConfMail, and will never leave your system.  Second, make sure
     you don't have any echo area names that duplicate GroupMail
     areas, for the same reason (ConfMail will toss any messages
     that are supposed to go to your uplinks to those areas instead.
     The exception to this is if you're converting a GroupMail
     conference to Echomail, but right now we're assuming you aren't
     doing that, remember?).

     Of course, someone will say that if you are VERY careful about
     how you write your batch file, you can get around these
     problems.  That may be true (although I have my doubts!), but
     FidoNews 6-08                Page 4                   20 Feb 1989


     in any event I don't feel like giving a short course in writing
     batch files here.  I'm simply taking the safe road by saying
     "don't do these things."

     5) CONFIG.DOG - You need one of these, even though the
     GroupMail documentation says that a Mail.Sys file will do (it
     won't, at least not with GroupMail versions through 2.04).
     Fortunately, a Config.Dog file is simple to make... you just
     use any text editor.  Mine looks like this:

          name Jack Decker
          node 1:154/8
          aka 77:1011/8
          aka 8:70/8
          mail C:\MSG\NET
          files C:\FILE\NET

     "Name" is the name of the Sysop, "Node" is your primary
     address, "Aka" lines contain any other addresses you use (in
     the same net or in other nets), "Mail" is the path to your
     netmail area, and "Files" is the path to your incoming net
     files area (which is what GROUP can't find if you only have a
     Mail.Sys file).

     6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your
     system).  Be sure to put a poll statement in for each system
     you pick up GroupMail from (unless you are using some other
     method for doing polls, or your feed is calling you).

     7) DELIVER.GRP - You need this file if you are feeding
     GroupMail to any other BinkleyTerm systems, or any other system
     that can't generate File Update Requests.  Note that future
     versions of BinkleyTerm will supposedly include the capability
     to do File Update Requests, but present versions of Binkley do
     not.  DELIVER.GRP is simply a list of systems that are to
     receive any given GroupMail area from you.  I quote from SEA
     Technical Memorandum #0302:

     "The group mail conferencing system is, by design, a pickup
     system instead of a delivery system.  If at all possible, it
     should be used as such, because that is how group mail avoids
     the bulk of the technical problems with echomail.

     "However, at least one popular network mailer is not capable of
     properly negotiating a file update request, which is the
     mechanism by which group mail functions.  Until that can be
     rectified, GROUP requires some sort of delivery mechanism in
     order to link such systems into group mail.

     "If a file named 'DELIVER.GRP' is placed in the SEAdog
     directory, then GROUP 2.03 will use it as a delivery list, and
     create file attach messages for each new group mail archive as
     it is posted by GROUP PACK (for a top star) or GROUP IN (by a
     middle star).  The format of the DELIVER.GRP file will look
     very familiar to those acquainted with echomail.

     FidoNews 6-08                Page 5                   20 Feb 1989


     "The DELIVER.GRP file is a normal ASCII text file.  Each line
     begins with the name of a group conference, with the remainder
     of the line being a list of network addresses to which it
     should be delivered.  A conference may be listed more than
     once, in which case it is addative.

     "For example, a possible DELIVER.GRP file might be:

         BLATZ 520/1015 107/528
         GNORF 107/528


     "By adding support of a delivery mechanism, we open the door to
     all the troubles echomail is heir to.  However, the door is
     open only a tiny crack at this time.  The single biggest
     problem with a delivery system is that of faulty topologies
     that cause duplicate messages.  This is largely avoided from
     the start because all duplicate group mail archives have the
     same name.  The remaining opportunities for duplicate messages
     to be generated are avoided because GROUP 2.03 refrains from
     unpacking any group mail archive that is older than the 'update
     marker' for that conference."

     [end quote]

     Two notes about DELIVER.GRP... first, you DON'T put the node
     number of YOUR feed in it, only of those systems that are fed
     BY YOU (this differs from an AREAS.BBS file, which must contain
     the node number of your feed and of those system that you
     feed).  Second, if you aren't feeding a particular GroupMail
     conference to anyone else, it doesn't have to be listed at all.

     8) OKFILE.LST - Your "requestable files" list for BinkleyTerm.
     Add the following line:

          C:\GRPHOLD\*.*

     (or whatever path you specified for your GRPHOLD directory in
     the SET command in AUTOEXEC.BAT).  I'm assuming that you
     already have such a list.  If not, you'll also need to
     uncomment the following line in your Binkley.Cfg file:

          Okfile     c:\opus\okfile.lst

     (of course you should change the path if the subdirectory
     you're running Binkley out of is not called OPUS).

     This should allow other systems to obtain any GroupMail areas
     that you carry on your system.

     9) \GROUP\ORIGIN - A file called "Origin" that sits in your
     GROUP directory.  For starters, this can be the same as the
     first line of your "AREAS.BBS" file up to the exclamation
     point.  You can use custom origin lines for individual
     conferences by creating a file called "Origin" in individual
     Group areas, in the same manner in which you create custom
     FidoNews 6-08                Page 6                   20 Feb 1989


     origin lines for individual message areas using ConfMail.  See
     the GroupMail documentation for more information.

     10) System files.  You'll need to provide your BBS program
     and/or message reader/editor with the paths to your GROUP mail
     areas.  Ditto with your message cleanup routine (that calls
     RENUM or some other message renumberer).  This will vary from
     system to system, but should not be too difficult to figure
     out.

     11) ARCE.COM - This one threw me at first, and is the one
     drawback I found in GroupMail.  GroupMail wants to use either
     ARC.EXE or ARCE.COM when unpacking mail, and any other filename
     just won't do.  I've been running PAK10 (and/or another popular
     program which shall remain nameless) to extract mail archives
     and had to scrounge through my piles of floppies to find a copy
     of ARCE.COM.  If you are a Top Star for any conference, you'll
     also have to have either ARC.EXE or ARCA.COM.  I wish these
     filenames weren't hardcoded in the GroupMail program, because I
     use PAK10 to move echomail around (with the help of a program I
     wrote called PAKIT101.ARC, which lets "consenting Sysops" use
     any of the "big three" methods of file compression for their
     mail archives), and could at least use PAK.EXE to extract
     GroupMail bundles.  I guess it just bugs me that GroupMail
     won't let you use anything other than the most inefficient
     method of file compression around.  If anything hinders the
     acceptance of GroupMail, this will be it, because some folks
     will see this as an effort of SEA to force people to use ARC.
     (Sorry, Thom, I like GroupMail but I don't care much for ARC,
     or I should say, ARC's "crunching" method of compression, which
     is rather inefficient by today's standards.  What can I say?).

     12) GROUP.EXE - The central program of GroupMail, and the one
     that does most of the work for you.  If you've set up echomail
     conferences in the past, you'll appreciate the ease with which
     GROUP takes care of many of the little details of adding or
     deleting conferences for you.  For example, it creates all
     necessary subdirectories for you, creates and maintains the
     AREAS.DOG file for you, etc.

     Now, if you are not a Top Star, you can basically get by using
     only three basic GroupMail commands (quoted from the GroupMail
     documentation):

     GROUP ADD <conference> <description> ;<uplink>

          This is the command you use to add a new conference.
          Suppose, for example, that you would like to get the BLATZ
          conference from 520/542.  You would type:

              GROUP ADD BLATZ Gzorniblatz forum ;520/542

          GROUP will take care of the details, like creating the
          proper directories and updating your AREAS.DOG file.  If
          you run a BBS and you want the conference to be available
          on your system you will need to add the directory to your
     FidoNews 6-08                Page 7                   20 Feb 1989


          message areas.  The message directory that GROUP creates
          will (by default, see later) be a subdirectory of the
          GROUP subdirectory, or in this case it would be
          "GROUP\BLATZ".

          If you are running a mailer other than SEAdog, then you
          may need to add the directory to your areas list also.  In
          any event, DO NOT delete the AREAS.DOG file, as that is
          used by GROUP to keep track of your conferences.

          If you want to import group mail into a BBS that uses a
          different message base format, you'll need to do a bit
          more work.  See the section on this below.

     [You might imply from the above that you should add GroupMail
     areas to your AREAS.BBS file.  That is NOT the case, however,
     unless you are converting a GroupMail conference to echomail,
     which we're assuming that you're not doing right now!]


     GROUP DEL <conference> . . .

          This is used to remove one or more conferences.  For
          example, if you wanted to remove the BLATZ conference you
          would type:

              GROUP DEL BLATZ

          If you wanted to remove both the BLATZ conference and the
          GNORF conference, you would type:

              GROUP DEL BLATZ GNORF

          Again, GROUP will take care of the housekeeping details,
          such as deleting any messages and removing the
          subdirectory.



     GROUP EDIT <conference> <description> ;<uplink>

          This is used to change an existing conference.  For
          example, if you wanted to change your uplink on the BLATZ
          conference to 440/1, you would type:

              GROUP EDIT BLATZ Gzorniblatz forum ;440/1

          As always, GROUP takes care of any housekeeping details.


     [end of quoted material]

     Since Binkley can't do File Update Requests, you do NOT use the
     GROUP ASK command.  We've already covered the use of GROUP IN
     and GROUP OUT in the batch file.  You don't use GROUP PACK
     unless you're a top star for a conference.  I don't know why
     FidoNews 6-08                Page 8                   20 Feb 1989


     you'd want to use GROUP KILL, but I've not yet found a reason
     to do so (it looks like a somewhat dangerous command!)

     There are several option switches that you can use to modify
     how GROUP works, and most are described in the GROUP
     documentation.  The one that you will probably want to use is
     the /R switch:

     /R<x>  Retention;  This tells GROUP that any group mail
          archives that you are holding (if you are a star) should
          be deleted after <x> days (default is 30 days).  For
          example, you would use "/R5" to retain archives for five
          days.

     For example, if you wanted to add the BLATZ conference with
     yourself as a middle star retaining group mail archives for
     three days, you would type:

         GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3

     Also, because Binkley cannot generate File Update Requests,
     you'll want to use the /X switch when adding new conferences,
     as described in SEA Technical Memorandum #0302:


     /X   In ADD or EDIT only.  This switch indicates that the
          designated conference should not be requested.  The GROUP
          ASK command will not generate an update request for any
          conference that carries this switch.  This is intended
          mainly for use with conferences which are delivered or
          which are obtained via a GROUP GET (see above).

     The bottom line is that when you add a new GroupMail
     conference, your GROUP ADD line will most likely appear
     something like this:

         GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7

     (assuming you want to retain conference archives for seven days
     in this case).

     If you are a leaf node (that is, you don't hold a particular
     conference for anyone else to pick up), omit the asterisk and
     the /r7 in the above line.  In this case, the GroupMail bundle
     will be deleted after it has been tossed.  The command line
     would then look like this:

         GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X

     When you use the GROUP EDIT command, it should be in exactly
     the same format as the GROUP ADD command.  In other words, if
     you are adding switches, you must also re-enter all of the
     original switches.  The word EDIT simply tells Group that you
     are modifying the particulars of an existing conference, rather
     than creating a new one.

     FidoNews 6-08                Page 9                   20 Feb 1989


     EXCEPTIONS AND SPECIAL CIRCUMSTANCES

     The GroupMail manual tells you how to import GroupMail into
     non-compatible message base formats (such as QuickBBS or TBBS).
     In this case you use the /N flag in your GROUP ADD statement.
     Since most such systems don't use ConfMail, this type of setup
     is a bit beyond our discussion.  I would only caution you to be
     careful about the sequence in which you run you mail import
     routine and GROUP IN.  You may have to run your import routine
     twice... once to toss incoming mail, then GROUP IN to toss
     incoming GroupMail bundles to the netmail area (and to
     readdress any GroupMail messages destined for your uplinks),
     and once more to import any GroupMail messages tossed to your
     netmail area by GROUP.  This is just guessing on my part, since
     I don't have any actual experience with such systems.

     However, a similar technique is used to convert GroupMail to
     Echomail.  You might want to do this if you are receiving a
     GroupMail conference and want to pass it on to another system
     that cannot run the GroupMail software.

     Now, I would suggest that you DON'T do this unless absolutely
     necessary.  If it's just a case of one of the nodes you feed
     objecting to having to put up the GroupMail software (although
     they are perfectly capable of doing so), I would invite them to
     seek a feed elsewhere.  Converting a conference from GroupMail
     to Echomail introduces several possible headaches, not the
     least of which is that you could be the source of duplicate
     messages entering the conference.

     On the other hand, it's not something that's terribly difficult
     to do if you have to.  SEA Technical Memorandum #0303 describes
     the process, but in my opinion makes the process unnecessarily
     complicated.  So, I will give a couple of examples specifically
     for BinkleyTerm/ConfMail users.

     The assumption here is that you are a middle star that is
     receiving the conference in question as GroupMail, and feeding
     it to some other nodes as GroupMail while feeding still other
     nodes as Echomail.

     Your GROUP ADD line would be the same as usual, with the
     addition of the /N switch... for example:

         GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7

     If you are not sending the conference to any other nodes AS
     GROUPMAIL, you can omit the asterisk and the "/r7" switch.

     Next, you ADD this area to your AREAS.BBS file, just like you
     would any normal echo.  On your system, you will treat this
     conference as an echomail area rather than a GroupMail area.
     The /N option that you used in your GROUP ADD statement causes
     GROUP to add an "AREA:" field and a "SEEN-BY:" field listing
     the address of the uplink to any conference that you're
     converting to echomail.
     FidoNews 6-08                Page 10                  20 Feb 1989


     In your batch file, you will probably want to run ConfMail
     Import (WITH the -M option), THEN Group In, and THEN a second
     run of ConfMail Import (WITHOUT the -M option).  This will make
     sure that any GroupMail received from your downstream nodes
     gets properly readdressed to your uplinks, and that any Group
     conferences that GroupMail tosses to your netmail area get
     properly tossed (by ConfMail) to the Echomail area you've set
     up for that conference.  For example:

          confmail import areas.bbs -M -N -F confmail.out
          group in /L
          confmail import areas.bbs -K -N -F confmail.out

     The only other items you have to worry about are how the area
     is defined in your DELIVER.GRP and AREAS.BBS files.  As usual,
     your DELIVER.GRP file should contain ONLY a list of nodes
     receiving the conference from you AS GROUPMAIL.  Your AREAS.BBS
     entry for the conference in question should contain a list of
     the nodes receiving the conference from you AS ECHOMAIL, plus
     YOUR FEED of the conference.  The reason for including your
     feed is so that any messages entered on your system, or sent to
     you by your downstream links, will be exported to your upstream
     feed.

     You may wonder what will happen to an echomail message sent
     upstream in such a manner to your GroupMail feed.  If he is
     running that area strictly as GroupMail, the message will be
     tossed into his netmail area (so long as he does not have a
     BAD_MSGS area... this is why you CANNOT use a BAD_MSGS area
     with GroupMail!!!), where (hopefully) GROUP IN will find it and
     readdress it to his uplink, and so on.  If he is also operating
     the area as both echomail and GroupMail, the message will get
     tossed into the echo area on his system, and then exported to
     his upstream feed, and so on.

     Anyway, that's all there is to it... BUT again I ask, "do you
     REALLY want to convert echomail to GroupMail?"  If you are only
     feeding one or two nodes that cannot accept GroupMail, there
     may be a better way:

     SENDING GROUPMAIL TO NON-MSDOS SYSTEMS

     The following information should be considered HIGHLY
     experimental.  If it works for you, GREAT!  If it doesn't...
     well, you can always convert your GroupMail conferences to
     echomail.

     Let's say that you're feeding a point system that's running on
     a Commodore Amiga (coincidentally, this is what Steve Palm, a
     point operator off of my system is using).  He has a version of
     ConfMail and BinkleyTerm that's been ported to the Amiga, as
     well as a message reader/editor, but there is no way he can run
     the GroupMail software.

     But, he is a leaf node.  That means he doesn't have to worry
     about forwarding the conference to anyone else.  All he needs
     FidoNews 6-08                Page 11                  20 Feb 1989


     to be able to do is to read the messages he receives, and send
     replies.

     We already know (from the above discussion) that if he creates
     an echo area with the same name as a GroupMail area on my
     system, and puts my node in his AREAS.BBS list, that any
     messages he enters in that area will be exported to my system,
     where GROUP IN will find them and readdress them to my feed for
     the conference.  So as long as he can send me messages with the
     proper AREA tag (which will be automatically affixed when
     ConfMail exports the message from the echo area he's created),
     he will be able to enter messages in a GroupMail conference.
     So, if he can figure out some way to process an incoming
     GroupMail bundle (so that he can read incoming messages), I can
     just put his node in my DELIVER.GRP file and treat him like any
     other GroupMail delivery point (which means I don't HAVE to
     convert the GroupMail conference to Echomail!)

     The question is, can he unpack a GroupMail bundle?  Well, it
     turns out that there IS a way this can be done.  Once you unARC
     a GroupMail bundle, the extracted mail packet has roughly the
     same format as an Echomail packet, except that it's addressed
     to -1/0.  At least, it's close enough that ConfMail will unpack
     and toss it if it thinks it's running on node -1/0

     So, in his CONFIG.DOG file, Steve inserts the address -1/0 as
     an AKA address.  Then, in his batch file, he has to put a
     command to look for and unARC any GroupMail bundles he might
     receive.  For example, if he's getting COOKING and SHORTWAV
     from me, he'd put in the following lines (note these are MS-DOS
     batch file lines for illustrative purposes only, not what Steve
     is actually using on his Amiga):

          PKXARC \FILE\NET\COOKING.*
          DEL \FILE\NET\COOKING.*
          PKXARC \FILE\NET\SHORTWAV.*
          DEL \FILE\NET\SHORTWAV.*
          CONFMAIL IMPORT AREAS.BBS -N -A PKXARC

     ConfMail will find the bundles (addressed to -1/0, but the AKA
     takes care of that) and unpack them.  Next... and this is
     important... he must do a CONFMAIL EXPORT using an alternate
     AREAS.BBS format file that contains the following:

          Origin Line ! Sysop Name
          \MSG\COOKING COOKING -1/0
          \MSG\SHORTWAV SHORTWAV -1/0

     Why are we exporting to -1/0?  Well, since GroupMail uses that
     address, I thought I would, too... actually, we could export to
     ANY phony node, but the idea is to make ConfMail do an export
     operation on the newly-imported GroupMail messages.  Why?
     Well, keep in mind that GroupMail messages don't have an origin
     or SEEN-BY lines.  Thus, if we simply allow them to be
     rescanned in the normal manner, we've created an instant dupe
     loop, since they will all get sent back to the source.  So, we
     FidoNews 6-08                Page 12                  20 Feb 1989


     do a "dummy" export operation in order to reset the "high water
     mark" past the last new message that we have just received in
     the area.  This may create an unwanted ".OUT" file for -1/0,
     but we can always delete that as the next operation in the
     batch file

     So, the complete batch file segment would look something like
     this:

          PKXARC \FILE\NET\COOKING.*
          DEL \FILE\NET\COOKING.*
          PKXARC \FILE\NET\SHORTWAV.*
          DEL \FILE\NET\SHORTWAV.*
          CONFMAIL IMPORT AREAS.BBS -N -A PKXARC
          CONFMAIL EXPORT ALTAREAS.BBS {options}
          DEL \OUTBOUND\FFFF0000.OUT

     ...where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy
     -1/0 net/node numbers, and FFFF0000.OUT is the name of the mail
     packet (for -1/0) created by the dummy export operation.

     Of course, when messages are entered using the message
     reader/editor, we have to run ConfMail Export using the "real"
     AREAS.BBS file that contains the same entries, but with the
     real net/node numbers for the GroupMail feed(s) from which the
     conferences are received:

          Origin Line ! Sysop Name
          \MSG\COOKING COOKING 154/8
          \MSG\SHORTWAV SHORTWAV 154/8

     Now, all of the above will work BUT there is one MAJOR problem.
     It turns out that while each GroupMail bundle has a unique
     filename, two or more GroupMail bundles for the same conference
     can contain .PKT files that have exactly the SAME names.  Thus,
     there is a very good chance that the above batch file segment
     would fail whenever more than one mail bundle is received for
     the SAME GroupMail area in the same transmission (it would most
     likely stop and ask the user whether to overwrite the the .PKT
     file from the first mail bundle with the .PKT file from the
     second... or on some systems, it might just go ahead and
     overwrite the file without asking, an even less desirable
     situation!).  On an MSDOS machine, you could use a FOR-DO loop
     in the batch file to unarc each GroupMail bundle and then have
     ConfMail toss (import) the contents of that mail bundle before
     unarcing and tossing the next GroupMail bundle (but then, on an
     MSDOS machine you could just run the GroupMail software).
     There are probably ways to accomplish the same thing on other
     systems, but the actual method would depend on the commands
     available in the batch file language, and/or the availability
     of external utilities that might aid in the process.  Or, you
     could just run the batch file manually (when an operator is
     present to watch and resolve any such conflicts that might
     occur)... that might be the most expiditious method at present
     for point system operators.  Note to the developers of
     GroupMail:  It would sure be nice if future versions did not
     FidoNews 6-08                Page 13                  20 Feb 1989


     create duplicate .PKT names within different mail bundles for
     the same GroupMail conference.

     The method I've shown for preventing the imported GroupMail
     messages from being rescanned back to the GroupMail feed is not
     real elegant, and begs for a simple utility that would either
     a) reset the "high water mark" (the number of the last message
     scanned by ConfMail Export) to that of the highest message in
     the area, or b) append an Origin line and SEEN-BY lines to any
     messages that don't already have them in the specified area,
     and place the net/node number of the feed for the area in all
     messages currently in that area.  Such a utility could be run
     every time messages have been tossed to the specified area, and
     would eliminate the need for the dummy ConfMail Export
     operation.  Yet another (better) option would be to forget the
     alternate AREAS.BBS file and the dummy ConfMail Export option,
     but instead use only the regular AREAS.BBS file with NO
     net/node number following the Group conference area names, so
     that messages in Group areas would NEVER be exported by
     ConfMail.  Then use a separate utility that would search
     through Group conference areas for locally-originated messages
     (messages containing the node's primary net/node number in the
     FROM field of the message header) and move those TO the netmail
     area, at the same time readdressing them to the feed for the
     GroupMail conference and flagging them as Kill/Sent.  Such a
     utility would be relatively easy to create, and would allow
     non-MSDOS systems to handle GroupMail in a way that more
     closely resembles the way GroupMail is supposed to operate
     (that is, a locally-entered message disappears from your BBS
     until such time as it comes back as part of a GroupMail
     packet).

     But, at this point, the fact that a non-MSDOS system can import
     and process GroupMail is a bit akin to the dancing bear... the
     wonder is not how well it's done, but that it can be done at
     all.

     I hope that these hints prove helpful to you in setting up
     GroupMail on BinkleyTerm/ConfMail and other types of systems.
     Please let me know if you find any glaring errors in the above
     information, or if you can add anything that might simplify the
     process or make it more understandable.

     Jack Decker (Fidonet 1:154/8, LCRnet 77:1011/8, NetWork 8:70/8)

     -----------------------------------------------------------------
     FidoNews 6-08                Page 14                  20 Feb 1989


                          What's Happening at SEA?


     SEAdog 4.50 added many new capabilities and features, and some of
     them  required more data from the node list than we were getting.
     So we've upgraded XlatList to support those features.  Along  the
     way we added some other things people have asked for.

     First,  we expanded the OZONE statement.  You may be aware of the
     earlier form:

         ozone 1:107

     which would import the data for net 107 of zone 1 into your  node
     list.  That still works, of course, but now you can also say:

         ozone 1:all

     which  will  import  ALL  of  zone  1  into your node list.  This
     defeats the purpose of zones to some extent, but many people felt
     a need for it.


     Speaking of zones: When zones were first designed, there was only
     the one network, with no hint that other networks would ever form
     and want to  exchange  network  mail.  Hence,  the  zone  concept
     asumes one central authority to assign zone numbers, oversee zone
     gates,  and  so  on.  As  we all know,  that isn't quite the case
     today.

     To address the current world  of  multiple  independent  networks
     (pun  unintentional),  Jim Nutt came up with the idea of domains,
     domain addressing,  and domain gates.  We wholeheartedly  endorse
     Jim's  domain  concept,  and  we support it in SEAdog 4.50 and in
     XlatList.

     SEAdog 4.50 contains the mechanisms for turning a domain  address
     into the appropriate extended address via your local domain gate,
     but  you still have to get the domain address from somewhere.  Of
     course, you could just remember it and type it in as needed,  but
     we  wanted  to find an easier way.  We turned to XlatList for the
     answer.

     XlatList 2.90 implements a  new  command,  "DOMAIN".  This  works
     like  the  older  PUBLIST  command,   except  that  the  list  is
     designated as being part of a domain.  Here's how it works:

     Suppose you're node 520/1015 in AlterNet,  and you'd like  to  be
     able to send mail to people in FidoNet.  Net 107,  in particular,
     has several people in it you send mail to  regularly,  but  you'd
     like  to be able to reach the rest should the mood strike you.  A
     system near you (let's say 520/16,  for example) has  volunteered
     to be your domain gate into FidoNet.  In your CONFIG.DOG file you
     would put the statements:

         node 520/1015@AlterNet
     FidoNews 6-08                Page 15                  20 Feb 1989


         domain FidoNet 520/16

     That  tells SEAdog what to do.  Now in your XLATLIST.CTL file you
     put:

         node 520/1015@AlterNet
         domain AlterNet anetlist anetdiff
         domain FidoNet nodelist nodediff
         ozone 1:107

     What does this do?

      o  The NODE statement tells XlatList who you are, including what
         domain you are in.

      o  The first DOMAIN statement pulls in the node  list  data  for
         AlterNet.  Since that's your own domain, it works just like a
         PUBLIST statement.

      o  The  second  DOMAIN statement pulls in the node list data for
         FidoNet.  Since this is NOT your own domain,  then  the  data
         won't  appear  in your NODELIST.BBS unless you say otherwise.
         Instead,  it's used to create interdomain address entries  in
         your FIDOUSER.LST user index.

      o  The OZONE statement says otherwise, telling XlatList that net
         107  in  zone 1 should be incorporated into your NODELIST.BBS
         just as if they were in your own domain and zone.


     So what happens now?

      o  Say you enter a message to Karl Wong,  who  is  in  net  107.
         Since you have the data for net 107 ready to hand, it goes as
         normal network mail.

      o  Say  you enter a message to Vince Hartman,  who is in net 199
         in  FidoNet.  SEAdog  will  pick  his  address  out  of  your
         FIDOUSER.LST  and,  finding  it to be an interdomain address,
         ruote it via your FidoNet gateway at 520/16.


     What does all this get you?

      o  Direct access to the systems you normally deal with, and

      o  The ability to send mail to any system anywhere in the  world
         WITHOUT  having  to carry around megabytes of data on systems
         you never call.



     XlatList 2.90 also adds support for the new SEAdog routing  class
     capability.  Systems  with  high  speed  modems are predefined by
     XlatList as being in routing class "F" (for Fast),  and  you  can
     define your own routing classes based on node list comments.  For
     FidoNews 6-08                Page 16                  20 Feb 1989


     example,  if  you wanted everyone with a "CM" flag to be in class
     C, everyone with "XP" to be in class X, and everyone with "MO" to
     be in class  "M",  you  can  make  it  happen  by  putting  these
     statements in your XLATLIST.CTL file:

         class CM C
         class XP X
         class MO M

     This let's you use routing commands like:

         Send-to class-C

     to say "send mail to anyone with a CM flag."


     Our intent was to do away with the need for RouteGen, while still
     giving  you  the  flexibility  and routing control you've come to
     expect.  We think we've succeeded.


     Files mentioned this week:

                   XLATRGEN.ARC        XlatList 2.90, and RouteGen

     XLATRGEN.ARC  may  be  downloaded  from  our  technical   support
     bulletin  board at (201) 473-1991,  or may be file-requested from
     either 520/1015@AlterNet or 1:107/1015@FidoNet.


     Next week:  A sample SEAdog script

     -----------------------------------------------------------------
     FidoNews 6-08                Page 17                  20 Feb 1989


     Gordon T. Gattone, moderator
     18/8


                             The Watson Echo Conference

          The WATSON board is a modem that has many additional
     capabilities such as the ability to record speech on a hard drive
     and to interact with its callers via touch tones.  According to
     the manufacturer, Natural Microsystems in Natick, MA there have
     been over 25,000 of them sold.

          The new WATSON echo is an attempt to bring together those of
     us who program WATSON and VIS (Voice Information Systems)
     sequences.  Natural Microsystems has agreed to participate and in
     fact, has allocated funds for equipment purchases to dedicate to
     the echo.

          The echo is available from 18/8, 151/1000, 151/100, and
     151/2 so far. With so many WATSON modems out there, I would
     expect the growth rate to be rather rapid.

          Please contact me at 18/8 if you have any questions or would
     like a feed.

     -----------------------------------------------------------------
     FidoNews 6-08                Page 18                  20 Feb 1989


     =================================================================
                                  COLUMNS
     =================================================================

          The Old Frog's Almanac - Part the Three (and last)

     I've  explained, in previous columns, how I came to  develop  the
     system  which  I  chose to call The Old Frog's  Almanac.  What  I
     haven't  told  you  is perhaps the most important  factor:  I  am
     having a BALL!

     Every  morning,  when  I check my morning  mail,  I  find  myself
     scanning HDCONF, TELIX, DBASE and other conferences to see what's
     left after Sirius gets through....and every time I come across  a
     new  thread  -  one which shows real potential -  I  find  myself
     adding it to the Sirius/EGREP system, and The Almanac grows a tad
     bit  larger...I have, to put things in  perspective,  accumulated
     approximately  3.5 MEGS of archived topical extracts, all in  the
     space  of  five weeks. There seems to be a compulsion  within  to
     initiate  more  and  more files, and eat up more  and  more  disk
     space,  just to provide my users with a massive amount of  USEFUL
     information.....let's face it - no matter how many message  areas
     your  system  carries, there isn't a user born who  can  possibly
     keep  up with the unbridled flood of  information....providing  a
     painless and exciting means by which those thousands of  messages
     can continue to provide value to the users is proving to be FUN.

     How  addictive  can this system be? Let's put it  this  way....my
     SEAdog  batch  file,  which once stood at a  contented  28K,  now
     exceeds  100K; it now processes and maintains over  200  specific
     topical  files,  and more are added daily. God  knows  what  will
     happen when another 200 topics are added...(now, if someone would
     show me a way to compile the sucker, I'd die happy:-))

     I  thought  I would close this series by offering you  a  partial
     list of the files now available on The Almanac - while the 50  or
     so files represent but 20% of those now extracted and  maintained
     without operator intervention, they are more than enough to  give
     you a clear idea of the scope of the system.

     - BBS-related Extracts (MEADOW & PNW_MEADOW)

     95% of the information contained in these files is extracted from
     MEADOW....It's reassuring to think that a sysop having a  problem
     with  LASTUSER.BBS can request specific files which contain  ONLY
     messages  related  to LASTUSER.BBS for any given  month,  without
     having to wade through the SEA vrs. PKWare wars, or the arguments
     about PAK's latest version :-)

     BMDM*.PAK Opus/BiModem Extracts, 02/89
     EGRD*.PAK ECHOGUARD Extracts, 02/89
     EMBD*.PAK OECC/Embedded Commands MEADOW Extracts, 01/89
     JMDM*.PAK JMODEM MEADOW Extracts, 01/89
     LUSR*.PAK LASTUSER.BBS Extracts, 01/89
     MCHK*.PAK MAILCHECKING Extracts, 01/89
     MODM*.PAK MODEM SETUP Extracts, 01/89
     FidoNews 6-08                Page 19                  20 Feb 1989


     NORG*.PAK Opus/NoOrigin Extracts, 02/89
     ODOS*.PAK Opus - DoubleDOS Extracts, 02/89
      ODV*.PAK Opus & DesqView, 02/89
     OKFL*.PAK OFILE Extracts, 01/89
     OKFL*.PAK OFILE Extracts, 02/89
     OMMM*.PAK OMMM Extracts, 01/89
     OMMM*.PAK OMMM Extracts, 02/89
     OPXP*.PAK Opus Express Extracts, 01/89
     OPXP*.PAK Opus Express Extracts, 02/89
     OREG*.PAK REGISTER Extracts, 01/89
     OREG*.PAK REGISTER Extracts, 02/89
     OTWR*.PAK Opus - TradeWars Extracts, 01/89
     OTWR*.PAK Opus - TradeWars Extracts, 02/89
     OWIN*.PAK Opus/Windows Extracts, 02/89
     OZMD*.PAK Opus & ZModem, 02/89
     PRIV*.PAK PRIV File Extracts, 02/89
     PSIG*.PAK PC-SIG CDROM, 02/89
     RASM*.PAK RASMAM, 02/89
     STCK*.PAK STACK Extracts (MEADOW) 02/89
     XLAX*.PAK NODELIST Processing, 02/89

     - DeskTop Publishing Extracts
      APM*.PAK PAGEMAKER, 02/89
     DPUB*.PAK DeskTop Publishing extracts, February 1989
     DQ&A*.PAK DPUB-Q&A, 02/89
     FONT*.PAK FONTS, 02/89
      GEM*.PAK GEM, 02/89
     GLYP*.PAK GLYPHIX Font Mgr., 02/89
     LOGI*.PAK DPUB-LOGITECH Mouse, 02/89
     LPTR*.PAK LASER PRINTERS, 02/89
     PBIT*.PAK Publish It! Extracts, 02/89
     PFSF*.PAK PFS FIRST PUBLISER, 02/89
     PIRC*.PAK Pirated ClipArt Extracts, 02/89
     PSCR*.PAK PostScript Extracts, 02/89
     TOPS*.PAK TOPS, 02/89
     VENT*.PAK VENTURA, 02/89

     - Hard Drives-related Extracts (HDCONF)

     HDCONF  has always been a rich source for technical  information,
     and  the Almanac's extracts reflect that in spades...in  addition
     to  the files listed below, I also carry a file specific to  each
     Seagate and Miniscribe drive discussed in the conference....

     ADAP*.PAK Adaptec Controller Extracts, 02/89
     BKUP*.PAK BACKUP UTIL'S, 02/89
     BUER*.PAK Bulk Erasure, 01/89
     CDCW*.PAK CDC Wren Drives, 01/89
     CMOS*.PAK CMOS, 02/89
     CORE*.PAK CORETEST, 02/89
     CPMQ*.PAK Compaq Drives, 02/89
      D33*.PAK DOS 3.3 Extracts, 02/89
     ESDI*.PAK ESDI Drives/Controllers, 02/89
      FAT*.PAK FAT Extracts, 02/89
     FLPY*.PAK Floppy Drive-related Extracts, 02/89
     FUJT*.PAK FUJITSU Drives, 02/89
     FidoNews 6-08                Page 20                  20 Feb 1989


       HD*.PAK  Hard Drive Conference extracts, 02/89
     INLV*.PAK INTERLEAVE, 02/89
     MAXT*.PAK MAXTOR Hard Drives, 02/89
     MCRP*.PAK MICROPOLIS HD Extracts, 02/89
     MIHD*.PAK MicroScience Drives, 02/89
     MITS*.PAK Mitsubishi Drives, 02/89
     MSHD*.PAK MicroScience Drives, 02/89
     OPTI*.PAK Omptimizing/Optimizers, 02/89
     PARK*.PAK HD PARK Extracts, 02/89
     PERS*.PAK PERSTOR Controller, 02/89
     PRIM*.PAK Priam Drives, 02/89
      RLL*.PAK RLL, 02/89
     RODI*.PAK RODIME Drives, 02/89
     SCSI*.PAK SCSI Drives/Controllers, 02/89
     SDCH*.PAK Static Discharge extracts, 02/89
     SPIN*.PAK SpinRite HD Management, 02/89
     SQHD*.PAK Syquest Drives, 02/89
     TAPE*.PAK Tape Backup Systems, 01/89
     TDHD*.PAK Tandon Drive Extracts, 02/89
      THD*.PAK Tandy Hard Drive Extracts, 01/89
     TOSH*.PAK Toshiba Drives, 02/89
     VRTX*.PAK Vertex Drives, 01/89
     WDHC*.PAK Western Digital Controllers, 02/89
     OPTN*.PAK OPTUNE, 02/89
     VIRU*.PAK VIRUS, 02/89

     Just  one  last reminder....the asterisk in the  filenames  above
     represents  a  four-digit  number, in the format  "mmyy"  -  ergo
     requesting   TDHD*.PAK   will   get   you   one   complete   file
     (TDHD0189.PAK) now, and one partial file (TDHD0289.PAK) -  Should
     you request it next January, it'll get you twelve files - one for
     each month. (A complete list of all Almanac files is available as
     ALMANAC.LST - the system I use is available as ALMANAC.PAK, which
     includes the morning's updated ALMANAC.LST)

     Ain't life GRAND?

     -----------------------------------------------------------------
     FidoNews 6-08                Page 21                  20 Feb 1989


     =================================================================
                              LATEST VERSIONS
     =================================================================

                               GMAIL 1.10

     The first verison of GMail, a QuickBBS Group Mail processor has
     been released, and is available from 1:266/15, or 7:520/911.

     GMail is a fully functional Group Mail processor, with the
     ability to import and export directly to/from the QuickBBS
     message base, as well as functioning as a top or mid-level star.
     GMail is also fast, on the development system, a 12MHZ AT, with a
     28ms HD, it imports almost 3 messages per second.

     The release archive is available as GMAIL110.ARC, and is
     file-requestable of downloadable from 7:520/911, or 1:266/15.  A
     support conference, with the name of GMAIL, is also available
     from the same system.


     -----------------------------------------------------------------
     FidoNews 6-08                Page 22                  20 Feb 1989


                          Latest Software Versions

                           Bulletin Board Software
     Name        Version    Name        Version    Name       Version

     Fido            12K*   Opus          1.03b    TBBS           2.1
     QuickBBS       2.03    TPBoard         5.0    TComm/TCommNet 3.2
     Lynx           1.10    Phoenix         1.3    RBBS         1.71C


     Network                Node List              Other
     Mailers     Version    Utilities   Version    Utilities  Version

     Dutchie       2.90C*   EditNL         4.00    ARC           5.32
     SEAdog         4.50*   MakeNL         2.12    ARCmail        2.0*
     BinkleyTerm    2.00    Prune          1.40    ConfMail      4.00
     D'Bridge       1.10    XlatList       2.90*   TPB Editor    1.21
     FrontDoor       2.0    XlaxNode       2.31    TCOMMail       2.0
     PRENM          1.40    XlaxDiff       2.31    TMail         8901*
                            ParseList      1.30    UFGATE        1.02*
                                                   GROUP         2.04*
                                                   EMM           1.40
                                                   MSGED         1.96

     * Recently changed

     Utility authors:  Please help  keep  this  list  up  to  date  by
     reporting  new  versions  to 1:1/1.  It is not our intent to list
     all utilities here, only those which verge on necessity.

     -----------------------------------------------------------------
     FidoNews 6-08                Page 23                  20 Feb 1989


     =================================================================
                                  NOTICES
     =================================================================

                          The Interrupt Stack


     19 May 1989
        Start of EuroCon III at Eindhoven, The Netherlands

     24 Aug 1989
        Voyager 2 passes Neptune.

     24 Aug 1989
          FidoCon '89 starts at the Holiday Inn in San Jose,
          California.  Trade show, seminars, etc. Contact 1/89
          for info.

      5 Oct 1989
        20th Anniversary of "Monty Python's Flying Circus"

     If you have something which you would like to see on this
     calendar, please send a message to FidoNet node 1:1/1.

     -----------------------------------------------------------------

     FidoNews 6-08                Page 24                  20 Feb 1989


     =================================================================
                                  REPORTS
     =================================================================

                          IFNA Treasurer's Report
                               January, 1989
                           Steve Bonine   115/777


     IFNA Treasurer's report for January, 1989

     RECIEPTS & DEPOSITS
        Membership fees                          150.00
        FidoCon '88                             1200.00

     TOTAL RECEIPTS                                          $1350.00

     DISBURSEMENTS
        Postage                                   12.65
        Professional services (Marc Rubin)        34.00
        Bank charges                              17.40

     TOTAL DISBURSEMENTS                                        63.79

     EXCESS RECEIPTS OVER DISBURSEMENTS                       1286.21

     ADD BEGINNING BALANCE                                    6082.72

     BALANCE IN ACCOUNT                                       7368.93

     Note:  The $1200 item is a payment from the FidoCon 88 sponsors.
     I have received no financial statement from this group which
     details any of their expenditures.

     This is my last monthly IFNA treasurer's report, as I will resign
     as IFNA treasurer at the Board meeting on February 17-19.  Until
     February 20, full IFNA financial data will be available for file-
     request from 115/777 using the magic filename of IFNA$.  After
     that date, requests for information should be submitted to the
     new treasurer.


     -----------------------------------------------------------------
     FidoNews 6-08                Page 25                  20 Feb 1989


            OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION

     Hal DuPrie     1:101/106  Chairman of the Board
     Bob Rudolph    1:261/628  President
     Matt Whelan    3:3/1      Vice President
     Ray Gwinn      1:109/639  Vice President - Technical Coordinator
     David Garrett  1:103/501  Secretary
     Steve Bonine   1:115/777  Treasurer



                         IFNA BOARD OF DIRECTORS

         DIVISION                               AT-LARGE

     10  Courtney Harris   1:102/732?    Don Daniels     1:107/210
     11  Bill Allbritten   1:11/301      Hal DuPrie      1:101/106
     12  Bill Bolton       3:711/403     Mark Grennan    1:147/1
     13  Rick Siegel       1:107/27      Steve Bonine    1:115/777
     14  Ken Kaplan        1:100/22      Ted Polczyinski 1:154/5
     15  Larry Kayser      1:104/739?    Matt Whelan     3:3/1
     16  Ivan Schaffel     1:141/390     Robert Rudolph  1:261/628
     17  Rob Barker        1:138/34      Steve Jordan    1:102/2871
     18  Christopher Baker 1:135/14      Bob Swift       1:140/24
     19  David Drexler     1:19/1        Larry Wall      1:15/18
      2  Henk Wevers       2:500/1       David Melnik    1:107/233

     -----------------------------------------------------------------
     FidoNews 6-08                Page 26                  20 Feb 1989


                                      __
                 The World's First   /  \
                    BBS Network     /|oo \
                    * FidoNet *    (_|  /_)
                                    _`@/_ \    _
                                   |     | \   \\
                                   | (*) |  \   ))
                      ______       |__U__| /  \//
                     / Fido \       _//|| _\   /
                    (________)     (_/(_|(____/ (tm)

            Membership for the International FidoNet Association

     Membership in IFNA is open to any individual or organization that
     pays  a  specified  annual   membership  fee.   IFNA  serves  the
     international  FidoNet-compatible  electronic  mail  community to
     increase worldwide communications.

     Member Name _______________________________  Date _______________
     Address _________________________________________________________
     City ____________________________________________________________
     State ________________________________  Zip _____________________
     Country _________________________________________________________
     Home Phone (Voice) ______________________________________________
     Work Phone (Voice) ______________________________________________

     Zone:Net/Node Number ____________________________________________
     BBS Name ________________________________________________________
     BBS Phone Number ________________________________________________
     Baud Rates Supported ____________________________________________
     Board Restrictions ______________________________________________

     Your Special Interests __________________________________________
     _________________________________________________________________
     _________________________________________________________________
     In what areas would you be willing to help in FidoNet? __________
     _________________________________________________________________
     _________________________________________________________________
     Send this membership form and a check or money order for $25 in
     US Funds to:
                   International FidoNet Association
                   PO Box 41143
                   St Louis, Missouri 63141
                   USA

     Thank you for your membership!  Your participation will help to
     insure the future of FidoNet.

     Please NOTE that IFNA is a general not-for-profit organization
     and Articles of Association and By-Laws were adopted by the
     membership in January 1987.  The second elected Board of Directors
     was filled in August 1988.  The IFNA Echomail Conference has been
     established on FidoNet to assist the Board.  We welcome your
     input to this Conference.

     -----------------------------------------------------------------
