home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 2 BBS
/
02-BBS.zip
/
RAIDP100.LZH
/
RAID_100.DOC
next >
Wrap
Text File
|
1990-01-01
|
70KB
|
2,043 lines
Raid version 1.00
January 1, 1990
Copyright 1989 by George Peace -- All Rights Reserved
RAID is a companion utility for Barry Geller's
TICK program. It offers facilities for command-
line and NetMail driven maintenance of the Tick
operating environment.
"Tick without Raid is like watchmaking
without a sledgehammer"
-- Unclaimed
Raid v1.00 January 1, 1990
The Disclaimer
This software is not guaranteed to do anything except take up space on
your computer's disk. Any benefit you might derive from use of this
software is welcome but not implied by its release. The author of this
software shall not be held responsible for any damages, either
directly or indirectly, from its use. This software must not be sold.
If it is repackaged for distribution, all original files must be
included. No additional files may be included and original files may
not be modified.
Contents
What Is Raid, Anyway?................................................4
Manual Mode..........................................................5
Command Line Switches..............................................5
FIND...............................................................6
ADD................................................................7
DELETE.............................................................8
NOTIFY.............................................................9
Response Mode.......................................................10
NetMail Processing in Response Mode...............................11
NetMail Message Format.........................................11
Processing Security Levels........................................13
Response mode off..............................................14
Inquiry only...................................................14
Updates enabled................................................14
The Configuration File..............................................15
Access to RAID.CFG................................................15
Configuration Directives..........................................16
Address........................................................16
Sysop..........................................................17
Tick...........................................................17
Log............................................................17
NetMail........................................................17
NotifyPrefix...................................................18
InfoFile.......................................................18
Alias..........................................................18
Def_Password...................................................19
Def_Flags......................................................19
Access.........................................................19
Area...........................................................20
AreaDefault....................................................21
HideArea.......................................................21
WildCard.......................................................22
NotifyExclude..................................................22
NotifyThreshold................................................22
NotifyMinimum..................................................22
Copyright 1989 by George Peace - All rights reserved page 2
Raid v1.00 January 1, 1990
NotifyMaximum..................................................23
PointNet.......................................................23
NotifyBehavior.................................................23
NetMailBehavior................................................24
KillReceived...................................................24
Changing the Tick control file appearance......................24
TidyNodes....................................................25
Controlling the Available Area List............................25
AreasPerLine.................................................25
Available....................................................26
NotifyAvailable..............................................26
Active_Marker................................................27
Priv_Marker_Left.............................................27
Priv_Marker_Right............................................27
The Log File........................................................28
MS-DOS Errorlevels Returned.........................................30
Other Topics........................................................31
Release Information...............................................31
A Few Words About Raid and Zones..................................31
Trouble Reports and Support.......................................32
Testing Raid......................................................32
Copyright 1989 by George Peace - All rights reserved page 3
Raid v1.00 January 1, 1990
What Is Raid, Anyway?
Raid is a utility intended to complement Barry Geller's Tick program.
It offers both manual and automated maintenance capabilities for the
Tick control file (typically TIC.CFG). Raid accepts commands from the
command line (manual mode) and from remotely entered NetMail (response
mode).
Manual mode operations consist of...
FIND - search the Tick control file for connections matching a
requested network address.
ADD - insert a network address in an existing AREA block
DELETE - remove a network address from an AREA block
NOTIFY - generate NetMail connection notification messages to all
or selected network addresses.
Response mode operations are...
QUERY - locate requestor's network address in Tick control file
and report connections
ADD - insert or update a connection for requestor's network
address
DELETE - remove a connection for requestor's network address
Use of Raid is closely linked to Tick. Familiarity with Tick operation
and its control file is necessary for successful operation of Raid.
Copyright 1989 by George Peace - All rights reserved page 4
Raid v1.00 January 1, 1990
Manual Mode
The Raid command line offers access to the Tick control file
maintenance functions most frequently required by System Operators.
These functions are performed in Raid's manual mode. Day to day
changes can all be made directly from the command line.
'Switches' in the following command descriptions, though shown as '-
switch', can be entered as '/switch'. Switches can be upper or lower
case.
Command Line Switches
These command line switches are recognized for all manual mode Raid
executions...
-Cd:\directory\file.ext
This optional switch forces Raid to point to the Raid
configuration file identified. This switch overrides the
default search sequence. If the file identified by the
switch cannot be located the program will not continue.
-Ld:\directory\file.ext or
-L
This optional dual action switch changes the default log
file destination. -L by itself turns off all log file
activity. -L followed by any filespec overrides the log file
destination from that identified by the "Log" configuration
file directive to d:directory\file.ext. If the log file
defined by this switch cannot be accessed the program will
continue without a log file.
-Mx
This optional switch causes NetMail responses to be sent to
network address z:net/node as provided on the Raid command
line. The optional modifier 'x' can be C (crash), D
(direct), H (hold) and K (kill/sent) to override NetMail
behavior defined in the configuration file.
-Td:\directory\file.ext
This optional switch forces Raid to point to the Tick
control file identified. This switch overrides the filename
defined by the "Tick" configuration directive in Raid.Cfg
(see page 15). If the file identified by the switch cannot
be located the program will not continue.
Copyright 1989 by George Peace - All rights reserved page 5
Raid v1.00 January 1, 1990
FIND
This function does a 'sliding' search for the network address string
provided on the command line. Raid searches all entries in all AREA
blocks in the Tick control file for the network address (or partial
network address) provided on the command line. 'Finds' are listed to
the screen. When no network address is provided on the command line.
all entries in all AREA blocks are reported. If the -M command line
switch is present z:net/node must be an exact match. Whenever -M is
present a NetMail message will be generated to z:net/node.
RAID FIND <-switch ...> z:net/node
switch: -C, -L, -M, and -T (see page 5)
z:net/node This parameter defines the search argument for the find.
In local mode (-M not present) any area block entry
containing the address field string represented by the
z:net/node (or a partial address) is displayed. If omitted,
all entries in all area blocks will be displayed.
Examples: RAID FIND 1:999/999 -m
locates all occurrences of network address 1:999/999 in the
Tick control file and sends the resulting list to address
1:999/999.
RAID FIND 1:999/
locates all zone 1, net 999 addresses in the Tick control
file. NetMail is not generated.
RAID FIND
lists all connections for all AREA blocks in the Tick
configuration file. NetMail is not generated.
Copyright 1989 by George Peace - All rights reserved page 6
Raid v1.00 January 1, 1990
ADD
This function updates the Tick control file by adding one or more
areas for distribution to a network address. An ADD request for an
existing connection is treated as an UPDATE request, allowing password
and flag changes to existing connections.
RAID ADD <-switch ...> z:net/node area-1 ... area-n
RAID ADD <-switch ...> z:net/node ALL
switch: -C, -L, -M, and -T (see page 5)
-Fflags
This optional switch overrides flags field definitions in
the Raid configuration file. "flags" will be added to any
area block additions made. No editing is done on the field.
If -F is not provided, the flags for all connections added
will be determined by "access" or "def_password"
configuration file directives.
-Ppassword
This optional switch forces <password> to be used for all
area block additions made. This overrides the any password
definitions in the Raid configuration file. If -P is not
provided, the password for all connections added will be
determined by "access" or "def_password" configuration file
directives.
z:net/node This parameter defines the network address for the add
operation. All areas added by this Raid execution will match
this address exactly.
area This is the (required) list of one or several area blocks.
z:net/node is added to each of the area names. If an area
name does not exist that area is omitted and the remaining
area names are processed.
ALL This is the 'wild card' area name. If included as one of or
the only area name z:net/node will be added to all area
blocks defined in the Tick control file. The "wildcard"
configuration file directive can be used to redefine the
wildcard.
Examples: RAID ADD 1:999/999 SOFTDIST SDSRBBS SDSBINK
adds network address 1:999/999 to area blocks SOFTDIST,
SDSRBBS, and SDSBINK in the Tick control file.
RAID ADD 1:999/999 ALL -M
adds network address 1:999/999 to all area blocks defined in
the Tick control file. The results are sent to network
address 1:999/999.
Copyright 1989 by George Peace - All rights reserved page 7
Raid v1.00 January 1, 1990
DELETE
This function updates the Tick control file by deleting one or several
areas from distribution to a network address.
RAID DELETE <-switch ...> z:net/node area-1 ... area-n
RAID DELETE <-switch ...> z:net/node ALL
switch: -C, -L, -M, and -T (see page 5)
-O
This optional switch forces an override of strict z:net/node
matching for delete requests. In this case all network
addresses in the Tick control file containing the partial
z:net/node address will be deleted. -O and -M cannot be used
in combination.
z:net/node This parameter defines the network address for the delete
operation. All areas deleted by this Raid execution will
match this address.
area This is the (required) list of one or several area blocks.
z:net/node is deleted from each of the area names. If an
area name does not exist that area is omitted and the
remaining area names are processed.
ALL This is the 'wild card' area name. If included as one of or
the only area name z:net/node will be deleted from all area
blocks defined in the Tick control file. The "wildcard"
configuration file directive can be used to redefine the
wildcard.
Examples: RAID DELETE 1:999/999 SOFTDIST SDSRBBS SDSBINK
deletes network address 1:999/999 from area blocks SOFTDIST,
SDSRBBS, and SDSBINK in the Tick control file.
RAID DELETE 1:999/999 ALL -M
deletes network address 1:999/999 from all area blocks
defined in the Tick control file. The results are sent to
network address 1:999/999.
RAID DELETE 1:999/ ALL -O
deletes all connections for all zone 1, net 999 network
addresses from the Tick control file.
Copyright 1989 by George Peace - All rights reserved page 8
Raid v1.00 January 1, 1990
NOTIFY
This function triggers an automatic "FIND" operation for all (global)
network address with connections in effect in the Tick control file or
for a list of network addresses (directed). Network addresses can be
excluded from the global notify operation by using the "NotifyExclude"
configuration directive.
RAID NOTIFY <-switch ...> <z:net/node ... z:net/node>
switch: -C, -L, and -T (see page 5)
-Mx
This optional switch can be used to override the configured
behavior of connection status notification NetMail messages.
Modifier 'x' can be C (crash), D (direct), or H (hold) and K
(kill/sent). This value overrides the default message
behavior defined in the configuration file for all
addresses.
The notify process searches for a text file defined by the
"notifyprefix" configuration directive before generating messages.
That file, if found, is copied into the body of each notification
message as introductory text. The file is transferred directly with no
attempt to format, translate or validate its contents other than to
delete the trailing control Z (^Z) if present. File size and content
must conform to NetMail processing software restrictions and
limitations. If "notifyprefix" is not defined or the file cannot be
opened a default introduction will be used.
The -M directive can be used to control the outbound behavior of
notification NetMail messages. Absence of the -M switch results in use
of the flags (C, D, H or N) defined on "access" or "def_flags"
configuration directives. If an "access" directive exists for a
network address the value in the "mail" field will be used to
determine outbound behavior for that address. If that field is missing
the C or H (or their absence) from the directive's "flags" field will
determine the behavior. If no "access" directive exists for the
network address, the C, D, or H (or no flag) defined by the
"def_flags" configuration directive will determine the behavior of the
message.
If a list of network addresses is provided Raid will generate
connection notification messages for each address provided. All
configuration file checks for excluding ("NotifyExclude" and skipping
("NotifyThreshold", "NotifyMinimum", and "NotifyMaximum") will be
bypassed. Up to 100 addresses can be provided for the directed mode
notify..
Copyright 1989 by George Peace - All rights reserved page 9
Raid v1.00 January 1, 1990
Response Mode
Response mode offers remote users the convenience of making inquiries
and connection updates to the Tick control file without directly
involving the distribution site System Operator. Remote operations can
be disabled or engaged to whatever extent necessary for secure
operation of the distribution site. Password access and multiple
security privilege levels are supported.
Response mode is activated by the program call:
RAID -Rx <-switch ...>
This call will typically be used in a batch file on the distribution
system following the mail import operation. The -R switch triggers
Raid to scan the NetMail message area for messages addressed to "Raid"
or an alias defined by the "alias" configuration directive. The
optional modifier 'x' can be C (crash), D (direct), H (hold) and K
(kill/sent). This will unconditionally override behavior flags defined
in the Raid configuration file for response messages generated by
Raid.
Additional switch values recognized in response mode are...
switch: -Cd:\directory\file.ext
This optional switch forces Raid to point to the Raid
configuration file identified.
-Fflags
This optional switch overrides flags field definitions in
the Raid configuration file. "flags" will be added to any
area block additions requested. No editing is done on the
field. If -F is not provided, the flags for all connections
added will be determined by "access" configuration file
directives.
-Ppassword
This optional switch forces <password> to be used for all
area block additions made. This overrides any password
definitions in the Raid configuration file. In this case the
"access" directive password will be used only for initial
security validation. If -P is not provided, the password for
all connections added will be determined by "access"
configuration file directives.
-Ld:\directory\file.ext or
-L
This optional dual action switch changes the default log
file destination. -L by itself turns off all log file
activity. -L followed by any filespec overrides the log file
destination from that identified by the "log" configuration
file directive to d:directory\file.ext.
Copyright 1989 by George Peace - All rights reserved page 10
Raid v1.00 January 1, 1990
-Td:\directory\file.ext
This optional switch forces Raid to point to the Tick
control file identified. This switch overrides the filename
defined by the "Tick" configuration directive. If the file
identified by the switch cannot be located the program will
not continue.
NetMail Processing in Response Mode
In order for Raid to process a NetMail message on the distribution
system several conditions must be satisfied:
- The Raid configuration file "netmail" directive must be present
and must point to the distribution system NetMail message
directory.
- The message must be addressed to the zone:net/node of the
distribution system as determined by the "address" configuration
directives.
- The message must be addressed To: RAID (exactly 4 characters,
case-insensitive) or any alias defined by "alias" configuration
directives.
- The LOCAL and RECEIVED message attributes must both be clear (not
set) to prevent Raid from processing its own outbound messages
(local attribute set) or processing inbound messages more than
once. Raid sets the received attribute when it processes an
inbound message.
Once these conditions are met Raid continues processing the netmail
message. Security will be validated and a response generated according
to the processing level in effect for the requesting address. If
security requirements are satisfied, each line in the message body is
interpreted and processed as an individual add/delete request. Once
all lines in the message body have been processed Raid will list area
connections for the requesting network address and display all area
names available on the distribution system.
NetMail Message Format
NetMail messages addressed to Raid can be created by any FidoNet
compatible message editor. A typical Response mode request might be:
Copyright 1989 by George Peace - All rights reserved page 11
Raid v1.00 January 1, 1990
To: Raid (1:270/101)
From: Sysop (1:987/654)
Subj: Mypasswd -I -Q
Attr: privileged
------------------------------------------
DAZZLE
-SWIZZLE
---
Raid uses several message components to validate and process the
request.
To: Raid processes NetMail messages addressed To: Raid or to any
one-word alias defined by the "alias" configuration
directive. In addition, the To: network address must match
the zone:net/node defined by one of the "address"
configuration directives. If no INTL kludge line exists in
the message body Raid assumes the To: zone is the same as
the primary "address" zone. If an INTL kludge line is
located the destination address from that line is used as
the To: zone:net/node.
From: Raid checks the net/node portion of the from field for
access validation. If an "access" configuration directive
does not exist for the address the request is rejected. The
name portion of the from field is not used for validation.
That field is used only to create the response. Kludge lines
(INTL and MSGID) in the message body always override the
From: network address.
Subj: This field defines the security validation password as well
as request flags from the requestor. The first "word", which
must be eight characters or less, must match the password
field on the "access" configuration directive corresponding
to the From: network address. Case is ignored. The request
flags are:
-I (information) requests Raid to file-attach an information
file to the NetMail response if the request passes security
validation. The file is defined by the "raidinfo"
configuration directive.
-Q (query) requests Raid to add descriptions to the list of
file echo areas available on the distribution system. The
descriptions are provided on "area" configuration
directives. See the section titled "Controlling the
Available Area Display" for additional information.
Attr: If either the "local" and "received" flag is set Raid will
ignore the request. The "local" flag is always set on
NetMail generated locally and so could not be a valid Raid
remote request. The "received" flag is set by Raid when
after it completes security validation but before it
processes the message body.
Copyright 1989 by George Peace - All rights reserved page 12
Raid v1.00 January 1, 1990
Body: The message body defines the list of file echo areas to be
added, deleted, and updated in the Tick control file. Each
area request must begin a new line.
The message body scan ends when it finds a blank line or a
"tear line" (a line beginning with three dashes)
If the message body contains an ^AINTL or ^AMSGID: line the
originating network address from that line will replace the
From: network address for validation and processing. In
addition, the ^AINTL destination address will replace the
To: network address.
Processing Security Levels
Response mode is activated at one of three processing levels for each
network address connected to the distribution site:
Response mode off
Inquiry only
Updates enabled
Response mode access privileges are determined by the existence and
content of "access" and "area" directives in the Raid configuration
file. This file and the directives are described in another section.
Copyright 1989 by George Peace - All rights reserved page 13
Raid v1.00 January 1, 1990
Response mode off
This is the "default" mode for Raid. Only manual requests (command
line operation) are executed. All remote NetMail requests are declined
with an appropriate response to the requestor. This mode is determined
by a lack of network address "access" definitions in the Raid
configuration file. This mode is intended to allow the distribution
system SysOp to decline all remote requests or to screen remote
requests before applying them manually.
Inquiry only
Inquiry only mode is triggered when the security levels defined on all
"access" configuration directives are lower than the levels defined on
all "area" directives. This results from the fact that the "area"
security level must be equal to or lower than "access" security level
for updates to be accepted. In this case NetMail messages addressed to
RAID will be processed as inquiries since add/delete access will be
denied. If security requirements are met Raid will respond with a list
of area connections and optionally -- see the "available"
configuration directive -- list of areas available on the distribution
system.
Updates enabled
Update mode is determined on a node by node basis according to the
"access" directive security level. Once security requirements are met
Raid will process the NetMail message body. Each line is processed as
a separate request to add an area connection to or delete one from the
Tick control file on the distribution system. Each "area" security
level is compared to the network address's "access" security level. If
the "access" level is equal to or higher than the "area level the
request is processed.
Copyright 1989 by George Peace - All rights reserved page 14
Raid v1.00 January 1, 1990
The Configuration File
The Raid configuration file (RAID.CFG) provides the distribution
system operator the flexibility and power to direct Raid operation
according to individual processing requirements:
- Location of all files and directories necessary for Raid
operation on the distribution system
- Inquiry and update capabilities for individual network addresses
- Access levels for file areas
- Default Tic.Cfg password and flag fields for additions
- Control of NetMail message behavior (Crash / Direct / Hold /
KillSent)
- Definition of text to accompany connection status notification
messages
- Definition of the wildcard "all areas" operator
- Options to control information provided in Raid NetMail responses
- Zone and point and support
Access to RAID.CFG
Raid offers flexibility in Raid.Cfg location and access. Raid will
search several locations in sequence in order to locate the
configuration file.
- The file and directory defined by the RAID environment variable:
(SET RAID=d:\direct\file.ext)
- The current directory
- RAID.CFG in the directory defined by the BBS environment variable
- RAID.CFG in the directory defined by the MAIL environment
variable
- RAID.CFG anywhere in the program search PATH
- If the configuration file search is not successful Raid execution
will not continue.
The configuration file location can be overridden with the command
line -C switch. See page 5 for -C definition.
Copyright 1989 by George Peace - All rights reserved page 15
Raid v1.00 January 1, 1990
Configuration Directives
The following paragraphs describe configuration directives available
in RAID.CFG. Additional information and examples of configuration
directive use are available in the sample RAID.CFG provided in the
Raid distribution package. All directives are described in four parts
-- Directive name; description and usage nodes; Default value if the
directive is not provided; and At least one example. The only REQUIRED
directive is ADDRESS. All others are optional according to features
and parameters you need to customize Raid to your unique requirements.
Unused and optional commands can be "commented out" in Raid.Cfg.
Comment lines (beginning with ; or * or %) can be removed for a slight
performance improvement.
Address
Defines the network addresses of the distribution system. At least one
address directive must be provided. Additional addresses (akas) can be
defined by providing multiple "address" directives. Full zone:net/node
syntax is required.
The first address directive MUST be the primary net address. That
address will be used on all NetMail generated in manual node (except
as noted elsewhere). That address will also be used in response mode
replies in multiple zone situations requiring different zones for
NetMail routing.
Response mode operation in multiple zones is defined through this
directive. Response mode NetMail requests can be addressed to any of
the addresses defined. Though not required for successful operation in
a multiple zone environment, best results will be achieved if INTL or
MSGID kludge lines are included in NetMail addressed to Raid.
An additional optional field is available for assignment of an "aka"
to response mode ADD requests. A single hexadecimal digit added to an
address definition will force Raid to append A<hexdigit> to the flags
field of area distribution lines ADDed in response mode. If an aka is
already defined by "access" or "def_flags" directives the field is
ignored. Please see the Tick documentation for use and implications of
akas.
Default: no default available -- REQUIRED
Example: ADDRESS 1:270/101
ADDRESS 2:123/456
ADDRESS 1:2/1
ADDRESS 1:1/2
Copyright 1989 by George Peace - All rights reserved page 16
Raid v1.00 January 1, 1990
Sysop
Defines your name for NetMail messages generated by Raid in manual
mode. This directive simply "personalizes" NetMail you direct Raid to
generate rather than using the default Raid id. Response mode NetMail
replies always use the Raid id rather than the System Operator name.
Default: Raid v#.##
Example: SYSOP George Peace
Tick
Defines the path and filename for the Tick control file. If this
directive is not provided Raid looks for TIC.CFG in the current
directory. The -T command line switch overrides this directive. See
page 5 for -T definition.
Default: TIC.CFG in the default directory or as identified by the -T
command line switch.
Example: TICK C:\BBS\TIC.CFG
Log
Defines the path and filename for the Raid log file. If This directive
is not provided Raid updates RAID.LOG in the current directory. The
command line -L switch overrides this directive. If Raid cannot read
or update the log file (whether defined in Raid.Cfg or -L) execution
proceeds without a log file. See page 5 for -L definition.
Default: RAID.LOG in the default directory
Example: LOG C:\BBS\RAID.LOG
LOG NUL
NetMail
Defines the path for the NetMail message area. This directive must be
provided if Raid will be operated in response mode or if NetMail is
generated in manual mode (NOTIFY and -M command line switch). The path
can terminate with or without backslash (\).
Default: no default available
Copyright 1989 by George Peace - All rights reserved page 17
Raid v1.00 January 1, 1990
Example: NETMAIL C:\MSG\NETMAIL
NotifyPrefix
Defines the file to be transferred to the body of each status
notification (notify) NetMail message. This descriptive text message
is displayed as the introductory text in all connection status
notification messages. This message might describe your file
distribution setup and provide instructions for remote access to
Raid's response mode. An example RAIDNOTE.TXT is provided with the
Raid release.
Default: RAIDNOTE.TXT in the default directory
Example: NOTIFYPREFIX C:\BBS\RAIDNOTE.TXT
InfoFile
This file will be file-attached to a response mode NetMail reply
message if the remote requestor included the -I (information request)
modifier after the access password on the message subject line. If the
filename contains wildcard characters (* ?) the first filename
matching the specification will be attached. If the INFOFILE directive
is not provided or no matching filename is found -I requests will be
ignored.
Default: none -- -I on remote requests is disabled
Example: INFOFILE C:\BBS\INFOFILE.TXT
INFOFILE C:\BBS\RAIDINFO.???
Alias
Defines names Raid will recognize in addition to "Raid" in the To:
field of incoming NetMail messages. Each "alias" must be a single word
up to 32 characters in length with no embedded punctuation, blanks, or
tabs. Case is ignored. Up to 100 "alias" directives can be defined.
Default: none
Example ALIAS TICKFIX
ALIAS TICK
ALIAS FIXTICK
Copyright 1989 by George Peace - All rights reserved page 18
Raid v1.00 January 1, 1990
Def_Password
Defines the default password to be used for manual add requests (add)
when no "access" definition exists for the target network address. The
password value can be any password string accepted by Tick. The -P
command line switch overrides this directive (and the access
password). The password length is limited to a maximum of eight
characters.
Default: PASSWORD
Example: DEF_PASSWORD PassWord
Def_Flags
Defines the default flags to be used for manual add requests when no
"access" definition exists for the target network address. The flags
value can be any string accepted by Tick. This will also determine the
routing behavior of NetMail generated as a result of manual
find/add/delete requests when no "access" definition exists for the
target network address. "C" forces crash or express priority, "D"
forces direct delivery (where supported via packer software) and "H"
forces the message to be held for pickup. If neither is present in the
default flags field generated messages will be flagged for "normal"
routing. "NetMailBehavior" and "NotifyBehavior" directives as well as
the command line -M switch override the "Def_Flags" C and H settings.
Default: none
Example: DEF_FLAGS *H
Access
Defines all security access and control parameters for a network
address. Access directives must be present for any network addresss
accessing Raid remotely. The directives are optional for other network
addresses but will enable increased control and ensure consistent
manual operations if provided. Up to 500 network addresses can be
defined.
All "access" fields are "positional". As a result, all fields to the
left of any field specified are necessary for proper use. For example,
if you want to use the sysop entry the mail and flags fields are also
required.
The required net address field specifies the full network address. It
must be in zone:net/node format.
Copyright 1989 by George Peace - All rights reserved page 19
Raid v1.00 January 1, 1990
The required password entry is the password a remote requestor must
use as the NetMail subject for security validation. It is also the
default password for manual and remote ADD requests unless overridden
by a remote request or the command line -P switch.
The required security level entry is used to define update
capabilities for the network address. A value of 0 disables remote
updates but allows inquiries if other security requirements are
satisfied. The field is also used by the manual mode NOTIFY function
in order to list accessible area names.
The optional flags entry is used to build connection entries generated
by manual and remote ADD requests unless overridden by the command
line -F switch. If the field is blank, the value defined by the
DEF_FLAGS directive will be used. If a blank flags field is required
you can use a single period (.) as in the third example below. Raid
will interpret the period as a blank field. The period also satisfies
the "positional" field requirement in cases where the mail and/or
sysop fields are provided and the flags field must be blank.
The optional mail entry defines the outbound behavior of any NetMail
Raid generates to a network address. Allowable values are C (Crash or
Express delivery), D (Direct routing), H (Hold for pickup) and N
(Normal routing as defined by the packer and mailer). The mail value
can be overridden by the -Mx and -Rx command line switches. If the
mail value is omitted, the flags field contents (or "def_flags")
determines outbound NetMail behavior.
The optional system operator field allows Raid to "personalize"
netmail generated to a network address by Raid. NetMail message format
limitations require that only first 36 characters be used.
Default: none
Example:
net address password level flags mail sysop
----------- -------- ----- ----- ---- -----
Access 1:13/0 Password 4095 *C N George Peace
Access 1:270/102 Password 10 H H
Access 99:999/999 PassWord 1 . C Who Are You?
Area
Defines the response mode access security level for a Tick area block.
Up to 500 areas can be defined.
Copyright 1989 by George Peace - All rights reserved page 20
Raid v1.00 January 1, 1990
The required security level field identifies the lowest network
address "Access" security level able to add itself for distribution of
this file area. A value of 0 defines the area for "unrestricted"
access. The area security level is not used for response mode delete
requests. All file areas not explicitly defined with "Area" directives
are assigned the security level provided on the "AreaDefault"
directive.
The optional description field describes the contents or purpose of
the file area. Remote callers who include the -Q modifier after the
password on the message subject line will receive a specially
formatted "available areas" display that includes this description.
Only the first 60 characters are used. See the section titled
"Controlling the Available Area Display" for additional information.
Default: none
Example:
areaname level Description
-------- ----- ---------1---------2---------3---------4-
Area DAZZLE 200 Distribution of DAZZLE software
Area SWIZZLE 100 Software to stir a crowd
AreaDefault
Defines the default area access security level for Tick area blocks
not explicitly defined by "Area" directives. A value of 0 defines an
area for "unrestricted" access.
Default: 0
Example: AREADEFAULT 20
HideArea
Defines the lowest file "area" security level to hide from remote
requestors. Any area defined with a security level equal to or higher
than "hidearea" will not be displayed in the list of available areas
in NetMail response messages. This offers protection for "private"
areas that are accessible only by special arrangement but would
otherwise be visible to all requestors.
Default: none
Example: HIDEAREA 1000
Copyright 1989 by George Peace - All rights reserved page 21
Raid v1.00 January 1, 1990
WildCard
Defines the "process all file areas" literal for manual mode add and
delete requests. The wildcard literal is not accepted in response mode
NetMail update requests.
Default: ALL
Example: WILDCARD WORLD
NotifyExclude
Defines individual network addresses (z:net/node format) to exclude
from connection status notification mass mailings (RAID NOTIFY). Each
occurrence of the directive excludes one address. Up to 500 addresses
can be excluded.
Default: none
Example: NOTIFYEXCLUDE 1:13/0
NOTIFYEXCLUDE 2:123/456
NotifyThreshold
Network addresses must have at least this number of active area
connections in TIC.CFG to be included in a normal notify operation
(RAID NOTIFY). The default value of one excludes all network addresses
with no active connections listed.
Default: 1
Example: NOTIFYTHRESHOLD 0
NotifyMinimum
Specifies the lowest "access" security level that will be processed by
notify requests. Any network address with a lower "access" security
level will be bypassed. The default value of zero implies that all
addresses listed in TIC.CFG that pass other tests will receive
notification messages. Any other value causes notification messages to
be generated only for network addresses with "access" directives
because the default security level without "access" is zero.
Default: 0
Copyright 1989 by George Peace - All rights reserved page 22
Raid v1.00 January 1, 1990
Example: NOTIFYMINIMUM 10
NotifyMaximum
Specifies the highest "access" security level that will be processed
by "notify" requests. Any network address with a higher "access"
security level will be bypassed.
Default: 4095
Example: NOTIFYMAXIMUM 999
PointNet
Defines the private point network number assigned to the distribution
system. If PointNet is configured (and not zero) and response mode
requests are received from one of the distribution system's points the
"pointnet" network will be used for access validation and add/delete
requests. Traffic from a point is defined as netmail both from and to
the distribution system network address with "^AFMPT #" in the message
body. As a result, "yourzone:pointnet/pointnumber" will be used for
remote update requests from your points.
Default: none
Example: POINTNET 30000
NotifyBehavior
Sets the default behavior of NetMail generated by the Notify command.
Values accepted are C (crash priority), D (direct routing), or H (hold
for pickup) and K (kill message when sent).
The "K" value can be used in combination with "C" or "D" or "H" to
cause all Notify NetMail messages to be deleted after being sent. It
has the same function and meaning as the -MK command line switch (RAID
-MK NOTIFY).
The "C", "D", and "H" values take precedence over C, D, and H mail
values assigned by "Access" configuration directives (only for NetMail
generation). Both "Access" flags and "NotifyBehavior" flags will be
overridden by command line switch -MC, -MD, or -MH.
Copyright 1989 by George Peace - All rights reserved page 23
Raid v1.00 January 1, 1990
Be careful! Unless you are local to all your connections,
"NOTIFYHEHAVIOR C" can be expensive.
Default: none
Example: NOTIFYBEHAVIOR K
NetMailBehavior
Sets the default behavior of NetMail generated in "response mode" and
in "manual mode" with the -M command line switch. Values accepted are
C (crash priority), D (direct routing), or H (hold for pickup) and K
(kill message when sent).
The "K" value can be used in combination with "C" or "D" or "H" to
cause all non-Notify NetMail messages to be deleted after being sent.
It has the same function and meaning as the -MK command line switch
(RAID -MK <request...>).
The "C", "D", and "H" values take precedence over C, D, and H flag
values assigned by "Access" configuration directives (only for NetMail
generation). Both "Access" flags and "NetMailBehavior" flags will be
overridden by command line switch -MC, -MD, or -MH.
Be careful! Unless you are local to all your connections,
"NETMAILBEHAVIOR C" can be expensive.
Default: none
Example: NETMAILBEHAVIOR KH
KillReceived
Causes all Response mode NetMail requests to be deleted from the
NetMail message area after being processed by Raid.
Default: NO
Example: KILLRECEIVED YES
Changing the Tick control file appearance
The appearance of the Tick control file can be adjusted with this
directive. The directive will direct Raid to write the control file in
different formats following update operations.
Copyright 1989 by George Peace - All rights reserved page 24
Raid v1.00 January 1, 1990
TidyNodes
Activates a "tidying up" of the Tick control file when it is written
back to disk following update operations. All active address lines in
all AREA blocks in the Tick control file will be aligned vertically on
16 character boundaries.
An area block like this:
AREA C:\FILES FILEAREA
1:123/456 PassWord *H
2:123/654 PASSWORD HA2
will look like this after tidying:
AREA C:\FILES FILEAREA
1:123/456 PassWord *H
2:123/654 PASSWORD HA2
Default: none
Example: TIDYNODES
Controlling the Available Area List
Several directives are available to control the available area list
Raid appends to NetMail response messages. The display width, amount
of information, and special notation characters can all be defined.
The available area list can displayed in either short or long format.
"Short" format simply lists area names with active and protection
indicators. Multiple area names are displayed on one line. "Long"
format is always exactly one area per line. The first 60 characters of
"area" directive description data is displayed following the area
name.
AreasPerLine
Defines the number of area names to display per line when reporting
available areas in short format. Each area name requires 12 character
positions so the maximum practical value for an 80 column line width
is 6 (12 x 6 = 72). Higher values (up to 4095) can e defined for a
"wrap" effect.
Default: 5
Example: AREASPERLINE 4
Copyright 1989 by George Peace - All rights reserved page 25
Raid v1.00 January 1, 1990
Available
Provides control of the available area display format in NetMail
response messages (except NOTIFY function messages). Six variations
are available ranging from no display to unconditionally providing
long format displays.
- NEVER Unconditionally disable the available area
display. The -Q request modifier is ignored.
- NORMAL Display a short format available area list unless
the remote requestor used the -Q request modifier. Display the
long format list if -Q was used.
- REQUEST SHORT Disable the available area display unless the
remote requestor used the -Q request modifier. Display the short
format area list if -Q was used.
- REQUEST LONG Disable the available area display unless the
remote requestor used the -Q request modifier. Display the long
format area list if -Q was used.
- ALWAYS SHORT Ignore the -Q request modifier and always display
the short format area list.
- ALWAYS LONG Ignore the -Q request modifier and always display
the long format area list.
Default: NORMAL
Example: AVAILABLE ALWAYS LONG
AVAILABLE NEVER
NotifyAvailable
Provides control of the available area display format in NetMail
messages generated by the NOTIFY function. Three variations are
available.
- NEVER Unconditionally disable the available area
display. The -Q request modifier is ignored.
- ALWAYS SHORT Always display the short format area list.
- ALWAYS LONG Always display the long format area list.
Default: ALWAYS SHORT
Example: NOTIFYAVAILABLE ALWAYS LONG
NOTIFYAVAILABLE NEVER
Copyright 1989 by George Peace - All rights reserved page 26
Raid v1.00 January 1, 1990
Active_Marker
Defines the character used to mark "active" file echo area names in
the available areas summary displayed in NetMail messages.
Default: *
Example: ACTIVE_MARKER $
Priv_Marker_Left
Defines the character used to offset the left end of restricted or
private file echo area names displayed in the available areas list
appended to all Raid NetMail messages.
Default: <
Example: PRIV_MARKER_LEFT {
Priv_Marker_Right
Defines the character used to offset the right end of restricted or
private file echo area names displayed in the available areas list
appended to all Raid NetMail messages.
Default: >
Example: PRIV_MARKER_RIGHT }
Copyright 1989 by George Peace - All rights reserved page 27
Raid v1.00 January 1, 1990
The Log File
Raid maintains an audit trail of every significant operation performed
and error encountered. Redundant and trivial log entries are avoided
in order to keep the log file size to a minimum. This speeds up log
file data reduction and reduces disk storage overhead.
The log file defaults to a name of RAID.LOG in the default directory
(where you were when you executed Raid). The command line -L switch
can be used to change the log destination or to eliminate it
entirely...
-Ld:\directory\file.ext
This format overrides the log file destination defined in
the "log" configuration directive to d:\directory\file.ext.
-L
This format disables all log file activity. The same effect
(with slightly higher execution time overhead) can be
achieved by defining NUL as the logfile destination on the
"log" configuration directive.
If Raid cannot write to the log file for any reason the program will
disable all log file activity as if -L was present on the command
line.
Raid appends new entries to the log file and terminates the file with
a control Z (^Z) after each session.
Log entries are formatted similarly to those generated by Opus,
BinkleyTerm, and Tick as:
20 Oct 23:42:49 RAID <data to be logged>
Errors will be logged with an exclamation point in column one and a
text explaining the error in the data area.
Normal Raid operation log entries will consist of a unique six
character keyword followed by additional information as required.
Keywords and data fields include:
ADDREQ zone:net/node area password flags
Zone:net/node was added to area with password and flags.
ADDNOF zone:net/node area password
Zone:net/node was not added because area was not located.
DELREQ zone:net/node area password flags
Zone:net/node was deleted from area.
Copyright 1989 by George Peace - All rights reserved page 28
Raid v1.00 January 1, 1990
DELNOF zone:net/node area
Zone:net/node was not active in area.
NETRPL zone:net/node behavior
A NetMail reply was generated to zone:net/node with the indicated
NetMail behavior.
NETREQ zone:net/node password
A response mode NetMail message was received from zone:net/node
using the indicated access password.
NETREP zone:net/node password
A response mode NetMail message was received from zone:net/node
(point) using the indicated access password.
NETNOF zone:net/node password
Zone:net/node was not found in the "access" table.
NETSEC zone:net/node password security
Zone:net/node was found in the "access" table and was not
authorized to use response mode.
NETPAS zone:net/node password
The access password used by zone:net/node was not valid.
NOTIFY zone:net/node behavior
A connection notification NetMail message was generated for
zone:net/node with the indicated NetMail behavior.
Copyright 1989 by George Peace - All rights reserved page 29
Raid v1.00 January 1, 1990
MS-DOS Errorlevels Returned
In addition to information provided in its log file, Raid sets the MS-
DOS errorlevel to one of several values.
0 No updates to the TICK control file and no NetMail messages
generated with -M switch set.
1 NetMail was generated in RESPONSE mode or in command line mode
with the -M switch set.
5 An error was encountered reading the TICK control file.
Processing is terminated without applying updates.
6 An error was encountered writing the updated TICK control file.
Processing is terminated without applying updates.
7 A critical error occurred renaming the temporary (updated) TICK
control file to overlay the actual file. Though this error should
be extremely rare, it will require immediate attention if it
occurs since the original Tick control file has been renamed to
TIC.OLD (or d:\filename.OLD as provided by the command line -C
switch).
8 An error has occurred accessing the NetMail directory for read or
write. This includes failure to locate the directory as defined
in TIC.CFG (MAIL directive) and errors reading and writing
NetMail messages in that directory.
9 At least one fatal error was encountered while processing the
Raid configuration file.
10 Raid ran out of available memory to store data from its own
configuration file or data from the Tick control file. Either
reduce the amount of optional configuration data or obtain a
"large capacity" version of Raid. RAIDBIG is available via file
request from 1:270/101.
99 Miscellaneous errors causing Raid to terminate prematurely. As
with the other error conditions, Raid will not apply updates.
Copyright 1989 by George Peace - All rights reserved page 30
Raid v1.00 January 1, 1990
Other Topics
Release Information
Public releases of Raid will always be "whole" numbers such as 1.00,
2.00, etc. Intermediate test and special function releases will always
be "fractional" such as 1.02, 2.20, etc.
The latest public release of Raid will always be requestable at
1:270/101 as RAID.
1.00 January 1, 1990
This is the initial public release. Happy New Year!
A Few Words About Raid and Zones
Zone support within Raid doesn't pretend to be all-knowing or entirely
without fault. Raid does attempt to be zone-smart rather than merely
zone-aware. But there are a few things that technical standards and
some current message packers will just not let us do.
If you select a non-(N)ormal outbound behavior value -- (C)rash or
(D)irect or (H)old -- your packer might not transfer mail for another
zone to that zone's outbound area. That may be because the packer /
router acts only on Normal mail (.OUT files).
NetMail response messages generated by Raid must contain a ^AINTL
"kludge" line when origin and destination zones differ. That is
because there are no standard fields in .MSG headers to support zone
information. Be careful though. Your packer / router might not
recognize the kludge line and so might not route the message to the
correct zone as it converts the .MSG to a .?UT.
All this contributes to problems with inter-zonal Raid response
message routing and delivery. Some folks necessarily want Raid
response NetMail to take different paths than EchoMail for security of
password data. Simply setting a non-(N)ormal response behavior might
not be the solution. Instead, a special routing "schedule" might be
required for the packer / router to adjust response message behavior
and flow. The Raid exit errorlevels can help with that process. Raid
will always exit with errorlevel 1 if NetMail was generated. As a
result, something like this might work...
Copyright 1989 by George Peace - All rights reserved page 31
Raid v1.00 January 1, 1990
RAID -R
IF ERRORLEVEL 2 GOTO FINISH
IF ERRORLEVEL 1 GOTO REPACK
IF ERRORLEVEL 0 GOTO FINISH
REPACK:
COMMAND /C MASH REPROCESS_RAID_MAIL
FINISH:
The "reprocess_raid_mail" schedule might include packer / router
directives to change the mail behavior to Normal and to route it
directly to its intended destination.
Trouble Reports and Support
Assistance with use of public releases of Raid will be provided as
time and phone bill permit. If you take time to document and report a
bug by netmail (1:270/101 717-657-2223) I'll take time to research the
trouble and offer a workaround or a fix. I can't promise immediate
turnaround or a reply to every NetMail but I can assure you I'll pay
attention to your comments and reports.
No dedicated message conference exists for Raid support and
information exchange. As a result, I hope you'll help me to minimize
Raid help desk activities in International conferences where
moderators restrict topic or volume of data. Thank you.
Testing Raid
The Raid Beta Test Team is a generous group of folks who dare to
operate unstable development versions of Raid on their systems. My hat
is off to each and every one of them. Raid wouldn't be what it is
today without their reports and friendly advice <grin>.
If you have the qualities we're looking for (daring, BBS fanatic, and
a little silly) you too can join the Team. Drop me a note at 1:270/101
(717-657-2223) if you're interested. Or search out the RAIDBETA
message conference and file echo area in a region near you.
Thanks for your support.
Copyright 1989 by George Peace - All rights reserved page 32