This tutorial is about the newest feature of GT Power, EchoMail.  It is 
not intended to be considered an exhaustive study of the subject, but it 
should be sufficiently detailed to help the vast majority of readers to 
understand what it is, how it works, and how to set it up.

First, as usual, some definitions.

Netmail:  Whenever used in this tutorial, Netmail refers to the function 
available to registered GT Power users.  It is not meant to include any 
other form of electronic message switching or E-Mail services, and it 
certainly does not mean to suggest that the programs associated with GT 
Power that perform these functions are in any way compatable with any 
other such service.  As of this writing, 11/08/87, there is no such 
compatability.  (See GTTUTOR5.TXT for a fairly complete discussion of 
Netmail).

Echomail:  An extension of Netmail that allows message files to be 
replicated on other systems.  That is, a particular message base, known 
as the Hub or Sponsoring base, is the end of a set of chains (Net/Nodes) 
and any messages placed into that message base will be copied (via 
Netmail) to similar message bases on all 'Subscribing' systems.  
Further, that same message base may have messages added to it by any of 
those Subscribing systems and these messages will also ultimately be 
strewn throughout the set of subscriber systems after they have found 
there way to the Sponsoring message base.  These ideas will be far 
better explained as you read on.

Sponsoring message base:  This is the set of messages which reside on
the system that creates the conference.  For example, the National
Echomail Conference that deals with Financial issues is located on the 
system located at Net/Node 001/000.  The Sysop of that system, myself, 
has agreed to 'Sponsor' this conference and, thus, created the message 
base and let its existence be known throughout the Network.  In order to 
become a Sponsor you must establish a unique Net/Node address that 
represents your conference, and publish that address so that others may 
know about it.  In the case of the National Echomail conferences,
you must have this Net/Node address assigned to you by the National 
Echomail coordinator.  Local Echomail conferences, (those available to 
only your Net, for example), are assigned identifiers by the local 
Echomail coordinator.  These Echomail Net/Node numbers are in addition 
to the normal Netmail Net/Node address that is assigned to your system 
and they always begin with the letter 'E'.

Subscriber message base:  Any node on the Network may become a 
'Subscriber' to any and all conferences which they are made aware of.  A 
subscribing message base is a copy of the Sponsoring message base in 
that it is created for that purpose and its contents come from Netmail 
contact with another system that is either a subscriber or sponsor of 
the conference.  In order to become a subscriber, you need only 
establish entries in your ROUTING.BBS file that properly identifies the 
conference and which point to a source Net/Node from which to get that 
conference updated via Netmail.  Each Echomail conference has a unique 
identifier as described above.  For example, the National Finance 
conference is identified as conference E00/003.

Public access:  Netmail, and of course, by extension, Echomail, is NOT a 
public service.  It is a function of GT Power that is available to 
registered users and their authorized guest users.  Further, just 
because you have access to the Netmail/Echomail code does not mean that 
you automatically have access to the International Netmail Network, or 
to any Echomail conferences that are on that Network.  Instead, access 
to a Network (National, Local, or private) requires that you have been 
issued an enabling CRC and a unique Net/Node address that identifies 
your system to all others that are on the Network in question.  The 
assignment of a Net/Node and a CRC is not automatic, nor is it a 'right' 
belonging to all registered users of GT Power.  It is the right of the 
Network coordinators to exclude or authorize whomever they wish to these 
services.  While access is generally not denied to anyone that applies, 
such denial is possible.  Similarly, access to a particular Echomail 
conference is neither automatic nor is it a 'right'.  In the case of 
National Echomail conferences, access is accomplished rather easily and 
without prior authorization.  The nature of the National conferences is 
such that they may be accessed by any existing Netmail Net/Node that has 
not been specifically excluded by the sysop of a system that the 
'subscriber' wishes to obtain access to the conference from.  Since 
there are many alternatives to choose from, each providing access to the 
same message base, this is effectively the same as saying that anyone 
that is authorized to use the National Network may access any National 
conference.

All of which is to say that these conferences are easily joined, but 
they are NOT PUBLIC SERVICES.  However, as it would make no sense, 
whatever, for private messages to be distributed across the systems of
all subscribers to these conferences, YOU MAY NOT HAVE ANY PRIVATE 
MESSAGES IN AN ECHOMAIL CONFERENCE.  Indeed, Netmail/Echomail prevents 
you from doing so.

Chains of Subscribers:  While there may be only one Sponsoring message 
base, there may be any number of Subscribers and, thus, any number of 
copies of that message base.  Since Subscribers may obtain access to the 
conference by connecting either with the Sponsoring system or that of 
any other subscriber, you can see that an Echomail conference will 
consist of some number of chains of subscribers.  Whenever messages are 
added to the Sponsoring message base they will be made available to any 
subscriber that should call the sponsoring system as of the next Netmail 
session hosted by that Sponsor.  Once these messages are received into 
the subscriber's conference message base they may be obtained by any 
other subscriber that calls that system, but usually there will be a one 
day delay in such availability.  Thus, the farther down a particular 
chain you are, the less current will be your conference, but they will 
always be complete up to the last update they receive.  Delays of a day 
or two or three are normal and expected in Echomail conferences.  Should 
a chain be 'broken' for any reason, any subscriber downstream may 
reestablish the conference by connecting with any other subscribing 
system that is upstream (closer to the Sponsor).  In doing this there 
will be NO LOSS in terms of the contents of the conference once the 
chain is reestablished.  This is because Echomail will automatically 
determine the date of the last update to a subscriber's conference and 
provide all messages subsequent to that update.

What is not obvious so far is that if you should try to reestablish a 
broken chain by connecting to a system that was downstream rather than 
upstream relative to yourself, then you will have established a closed 
loop conference that will no longer be able to obtain updates from the 
sponsor.  Great care must be taken to insure that all subscribers are 
always connecting to either an upstream subscriber or to one that is 
subscribing via a different chain than was previously in existence.  
Said differently, you must NOT allow a circular path, closed loop, to exist.

Directories:  Echomail uses normal Netmail directories (\MAILOUT, 
\MAILIN, and \MAILWORK).  What it does NOT use are Netmail message 
bases!  All Echomail conferences are normal 'vanilla' message bases.  
These message bases are usually set up to preclude private messages (via 
placing a carrot (^) at the beginning of the message base pathname in 
GTMDIR.BBS), but they NEVER are to include the Netmail symbol (~) as 
part of their pathname.

There is only one semi-official Echomail file: ECHOMAIL.BBS.  This file 
is not in any way necessary for the operation of Echomail.  It is merely 
a list of the currently available National Echomail conferences, the 
Net/Node of the Sponsor of these conferences, and the times of day that 
the Sponsoring system is available to receive Echomail calls from 
Subscribers.  This list is expected to be updated frequently and made 
available from the National Echomail coordinator.

Additional concepts:

From the previous paragraph you may have surmised that Sponsors do not 
have any obligation to make calls out to subscribers.  You would be 
correct.  Subscribers MUST initiate the request to obtain an update for 
each conference of interest.  This request may be done during any 
Netmail session, regardless of which side placed the call, if it is a 
local call or if it is via PC Pursuit.  (Long distance calls make the
request via a PICKUP OVERRIDE.)

When you first join (subscribe to) a conference, you will not receive 
the entire contents of the message base unless it is a relatively new 
conference.  The default setup of Echomail provides that a Sponsoring 
system will retain only the latest 14 days of updates for distribution.  
A Sponsor may elect to save as many or as few days as they wish, but it 
is unlikely that they will provide dozens of days of such updates to new 
subscribers.

Updates are sent downstream via mailbags with the first letter 
containing an 'E' rather than a 'B'.  Receipt of these mailbags causes 
them to be placed into both your \MAILIN and \MAILOUT direcotries.  
Those that are placed in your \MAILIN directory are subsequently 
unbagged into your conference message base and those that are placed 
into your \MAILOUT directory are made available to any subscriber who 
should call your system and request the conference from you.

Any messages that are created on your system as part of the conference 
message base will be bagged by the MBAGGER program and placed into 
normal mailbags (beginning with the letter 'B') and sent upstream.  
These bags flow upstream until they eventually reach the sponsoring 
system at which time they will be unbagged into the sponsors conference 
and, thus, become available to all subscribers of the conference with 
the next day's Netmail session.  When the messages that originated on 
your system finally are sent back to you in an 'E' mailbag, they are 
ignored in order to prevent duplicate messages from appearing on your 
system.  They will, however, continue to flow downstream and be placed 
in each recipient subscriber's conference.  In this way, eventually all 
conferences will contain the same messages as all other subscribers.  
Note, however, that the sequence of messages in the messages bases will 
have significant variances from system to system.  They will, however, 
be reasonably associated within date sequence.

Echomail conferences are not available to a subscriber just because his 
system is connected to another system via a Netmail session.  That is, 
the transfer of messages (mail) usually has high priority over the 
transfer of Echomail conferences since Echomail conferences can be 
delayed by up to 14 days without meaningful loss.  Mail, on the other 
hand, must be transferred as expeditiously as possible.  For this 
reason, there is a facility within the code to allow Echomail conference 
requests to be honored only between certain times of the day.  For 
example, suppose that a sponsoring system runs Netmail code from 3:15 
a.m. until 5:00 a.m. every day.  Further, suppose that Netmail message 
transfers are scheduled to run from 4:00 a.m. until 5:00 a.m.  This 
means that Echomail should be made available to subscribers from 3:15 
until 4:00.  A new entry in the ROUTING.BBS file allows oyu to specify 
the hours which your system will honor Echomail requests.  It is a 
single line entry in that file which for this example would look like 
this:   ECHOMAIL HOURS  3:15 4:00

Obviously, a subscriber MUST find out the Echomail hours provided by the 
system he is calling to obtain the desired conference from.  Further, he 
must call during those hours.

As an aside, even if Netmail message traffic is scheduled from 4:00 
until 5:00 in the morning, in the situation described above, if there is 
any mail to be exchanged between the subscriber and the system he is 
connecting to, that mail will be transferred between them during the 
Echomail call.  In other words, mail transfers will always be made if it 
is possible to do so, even if it is not during the scheduled Netmail 
'hour'.

Since Echomail is an extension of Netmail which uses the same code, then 
how is it that you can place Echomail calls outside of Netmail time 
without making calls to systems that do not have echomail conferences?  
That is, if you have a mailbag waiting to be sent to someone, unless you 
tell Netmail otherwise, it will try to place a call to effect delivery 
of that mail.  Thus, you will need to create a separate ROUTING.BBS file 
to be used during Echomail times from that which is used during normal 
Netmail.  In the Echomail ROUTING.BBS file you are to set ALL NODES that 
you are not calling for ECHOMAIL purposes into your INBOUND NODES list.

In your ROUTING INSTRUCTIONS section of the routing files you must place 
ACCEPT statements for each conference you are interested in.  Say, for 
example, that you are interested in subscribing to National Conferences 
E00/003 and E00/006.  Suppose that you determine that a local node on 
your Net carries both conferences so you need only to call that one 
system in order to subscribe to both.  Supposing that that local system 
is Net/Node 006/000, you would place the following two ACCEPT statements 
into your ROUTING INSTRUCTIONS section:
   ACCEPT  E00/003-003 -> 006/000
   ACCEPT  E00/006-006 -> 006/000

In this way, Netmail knows that you are subscribing to these conferences 
(and that you are NOT the sponsor), and that you wish to obtain the 
conferences via calls out to 006/000.  (If you were a conference Sponsor 
you would leave off the re-direction information for your conference).

There is only one more thing to do in the routing file.  You must 
include an OUTBOUND NODES entry for each conference you are subscribing 
to.  You would need to have the following two entries in this case:
   E00/003
   E00/006

Note, it is not enough that you are connected to 006/000 based on one or 
the other of these OUTBOUND NODES entries.  Conference requests will be 
issued ONLY for those that are specifed with an entry.  That is, having 
E00/003 as an OUTBOUND NODE will cause your system to call and connect 
with 006/000, but it will NOT cause a request for E00/006 to be issued 
unless there is also such an OUTBOUND NODE specified.

One more new section is now of importance to you.  It is called the 
MESSAGE DISTRIBUTION section.  Here is where you tell the MDIST program 
what to do with messages that are unbagged by it.  Unless you specify, 
all messages are placed into the first Netmail message base listed in 
GTMDIR.BBS.  Echomail must be sent to the appropriate message bases 
instead of to the Netmail message base.  Your entries in this section 
would look like this:

    E00/003-003 -> C:\ECHO\FINANCE
    E00/006-006 -> C:\ECHO\SYSOP

where the information to the right of the re-direction symbol is the 
pathname of the conference message base.  Thus, all mailbags that are 
marked as belonging to E00/003 will be unbagged into messages that are 
placed into the C:\ECHO\FINANCE message base.  Recall that these are 
just normal message bases, NOT Netmail message bases.

That's about it.  What's next is to determine how to setup so that you 
can exchange routing files and support both Echomail and Netmail session 
on one system.  This is done, as you must suspect, via scheduled events 
and batch files.

In the example I have been creating above, you might have the following 
two entries in your SCHEDULE.BBS file to start events:

03:15-03:59 ECHOMAIL
04:00-04:45 NETMAIL

Then, you might create two batch files that look like this:

ECHOMAIL.BAT:

   COPY ROUTING.ECO ROUTING.BBS
   MBAGGER
   MDRIV028 xxxx-xxxx 3:15 04:00

NETMAIL.BAT:

   COPY ROUTING.NET ROUTING.BBS
   MDRIV028 xxxx-xxxx 4:00 5:00
   MDIST

ROUTING.ECO containing the routing file image that has all non-Echomail 
Net/Nodes specified as INBOUND NODES and ROUTING.NET being the routing 
file used for normal Netmail.

These two events could just as easily, of course, have been only a 
single event and the batch files would be concatenated into a single 
file.  Either way is fine, but there are a couple of things you must NOT 
DO.

1) Do not allow MBAGGER to run more than once a day (unless you use the 
/N option for the second and subsequent times it is run).

2) Do not attempt to run MBAGGER or MDIST programs unless the routing 
file contains the appropriate Echomail information.  If you do not have 
the MESSAGE DISTRIBUTION section properly setup, then MDIST will not 
operate correctly, and the ROUTING INSTRUCTIONS must also be properly 
setup for the Echomail conferences.  This argues that whether running 
Echomail or just Netmail, the ROUTING INSTRUCTIONS and MESSAGE 
DISTRIBUTION sections should be identical.  That is good advice.  Take 
it from someone who learned the hard way.

One more thing you should know about Echomail is that it does not 
support file transfers.  It would make no sense, whatever, to allow 
either File Attach or File Request commands in an Echomail environment.  
Though you can create a message that appears to include the .FR or .FA 
commands, they will be ignored by the Echomail code.

There is a lot more to know about Echomail, but you now have enough to 
get started.  Enjoy the feature and while you are at it, please accept 
my invitation to join the National Echomail Finance conference.  As the 
Sponsor of this conference, I welcome any comments and observations you 
might wish to offer, and invite you to post your thoughts relative to 
economic or financial issues in the conference for all who subscribe to 
benefit from.

James Davis
National Netmail Coordinator
001/000
Finance Conference Sponsor
E00/003

(713) 589-0307 - James Davis' Retreat - Houston Texas