Hello Sean.

12 Nov 02 17:33, Sean Dennis wrote to All:

 SD> Hello, All.

 SD> I'm using Seal 0.50 for my areafix manager and it works great... the
 SD> question I have is how can I specify different networks in TIC.CFG?  I
 SD> carry 10 networks and filebones for each of them... do I have to
 SD> specify my alias for each network or do I just put in each
 SD> uplink/downlink into TIC.CFG and let Seal worry about it?


I haven't tried it, but here's the poop in the SEAL docs:

When writing the TIC.CFG file, Seal will automatically write your primary
address as well as all your Akas as listed in SQUISH.CFG. This is so Seal
can automatically determine the Ax flag for adding a downlink to an area.
(Consult the documentation with Tick 2.10 or later for complete details on
this switch.) To be consistent, Seal will also add the Ax switch to each
nodes entry in TIC.CFG when needed to ensure they match the akas listed.
This allows you to change your akas in SQUISH.CFG and they will be changed
accordingly in your TIC.CFG next time it is written. To force the update,
you must do a SEAL FORMAT.

=== and from Tick docs:

                                  AKA's


Several of you have asked for this feature.  Here's how it works:

For each alternate address you are known by, add a line to the CFG file
beginning with the keyword "AKA", and followed by your address in
[zone:]net/node format.  If the zone is not present, it defaults to the
default zone (the first ZONE statement in the CFG file).  For example:

           AKA 1:1/313

When I place this in my CFG file, I will add both my main address of
1:266/12, and 1:1/313 to the seenby list in my outbound TIC's and Fle's.

You may specify for each node you send to, what address you are sending
from. All addresses still appear in the seenbys.

Here's how it works:  There is an additional flag for the node's flag field
(the field where you specify if that node is rash, old,
, etc).  If you want that node to receive from you as your primary
address, you need make no change.  If you want to send to that node as an
AKA, the new flag is "A", followed by the number of the AKA to
use (from 0 to F in Hex).  The number corresponds to the order that you
have defined AKA's in your CFG file . . . The first AKA is "0",
the second is "1", etc.

     NOTE THAT THE NUMBERING STARTS AT '0', NOT AT '1'.

For example, to send to node 2:512/26 using my first AKA of 1:1/313, I
would set the node up like this:

          2:512/26 Password HA0*

This will instruct TICK to communicate with that node as 1/313, send it
HOLD, and accept files from him as well.  Since I will be now sending to
2:512/26 as 1:1/313, he must set up my node as 1/313 in his TIC.CFG, and
need NOT set up my node as 266/12.

The number after the "A" must be a single character, and must not
be separated from the "A" by a space

USE CAUTION WITH SENDING TO OTHERS AS YOUR AKA!  If not carefully used,
this will increase the likelyhood of a DUP ring.  It's recommended that
AKA's only be used when crossing between zones at a designated
"gate", which does not loop back into the first zone somewhere
else.  Oh yes . . . The limit on AKA's is 16 of 'em.

=== end cut

So it appears that SEAL claims to take care of things for you as long as
all of your AKAs are set up in your SQUISH.CFG.  You should be able to
check your existing TICK.CFG to verify that SEAL has already written the
appropriate AKA lines at the beginning.

Presumably your different bones will have different Filefeed entries and NA
files.  If a duplicate tag exists in multiple networks, then SEAL is
probably going to request-forward to the first match found.

I'd be interested in hearing how you make out, even if it works as
advertised. SEAL has been quirky for a lot of users in odd circumstances
that has caused them to give up on it, but I still use it because it does
too many things that it would take a gaggle of replacements to duplicate
the functionality of.  Only wish that Robert could've managed a native OS/2
port before he lost the source.

.\\ike

--- GoldED 2.50+