TICK v1.30
What is it?
Tick is a program which does for files what echomail does for
messages. It was largely inspired by the program "Flea", by Ron
Bemis. Tick picks up on that concept, and adds to it.
Using any ASCII editor, you set up a configuration file to tell
TICK about your system and to set up file echo areas. TICK then looks
in your inbound area for received TIC attaches, tosses them to the
echo-area directory you specify, appends the FILES.BBS in that area,
and optionally echos the files to other systems you specify. If your
BBS doesn't use a FILES.BBS, you can have TICK create a user-
customized file-list in the format you would like (so long as it's
ASCII). You can set up different areas for different file-echos, much
as you may have many echotags in echomail. In each file-echo area,
you may list up to 40 nodes to which you echo the files. The program
establishes passwords which are used to verify that the files you
receive are from the node you expect them to be from. You may also
specify which nodes in a file echo are allowed to send you files,
which may only receive files from you but not send them to you, or
which nodes may send you files but never receive them from you.
TICK will allow you to configure so that it creates FLO file at-
taches for mailers such as Binkley and Opus, which use them, or MSG
attaches for Seadog-type systems that use that kind of attach. This
second method is referred to as "FIDO" mode within TICK. When TICK
creates an attach, it sends both the desired file, and a small control
file which contains seenby and other information. The preferred in-
formation file is the TIC file, which is defined in FSC-0028. TICK
will also generate the FLE file format for communication with FLEA.
The choice of which file format to use may be made for each echoed
system, independently of other systems echoed. You may set TICK to
receive both TIC's and FLE's, or have it process only TIC's received.
The choice of which file format you send to other nodes is independent
of which file format you received with the original file.
Files are entered into an echo using the companion program HATCH.
HATCH uses the same configuration file as TICK.
If you are upgrading, please skip to "WHAT'S NEW" before reading
further. If you are setting up TICK for the first time, read on.
WHAT DOES IT DO
When TICK operates, it looks for inbound files with the extension
TIC (or FLE). These are "control" files which tell the program what
the name of the "real" file is, the echo area it is to go to, and what
systems have already seen the file. The information is checked
against the configuration file, and if passwords match and the area
exists, the file is tossed to the "destination directory" established
1
TICK v1.30
when the AREA was set up. (The file is moved to the destination direc-
tory by renaming it if it is possible, or by copying and deleting the
original if it is not possible). The FILES.BBS in that directory is
appended with the description (again, part of the TIC file). If there
are other nodes listed for that echo, TICK will then create new TICs
or FLEs for them, and will create FLO files to those nodes in the out-
bound. The FLOs will send the new TIC and the "real" file to the
other nodes. This does NOT happen if that node is already listed in
the seenby line of the original TIC.
TICK should be called in your batch file after receiving files.
It is designed so that you may redirect its output to the Binkley.log,
Opus.log, or to a log of its own. In the simplest form, the command
would look something like this:
TICK >> Binkley.Log
If running from a shell (not suggested), it would be preferable
to use a separate log to avoid problems of writing to a file which may
already be open.
THE CONFIGURATION FILE
Before TICK or HATCH can run, you will need to create a con-
figuration file to tell the program about your system, select optional
parameters, and to establish file-echo AREAS. Each AREA (you may have
many) is equivalent to a different echo area in echomail, and lists
the nodes that you receive from and send to. The addresses of the
nodes are zone aware.
The brackets indicate optional items, and should NOT be entered
in the real configuration file.
The format of the configuration file follows:
IN c:\file\inbound (This specifies the inbound area)
ZONE 1 c:\opus\outbound (This specifies the Outbound area)
(The FIRST Zone is the DEFAULT Zone)
ZONE 2 c:\opus\outbound.002
ZONE 3 c:\opus\out3 (Zones need not follow Binkley style)
NET 266 (Your Net)
NODE 12 (Your Node)
HOLD c:\holddir\ (Where outbound TICs and FLEs are kept)
QDIR c:\qdir (MUST be defined - not yet used)
2
TICK v1.30
[ListFmt %3:-13 %1] (Alters the default format of the FILES.BBS)
[ListName Files.Bbs] (Alters name and/or location of FILES.BBS)
[AKA 1:1/313] (Adds your AKA addresses to the Seenby lines)
[AKA 5:678/90]
[STOPDUP [c:\tickdir]] (Optional parameter, turns on Stopdup
feature - Specifies where DUP files
are to be kept)
[QUIET] (Optional - Stops beeping on fatal error)
AREA c:\file\ticktest TICKTEST
Local ListName c:\files\RBBS.LST
1:266/1 Passwrd1 [FLAGS] (Where flags = [*][&][F][C|H][An])
2:512/26 Pass2p
[TEMP c:\ramdisk] (Optional directory for temporary files)
[FIDO] (Send files as MSG attaches instead of FLO attaches)
[MAIL c:\netmail] ( Location of Netmail - Required if FIDO specified)
[FLEA] (If present, tells the program to also process
inbound FLE files)
[LOGPATH] (If present, log the PATH lines to the logfile)
[LOGSEEN] (If present, log SEENBY lines to the logfile)
[CRC] (Enable CRC testing)
[LogCRC] (Place copy of CRC in the log)
[Crc2Dup] (Place copy of CRC in the DUP file)
[NoWait] (Prevent HATCH's re-prompt for bad FILEname or AREAname)
The brackets indicate optional items, and should NOT be entered
in the real configuration file.
Now ... an item by item description:
3
TICK v1.30
IN c:\netfile This entry should point to the inbound files area.
Directory entries in the TIC configuration file may be entered
with or without trailing backslashes, and must reference an ex-
isting directory.
ZONE 1 c:\opus\outbound This specifies the Outbound area for zone 1.
TIC allows multiple zones in multiple outbound areas (Binkley
style). The ZONE line may be repeated for as many zones as you
are communicating with. THE FIRST ZONE STATEMENT MUST REFERENCE
YOUR OWN ZONE, and is used as the default zone when a control
file (TIC or FLE) does not contain a specified zone. The control
file must have at least one ZONE line.
ZONE 2 c:\opus\outbound.002 This tells the system where to place FLO
files for zone 2. Note that a directory must be declared for
each zone you plan to address, even if you run FIDO mode and
don't create FLO files.
ZONE 3 c:\opus\out3 The directory must be specified for each zone.
Tick does NOT assume that zones other than your own are named the
way they are done in Binkley.
NET 266 This line must contain your primary net number, and is re-
quired.
NODE 12 This line must contain your primary node number, and is
also required. (In a future release, I'll change this so you can
just specify your address as NET/NODE on the same line).
HOLD c:\holddir\ This specifies the location of the "HOLDing" direc-
tory. This is where the outbound TIC and FLE control files are
stored until your mailer sends them. It also will be used by fu-
ture TICK versions to hold other information as well. This
directory is maintained by TICK, and should not contain other
files. Know what you are doing before changing anything in this
directory.
QDIR c:\qdir This directory should be a separate directory and should
contain nothing. It is not yet used, but MUST be declared. It
will have a use in a future version of TICK.
[ListFmt %3:-13 %1] This optional entry allows you to alter the
default format of the "Files.BBS" file that TICK has always
created. The format may be compatible with TBBS, RBBS, and
nearly any other BBS that uses an ASCII file as a files list.
Additional description is below. The numbers shown in this ex-
ample are the default parameters used if you do NOT declare a
ListFmt.
4
TICK v1.30
[ListName Files.Bbs] Just as TICK may give you a different format for
the FILES.BBS, it is not restricted to the name "FILES.BBS". It
is possible to have it called by any legal dos filename. You may
locate the file in any directory, rather than the same directory
that the files go to, and you may specify that ALL descriptions
go to the SAME file is that's what you require. (See more
below).
[AKA 1:1/313]
[AKA 5:678/90] These entries direct TICK to add these nodes to the
Seenby list. It is now possible to establish a link with chosen
nodes using the AKA address instead of your main address. (See
more below.)
[STOPDUP c:\tickdir] This optional line, if present, activates a
function similar to the STOPDUP program I had written to help
limit duplicate files from being passed by Flea. What it does is
to keep a list of all filenames processed in each echo area.
Whenever a new file is received in an echo area, the filename is
compared to all names in the list. If that name has previously
been seen, the incoming TIC or FLE file has its extension renamed
to BAD, and the received file is ignored. If you later decide
that the file should be passed anyway, you may rename the BAD
file back to TIC or FLE, and delete the filename from the ap-
propriate ECHONAME.DUP file. The next time TICK is run, the file
will be passed. As implied above, when STOPDUP is specified,
TICK keeps a file in the specified (or default, if none is
specified) directory for each echo area you have set up. If the
echotag is "NODELIST", then the file name is "NODELIST.DUP".
[QUIET] If this is not present, TICK will beep should it need to
abort with a fatal error. Non-fatal errors will not cause a beep
in any case.
AREA c:\file\ticktest TICKTEST
Local ListName c:\files\RBBS.LST
1:266/1 Passwrd1 [*][F][&][[H][An] or [C]]
2:512/26 Pass2p
This structure is used to define the echo areas. It is
analogous to the AREAS.BBS used by confmail. For each echo, you
use the keyword AREA, followed by the directory, followed by the
echotag. The following lines are in the format shown above, con-
sisting of ZONE:NET/NODE PASSWORD FLAGs. There may be up to 40
such addresses lines present in each AREA. An AREA ends at the
first line NOT in the ADDRESS PASSWORD format, such as a blank
line. The exception is that lines beginning with the keyword
"LOCAL" do not end an area if they immediately follow the AREA
line. These LOCAL lines are used to establish special treatment
specific to that area only.
5
TICK v1.30
The password is the password used for that particular node,
and may be up to 8 characters. It is case insensitive. The
other node must specify the same password for your node in his
TIC.CFG file. The "*", if present, specifies that you will ac-
cept files coming from that node. If not present, you may send
files to that node, but will not accept them from him/her.
The "&", if present, tells TICK and HATCH to ignore that
node when sending files. Files are never sent to a node which
has the "&" flag. If combined with the "*" flag, that node be-
comes a "receive-only" node. You will accept file coming from
the node, but will NOT echo files TO it. If the "&" flag is
present but the "*" flag is NOT present, the node may neither
send nor receive from you, and is effectively commented out
without ending the area.
It is possible to tell TICK to generate CLO and HLO files
directly, or to generate FLO files as the default. The way this
is done is to append a "C" for crash or a "H" for hold as the
last token in the system you are connecting to. The "C" and "H"
are mutually exclusive. If you attempt to use them both in the
same line, TICK will issue a warning, and will treat the system
as a HOLD. If you are running in the FIDO mode, the MSG produced
should have the Crash or Hold bits set as appropriate. In the
Non-Fido mode, FLOs, CLOs, or HLOs are produced. The Address and
password are separated by whitespace, as are the password and
flag fields. The FCH*& flags are in any order, but are contained
in a single "word". They must NOT be separated from each other
by spaces.
The "F", if present, may be upper or lower case (as may be
the C or H), and specifies that you will send Flea compatible
files (FLE extension) to that node (instead of sending TIC
files). The format of the received file is irrelevant.
The "An" flag takes the form of the letter "A", followed im-
mediately by a single hex number ranging from "0" to "F". This
is used to designate that an AKA address is to be used in the
link to the node declared on this line. Further description is
below.
The AREA statement, as mentioned, may have up to 40 nodes
listed for each echo. You may repeat the AREA statement for as
many echos as you carry. The statement is considered to end at
the first line which is not in ZZ:NET/NODE PASSWORD form. (The
LOCAL lines are a partial exception to this rule).
6
TICK v1.30
[FLEA] This statement tells the program that it is also to process
any inbound FLE files as well as TIC files. The default is to
process only TIC format. (Again, you may SEND either format
regardless).
[TEMP] c:\ramdisk This allows you to specify where TICK will write
its temporary files. Choosing a ramdisk here will speed up the
processing. If this is not included in your CFG file, TICK will
use the default directory for your temporary files.
[FIDO] What this will do is to have TICK create MSG attaches rather
than FLO files. (See WARNING below!) This should then force
TICK to handle attaches to messages rather than creating FLO
files. The TIC's and FLE's are still placed in the outbound.
The code will try to put both file attaches in the same message
if there is room. If the combined length of the paths and
filenames exceed the 72 byte field allowed, two messages will be
created instead. The created messages will have the killsent
flag set, so that your mailer may kill the message once it is no
longer needed. I am assuming that whatever software you are run-
ning will respect the "killsent" flag and delete the MSG file
which "points to" the TIC of FLE in the outbound. What TICK does
is to find all MSG files which are file attaches, local, private,
have the killsent flag set, and are from "TICK .....". It takes
the subject lines from MSG's meeting these criteria, and writes
them to a temp file. It then looks at all TIC's and FLE's in the
outbound(s). Any which do not have an active MSG attach are con-
sidered "orphans" and are deleted.
WARNING: DO NOT RUN TICK IN THE FIDO MODE IF YOU HAVE ANY TIC'S OR
FLE'S IN THE OUTBOUND WHICH ARE "POINTED TO" BY FLO FILES.
TICK will find no MSG attach, assume that the TIC/FLE's are or-
phans, and delete them!
[MAIL c:\netmail] This entry is REQUIRED if you are running in the
FIDO mode. It allows TICK to find your netmail directory for
MSG's. If you do NOT use the FIDO mode, this entry is not
needed.
[LOGPATH] If present, path information (present in the TIC format
files) will be sent to your log file for future reference. This
is useful in determining topology. Also, since the time and date
that each system processed the file is included in the PATH, this
allows you to see how much delay was encountered on each leg of
the trip.
7
TICK v1.30
[LOGSEEN] If present, all seenby lines in the received TICs or FLEs
are also logged to the LOG file. This results in very large
logs, and is only intended for debugging and finding problems.
[CRC] Tick generates a CRC-32 on all files that it processes. If you
include CRC in your CFG file, the CRC in the inbound TIC file
will be compared to the one calculated. If they don't match, the
file will be failed.
[LogCRC] If this is in your CFG, the CRC-32 will be logged to the
logfile.
[Crc2Dup] This will cause the CRC-32 to be stored in the DUP file.
It doesn't do anything now, but might be useful in the future.
[NoWait] This prevents HATCH from looping back for new input when you
enter an incorrect FILEname or AREAname.
All lines other than the ZONE and AREA structure lines may be in
any order, and need not be left justified. Unknown lines are ignored.
Defining a FILES.BBS-type file
Thanks to a lot of help from Bob Hartman, TICK will support the
file-list format needed by many different BBS packages. If you don't
do anything special, the defaults will be to establish a file-list
file called "FILES.BBS" in each "toss-to" directory. (The "toss-to"
directory is the directory that is associated with an AREA, and to
which the received file is tossed).
* Bob Hartman has provided a great deal of the code to allow mul-
tiple formats of files.bbs files. Following is the description
provided by Bob. You can set the output format of the files.bbs file
by adding a line to your config file with the keyword "LISTFMT" fol-
lowed by the format you desire.
--------
Any character not proceeded by a % is just put into the string.
If the character is a %, then the stuff following it is interpreted as
follows:
y stands for the length of the field to use. If it is a negative
number, then it is meant to be left justified. A positive number is
right justified. If it does not appear, or is zero, then the field is
considered to be unlimited.
8
TICK v1.30
z stands for special processing. The first one defined was '1',
and it is used only in the file description for TBBS systems. It will
append a return and an exclamation point and then continue the
description. This is for TBBS 'linked comment' fields. 2 and 3 are
also now defined, and are described below.
%x[:y[.z]] (y = LENgth of field, z = "specification")
where x is 1-7 (or 100) and stands for:
1 - file description
2 - path to file with trailing backslash (that is correct
isn't it?)
3 - actual file name
4 - file size
5 - date as mm-dd-yy - There are changes here. If you
simply specify this as "%5", you will get the "file-
date". If you specify it like this: "%5:8.3", you
will get the SYSTEM date. This should be helpful for
RBBS boards, and others that need to list the date
received, rather than the file-date.
6 - Day-of-the-week - This will give you the day of the week
(spelled out fully) if you specify "%6". This is the
day the FILE was created. If you want only the first 3
characters (as in "Mon", "Tue", etc), then specify it
as "%6:3". If you want the SYSTEM day-of-week, then
specify it as "%6:3.3" for the 3 character string, or
as "%6:0.3" for the full string. (A length of "0" is
interpreted as an unlimited field).
7 - Hex CRC value for the file.
100 - See below.
So, for TBBS systems, the file should look like: full_path_name
file_name description(40 chars+linked comments) and the line format
would be:
%2%3 %3 %1:-40.1
For RBBS it would be
%3:-12%4:9 %5 %1:-43 001
where the 001 would be whatever file area they wanted to specify.
9
TICK v1.30
For Opus systems it would be:
%3:-13 %1
(which is the default if you don't set the ListFmt descriptor in
the CFG file.
Now for the really fun part! There is another value x can take.
The format %100:y.z is used to set up special wrapping for long com-
ment lines. Here is a portion of the description Bob sent me.
%100 is very new. It is used to set the indent and the first in-
dent character for overflow lines. The length parameter (after the
colon) gives the indent length, while the specification parameter
(after the period) gives the ASCII value for the first character of
the line. It is probably wise for people to make this the first thing
in their format string if they wish to use it (otherwise they may have
wrapped before it gets evaluated). For example, Opus systems might
want:
%100:1 This makes it a single space as indent (or)
%100:20 which would give a 20 character indent.
They can also do wild things like:
%100:20.45 which (I think) will output 20 spaces on the new
line, but after a '-' is put there first.
%100 comes into play whenever the specification type of a
parameter (the field after the period) is a 2. TBBS uses a 1, while
this new stuff uses a 2. I imagine that descriptions are the most
likely place for it to be used. TBBS needs two special characters for
the continuation line, so it cannot be done using the %100 instead.
Of course, this makes things VERY interesting, and very tricky. It is
easy for people to screw i up, so recommend that they experiment. It
is all automatic for TBBS systems, but for others, this hopefully
gives them the ability to do what they need.
One interesting sidenote. When using a length with either the
TBBS .1 or other style .2 specification, the length given is used on
ALL lines. For example, using %1:-40.1 as in a TBBS style line will
break the description into a 40 character block, add \n!> (tbbs
specific), then add the next 40 characters of the description (and
repeating if necessary), padded out with spaces if necessary! This
way things always remain in the correct columns if necessary. It
shouldn't matter. If people complain, then it might be able to
change it later on.
For Opus, try this: ListFmt %100:31%3:-12 %1:-48.2
10
TICK v1.30
That tells TICK to set indent at 31 spaces for wrap-around. The
first entry in the line is the filename (which starts flush against
the left, hence there is no space after the "31"). The filename field
is left justified, and occupies 12 characters. It is followed by a
space and then the DESCription, which is left justified, occupies 48
spaces, and will wrap to the next line inset by 31 spaces.
The wrap feature is not polished. It will wrap at the specified
length even if it comes in the middle of a word.
* You now have the option of having the file created called some-
thing other than "FILES.BBS", by using the keyword "ListName".
* The FileFmt and ListName may be different for each AREA if you
want. Here's how it all works:
If you do nothing, the programs will create FILES.BBS in the
"toss-to" directory as always.
If you add the keyword LISTNAME, followed by a "simple" (ie. -
without drive:\path\) filename, TICK and HATCH will use that filename
in each "toss-to" directory.
If you follow LISTNAME by a complete filespec, then the FILES.BBS
type file will be named what you want, and will also be created in the
specified directory, instead of the default of the "toss-to" direc-
tory. This would allow you to send *all* areas descriptions to the
*same* description file, as is done for RBBS.
Last ... If you follow LISTNAME with a drive:\path\ ONLY, you
will get the default "FILES.BBS" filename in the specified directory.
Here are some examples of LISTNAME:
LISTNAME RBBS.FIL - gives you a file called "RBBS.FIL" in each
"toss-to" directory.
LISTNAME C:\files\TBBS.TXT - This will give you a single file
named TBBS.TXT in the C:\files\ directory for all AREAs (unless over-
ridden by a LOCAL keyword - see below).
LISTNAME c:\foo\ - This will give you a single FILES.BBS in
directory c:\foo\ for all areas (unless overridden with a LOCAL).
You may, as before, choose an alternate line format with the
"ListFmt" keyword. The format you select serves as the default format
for any areas not overriding it with a LOCAL command.
11
TICK v1.30
Local Area Keywords
You may also have differing files.bbs-type filenames and direc-
tory locations for specific areas. You accomplish this by the "LOCAL"
keyword in the area definition.
AREAs were previously defined as the keyword "AREA", followed by
the "toss-to" directory, the AREA's tag, and the (optional) secondary
tag. This line was followed by one or more lines of "addresses -
passwords - flags". The area ended at the first line not in the stan-
dard "Address-PW-Flags" format. This format will still work, but you
may now have additional lines between the "AREA" line and the address
lines, transforming the AREA line into an area definition BLOCK, in-
stead of LINE.
The additional lines MUST begin with the keyword LOCAL.
NOTE: IF YOU HAVE ANY LINES (INCLUDING BLANK LINES) BETWEEN THE
"AREA" LINE AND THE ADDRESS LINES, AND THE LINES DO NOT BEGIN WITH THE
KEYWORD "LOCAL", THE AREA WILL END RIGHT THERE, AND NO NODES WILL BE
ASSOCIATED WITH THAT AREA!
After the "LOCAL" keyword, there are presently defined two pos-
sible keywords: LISTNAME, and LISTFMT. They are defined as described
above for the global defaults above. If you do not define a LOCAL for
a certain area, then that area defaults to the name or format defined
globally, or to FILES.BBS in the toss-to directory, and "%3:-13 %1"
for the format. Examples follow:
AREA c:\file\softdist SOFTDIST
LOCAL LISTNAME f:\farm\animal.bbs
LOCAL LISTFMT %3:-13 Hello there %1
1:266/21 password C*
2:261/662 hitom C
AREA c:\file\beans BEANS
LOCAL lISTNAME Foo.txt
7:26/67 whomi H
1:266/13 wham C*
The first example creates an area with 2 listed nodes. The
"files.bbs" for that area will be called "animal.bbs", and will be lo-
cated in the directory "f:\farm". The Line format will be the
filename in a left justified 13 character field, followed by the con-
stant text "Hello there", followed by the description text. The area
ends after the second node, because there is a blank line there.
12
TICK v1.30
The second area is tagged "BEANS". The "files.bbs" will be
called "Foo.txt", and will be located in the "toss-to" directory
called "c:\file\beans". The format will default to the format defined
in the global LISTFMT statement, or to "%3:-13 %1 if none has been
defined.
--------
CRC-32
CRC-32 checking is present in TICK/HATCH. All files processed by
either program will have the CRC computed and present in the outbound
TIC's. If you add the keyword "CRC" to your CFG file, then inbound
TIC's that have CRC's in them will have that CRC compared to the com-
puted CRC. If the numbers don't match, the file will fail. TIC's
received from older versions, having no CRC line, will be spared this
check, but outbound TIC's will still have the CRC line in either case.
One negative side effect of this is that significant time is required
to calculate the CRC. I feel that the added safety is worth it,
however.
If you would like the CRC value to appear in your log file, add
the keyword "LOGCRC" to your TIC.CFG. If you choose to log your
CRC's, the value in the log will be followed by a star (*) if the in-
bound file also had a CRC in the TIC.
If you want to also save the CRC in the *.DUP file after each
filename, add the keyword "CRC2DUP". Right now al this will do is
make your DUP files larger, but it might be useful for future develop-
ments.
Having the CRC compared to the CRC present in the inbound TIC can
cause problems in at least one situation. If you run a program like
STRIPZIP to eliminate potentially dangerous ASCII sequences from
received ZIP files, the CRC of the file you received will no longer
match the CRC in the TIC file. To get around this problem, there is a
(previously undocumented though present in the betas) command line
switch for this situation. What you do is to NOT define "CRC" in your
TIC.CFG file. When you receive new files, first run TICK with the
command line switch "/OC". That will cause TICK to test the un-
modified file's CRC against what is present in the TIC. (It also
tests for proper password, proper FROM address, etc.) If the CRC's do
not match, the TIC file is renamed to "*.BAD". If all is well, the
file is not further processed, and outbound TICs/FLEs are *not*
created. This mode is a "check-only" mode. After running TICK with
the /OC switch, you can then run STRIPZIP. After Stripzip, have the
batch file call TICK, this time *without* the /OC switch. Tick will
13
TICK v1.30
process normally, and will ignore the CRC in the inbound TIC's, since
you don't have CRC in the TIC.CFG. The new CRC generated in the out-
bound TIC's will be proper for the file as you are sending it.
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 ad-
dress 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 <C>rash,
<H>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 512/26 as 1/313, he must set up my node as 1/313 in his
TIC.CFG, and need NOT set up the dummy 266/12 as was previously re-
quired.
The number after the "A" must be a single character, and must not
be separated from the "A" by a space
14
TICK v1.30
USE CAUTION WITH SENDING TO OTHERS AS YOUR AKA! If not carefully
used, this will increase the likelyhood of a DUP ring. It's recom-
mended that AKA's only be used when crossing between zones at a desig-
nated "gate", which does not loop back into the first zone somewhere
else. Oh yes ... The limit on AKA's is 16 of 'em.
Finding the CFG file
The TICK program, and accompanying HATCH program should be placed
in any convenient directory. When run, both programs need to find the
configuration file. Tick / Hatch first looks to see if you have en-
tered the configuration file as a command line parameter. If you
choose this method, the following form applies:
TICK /Cc:\other.cfg
The "/C" may be upper or lower case.
If there is no command line parameter, TICK next looks to see if
you have set the environmental variable TIC as in:
TIC=C:\OTHER.CFG
Where C:\OTHER.CFG is the configuration file to be used this run.
If neither option is chosen, then the default is to use the file
TIC.CFG in the current directory. If no such file is available, TIC
aborts with a fatal error.
In addition to the CFG file, you should set the TZ environmental
variable to the difference between local time and GMT. This is the
same variable used by Opus and many other bbs-related programs. For
the Eastern time zone, it would be set to TZ=EST5EDT. In your batch
file, have the line:
SET TZ=EST5EDT
This variable is not needed for TICK to run; but if the time-
stamps in the PATH statement are to be meaningful, it should be set.
If it is NOT set, it defaults to the Pacific time zone. This was not
MY decision, but rather was the decision made by Microsoft when they
coded their comilper. When time-released versions of TICK become
available, it will be necessary to set this variable so that the
release time will be proper. WARNING: Bob Germer pointed out to me
that this form of TZ variable can cause problems for Opus, depending
on what version of DOS you run. If you experience problems with other
programs using this TZ string, you could use the form:
SET TZ=EST5
15
TICK v1.30
This will work for both TICK and Opus. Its disadvantage is that
you will need to change the "5" to "4" during daylight savings time.
The first format will give the correct results within TICK in standard
and in daylight time zones without the need to manually alter the
string. An alternative would be to set the EST5EDT format in your
batch file that calls TICK, and reset it to the EST5 format after TICK
has been run.
Tick and other file-echo software
The TIC file format should be compatible with the files produced
by Randall Greylock's UPCL program. TICK also offers support of the
FLE file created by Ron Bemis' FLEA. TICK does NOT currently provide
for time-released files as Flea 2.2 does, but will preserve the
release time information when acting as an intermediate between two
systems running Flea 2.2. Time release capability is planned for a
future release.
HATCH
Files are started into a file-echo with the program HATCH. HATCH
uses the same configuration file (see below) as TICK, and the CFG file
must be present for either program to run. File-echos are set up in
AREAs, each AREA having an echo tag, similar to the echotag in
echomail. An AREA name may be up to 8 characters, and must consist of
characters legal in a dos filename. You may have multiple AREAs (and
probably will). When you run HATCH, you need to tell it what AREA you
are hatching the file in, the file's name and location, and the
description to put in the FILES.BBS of the directory associated with
that AREA. This may be done interactively, or from the command line.
If you choose to use hatch interactively, as most do, just enter
HATCH (optionally followed by the CFG file to use, as in :
HATCH /cOTHER.CFG
Hatch will prompt you for the filename. HATCH prefers that the
file you HATCH to be in the "toss-to" directory associated with the
AREA at the time of hatching. If you MUST hatch from a directory nor-
mally NOt associated with that AREA, You will need to include the full
pathspec as in previous versions of HATCH. If you place the file in
the "toss-to" directory first, you need only give the filename when
you hatch.
If the file is not found, hatch will say so and abort. Othewise
it will prompt you for the AREA (file echo tag) you want to send the
file in, and the DESCRIPTION that will be placed in the FILES.BBS for
that file. It is recommended that the file to be hatched be located
16
TICK v1.30
in the "destination directory" normally associated with that AREA. If
it is NOT, it will still send the file just fine and the FILES.BBS
will be updated. However, your BBS will likely report that the file
is MISSING.
If you choose to enter all or some of the information from the
command line, there are 4 additional command line switches:
/A , /F, /ON, and /D.
The /A switch specifies the file-echo AREA to hatch into. The /F
switch specifies the file to hatch. The /D switch specifies the
description line to use for the FILES.BBS. Like the "/C", all the new
parameters are NOT separated from the switch-letter. Ie: The area
SOFTDIST would be written as /aSOFTDIST instead of /A SOFTDIST.
An example: To hatch the file FOO.ext in area SOFTDIST with the
description line "This is the Description", use the following line:
HATCH /aSOFTDIST /fFOO.ext /dThis is the description >> logfile.log
Any parameters NOT specified on the command line are prompted for
as before. If the /D description switch is used, it must be the last
switch on the command line, as it is of variable length and number of
tokens (words). The description may be up to 80 characters long, but
it is strongly recommended that the description be kept below 50
characters.
In conjunction with DAYNBR.ARC, this should make hatching of
nodediffs effortless and automatic with the proper batch.
The above example shows another design feature of TICK and HATCH.
Both are designed to allow redirection of output to a log file for
review of what has happened. The sign-on credits will go to the
screen, not the log. The log is formatted to match the form of the
Binkley and Opus logs. In fact, I use the same log for Binkley, Opus,
and Tick here. The ">>" redirects the log output as an append.
Hatch allows you to re-enter an incorrectly entered area or
filename. The AREA comes first, then the filename, then the descrip-
tion when running in the interactive mode. (The AREA *must* precede
the filename in interactive mode, since TICK needs to know where to
look for the file when you don't enter the path).
Having HATCH loop back for a file not present or a misspelled
area name could present problems for those of you who use batch
processing and don't want the hatch to "hang" looking for keyboard in-
put that is never coming. For this reason there is a "NOWAIT" option
available. Either put the keyword "NOWAIT" in the CFG file, or have
the batch call HATCH with the switch "/ON" (without the quotes. The
"O" stands for "Option", by the way.)
17
TICK v1.30
Command Line Switches
There are a number of command line switches that are useful. At
the present time these consist of /C /A /F /D /ON /OC. They are
defined as follows:
"/Cc:\subdir\other.CFG" This will define the file c:\subdir\other.cfg
as the CFG file to use for this run of TICK or HATCH.
"/Asoftdist" This tells HATCH that the AREA you are HATCHing into is
the area called SOFTDIST. It is ignored when used with TICK.
"/Fc:\utility.ext" This tells HATCH that the file you are HATCHing is
c:\utility.ext
"/DThis is a useful utility" This will set the DESCription to "This
is a useful utility". It is useful only with HATCH, and if used
must be the LAST switch on the command line.
"/ON" This switch tells HATCH to not loop back for corrected input
when it can't find the FILE or AREA you are HATCHing.
"/OC" Runds TICK in the "check mode". Errors will set the inbound
*.TIC to *.BAD, but no tossing or forwarding of files occurs.
Error Levels
Tick and Hatch exit with the following errorlevels if there is a
fatal error:
1 = Error reading a file
2 = Error Writing a file
3 = Out of Memory
4 = Invalid CFG file
5 = Invaild PATH or filespec
6 = Processing Error
WHAT'S NEW?
IF YOU ARE UPGRADING FROM AN EARLIER VERSION OF TICK, PLEASE READ
THIS SECTION CAREFULLY ... THIS VERSION MIGHT REQUIRE MODIFICATIONS TO
YOUR CONFIGURATION FILE AND BATCH FILES.
18
TICK v1.30
* DOCUMENTATION ERROR - Previous versions of TICK indicated that
the TZ environmental variable could be defined in the form: TZ=EST+05.
This may have been OK with earlier versions of MSC, but this form
creates errors when used with MSC 5.1. The correct method is shown
above.
* Corrects a bug where an area defined with only one node, and
that node bearing the "*" and "&" flags, would result in the file
being properly tossed but the inbound TIC not being deleted.
* Added code to do a simple test to see if the AREA directory you
are about to toss to happens to be the same as the IN directory you
are tossing from. In such a case, the file may be deleted for good.
Now, TICK will abort with a errorlevel 4 fatal error and indicate why.
This is a simple-minded test, which will not detect SUBSTituted direc-
tories, but should help protect new users from shooting themselves in
the foot.
* Fixed a bug where a received FLE file with a pre-release date
would not maintain the pre-release time in the echoed FLE's and TIC's,
and would alter a random memory location in the data segment.
* Fixed a bug that might have allowed a non-starred node to send
you a file under certain rare circumstances.
* The definition of a QDIR directory in the CFG file is now a re-
quirement. So far, this doesn't do anything, but will be important in
a future release. Just point it to an empty directory that won't be
used for anything else. Be aware that if you need to do a RESTORE on
your disk, you might need to re-create the QDIR directory, as some
backup/restore programs fail to restore empty directories.
* There is a slight change in the way that the new TIC and FLE
files are named. They will still have the same general format, but
the nameing will occur faster than the previous 1 per second if your
machine is fast enough.
* TICK now supports variable formats of the FILES.BBS type file.
You may have different formats for each area, send ALL areas to a
single FILES.BBS file, or use names other than "FILES.BBS" if it fits
your purpose.
* Fixed bug in which a a received TIC or FLE would be renamed to
".BAD" instead of being deleted if there were no systems to send the
file to (all systems already listed in the Seenbys).
* Tick will now indicate the original AREA of a received file in
the log.
19
TICK v1.30
* Tick/Hatch can now display to the screen and to the log file at
the same time. There is a new keyword "SCREENLOG". If this keyword
is present in the TIC.CFG, TICK will send the log to the screen, as
well as to whatever you are re-directing output to. If you are NOT
keeping a log by redirecting TICK's output, then do NOT use this
keyword, or you will get double (nearly) everything on the screen.
* NOTE: HATCH now prefers the file you HATCH to be in the
"toss-to" directory associated with the AREA at the time of hatching.
If you MUST hatch from a directory normally NOt associated with that
AREA, You will need to include the full pathspec as in previous ver-
sions of HATCH. If you place the file in the "toss-to" directory
first, you need only give the filename when you hatch.
* TICK now attempts to use a larger buffer when copying files.
This should dramatically improve speed when you are moving a large
file to a different logical drive.
* The timestamp in the path created by TICK now is consistent
with the timestamp in the path line created by HATCH.
* CRC-32 checking is now in TICK/HATCH.
* HATCH will now not allow you to attempt to send a directory
name or volume label as a file.
* Hatch will now allow you to re-enter an incorrectly entered
area or filename. The AREA comes first, then the filename, then the
description when running in the interactive mode. (The AREA now
*must* precede the filename in interactive mode, since TICK needs to
know where to look for the file when you don't enter the path).
* Fixed the faulty informational message that was generated when
all listed systems had already seen the file.
* Have implemented a form of AKA's into the program.
* Fixed an incorrect memory allocation of the AREA address list
structure. You may now have 40 nodes per area, instead of 39.
(Nobody noticed this, so I imagine that nobody is sending to that many
nodes in a single area).
* Fixed HATCH so that if you are re-directing output to a log
file, you still see the prompts when necessary.
* Tick will now display the faulty path when there is a bad path
specified for an AREA.
* TICK now does some additional testing of its temporary files to
try to determine if you have run out of disk space on the TEMP drive
when writing them. I believe that this is the cause of the infamous
20
TICK v1.30
26 byte TIC's that a certain nameless individual likes to send around
to see if we are paying attention. :-) It won't catch EVERY case, as
there is one out of 512 times that the file will have self-flushed ex-
actly at the last byte of the final fprintf.
Parting Comments
I hope you find this utility useful. Tick may be used in any
non-commercial environment free of licensing charges. It may be
freely distributed so long as there is no charge for it and it is dis-
tributed only in the original archive.
There is NO warranty with this product, and I assume no
responsibility for any damages it might do to your system, nor any
consequential damages.
In other words, you assume all risks should you decide to use it.
It is working well on my system, and on the systems of those brave
sysops who have helped me beta test it.
I want to thank George Peace (1:13/13), Jeff Myers (1:266/13),
Bob Germer (1:266/21) , Don Dawson (1:141/730), Randall Greylock
(1:321/202), Mike Fuchs (1:266/71), Tom Hendricks (1:261/662), and
many others for their assistance in testing.
Special thanks go to Bob Hartman (1:132/101), for sending code to
allow us all those wonderful variations on the FILES.BBS-type file.
I'm certaint that those of you who run a BBS that can't use a
FILES.BBS are especially grateful as well.
I also would like to thank Jeff Nonken (1:103/322) for the code
which allows the paths set in the environment to end either with or
without a backslash, Scott Dudley (1:148/314) for help with the com-
mand line parser, and Jim Nutt for the MSG structure I used in im-
plementing the "Seadog-type" file attaches.
I should also mention that Binkley is a trademark of Spark
Software/Bit Bucket Software, Flea is a trademark of Ron Bemis, Opus
is trademarked by Wynn Wagner,III, and Seadog is a trademark of SEA
(System Enhancement Associates). (If I spelled any of these
wrong or got any of these credits wrong, I'm certain someone will
tell me sooner or later.) Other names mentioned may be trademarked by
their respective owners.
Barry Geller
Maple Shade Opus
1:266/12
609-482-8609
21