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.
-----------------------------------------------------------------