1480 lines
53 KiB
Plaintext
1480 lines
53 KiB
Plaintext
\input defs
|
|
\input fontsize
|
|
\input errata.sty
|
|
\input output
|
|
|
|
\raggedright
|
|
\hfuzz=2pt
|
|
%\advance\baselineskip-.50pt
|
|
%\advance\parskip-.50pt
|
|
|
|
\def\tty{\vskip\parskip\tt\obeylines\parskip=0pt}
|
|
|
|
\footline={\hfil\hl\folio\hfil}
|
|
|
|
\centerline{\hl Changes \& Enhancements not in the Book}
|
|
\vskip\parskip
|
|
\centerline{\fido\ version 12s}
|
|
\centerline{1 May, 1990}
|
|
\vskip\parskip
|
|
\centerline{Fido Software, Box 77731, San Francisco CA 94107}
|
|
\line{\hfill voice: 415-764-1688\hfill data: 415-764-1629\hfill}
|
|
|
|
\skip
|
|
\bar
|
|
\begindoublecolumns
|
|
|
|
\subheading{New Commands}
|
|
|
|
The Fido commands defined in COMMANDS.INI have been rearranged�
|
|
and enhanced. A new one is included on the diskette. If you had�
|
|
set custom privilege levels and locks (P= and L=) you will need�
|
|
to make these changes yourself to the new file.
|
|
|
|
If you forget to replace COMMANDS.INI, SET-FIDO will remind you.
|
|
|
|
\subheading{Replying and Quoting}
|
|
|
|
A new major feature has been added to Fido; ``message quoting''�
|
|
when entering or replying to messages. The feature consists of a�
|
|
new Message Section command, a new command in the message editor,�
|
|
and enhancements to two existing message editor commands.
|
|
|
|
It works like this: while you are reading messages, you may find�
|
|
one that you want to reply to that has a number of points within�
|
|
it you want to address in your reply. Instead of taking notes,�
|
|
with the new W)rite-Buffer command (below) simply take a snapshot�
|
|
of the message. At any time before you disconnect, you can enter�
|
|
a new message, and read that snapshot into your message, where�
|
|
you can delete any parts that you don't want, which has been made�
|
|
a lot easier with the message editor enhancements.
|
|
|
|
Be warned: it is very easy to overuse message quoting, and�
|
|
generate huge and hard to read messages. A little goes a long�
|
|
way.
|
|
|
|
The edit buffer is a disk file named MSG.BUF; if the command line�
|
|
switch /I is used, the filename is modified in the same way as�
|
|
the log files.
|
|
|
|
\subheading{New Message Section Command}
|
|
|
|
A new command has been added to the Message Section:
|
|
W)rite-Buffer. It saves a copy of the message you just read into�
|
|
the newly-coined ``edit buffer''. There is only one buffer, so�
|
|
only the most recent use of the W)rite-Buffer command is�
|
|
remembered. The contents of the Edit Buffer is cleared when a new�
|
|
caller connects; it is not preserved from one caller to the next.
|
|
|
|
The end result of this is that when replying to a message, you�
|
|
can include the original author's message as reference. The�
|
|
R)ead-Buffer command lets you ``quote'' each line with a ``{\tt�
|
|
>}'' character to make quoted lines stand out.
|
|
|
|
For callers privilege 4 and above, the W)rite-Buffer command�
|
|
asks:
|
|
|
|
\example{File to write to [CR=Buffer]:}
|
|
|
|
Allowing you to save messages in a file you specify instead of�
|
|
the default buffer file. In this case, subsequent writes are�
|
|
appended to the file, letting you collect messages about a�
|
|
certain subject into a file.
|
|
|
|
\subheading{Message Editor Enhancements}
|
|
|
|
New command added: R)ead-Buffer. This reads the contents of the�
|
|
Edit Buffer into your message, as if you had typed it manually.�
|
|
It asks two questions:
|
|
|
|
\example{Prefix each line with ``>''? (y,N):}
|
|
\example{Force word-wrap on paragraphs? (y,N):}
|
|
|
|
The first option lets you make the words of another person you�
|
|
are quoting stand out. The second is unfortunate, and is meant to�
|
|
help you compensate for messages generated by programs that do�
|
|
not properly support standard ``word wrap'' file format. First�
|
|
try it without it; if paragraphs look terrible (ie. a series of�
|
|
long lines followed by a short line, over and over) then delete�
|
|
the lines and try again with ``force word-wrap'' YES.
|
|
|
|
Because R)ead-Buffer reads in the entire edit buffer, you will�
|
|
need to delete the lines you don't want; see the D)elete-Line�
|
|
enhancement, below.
|
|
|
|
If you are privilege 4 or higher, R)ead-Buffer asks you an�
|
|
additional question:
|
|
|
|
\example{File to read from [CR=Buffer]:}
|
|
|
|
It will accept any valid pathname. The file better be a text�
|
|
file. Many uses come to mind -- canned answers for common�
|
|
questions, etc.
|
|
|
|
|
|
\subheading{Additional Editor Changes}
|
|
|
|
Besides the R)ead-Buffer command addition, two very old commands�
|
|
in the message editor have been radically improved.
|
|
|
|
D)elete-Line, which lets you delete a line from your message, now�
|
|
accepts a ``range'' of line numbers, with which you can delete�
|
|
many lines at once. Previously, if you wanted to delete (for�
|
|
example) lines 5 through 16, you had to enter ``D 5'' 12 times;�
|
|
now you can do it with a single ``D 5-16'' command.
|
|
|
|
I)nsert-Line was limited to inserting a single line in your�
|
|
existing text, too limited to be of much use. I)nsert-Line is now�
|
|
a true text-insert command; starting at the line number you�
|
|
specify, text is entered until you enter a blank line, as in�
|
|
normal text entry. Lines below your insertion point are ``moved�
|
|
down'' to make room for the inserted text.
|
|
|
|
\subheading{C)hange Sub-commands}
|
|
|
|
|
|
Within the C)hange command submenu
|
|
|
|
Changes: Screen W)idth and L)ength have been renamed C)olumns and�
|
|
L)ines; the little-used T)abs command removed in favor of always�
|
|
expanding tabs; M)ore command removed in favor of setting L)ines�
|
|
to 0. The interim G)raphics was removed.
|
|
|
|
Additions: I)nterface command. It is the so-far promised�
|
|
language/graphics interface. Please refer to the ``Language''�
|
|
section of this errata sheet for details. Please note that the�
|
|
default privilege for this command is very high; if you use�
|
|
additional languages or graphic interfaces you will want to lower�
|
|
it.
|
|
|
|
|
|
\subheading{New Main Section Command}
|
|
T)riggers are manual controls over event execution. You can�
|
|
assign triggers to events defined in EVENTS.INI; you can put the�
|
|
same trigger on any number of events. Events without triggers are�
|
|
always on, just as they are in previous versions.
|
|
|
|
There are 8 triggers, which can have one of three possible�
|
|
settings: OFF, which means what it says; the trigger and any�
|
|
events that use it are disabled. ON allows that event to run when�
|
|
it's time comes. ONCE does also what it sounds like; after the�
|
|
event runs successfully, the trigger is turned OFF. This allows�
|
|
you to setup an event to run one time only, without having to�
|
|
remember to turn the event OFF after running it.
|
|
|
|
Triggers are placed on events when you define them in EVENTS.INI:
|
|
|
|
\example{All 9:00 360 FidoNet M\ \ \ \ \ \ T=4}
|
|
|
|
This event has trigger \#4; that trigger must be ON or ONCE for�
|
|
that event to run when the time becomes 9:00AM. An example would�
|
|
be a special FidoNet event that sends mail to any system in the�
|
|
nodelist directly, for high priority mail, which you would enable�
|
|
with a trigger set to ONCE.
|
|
|
|
The T)riggers command lists events for you to help you see what�
|
|
you are doing.
|
|
|
|
\section{Multi-Line Fido Installations}
|
|
|
|
There is now a way to run different modems on each of the�
|
|
different systems; See the new FIDO.INI option, {\tt system-path}.
|
|
Thanks go to Ken Ganshirt for this one.
|
|
|
|
It was never mentioned before, but \fido\ does file locking on�
|
|
CALLER.SYS, the caller file -- and does up to ten retries to open�
|
|
it successfully. So you never have to worry about losing caller�
|
|
data.
|
|
|
|
For two-line Fidos, under DoubleDOS, DESQview, etc, you can now�
|
|
run both ``sides'' completely from within one ``FIDO''�
|
|
subdirectory. Events and areas can be assigned to only one�
|
|
``task'', by a new option in AREAS.INI and EVENTS.INI, to allow�
|
|
controlling which side executes what event, and additionally have�
|
|
message and file areas unique to a task.
|
|
|
|
Each systems task ID is the nnnn/I command line option; referring�
|
|
to the manual, the /I number is the ``task ID'' that makes each�
|
|
side unique, and makes Fido create unique logfiles, and handle�
|
|
message areas slightly differently.
|
|
|
|
For example, you have a two line Fido running, with sides�
|
|
numbered 1 and 2 (1/I and 2/I). The two systems are identical to�
|
|
the user, and you want to have only one side run FidoNet mail.�
|
|
The following example would do just that:
|
|
|
|
\skip
|
|
{\tty
|
|
quick\ rush all\ \ 2:00\ 60\ \ \ FidoNet\ A\ \ \ \ ID=1
|
|
\ \ \ \ \ \ \ \ all\ \ 0:00\ 1440 \ Page
|
|
}
|
|
|
|
The first event is assigned to side 1 only; under no�
|
|
circumstances will side 2 ever execute that event. The second�
|
|
event, a Page event, is shared; it has no ID number and therefore�
|
|
is common to both.
|
|
|
|
You should limit FidoNet events to only one side, when sharing a�
|
|
netmail area; all other event types can be shared without a�
|
|
problem.
|
|
|
|
Message and file areas can be assigned to each side in an�
|
|
identical manner. The other side will not be able to access the�
|
|
other sides areas. Areas without an ID= statement are shared by�
|
|
both sides.
|
|
|
|
{\skip\tty
|
|
msgarea= msg\quad D=``Messages''\quad O=FidoNet ID=1
|
|
filearea= inbound U=outbound\quad D=``Files'' O=FidoNet ID=2
|
|
}
|
|
|
|
\subheading{Options in AREAS.INI}
|
|
|
|
Please note that in early versions (and in the Book) Fido let you�
|
|
specify options by the first character only; ``O=F'' was�
|
|
equivelant to ``O=FidoNet'', and so on. I hope you weren't too�
|
|
cheap with your typing -- as Fido now requires at least the first�
|
|
two characters now. This wasn't an arbitrary decision just to�
|
|
torment you -- the addition of the ``O=Private'' -- as opposed to�
|
|
the existing ``O=Public'' -- made this necessary. Sorry! SET-FIDO�
|
|
will inform you of your previous stinginess if necessary.
|
|
|
|
\example{O=ReadOnly}
|
|
|
|
Messages cannot be entered in this area, except by privilege�
|
|
level 7 (system operator).
|
|
|
|
\example{O=Private}
|
|
|
|
All messages entered in this area will be marked {\tt(PRIVATE)}.�
|
|
This helps those who run BBSs that may have marginal message�
|
|
contents; snoopy types simply cannot see anything, so you don't�
|
|
have to worry about getting caught.
|
|
|
|
\example{O=Shared}
|
|
|
|
Indicates to Fido that this message area is shared with another�
|
|
Fido or other program that can generate .MSG files in this�
|
|
directory -- this is meant to be used on multi-line Fido�
|
|
installations, to prevent message file contention. (It is�
|
|
actually file-locking, done at the right level for a change.) It�
|
|
causes Fido to recount messages whenever it needs to generate a�
|
|
new message file.
|
|
|
|
\example{O=Anon}
|
|
|
|
When a new message is created, it is marked {\tt From: Anon}.
|
|
|
|
\example{O=Public}
|
|
|
|
Makes Fido not ask {\tt Private? (y,N)}; all messages are public.
|
|
|
|
|
|
\section{New keywords in FIDO.INI}
|
|
|
|
\example{timelog <YES, no>}
|
|
|
|
This controls whether or not Fido creates TIMELOG.BBS and the�
|
|
.TLG timelog files.
|
|
|
|
\example{netlog <YES, no>}
|
|
|
|
Controls whether or not FidoNet creates NETLOG.BBS and the .NLG�
|
|
FidoNet call files.
|
|
|
|
\example{cont-interval <1-60>}
|
|
|
|
This controls how often CONT FIDONET events are run; in version�
|
|
12Q it was fixed at one minute. Also allowed within FidoNet route�
|
|
language files.
|
|
|
|
\example{system-path <pathname>}
|
|
|
|
Use this to define the pathname that \fido\ uses to locate the�
|
|
following files: CALLER.SYS, *.LOG, *.NDL, ROUTE.*, NODES.BBS.�
|
|
Normally Fido looks for these files in the default directory.
|
|
|
|
When running more than one \fido\ with a multitasker utility, you�
|
|
can now install each \fido\ in it's own subdirectory, but share�
|
|
critical files like the caller file, etc.
|
|
|
|
\example{rings <1 - 255>}
|
|
|
|
\fido\ normally answers the phone (well, modem\dots) on the first�
|
|
ring; this lets you change it to something else.
|
|
|
|
|
|
{\tty
|
|
directory
|
|
key
|
|
aka
|
|
system
|
|
sysop
|
|
point
|
|
log
|
|
flag
|
|
}
|
|
|
|
These are DCM (Dutchie's Conference Mailer) keywords; \fido\�
|
|
ignores them. DCM ignores \fido's keywords -- so you can use�
|
|
FIDO.INI to specify both \fido\ and DCM's installation, saving�
|
|
all that clutter and extra editing.
|
|
|
|
{\tty
|
|
dot <1 - 32767>
|
|
alt-dot <1 - 32767>
|
|
}
|
|
|
|
These two define your Point address. The default is zero (no�
|
|
point address). Please see the section on POINTS below for�
|
|
details.
|
|
|
|
{\tty
|
|
text-path <pathname>
|
|
\vskip10pt
|
|
help-path <pathname>\quad REMOVED
|
|
bbs-path <pathname>\quad REMOVED
|
|
}
|
|
|
|
The interim {\tt help-path} and {\tt bbs-path} options have been�
|
|
removed. They have been replaced by the single {\tt text-path}.�
|
|
This is where Fido will look for get all .HLP files and text .BBS�
|
|
files; quotes, WELCOMEs, BULLETIN.1 - BULLETIN.99, etc.
|
|
|
|
If multiple languages are implemented, then {\tt text-path} is�
|
|
where Fido will look for text files not uniquely specified for�
|
|
each particular language.
|
|
|
|
\example{node-path <pathname>}
|
|
|
|
Where Fido and FidoNet and the MAKELIST program will look for all�
|
|
of the NODELIST.* files.
|
|
|
|
SET-FIDO will {\it not} create these two subdirectories for you;�
|
|
you must create them manually and copy the files into them.
|
|
|
|
|
|
\example{multi-lingual <yes, NO>}
|
|
|
|
Please refer to the ``Language'' section of this errata sheet.
|
|
|
|
This controls how Fido treats the language interface; if YES,�
|
|
then Fido asks new users to choose a language as part of the
|
|
new-caller signon process, and requires that there be a�
|
|
COMMANDS.INI file in each language subdirectory. If NO, then the�
|
|
language interface is simply an option within the C)hange�
|
|
subcommand.
|
|
|
|
\skip
|
|
{\tty
|
|
zm-rx-type <number>\hfill ;DEFAULT: 0
|
|
zm-tx-type <number>\hfill ;DEFAULT: 0
|
|
zm-tx-start <number>\hfill ;DEFAULT: 1024
|
|
}
|
|
Please refer to the ``ZMODEM'' section in this errata sheet.
|
|
|
|
\skip
|
|
{\tty
|
|
keep-packets <yes,NO>
|
|
keep-nodemaps <YES,no>
|
|
wazoo <YES,no>
|
|
multi-tsync <YES,no>
|
|
fsc001 <yes,NO>
|
|
fsc011 <yes,NO>
|
|
system-name ``Your System Name''
|
|
session-password <password>
|
|
}
|
|
|
|
Please refer to the ``FIDONET'' section in this errata sheet. The�
|
|
default settings, if any, are shown above in CAPS -- unless you�
|
|
have a PARTICULAR REASON do not change the settings of these�
|
|
commands. They are for testing and protocol verification only.
|
|
|
|
\example{multi-tasker <number>\hfill ;DEFAULT: 0}
|
|
|
|
An option to inform Fido of any ``multitasker'' program you might�
|
|
be using. Fido will run fine with any multitasker, even one not�
|
|
listed here; this is an option to potentially improve�
|
|
performance. You should see a slight performance increase.�
|
|
Replace {\tt <number>} with one of the following: 0:Plain MSDOS;�
|
|
1:DoubleDOS; 2:DESQview. Others may be defined later. (Please�
|
|
refer to the manual about the ``nnnn/I'' command line switch when�
|
|
running more than one Fido.)
|
|
|
|
\skip
|
|
{\tty
|
|
external-login-A <number 3 - 255>
|
|
external-login-B <number 3 - 255>
|
|
external-login-C <number 3 - 255>
|
|
... ...
|
|
external-login-J <number 3 - 255>
|
|
}
|
|
|
|
This is part of a special option to allow Fido to run other login�
|
|
programs such as the uucp-to-FidoNet gateways software such as�
|
|
``UFGATE''. (The unix uucp-to-FidoNet gateway software -- ask Tim�
|
|
Pozar at 1:125/555 for details.)
|
|
|
|
It enables a program or a person to login normally, but run�
|
|
another program instead of Fido. There can be up to 10�
|
|
``external-logins'' at one time. When properly installed, a�
|
|
caller that successfully passes the name and password section of�
|
|
the Fido login exits \fido\ and runs a separate program, such as�
|
|
UFGATE. (It is up to the system operator to install the necessary�
|
|
programs and batch files to cause this to happen.)
|
|
|
|
You install this by first creating a batch file that runs your�
|
|
specified program via the DOS ERRORLEVEL convention. Then in�
|
|
FIDO.INI, you specify the {\tt external-login-A} ERRORLEVEL to�
|
|
match (``A'' can be any letter through ``J''). This tells Fido�
|
|
that when a caller logs in with External-Login A, to exit to DOS�
|
|
with this ERRORLEVEL.
|
|
|
|
Next, for each program or person you wish to invoke the special�
|
|
login procedure, you assign a special attribute to an otherwise�
|
|
normal caller in the Fido caller file, ``CALLER.SYS''. This is�
|
|
done by setting the ADDRESS FIELD in the caller record to the�
|
|
{\it exact} string below:
|
|
|
|
\example{external-login A}
|
|
|
|
Letters ``A'' through ``J'' identify which of the {\tt External-login}
|
|
definitions are used. The name and password fields are set�
|
|
normally. The address field is all the separates special logins�
|
|
from normal callers.
|
|
|
|
\example{dial-prefix ``string''}
|
|
|
|
The string is prepended to the phone number from the nodelist�
|
|
files before dialing. A space is added between the prefix and the�
|
|
phone number. Suggestions: put ``P'' for pulse or private PBX�
|
|
access in there, instead of in NODELIST.BBS with XlatList and�
|
|
save a bunch of disk space and hassle.
|
|
|
|
\skip
|
|
\settabs\+XXXXXXXXXX&XXXXXXX&\cr
|
|
\+NUMBER&PREFIX&RESULT\cr
|
|
\+297-9145&(none)&ATDT2979145\cr
|
|
\+297-9145&P..&ATDTP..2979145\cr
|
|
\+642-1034&\$DIAL&\$DIAL 6421034\cr
|
|
\+\$dial\underbar{ }642-1034&(none)&\$DIAL 6421034\cr
|
|
\+\$dial\underbar{ }642-1034&P..&P.. \$DIAL 6421034\cr
|
|
|
|
Fido can execute script files instead of just dialing phone�
|
|
numbers. The script language is exactly the same as in FidoTerm,�
|
|
a shareware telecomm program available from the Fido Software�
|
|
BBS, except that the screen and console oriented commands have no�
|
|
effect or display on the screen.
|
|
|
|
A bucks character ``\$'' in a phone number invokes the script�
|
|
processor. The text following the ``\$'' is the script filename�
|
|
and arguments, and anything before the ``\$'' is ignored. (That�
|
|
lets you mass-process phone numbers, using XlatList or
|
|
``dial-prefix'' in FIDO.INI without interfering.)
|
|
|
|
Arguments to script files must has spaces separating them; the�
|
|
usual ``\underbar{ }'' as defined for the nodelist file format is�
|
|
fine.
|
|
|
|
\example{show-seen-by <yes,no>\hfill ;DEF.: YES}
|
|
|
|
This affects only users of echo-mail programs CONFMAIL and the�
|
|
like; if set to ``NO'', Fido suppresses the verbose ``SEEN-BY''�
|
|
list of nodes.
|
|
|
|
\example{quick-login <yes,no>\hfill ;DEFAULT: NO}
|
|
|
|
If ``YES'', the Q)uick-Login command at the local console logs in�
|
|
the first caller in the caller list (presumably the system�
|
|
operator). Very handy for local maintenance. Leave disabled if�
|
|
many people have physical access to the system.
|
|
|
|
\skip
|
|
{\tty
|
|
\settabs\+modem-type 99 &\cr
|
|
\+modem-type 0&;no modem\cr
|
|
\+modem-type 2&;Direct connection\cr
|
|
\+modem-type 8&;POPCOM 2400\cr
|
|
\+modem-type 13&;Multitech 224e\cr
|
|
\+modem-type 12&;see below\cr
|
|
\+modem-type 21&;Hayes V-series no ASB\cr
|
|
\+modem-type 22&;ditto, locked 9600\cr
|
|
\+modem-type 23&;ditto, locked 19,200\cr
|
|
\+modem-type 24&;USR HST, locked 38,400\cr
|
|
\+modem-type 25&;USR Courier 2400,\cr
|
|
\+modem-type 27&;USR Dual Std, locked 9600\cr
|
|
\+modem-type 28&;USR Dual Std, locked 19,200\cr
|
|
\+&Hardware Handshake\cr
|
|
}
|
|
|
|
{\tt modem-type 0} prevents \fido\ from using the modem at all.�
|
|
In other words, Fido is usable only from the local console.
|
|
|
|
{\tt modem-type 2} is for direct-connect installations. When the�
|
|
CD line goes true, Fido assumes the online and connected state,�
|
|
at the baud rate set by {\tt maxbaud <number>} in FIDO.INI. DTR�
|
|
is used to disconnect. You must use the new script facility to�
|
|
accomplish dialing. No modem initialization is done.
|
|
|
|
{\tt modem-type 8} is for the Prentice POPCOM 2400 baud modem.
|
|
|
|
{\tt modem-type 12} had a bug in version 12K; it issued USR�
|
|
Courier-specific commands, and many ``generic'' 2400 baud modems�
|
|
failed. This has been repaired; see modem type {\tt 25}.
|
|
|
|
{\tt modem-type (14, 16, 17)} have additional initialization�
|
|
commands: {\tt AT\&H1\&R2}.
|
|
|
|
\section{Zmodem file transfer protocol}
|
|
|
|
This is a fully compatible, standard Zmodem implementation, with�
|
|
a few fancy features added. You can adjust Zmodems behavior with�
|
|
the two controls in FIDO.INI (details follow), because Zmodem can�
|
|
potentially accept data faster than your computer can handle. The�
|
|
default settings are quite conservative, and should work on all�
|
|
machines.
|
|
|
|
The block size used depends on the baud rate the connection is�
|
|
at, according to this table (see also {\tt zm-tx-start}).
|
|
|
|
\skip
|
|
\halign{
|
|
#\hfil& %block size
|
|
\hfil#\cr % baud rate
|
|
|
|
Block Size&Baud Rate\cr
|
|
1024&over 2400\cr
|
|
512&2400\cr
|
|
256&1200 \& below\cr
|
|
}
|
|
|
|
Upon two consecutive errors on the same block, the block size is�
|
|
halved; minimum block size is 64 bytes. Upon twenty consecutive�
|
|
blocks with no errors and no line noise junk characters, block�
|
|
size is doubled; maximum block size is 1024 bytes.
|
|
|
|
Keep in mind the whole point of having high speed modems and�
|
|
protocols is so that you can run as fast as your machine allows;�
|
|
a modem capable of 1500 characters per second doesn't make your�
|
|
computer any faster, all it guarantees is that it won't hold you�
|
|
back anymore.
|
|
|
|
Now that a few months has gone by since ZMODEM was fist installed�
|
|
in \fido, I can offer more concrete advice.
|
|
|
|
Full streaming works in nearly all circumstances. The
|
|
near-worst-case design is a 4.77MHz PC clone with an 80mS (slow!)�
|
|
hard disk, DOS 3.3, and an extremely fast modem, such as a US�
|
|
Robotics Dual Standard, locked at 38,400 baud. Even this�
|
|
combination is capable of doing 11,500 baud under good�
|
|
conditions. There is no need for even ``AT'' type hardware for�
|
|
high performance. (At least for file transfer speed alone.)
|
|
|
|
If you use a multitasker such as DoubleDOS, DESQview, Multilink,�
|
|
etc., and you experience high data error rates or lost data, then�
|
|
under these conditions please DO NOT USE Zmodem Receive full�
|
|
streaming. (See {\tt zm-rx-type}.)
|
|
|
|
\subheading{Zmodem Controls}
|
|
|
|
The receive controls affect only how your Fido\slash FidoNet or�
|
|
FT program receives files; if someone else calls in to download�
|
|
files, Zmodem will go as fast as their Zmodem tells Fido or FT to�
|
|
go. (They may have done something like this on their end as�
|
|
well.)
|
|
|
|
\subheading{REC'V: FULL STREAMING}
|
|
|
|
{\parskip=0pt
|
|
\example{FidoTerm:\quad ZRXTYPE 0 or 0/D}
|
|
\example{Fido:\quad zm-rx-type 0}
|
|
}
|
|
|
|
When receiving, tells the sending program that it can accept data�
|
|
at maximum possible data rate, ie. full streaming. This is meant�
|
|
for machines that can accept data at ``high speed'', whatever�
|
|
that means to you.
|
|
|
|
\subheading{REC'V: FULLY ACK'ED}
|
|
|
|
\skip
|
|
{\parskip=0pt
|
|
\example{FidoTerm:\quad ZRXTYPE 1 or 1/D}
|
|
\example{Fido:\quad zm-rx-type 1}
|
|
}
|
|
|
|
When receiving files, every block will be acknowledged. (For�
|
|
sending, Fido/FT will do whatever the receiver says.) This is�
|
|
extremely conservative, and probably only needs to be used in�
|
|
extreme circumstances, such as under a heavily loaded�
|
|
multitasker.
|
|
|
|
\subheading{TRANSMIT: VARIABLE WINDOW}
|
|
|
|
\skip
|
|
{\parskip=0pt
|
|
\example{FidoTerm:\quad ZTXTYPE {\it 1 - 64}/U}
|
|
\example{Fido:\quad zm-tx-type {\it 1 - 64}}
|
|
}
|
|
|
|
The preferred method of defining a sliding window. When sending�
|
|
files, and the receiver says it can accept full streaming Fido/FT�
|
|
will send data in full streaming mode, as long as it receives�
|
|
acknowledges from the receiver every so many [blocks]. The�
|
|
receiver sends occasional acknowledges, and the sender checks for�
|
|
them, without pausing the data flow. If the sender doesn't see an�
|
|
acknowledge it will stop and wait for one.
|
|
|
|
At 2400 baud and below, this has all the speed of full streaming,�
|
|
with improved error recovery. The slight penalty is the reverse�
|
|
channel does get used, which could slow some high-speed modems�
|
|
down.
|
|
|
|
Since the window size is stated in blocks, the size of the window�
|
|
depends on the baud rate and error rate; if many errors occur,�
|
|
Zmodem shrinks the block size, and hence the window shrinks too;�
|
|
if the error rate is exceptionally good, the block size increases�
|
|
as Zmodem increases block size. Higher baud rates start with�
|
|
larger blocks.
|
|
|
|
\goodbreak
|
|
\example{window size = [blocks] * block size}
|
|
|
|
Try starting with [blocks] at 6, which works out to be a 1.5K�
|
|
byte window at 300 and 1200 baud, 3K at 2400, and 6K at 9600 and�
|
|
beyond.
|
|
|
|
HINT: Don't look at the Senders modem activity lights when�
|
|
adjusting window size; look only at the Receivers lights. The�
|
|
senders activity can be misleading; for example, the US Robotics�
|
|
HST has a 32K byte internal buffer, so Zmodem fills it quickly�
|
|
then sits and waits for window synchronization; don't let this�
|
|
fool you into thinking you could make it faster, you can't. Data�
|
|
can only flow out of the modem into the phone line as fast as it�
|
|
goes, all that increasing the window size will do is make error�
|
|
recovery slower.
|
|
|
|
\subheading{TRANSMIT: FIXED SIZE WINDOW}
|
|
|
|
\skip
|
|
{\parskip=0pt
|
|
\example{FidoTerm:\quad ZTXTYPE {\it 1024 - 65536}}
|
|
\example{FidoTerm:\quad {\it 1024 - 65536}/U}
|
|
\example{Fido:\quad zm-tx-type {\it 1024 - 65536}}
|
|
}
|
|
|
|
This is the second method of defining a sliding window. It works�
|
|
the same as the previous method, except the size of the window is�
|
|
fixed, and specified in Kbytes. An 8K window is an 8K window,�
|
|
whether it contains 8 1024 byte blocks or 32 256 byte blocks.
|
|
|
|
\subheading{TRANSMIT: START BLOCK SIZE}
|
|
\skip
|
|
{\parskip=0pt
|
|
\example{Fido:\quad zm-tx-start {\it 64 - 1024}}
|
|
}
|
|
|
|
Normally Fido determines the data block size by baud rate and�
|
|
what the receiver can handle. On extremely bad phone lines, it�
|
|
may take too many errors to get the block size down to one that�
|
|
works; above 2400, where the block size starts at 1024 bytes, it�
|
|
will take 16 errors (block size halved every four errors, four�
|
|
times) to get the 64 byte packet that may work best.
|
|
|
|
This option lets you specify the largest block size to start the�
|
|
transfer with. Try 128 or 64 if you have many errors due to phone�
|
|
line noise; if the connection is good, then after every 20 blocks�
|
|
the block size will double, and performance improve. 20 blocks�
|
|
doesn't take very long when the blocks are 64 bytes each!
|
|
|
|
This controls only the starting block size; the block size can�
|
|
still increase in the normal manner if there are no errors, as�
|
|
outlines in the beginning of this section.
|
|
|
|
Please make sure that you use only the following values: 64, 128,�
|
|
256, 512, 1024.
|
|
|
|
\section{Miscellaneous Additions}
|
|
|
|
{\bf New command line switch /C}, forces Fido to simply end any�
|
|
outstanding FidoNet event, caused by either a reboot while Fido�
|
|
running (CTL-ALT-DEL) or when using the new {\tt keep-packets}�
|
|
option in FIDO.INI.
|
|
|
|
{\bf New system files: NODELIST.ZDX and NODE\-LIST.NDX} Fido can�
|
|
access any system listed in the nodelist with an average
|
|
worst-case of four small disk reads -- performance with 10,000�
|
|
nodes is much faster than most previous versions with only 500�
|
|
nodes.
|
|
|
|
MAKELIST creates these, and Fido and all of the supplied tools�
|
|
use them. It is an additional index, and contains all the HOSTS�
|
|
and REGIONS and ZONES in the system. The existing NODELIST.IDX�
|
|
file has not changed in format nor use; external programs that�
|
|
use it are not affected.
|
|
|
|
{\bf WELCOME3.BBS, WELCOME4.BBS and WELCOME5.BBS} are displayed�
|
|
right after the point where it now displays WELCOME2.BBS.
|
|
|
|
{\bf Incompletely uploaded or received files} (carrier loss,�
|
|
Control-X abort, timeout, etc) no longer clutter the directories;�
|
|
Fido kills 'em.
|
|
|
|
{\bf New option at the {\tt More[c,Y,n]} prompt}: C ==�
|
|
Continuous, ie. suspend the ``more'' function until the next�
|
|
prompt for input.
|
|
|
|
{\bf NODELIST.SYS is not used} anymore. MAKELIST.EXE used to�
|
|
generate it, and FIDO.EXE read it. Fido now uses NODELIST.BBS�
|
|
directly.
|
|
|
|
{\bf .BBS text files:} When Fido comes across certain control�
|
|
codes embedded in .BBS text files such as WELCOME1.BBS, it�
|
|
performs certain special functions (Page 26 in the manual). The�
|
|
following were added:
|
|
|
|
{\tty
|
|
\uparrow A\quad Skip characters until next CR
|
|
\uparrow B\quad Disable Control-C abort
|
|
\uparrow C\quad Re-enable Control-C abort
|
|
\uparrow D\quad Instant "More"
|
|
\uparrow E\quad Disable word-wrap (12s up)
|
|
\uparrow F\quad Enable word-wrap (12s up)
|
|
\uparrow J\quad Ignored (linefeed)
|
|
\uparrow M\quad Outputs CR, LF
|
|
\uparrow X\quad Word-wrap off til next CR
|
|
\uparrow Z\quad End of File
|
|
}
|
|
|
|
{\bf MsgMgr.EXE options added:} New keyword that can be used�
|
|
within MsgMgr script files:
|
|
|
|
\example{LOGFILE {\it logfilename}}
|
|
|
|
Normally MsgMgr logs it's activity in FIDO.LOG, the standard Fido�
|
|
log file. With this command, you can route log activity to any�
|
|
file or pathname or device, or to eliminate it entirely, to the�
|
|
device ``NUL''.
|
|
|
|
You can now specify the name of the script file that the message�
|
|
manager is to use, instead of just the default ``MSGMGR.INI''.�
|
|
For example, you could renumber/purge only your FidoNet area�
|
|
right before mail time, and then use MsgMgr in the usual manner�
|
|
after FidoNet.
|
|
|
|
MsgMgr will also now translate ``LASTREAD'' and ``HW.DAT'' files�
|
|
if they exist in each message area.
|
|
|
|
\enddoublecolumns
|
|
|
|
|
|
|
|
\pagebreak
|
|
|
|
\section{FidoNet}
|
|
|
|
With version 12Q came a rather radical simplification of overall�
|
|
FidoNet operation. Gone are all the confusing FidoNet event-type�
|
|
options. Since there are people looking at this who haven't seen�
|
|
a \fido\ since version 11, I'll sum up the changes here:
|
|
|
|
{\obeylines\parskip=0pt\parindent=14pt
|
|
\blob True three-level addressing (v12)
|
|
\blob Continuous incoming mail (v12)
|
|
\blob Incoming message/packet handling (v12s)
|
|
\blob Wazoo/Zmodem protocol (v12m)
|
|
\blob Usable continuous outgoing mail (v12m)
|
|
\blob File Requesting (v12m)
|
|
\blob True continuous outgoing mail (v12q)
|
|
\blob Incremental packeting (v12q)
|
|
\blob Basic point support
|
|
\blob Scheduled control of File Requests (v12q)
|
|
}
|
|
|
|
During this revision (12q), most if not all of the
|
|
FidoNet-program implementors were working towards making their�
|
|
program adhere to the basic FSC001 protocol standard, and we all�
|
|
tested against each others programs as well. Yes, you can even
|
|
file-attach to SEAdogs.
|
|
|
|
FidoNet, from the sysop's installation and operation point of�
|
|
view, was kind of a jumble of complex options in EVENTS.INI and�
|
|
less than satisfactory when trying to run continuous outgoing�
|
|
mail -- ie. to have packets ready for pickup at any time. I think�
|
|
it is safe to say that all of these problems have been fixed. You�
|
|
no longer need to have a zillion events throughout the day, and�
|
|
newly entered messages no longer sit around until one of those�
|
|
zillion events comes by.
|
|
|
|
The FidoNet event types you specify in EVENTS.INI were completely�
|
|
revamped. The previous method involved complex and obscure�
|
|
options that confused even me -- it was poorly thought out. There�
|
|
are now only three types of FidoNet event (described below).
|
|
|
|
There is what I think a good sample installation that should�
|
|
cover most peoples needs described below. It should be easy to�
|
|
install and understand.
|
|
|
|
\begindoublecolumns
|
|
|
|
\section{FidoNet Events}
|
|
|
|
There are three types of FidoNet events, each described below.
|
|
|
|
\subheading{Normal FidoNet}
|
|
|
|
\example{ALL 2:00 60 FIDONET A}
|
|
|
|
This is the old standby FidoNet event type. It runs until it's�
|
|
time is up. Human callers are not allowed into Fido; it accepts�
|
|
only FidoNet mail.
|
|
|
|
\subheading{Rush FidoNet}
|
|
|
|
\example{RUSH 2:00 60 FIDONET A}
|
|
|
|
Very similar to the previous ``vanilla'' FidoNet event, except�
|
|
that when there is no more mail to send, ie. all the packets have�
|
|
been delivered or the maximum number or tries has been reached,�
|
|
the event terminates early.
|
|
|
|
RUSH FIDONET events are especially useful when combined with a�
|
|
{\tt T)rigger}; you can define an event to run all day long ({\tt�
|
|
0:00 1440}), and use it to manually override normal scheduling.
|
|
|
|
\subheading{Continuous FidoNet}
|
|
|
|
\example{CONT 2:00 60 FIDONET A}
|
|
|
|
True continuous outgoing mail. This causes \fido\ to make�
|
|
packets, and have them available for pickup or delivery at any�
|
|
time, while allowing human callers to access Fido freely.
|
|
|
|
When there is no human caller occupying Fido, and there are�
|
|
packets to deliver (according to route language files) FidoNet�
|
|
will make calls once per {\tt dial-interval}.
|
|
|
|
Other FidoNet systems can call in at any time (well, assuming�
|
|
it's not in use), deliver FidoNet mail, and pick up packets�
|
|
addressed to it.
|
|
|
|
If a human or a FidoNet mailer generates a message in the FidoNet�
|
|
message area, FidoNet will immediately add it to an existing�
|
|
packet or create a new one; and deliver the packet as per normal�
|
|
FidoNet routing controls.
|
|
|
|
\subheading{QUICK FidoNet Option: Obsolete}
|
|
|
|
The QUICK option is no longer used. All FidoNet events are now,�
|
|
by definition, ``QUICK''. This means that you {\it must} run SET-FIDO if you change any of your ROUTE.* files. Which was strongly�
|
|
reccommended anyways. So now it's mandatory.
|
|
|
|
\section{A Sample Installation}
|
|
|
|
The following is a very good starting point for a full featured�
|
|
\fido\ installation for a node in the amateur FidoNet network. It�
|
|
is described in detail below:
|
|
|
|
{\tty
|
|
|
|
RUSH 0:00 1440 FIDONET R T=1
|
|
2:00 60 FIDONET A
|
|
CONT 2:00 1380 FIDONET L
|
|
}
|
|
|
|
(Fido executes events by scanning the list of scheduled events�
|
|
from top to bottom, and runs the first event it finds that is�
|
|
runnable. The RUSH FIDONET event will only run (and therefore�
|
|
override the events that follow) when Trigger 1 is turned on.)
|
|
|
|
And here's a sample ROUTE.BBS file to go with this:
|
|
|
|
{\tty
|
|
|
|
IF-SCHEDULE R ;manual override
|
|
SEND-ONLY
|
|
SEND-TO, NO-ROUTE MYZONE
|
|
|
|
IF-SCHEDULE A ;'ZoneMailHour'
|
|
SEND-TO ALL
|
|
|
|
IF-SCHEDULE L ;daytime mail --
|
|
SEND-ONLY, DIAL-TRIES 1
|
|
;generate packets for all
|
|
SEND-TO, NO-ROUTE MYZONE
|
|
;but call only my own net
|
|
HOLD ALL NOT MYNET
|
|
|
|
END-IF
|
|
}
|
|
|
|
The first event, RUSH FIDONET R, is controlled by Trigger 1, and�
|
|
we'll assume usually turned OFF. (When OFF, the event is inert�
|
|
and will not run.) When turned ON, FidoNet will repacket�
|
|
according to the route file; in this example, it will make�
|
|
packets for messages within our own zone (SEND-TO MYZONE),�
|
|
without host routing (NO-ROUTE MYZONE), and dial otu to deliver�
|
|
those packets as fast as possible (SEND-ONLY). It will stop when�
|
|
(1) if there were no messages to deliver, (2) as soon as all�
|
|
messages are delivered, or (3) the maximum number of tries is�
|
|
reached.
|
|
|
|
The second event, FIDONET A, is the normal, mandatory, FidoNet�
|
|
``ZMH''. SEND-TO ALL simply means enable mailing to all nodes in�
|
|
the nodelist (note that for inter-zone messages, the contents of�
|
|
ROUTE.DEF (elsewhere\dots) will route messages to the proper�
|
|
zonegate). This event will run until completion; in this example,�
|
|
from 2:00AM til 3:00AM.
|
|
|
|
The third event, CONT FIDONET L, is the ``background'',�
|
|
continuous FidoNet event. It will run whenever the previous two�
|
|
are not. It will make packets according to the route language for�
|
|
tag L: packets only to your zone (SEND-TO MYZONE), no default�
|
|
host routing (NO-ROUTE MYZONE). FidoNet will make phone calls�
|
|
only to nodes in your own net -- HOLD ALL NOT MYNET.
|
|
|
|
Assume now that it's in the afternoon, and CONT FIDONET L is�
|
|
running. You are, for example, 1:125/0, the host for net 125.�
|
|
1:161/12345 calls and delivers a packet with a message destined�
|
|
for 1:125/7. If there were messages for 1:161/12345 it would be�
|
|
on HOLD -- it is outside your net (HOLD ALL NOT MYNET) -- and it�
|
|
could be picked up at this time.
|
|
|
|
After it disconnects, Fido unpackets the message. FidoNet then�
|
|
discovers the new message for 1:125/7 -- it immediately creates a�
|
|
new packet for 1:125/7, and since that is within your own net,�
|
|
immediately calls it and delivers the packet. If '7 were busy,�
|
|
then Fido would run and wait for a caller. While Fido remains�
|
|
idle (no one calls in), every {\tt dial-interval} FidoNet will�
|
|
run, and attempt to deliver that packet to '7.
|
|
|
|
And further: assume a human caller connects now, with that packet�
|
|
to '7 still undelivered, and goes into the FidoNet netmail area,�
|
|
and enters some messages: another to 1:125/7, one to 1:161/12345,�
|
|
and another to say 2:500/5. When the caller disconnects, FidoNet�
|
|
will packet those messages: the first will go into the existing�
|
|
packet for 1:125/7, the second to (say) a new packet for�
|
|
1:161/12345, and the third will not be packeted at all -- you�
|
|
said SEND-TO, NO-ROUTE MYZONE so it just sits.
|
|
|
|
With the packets then updated, FidoNet runs again. It calls '7,�
|
|
connects, and delivers the packet. (The messages and packet can�
|
|
then be deleted.) The packet for 1:161/12345 is not delivered,�
|
|
since it is outside your net. FidoNet relinquishes control to�
|
|
Fido, allowing human or FidoNet callers in.
|
|
|
|
\section{Points}
|
|
|
|
\fido\ now (12N) includes basic Point addressing support. Later�
|
|
versions will provide complete ``boss node'' functions, so that�
|
|
\fido\ will be able to perform any possible FidoNet mailer�
|
|
function; zone gate, zone host, net/region host, ordinary node,�
|
|
point boss, point node.
|
|
|
|
\fido\ properly handles all point-addressed messages; it will�
|
|
scan for TOPT and FMPT Kludge lines, and incorporate them into�
|
|
the message address display.
|
|
|
|
When reading existing messages, Fido locates the TOPT and FMPT�
|
|
IFNA Kludge lines, like it always has for INTL lines, and�
|
|
incorporates them into the displayed address. To the user or�
|
|
sysop, there's nothing to even think about.
|
|
|
|
When entering a message, node address entry is as it always was,�
|
|
but you can add ``{\tt .<1 - 32767>}'' to the node number, or�
|
|
just the dot followed by the point number, to send to points�
|
|
within your own point network. For example: as 125/111, entering�
|
|
.33 would address a message to 1:125/111.33, etc. Same syntax and�
|
|
behavior as default net, etc.
|
|
|
|
When replying, Fido does the same as it does with nodes; the�
|
|
message is To: the From: node, unless it is the same as ``us'' in�
|
|
which case it reverses the addresses.
|
|
|
|
Internally, Fido generates TOPT and FMPT lines as the second and�
|
|
third lines in the .MSG file; INTL still comes first. Fido will�
|
|
locate any of these three lines as long as they occur within the�
|
|
first 256 bytes of text following the message header.
|
|
|
|
Note that Fido will display point numbers only if the point�
|
|
number is NOT zero. 1:125/111.555 will display that way; .0 will�
|
|
display as 1:125/111 only.
|
|
|
|
\section{Wazoo Protocol}
|
|
|
|
\fido\ now supports two network protocols automatically. One is�
|
|
``FidoNet'', known in some circles as ``FSC001'', after the�
|
|
filename of the standards document generated by Randy Bush. Fido�
|
|
has supported this protocol since 1985.
|
|
|
|
The other, newer protocol is called ``Wazoo'', and was originally�
|
|
implemented in Wynn Wagner's Opus program, and now it seems the�
|
|
most popular program supporting Wazoo is ``BinkleyTerm''. Both�
|
|
also do FSC001 style FidoNet. Wazoo operates in a similar manner,�
|
|
but uses Zmodem for it's transfers and can support ``file�
|
|
requests'', where the call originator can ``download'' files from�
|
|
the remote computer without the intervention of an operator to do�
|
|
``file attaches''. (With appropriate controls, etc.)
|
|
|
|
There is no impact on existing \fido\ installations regarding�
|
|
security, setup or installation, etc. The choice of Wazoo vs.�
|
|
FidoNet is made automatically, though the system operator can�
|
|
make changes. The defaults will work fine in all cases.
|
|
|
|
\subheading{FidoNet Controls in FIDO.INI}
|
|
|
|
{\tty
|
|
mail-errorlevel <0, 3 - 255>
|
|
file-errorlevel <0, 3 - 255>
|
|
}
|
|
|
|
With these you can make \fido\ exit to DOS whenever receives�
|
|
incoming message(s) and/or file(s),
|
|
|
|
\example{keep-packets <yes,no>}
|
|
|
|
{\tt keep-packets} can provide much better FidoNet performance�
|
|
improvement for some systems.
|
|
|
|
When Fido is first run, and there is an active FidoNet event,�
|
|
FidoNet is invoked to create all the packets, if any, that will�
|
|
be delivered or picked up by other nodes. It then either runs the�
|
|
event until completion, or returns control to Fido (during CONT�
|
|
events).
|
|
|
|
If you are also using DOS errorlevels (mail- or file-errorlevel,�
|
|
external-logins, etc) FidoNet ends the event before returning to�
|
|
DOS; the undelivered packets deleted, and a log file summary is�
|
|
made, before Fido returns to DOS.
|
|
|
|
Upon return from the DOS errorlevel processing, Fido then�
|
|
recreates the so-far undelivered packets, and attempts to deliver�
|
|
them or hold them for pickup, as determined by the event.
|
|
|
|
All of this packet/unpacket activity can take signifigant amounts�
|
|
of time, especially if you have many packets to deliver, or your�
|
|
system executes many DOS errorlevels per schedule.
|
|
|
|
{\tt keep-packets yes} makes Fido not delete the packets when�
|
|
executing a DOS errorlevel; therefore the time it took to do
|
|
end-schedule work, plus recreate the packets upon reentry to�
|
|
Fido, is saved.
|
|
|
|
(FidoNet will always do end-schedule processing if you type�
|
|
Control-C on the keyboard, or if there is an error, such as a�
|
|
critical missing file or disk full.)
|
|
|
|
The penalty for this is slightly increased complexity. When there�
|
|
are outstanding packets, the nodelist files and the .OUT and .FLO�
|
|
files in the outbound directory cannot be disturbed. There are a�
|
|
few cases where you must keep this in mind:
|
|
|
|
{\parindent=16pt
|
|
\item{1} If your machine is warm-booted (ie. CONTROL-ALT-DEL)�
|
|
while Fido was running, the nodelist files and packet files will�
|
|
not be updated properly.
|
|
|
|
\item{2} MAKELIST will not let you process a new nodelist if�
|
|
there are packets outstanding, since it needs to create new�
|
|
NODELIST files, but they currently contain important information.
|
|
}
|
|
|
|
To solve this problem, there is a way to simply perform the
|
|
end-of-schedule process, that will delete packets, complete the�
|
|
log file, and leave the nodelist files free:
|
|
|
|
\example{FIDO /C}
|
|
|
|
With /C, Fido will end any outstanding event, and then return to�
|
|
DOS. You should use {\tt FIDO/C} before running automatically�
|
|
MAKELIST, or in your AUTOEXEC batch file, if you are using {\tt�
|
|
keep-packets}.
|
|
|
|
You can use {\tt FIDO/C} even if there are no packets�
|
|
outstanding, or if {\tt keep-packets} is NO.
|
|
|
|
|
|
\example{system-name}
|
|
|
|
An optional 60 character string that is the ``name'' of your�
|
|
system. Fido transmits this name to the remote computer during�
|
|
Wazoo sessions. {\tt session-password} may be required for�
|
|
connecting to some other Wazoo-based systems; please make�
|
|
arrangements with the person requiring it.
|
|
|
|
|
|
\skip
|
|
{\tty
|
|
keep-nodemaps <yes,no>;default:YES
|
|
fsc011 <yes,no> ;default: NO
|
|
wazoo <yes,no> ;def.: YES
|
|
multi-tsync <yes,no> ;def.: YES
|
|
fsc001 <yes,no> ;default: NO
|
|
}
|
|
|
|
The following are for special purposes only, mainly for verifying�
|
|
FidoNet FSC001 protocol compatibility. Unfortunately in the real�
|
|
world there are varying levels of compliance to FSC001; the�
|
|
default is pretty ``loose'', for maximum compatibility. {\tt�
|
|
fsc011 yes} lets \fido\ accept so-called ``DIETIFNA'' protocol,�
|
|
which means it can skip the slow MODEM7 filename; however SEAdog�
|
|
does not accept TELINK blocks and file attaches will then fail.�
|
|
{\tt wazoo no} forces Fido to do only FSC001, ie. pre-12M�
|
|
compatibility. {\tt multi-tsync no} forces Fido back to 11W style�
|
|
single TSYNC character; there is nearly no reason to do this.�
|
|
{\tt fsc001 yes} makes FidoNet and it's XMODEM protocol driver�
|
|
conform to
|
|
letter-of-the-law FSC001 specifications; alas, not many FidoNet�
|
|
``compatible'' systems will then work, including many \fido\�
|
|
programs!
|
|
|
|
\section{File Requests}
|
|
|
|
Fido now supports file request in either FSC001-type or Wazoo�
|
|
FidoNet sessions. A file request is a file transfer originated by�
|
|
the calling system, that requests one of more files by name; the�
|
|
called system then transmits the requested files in that same�
|
|
session.
|
|
|
|
The receiving system has full control over what it will and will�
|
|
not allow to be requested; this is to prevent the obvious ``file�
|
|
request *.*'' getting copyrighted programs, critical data files�
|
|
(caller lists anyone?) and other problems.
|
|
|
|
There are shareware and free programs that will automatically�
|
|
generate a file request, given only the desired filenames and the�
|
|
node address to request from. What follows is the technical�
|
|
description of how it works.
|
|
|
|
A file request consists of a file with a special name sent to the�
|
|
receiving system, the one that will possibly honor the request.�
|
|
The filename is:
|
|
|
|
\example{XXXXYYYY.REQ}
|
|
|
|
Where: {\tt XXXX} is the receiving system's net number, in
|
|
four-digit hexadecimal, and {\tt YYYY} the receiving system's�
|
|
four-digit net number. For example, a request to 1/2 would be�
|
|
00010002.REQ; a request to 125/111 would be 007D006F.REQ.
|
|
|
|
Inside this file, one per line, are the file(s) to be requested.�
|
|
Each line ends with a CR or CR/LF. Filenames can be any length,�
|
|
and may not contain pathnames or drive letters. (Fido will ignore�
|
|
them.) Filenames can include wildcards.
|
|
|
|
\subheading{Generating File Requests}
|
|
|
|
You can request files from within Fido; it is an option in the�
|
|
message editor in the FidoNet message area. You can enter any�
|
|
number of filenames, with wildcards, as will fit on the line.�
|
|
Fido will automatically generate the awful .REQ file for you.
|
|
|
|
|
|
\subheading{Controlling File Requests}
|
|
|
|
The receiver has a file called ``FILEREQ.INI'', that is the list�
|
|
of files that may be requestable from the system. Initially only�
|
|
two sample files are requestable (see below), and the system�
|
|
operator needs to add to this list all files that you wish to be�
|
|
requestable remotely.
|
|
|
|
As provided by Fido Software, there are only two requestable�
|
|
files: ``ABOUT'', which is a short description of what your�
|
|
system is ``about'', and ``FILES'', which is the list of files�
|
|
requestable from your system. In the hobbyist FidoNet network, it�
|
|
is traditional (and useful!) to have these two files requestable�
|
|
at all times, so that other system operators can find out about�
|
|
your BBS without having to manually call and ask.
|
|
|
|
You can also restrict File Requests to specific hours, with the�
|
|
event type FILEREQUEST, in EVENTS.INI:
|
|
|
|
\example{ALL 3:00 1380 FILEREQUEST}
|
|
|
|
This allows file requests at any time except between 2:00 and�
|
|
3:00AM, the Zone Mail Hour. A file request made while it is�
|
|
disabled will send the contents of the file ``NOFILEREQ.BBS'' to�
|
|
the requesting system as file XXXXYYYY.FRQ, where XXXXYYY is the�
|
|
requesting node's address, as described under the .REQ file.�
|
|
Presumably you'd list in NOFILEREQ.BBS the reasons the file�
|
|
request was not honored.
|
|
|
|
\subheading{The FILEREQ.INI File}
|
|
|
|
This file is used to control how \fido\ handles file requests. It�
|
|
is a plain ASCII text file, that you create and maintain, that�
|
|
contains the list of files and directories you wish to have�
|
|
available for other systems to file-request with their FidoNet�
|
|
type mailer.
|
|
|
|
You can also put comments into this file; comments are any line�
|
|
that begins with a semicolon, like so:
|
|
|
|
\skip
|
|
{\tty
|
|
;
|
|
;Lines beginning with a ``;'' are comments,
|
|
;and are ignored by Fido.
|
|
;
|
|
}
|
|
Comments do however slow down processing, so try to keep them�
|
|
short.
|
|
|
|
All other lines in the file define requestable directories or�
|
|
specific files. The most popular method is to make the contents�
|
|
of a directory requestable. This is easy; simply list the�
|
|
directories you wish to make available, one per line.
|
|
|
|
\skip
|
|
{\tty
|
|
C:/LISTS
|
|
C:/FIDO/TEXTFILE
|
|
C:/SHAREWARE
|
|
}
|
|
|
|
And so on. It means that all files within each directory are�
|
|
requestable. There is one odd side effect; if the filename you�
|
|
request exists in more than one directory, \fido\ will send you�
|
|
every single one. Too bad. For example, ``FILES.BBS''. Fido will�
|
|
transmit, just as you asked, FILES.BBS from all directories that�
|
|
contain it. Too bad if that's not what you MEANT, that's what you�
|
|
SAID.
|
|
|
|
Note also that ``FILE'' can contain wildcards; ``*.*'' for�
|
|
instance. It will of course return every single requestable file�
|
|
stored in your system. (Ugh.)
|
|
|
|
It is also useful to have ``logical'' file requests; for example,�
|
|
you want to announce that requesting the file ``NODELIST'' will�
|
|
always return the very latest nodelist file, no matter what it is�
|
|
really named, without having to constantly rename the file:
|
|
|
|
\example{NODELIST=LISTS/NODELIST.*}
|
|
|
|
Whenever someone requests the filename ``NODELIST'', (the name to�
|
|
the left of the ``='' equals sign) Fido will send them your file�
|
|
(after the ``='' equals sign), that matches ``LISTS/NODELIST.*''.�
|
|
This lets files be requested by their logical names, no matter�
|
|
where they may reside on your disk. (For revenge, you can have a�
|
|
file called ``CALLER.SYS'' that returned something nasty instead�
|
|
of the actual caller file.)
|
|
|
|
You can use this in other ways: you could respond to a request�
|
|
for ``ALL-LISTS'' with all the files you have, for example:
|
|
|
|
\example{ALL-LISTS=LISTS/*.*}
|
|
|
|
There can also be more than one entry with the same requestable�
|
|
name. For example, if you wanted to have a ``kit'' of files for�
|
|
new system operators requestable, you could convert the request�
|
|
for ``NEW-SYSOP'' to send many files:
|
|
|
|
\skip
|
|
{\tty
|
|
NEW-SYSOP=LIST/NODELIST
|
|
NEW-SYSOP=NEWNODE.TXT
|
|
NEW-SYSOP=/TEXT/COORD.LST
|
|
etc
|
|
}
|
|
|
|
Fido will search the entire FILEREQ.INI file, and send all files�
|
|
that match all requests.
|
|
|
|
|
|
The third method is for when you want to make single files in�
|
|
arbitrary subdirectories available. For example, you might want�
|
|
to make certain files in your ``/FIDO'' directory available, but�
|
|
still maintain absolute security. Entering ``FILENAME=FILENAME''�
|
|
works, but is tedious and redundant. There is a short form for�
|
|
when you just want to make a file requestable with it's original�
|
|
name, and not necessarily provide multiple files, etc:
|
|
|
|
\example{C:/LIST/NODELIST.099}
|
|
|
|
A file request for the filename portion (``NODELIST.099'') causes�
|
|
your system to send that file, period. The pathname is used�
|
|
locally, in your system only; it is not requestable nor�
|
|
accessible. This shorthand lets you generate lists of files and�
|
|
place them, as-is, into FILEREQ.INI.
|
|
|
|
|
|
\subheading{Nodemaps}
|
|
|
|
\fido\ saves nodemaps it creates for each FidoNet schedule tag.�
|
|
(Nodemaps are what the Router produces by reading the ROUTE.*�
|
|
routing language files, and applying them to the file�
|
|
NODELIST.NMP.) There is one nodemap file (NODEMAP.tag) per�
|
|
schedule tag, and each file is four bytes per node in the�
|
|
nodelist -- or 24K per schedule you use for a 6,000 node�
|
|
nodelist. FidoNet generates a nodemap the first time each event�
|
|
runs -- after that changing FidoNet schedules is nearly�
|
|
instantaneous. (You can disable this (why?!) with the FIDO.INI�
|
|
command {\tt keep-nodemaps no}.)
|
|
|
|
|
|
\section{Routing Language Additions}
|
|
|
|
{\tty
|
|
rings <1 - 255>
|
|
dial-interval <1 - 60>
|
|
cont-interval <1 - 60>
|
|
file-errorlevel <0, 3 - 255>
|
|
mail-errorlevel <0, 3 - 255>
|
|
}
|
|
|
|
These FIDO.INI statements can appear in route language files. The�
|
|
first four are defined in this errata sheet.
|
|
|
|
|
|
{\tty
|
|
Zone 1 ;current ZONE is 1
|
|
BEGIN
|
|
Zone 4 ZoneGate a:b/c ;change ZONE to 4,
|
|
END
|
|
;zone is now 1 again
|
|
}
|
|
|
|
BEGIN and END add block structure to the router commands that�
|
|
change default behavior, mainly NET and ZONE. BEGIN saves the�
|
|
current state, and END restores them. NET and ZONE changes within�
|
|
a BEGIN/END group are local to that group; after the END, the�
|
|
values of NET and ZONE are restored to what they were at the time�
|
|
the BEGIN statement was executed. You can nest BEGIN and END up�
|
|
to four levels deep.
|
|
|
|
\smallskip
|
|
|
|
The one-argument commands POLL, PICKUP, NO-ROUTE, ACCEPT-FROM,�
|
|
HOLD, SEND-TO can be ``stacked'' together, for faster execution.�
|
|
For example, if you do a lot of things like:
|
|
|
|
\example{Send-To All, PickUp All}
|
|
|
|
They can now be stacked onto one argument, as in:
|
|
|
|
\example{Send-To, Pickup All}
|
|
|
|
The advantage is that all of the stacked commands are executed at�
|
|
once (when the ``All'' is read) instead of one at a time. ``ALL''�
|
|
makes the router apply the commands to all nodes in the nodelist;�
|
|
stacking in this example is twice as fast.
|
|
|
|
\smallskip
|
|
\example{ALIAS-AS <alias>, <nodes\dots>}
|
|
|
|
{\bf A powerful new route language command ALIAS-AS:} Similar to�
|
|
the current ROUTE-TO command, you can force all messages routed�
|
|
to the alias node, regardless of other routing or files attached.
|
|
|
|
For example, you exchange mail with a person who runs a node with�
|
|
more than one alias address; for example 105/6, 105/0, 1/2 and�
|
|
1/3 are all the same machine. You simply set (for example) 105/6�
|
|
as the alias for the other nodes.
|
|
|
|
Please note that this is not another ``route-to'' command; while�
|
|
it does a ``route-to'' as part of it's action, it is a new�
|
|
command entirely. Route-to only does one level of indirection;�
|
|
alias-as adds a second. Alias-as can be thought of as a kind of�
|
|
``route-to route-to''.
|
|
|
|
Route-to defines to what destination node a message goes to,�
|
|
possibly (probably) not the one the message is addressed to.
|
|
|
|
Alias-as defines to whose packet those routed messages go into.
|
|
|
|
\subheading{Route file processing}
|
|
|
|
A new ROUTE file is introduced: ROUTE.DEF. Fido looks for and�
|
|
processes ROUTE.DEF before looking for ROUTE.(tag) and/or�
|
|
ROUTE.BBS. This lets you do routing controls in common with all�
|
|
FidoNet events.
|
|
|
|
New keywords were added to the route language processor:
|
|
|
|
\skip
|
|
{\tty
|
|
IF-SCHEDULE <tag>
|
|
END-IF
|
|
}
|
|
|
|
Ken G's suggestion roundly applauded by everyone else. Even I now�
|
|
agree it is an excellent idea. It does what you think it does.�
|
|
You now have an alternative to all those scroungy little�
|
|
ROUTE.<tag> files; put them all into ROUTE.BBS (maybe keep�
|
|
ROUTE.DEF, it partitions that nicely and doesn't slow things�
|
|
down) for ease in maintenance.
|
|
|
|
If no IF-SCHEDULE statements are used, then FidoNet processes the�
|
|
route list normally; all statements are read and processed.
|
|
|
|
\skip
|
|
{\tty
|
|
IF-SCHEDULE A
|
|
\indent schedule A statements ...
|
|
END-IF
|
|
}
|
|
|
|
If the currently executing schedule is ``A'', then the statements�
|
|
between the IF\dots END are executed, otherwise they are ignored.
|
|
|
|
\skip
|
|
{\tty
|
|
IF-SCHEDULE M
|
|
\indent schedule M statements ...
|
|
|
|
IF-SCHEDULE B
|
|
\indent schedule B statements ...
|
|
|
|
IF-SCHEDULE D
|
|
\indent schedule D statements ...
|
|
|
|
END-IF
|
|
}
|
|
|
|
Not a big deal to figure out. Each IF-SCHEDULE ends the one�
|
|
before it (if any). Processing is as you'd expect.
|
|
|
|
If you have commands to execute for all schedules (say, PICKUP�
|
|
ALL) just place them before any IF-SCHEDULE statements.
|
|
|
|
\example{zone x ZONEGATE node}
|
|
|
|
This tells FidoNet to route all mail for Zone X to the specified�
|
|
node; the supplied ROUTE.DEF file implements IFNA type zone�
|
|
gating. There is no restriction on Fido's ZoneGate. For example,�
|
|
in ROUTE.DEF:
|
|
|
|
\skip
|
|
{\tty
|
|
;
|
|
;Do IFNA Kludge type Zone Gating
|
|
;
|
|
Zone 2 ZoneGate 1:1/2
|
|
Zone 3 ZoneGate 1:1/3
|
|
}
|
|
|
|
\example{DIAL-TRIES n}
|
|
\example{CONNECT-TRIES n}
|
|
|
|
Maximum number of times to dial each node. (Default is ``dial-
|
|
tries'' and ``connect-tries'', respectively, in FIDO.INI)
|
|
|
|
\example{MODEM-STRING s}
|
|
|
|
Presumably a command string of special initialization to be�
|
|
issued before this event starts. This is intended for special�
|
|
modems such as the TrailBlazer where you might want to enable�
|
|
special features during limited periods.
|
|
|
|
\example{MYZONE}
|
|
|
|
A modifier keyword, meaning All nodes in my own zone.
|
|
|
|
\example{THISZONE}
|
|
|
|
Another modifier keyword, meaning All nodes in the currently�
|
|
specified zone.
|
|
|
|
\enddoublecolumns
|
|
\bye
|