home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
acs_deng
/
acs_eng2.doc
< prev
next >
Wrap
Text File
|
1989-04-05
|
27KB
|
561 lines
P A R T 2
INFORMATION FOR THE NODE
Author: Roland Bohn
Translator: Frank Bell
Before you read PART 2, you should first read the documentation on the
Binkley Mailer. As a Point this section could be a little confusing and
its not necessary, so there isn't much use being troubled by it. As a
Node, it is very important that you understand what this section is about.
Mostly I'm going to explain the differences in how commands and/or
parameters are used as opposed to the Binkley documentation. What the
parameters mean should also be gotten from the Binkley documentation.
In Part 1 of this documentation, as you most likely noticed, exist very
many Commands which are important for the Node. That means that some of
the Commands were already explained. In Part 2 that rest of the Commands
will be explains from a Node's point of view.
The following Buttons in the Sysop-Info dialogbox haven't been
explained:
AKA DOMAIN KEY
What is AKA? - AKA means "Also Known As ..." and indicates another
Fido Address under which a Node can be identified.
The Node has two or more Addresses.
+------------------------------------------------+
| Multiple-Address Statements |
| |
| 90_:6000_/101__._____@______________ 6101__ |
| ___:_____/_____._____@______________ ______ |
| ___:_____/_____._____@______________ ______ |
| ___:_____/_____._____@______________ ______ |
| |
| Cancel Ok |
+------------------------------------------------+
In BTS the old designation (AKA) is shown, but 'Address' is still used in
Binkley.CFG. AKA is used to differentiate the indicated address from the
Main Address, besides, an 'old FidoNet horse' knows what's meant.
What a DOMAIN is is explained in Part 3, appendix 6. Or in the Binkley
documentation. We aren't going to go into it here. Domains, at this
time, are not needed and not even 100% supported.
But what is a KEY? - KEY is a function which I have taken over from the
THE-BOX utilities as I wanted my software to be
compatible to it (after a while i stopped supporting)
and is used very closely used with AKA Addresses.
Binkley has the ability to display an Address which
is similar to that of the opposite Node all by
itself. Lets take for example that in Binkley.CFG
we have entered two addresses: 2:241/5811 and
2:7700/1. When Binkley calls up Node 2:241/5800 or
2:310/12 then it shows its own address as 2:241/5811.
But when Node 2:7700/200 is called up Binkley
displays 2:7700/1.
Note: The new Version of ACS Software does this the same
way and it seems that most times it does right.
But it is possible that you will have a special
Configuration and therefore need this Feature.
+----------------------------------------------------+
| Special Address-Keys |
| use alternative Addr => at these Nodes |
| 1. 2__:7700_/1____._____ 2__:7700_/ALL__._____ |
| 2. ___:_____/_____._____ ___:_____/_____._____ |
| 3. ___:_____/_____._____ ___:_____/_____._____ |
| 4. ___:_____/_____._____ ___:_____/_____._____ |
| ... |
| Cancel Ok |
+----------------------------------------------------+
The Addresses on the left side are used as Sender Addresses of all
Netmails to the Nodes on the right side. As you can see in the above
example, the column on the right side can use the 'ALL' parameter. Here
all Netmails which go to Net 7700 in Zone 2 use the Sender Address
2:7700/1.
Known-Inbound and Protected-Inbound:
+--------------------------------------------+
| Path Configuration |
| |
| Loglevel : 5 |
| Logfile : \FIDO\SYSTEM.LOG___________ |
| Nodelist : \FIDO\NODELIST\____________ |
| Downloads: \FIDO\DOWNLOAD\____________ |
| Netmail : \FIDO\MSGS\NETMAIL_________ |
| |
| Netfile : \FIDO\IN\INBOUND\__________ |
| KnownInbound: \FIDO\IN\INBOUND.KWN\______ |
| ProtInbound : \FIDO\IN\INBOUND.PVT\______ |
| Hold : \FIDO\OUT\OUTBOUND\________ |
| |
| Cancel Ok |
+--------------------------------------------+
In Part 1 we haven't talked about KnownInbound and ProtInbound. Binkley
knows, with help of the Nodelist, just about all of the Nodes in the
Fido Network. The Nodes which are listed are know as "know" Nodes. Some
Nodes are contacted regularly, for example: POLLed. To be on the safe
side, Passwords with these Nodes have been agreed upon so that others
can't mess around with the Netmails. These Nodes are now "protected"
Nodes.
When one wants, the Netmails which are received from many different Nodes,
can be sorted into different Folders. Thats the reason behind
KnownInbound and ProtInbound. The normal (and the default) file for all
other Nodes is and remains Netfile.
Modem Init-Strings:
+--------------------------------------------+
| Modem Init-Strings |
| |
| Init : ATZ|~~_____________________ |
| Prefix : ATDP_______________________ |
| Suffix : ___________________________ |
| Answer : ATA|_______________________ |
| Busy : ___________________________ |
| PreInit : ___________________________ |
| PreDial : ___________________________ |
| TermInit: ___________________________ |
| |
| ModemTrans: HST PEP ________/_________ |
| Dial: __________ ________/_________ |
| |
| Cancel Ok |
+--------------------------------------------+
With the Modem Init Strings I recommend that the Binkley default strings
be used whenever possible (no entry in the above dialog box) and that the
most important Settings for the modem be stored in the modem as far as its
possible.
For example the HST Modems can be set up as follows:
ATI4 Info:
USRobotics Courier 14400 HST Settings...
B1 C1 E1 F1 M3 Q0 V1 X7
BAUD=19200 PARITY=N WORDLEN=8
DIAL=HUNT ON HOOK TIMER
&A2 &B1 &C1 &D2 &G2 &H1 &I0 &J0 &K3
&L0 &M4 &N0 &P0 &R2 &S1 &X0 &Y1
S00=000 S01=000 S02=043 S03=013
S04=010 S05=008 S06=002 S07=060
S08=005 S09=008 S10=004 S11=070
S12=050 S13=001 S14=001 S15=000
S16=000 S17=000 S18=000 S19=000
S20=000 S21=010 S22=017 S23=019
S24=150 S25=000 S26=000 S27=000
S28=008 S38=000
ATI5 Info:
USRobotics Courier 14400 HST NRAM Settings...
DIAL=TONE B1 F1 M3 X7
BAUD=19200 PARITY=N WORDLEN=8
&A2 &B1 &G2 &H1 &I0 &J0 &K3 &L0
&M4 &N0 &P0 &R2 &S1 &X0 &Y1
S02=043 S03=013 S04=010 S05=008
S06=002 S07=060 S08=005 S09=008
S10=004 S11=070 S12=050 S13=001
S15=000 S19=000 S21=010 S22=017
S23=019 S24=150 S26=000 S27=000
S28=008 S38=000
For Nodes the Answer String has to be entered, for example as "ATA|".
Miscellaneous Configuration Parameters:
+-------------------------------------------------------------+
| Miscellaneous Configuration-Parameter |
| |
| PollTries: 20__ BoxType: 0 ScreenBlank: Off Norm Key Call |
| |
| AfterMail: ______________________________________________ |
| Cleanup : ______________________________________________ |
| Packer : ______________________________________________ |
| CaptureFile: ____________________________________________ |
| Reader : \FIDO\LED.PRG_______________________________ |
| |
| AnswerBack : ____________________________________________ |
| |
| TimeOut: __ BBS: Off Batch Exit |
| |
| Banner : ______________________________________________ |
| DoingMail: ______________________________________________ |
| EnterBBS : ______________________________________________ |
| BBSNote : ______________________________________________ |
| |
| Cancel Ok |
+-------------------------------------------------------------+
I believe that the Binkley documentation and its recommendations be used.
I would like to explain the Screenblank Buttons though:
- The Button 'Off' means that this Function is turned off.
- The Button 'Normal' means Screenblank without a Parameter.
- The Button 'Key' means Screenblank with the Parameter 'Key'.
- The Button 'Call' means Screenblank with the Parameter 'Call'.
The same implies for the BBS Buttons in the above dialog box.
What is Readdress? - The Readdress Button hasn't been described in the
ACS Configuration dialog. It happens sometimes
that a Node or Point changes its address, goes on
vacation, etc. In cases like this the Netmails
have to be delivered to the correct Address. To
readdress all of these Netmails by hand is very
difficult and almost impossible. So lets let the
software do it for us. With Readdress all the
incoming Netmails, which are applicable for the
Readdress Command, are rewritten with the new
Address and processed as if these Netmails were
written using the new Address in the first place.
(Readdress is not Routing).
Notes: Your own Netmails on this Nodes/Points are
_not_ changed by Readdress. This is done
for different reasons. One should send
Netmails to the correct Address.
+----------------------------------------------------------+
| Readdress |
| |
| Readdress: Roland Bohn____________ *__:*___/*___.*___ ^ |
| To: *______________________ 2__:241_/5811.0___ | |
| | |
| Readdress: *______________________ 2__:241_/5811.1___ | |
| To: Christian Paas_________ *__:*___/*___.*___ | |
| | |
| Readdress: _______________________ ___:____/____.____ | |
| To: _______________________ ___:____/____.____ | |
| | |
| Readdress: _______________________ ___:____/____.____ | |
| To: _______________________ ___:____/____.____ V |
| |
| Cancel Ok |
+----------------------------------------------------------+
The first line contains the original (old) Address. The first two
parameters give information over the addressee, for which the Netmails
are to be detoured.
The second line contains the new addressee. The last two parameters give
information on who the Netmail is to be detoured to.
So far so good. If only fixed Addresses and Names can be used then this
wouldn't be very flexible. To really confuse things in Readdress an
Address Element of a Netmail can also be indicated which should be
changed.
The first of the the two parameters (Line 1) is responsible for checking.
When a '*' is entered in an element, then the element isn't checked. The
parameter "*" 2:241/*.* checks only if the Netmail if for Zone 2, Net 241.
The last two parameters (Line 2) are responsible for changes. When a "*"
is entered in an element, then the element isn't changed. The entry
"Christian Paas" *:*/*.1 changes only the name of the Netmail addressee
and set the Pointnumber to 1.
Important: Readdress should only be used when absolutely necessary. You
should very carefully think out the parameters you want to
use to get the correct results.
AreaFixPwd:
+------------------------------------------------------+
| AreaFix Passwords |
| |
| 2__:241_/5811.1___ HELLO_ ___:____/____.____ ______ |
| 2__:241_/5811.2___ TEST__ ___:____/____.____ ______ |
| 2__:310_/12__.____ JOKE__ ___:____/____.____ ______ |
| ___:____/____.____ ______ ___:____/____.____ ______ |
| ___:____/____.____ ______ ___:____/____.____ ______ |
| |
| Cancel Ok |
+------------------------------------------------------+
The AreaFix Passwords defines the Passwords for use in Come_In's built-in
AreaFix. With the help of AreaFix the indicated Nodes/Points can
subscribe to or cancel system Areas themselves. The Nodes/Points write
a Netmail to AreaFix with the above defined Password in the Netmail
Subject Line and then they can order new Areas or just ask for a list of
available Areas. How it works is described in Part 1.
FileFixPwd:
+------------------------------------------------------+
| FileFix Passwords |
| |
| 2__:310_/12__.____ NONE__ ___:____/____.____ ______ |
| 2__:241_/5811.3___ STUD__ ___:____/____.____ ______ |
| ___:____/____.____ ______ ___:____/____.____ ______ |
| ___:____/____.____ ______ ___:____/____.____ ______ |
| ___:____/____.____ ______ ___:____/____.____ ______ |
| |
| Cancel Ok |
+------------------------------------------------------+
The FileFix Passwords defines the Passwords for use in Come_In's built-in
FileFix. With the help of FileFix the indicated Nodes/Points can
subscribe to or cancel system FileEchos themselves. The Nodes/Points write
a Netmail to FileFix with the above defined Password in the Netmail
Subject Line and then they can order new FileEchos or just ask for a list
of available FileEchos. The use of FileFix, with the exception of the
Rescan Flag (which doesn't exist), is exactly the same as AreaFix.
What are FileEchos? - FileEchos are something like normal Areas, except
that Netmails aren't sent but real Files. Why?
because Nodes/Points have an easy possibility to
distribute files. This way, one is always
up-to-date as far as software is concerned.
Area Passwords and Passthrough Areas:
+----------------------------------------------+
| Edit Area |
| |
| Name : LOCAL____________ Days: 10_ |
| Path : \FIDO\MSGS\LOCAL_________________ |
| Origin : Hello Points. I'm new here.______ |
| Password: XYZ____ |
| |
| Nodes Pass through: O Cancel Ok |
+----------------------------------------------+
During Editing of Area, Nodes have to specify two additional items:
1. One can specify Passwords for every Area. This way you can protect
selected Areas from general access. Only Nodes/Points which know
the correct Password can subscribe to these Areas. Ordering a
Password protected Area is done using the normal Netmail to AreaFix,
where the extra line behind the AreaName is used for the Password
with a '!' prefix. For example: "Local !XYZ".
2. When one orders an Area, that isn't even read by the Node, but that
should be made available for Points then the 'Pass through' should be
clicked on. When 'Pass through' is set then the New/Unread Flags
won't be shown by LED. Only those Areas which you read yourself will
be selected when the '*' and '/' keys are pressed.
FileEchos:
+-----------------------------------------------------+
| Echos |
| |
| NODELIST |
| ECHOLIST |
| |
| |
| |
| |
| |
| |
| |
| |
| Del Add Insert Nodes <- -> Exit Save |
+-----------------------------------------------------+
Here the above mentioned Areas are maintained. One can Add new FileEchos,
Insert or Delete other FileEchos. Its usage should already be known.
You also need names for FileEchos, plus file paths and Passwords.
Note: The paths for FileEchos should be an existing Folder.
For every FileEcho, one must enter the connected Nodes, just like at the
Areas.
+-----------------------------------------------------+
| Nodes for FileEcho: NODELIST |
| |
| 2__:310_/12__.____ CIO__ ___:____/____.____ _____ |
| 2__:241_/5811.2___ HO___ ___:____/____.____ _____ |
| ___:____/____.____ _____ ___:____/____.____ _____ |
| ___:____/____.____ _____ ___:____/____.____ _____ |
| ___:____/____.____ _____ ___:____/____.____ _____ |
| |
| Cancel Ok |
+-----------------------------------------------------+
The corresponding Flags have to be entered for every Node. Just behind
the Node is a field for these Flags: 'Crash', 'Hold', 'In' and 'Out' can
be entered. The beginning letter of the Flag is used to indicate its
use or just click on the field with the mouse and a dialog box will be
displayed with these buttons which can then be selected.
Flags meanings:
Crash - When this Flag is switched on, then Files sent the connected
Nodes will be Crashed.
Hold - When this Flag is switched on, then Files to be sent to
picked up by the connected Nodes are put on Hold.
In - When this Flag is switched on, then Files sent by the
connected Nodes accepted when sent. This flag should be
set only for one Node of a Network so that Files won't be
received twice.
Out - When this Flag is switched on, Files for the connected Node
are sent out immediately. Otherwise only Netmail is sent
out and the Node has the possibility to request the File
is he is allowed to.
Command Line Parameters for the ACS Programs:
---------------------------------------------
Parameters for Come_In:
^^^^^^^^^^^^^^^^^^^^^^^
Command Line Description
-------------------------------------------------------------------------
-l An extract of the screen messages is written to the Log File
which is defined in BINKLEY.CFG.
-v Comprehensive information concerning Packet File is written
to the Log File.
-aARC.TTP x The Packer ARC.TTP should be used with the command 'x'.
-3 The Tickfiles which are sent together with regular Files
will use only 3D Addresses.
-k The packed Packets (*.mo0, *.tu0. etc.) are not deleted
after being imported and processed.
-f Before an Area is processed, the partition is checked for
enough room. If room is not available, the process is
cancelled.
-w Come_In waits for a 'key press' when finished.
-q No messages will be displayed on the screen.
Parameters for Tidy_Up:
^^^^^^^^^^^^^^^^^^^^^^^
Command Line Description
-------------------------------------------------------------------------
-dxx The number of days after which messages are automatically
deleted.
-hxx The minimum number of messages which should be left in an
Area. If the number of messages in an Area is less than
this number then the Area is skipped over.
-mxx The maximum xx Echos (during Scanning) to be create in
Netmail.
-aArea1 ... Only the indicated Areas plus those from the ECHOLIST file
are processed.
-l Refer to Come_In.
-v Refer to Come_In.
-s The Scan mode is turned on. New messages in the Areas are
made ready for export in Netmail.
-r Rescan mode is turned on. With rescan, already scanned
messages are made ready for export again. This is
important when old messages should be made available for
new Points.
-k Duplicate messages in an Area are deleted.
-e Refer to ExtraExpArea - This parameter says everything
anyway, doesn't it?
-c Just in case an eccentric clock shows the wrong date (2049
for example) Tidy_Up would is sure to remove all messages
because it would interpret them as being too old. If this
flag is turned on, then Tidy_Up checks to see if it has
been called within the last 10 days. If not, then a
message is displayed on the screen and Tidy_Up waits for
an answer.
-o A copy of Netmail is made before Tidy_Up starts processing.
-f Refer to Come_In.
-w Refer to Come_In.
-q Refer to Come_In.
Parameters for Go_Out:
^^^^^^^^^^^^^^^^^^^^^^
Command line Description
-------------------------------------------------------------------------
-d#|^ Refer to the "BinkleyTerm User's Guide". The characters
'#' or '^' are written to the corresponding Binkley-
Outbound-Flow-File to tell BinkleyTerm what to do with the
files after exporting them.
Using a '^' the files will be deleted.
Using a '#' the files will reduced to a length of zero.
Because the file name remains on disk, when using the
second method, the so-called FlowFile-Counter is activated.
File then exist with the ending *.MO0. After the next Poll,
then *.MO1, *.MO2, etc.
-aARC.TTP a This Parameter advises Go_Out to use the Packer ARC.TTP with
the command 'a'. If you set this Option, then Go_Out will
pack all the Mail with this Packer without making difference
if it should be ARC, LZH, etc.
-m[p]NODE This Parameter advises Go_Out to route all your Mail to this
NODE and use the Packer 'p' to pack the Mail before sending.
'p' should be: a for ARC, aj for ARJ, l for LZH,
zi for ZIP, zo for ZOO.
Example: -ma2:241/5811, -ml2:310/12 or unpacked -m2:244/1
-f[p]NODE This Parameter advises Go_Out to export only the Mail for
defined NODE if there exists some and use the Packer 'p'
to pack the Mail. This option is similar to -m, but it
doesn't route anything.
-h A NETMAIL.HDR is first renamed to to NETMAIL.OLD. Just in
case something happens the old Netmail structure can be
easily recreated.
-c When a Netmail is flagged 'Crash', its not routed like a
normal Netmail, its packed for direct transmission to the
addressee. If this flag isn't set on then the Crash Flag is
ignored.
-u Netmails won't be packed and are sent out as *.PKT files.
-rSCHEDULE Force Go_Out to use SCHEDULE as Schedulename. This way you
can define special Schedules in your Routefile which are
different to the normal ones used with numbers.
-n Force Go_Out to read the Nodelist. If you have something
in your Routefile which has to be executed even if there is
no Mail to export (like a POLL Statement) then set this Flag.
-s Go_Out creates a small Worklist in memory from NODELIST.DAT,
this means Go_Out has to process a little longer. When this
flag is turned on, the Worklist is saved to disk. The next
time Go_Out is called it just has to load the Worklist.
-e Refer to Tidy_Up.
-l Refer to Come_In.
-v Refer to Come_In.
-w Refer to Come_In.
-q Refer to Come_In.
