mirror-textfiles.com/bbs/FIDONET/JENNINGS/PROGRAMS/FIDOSHEETS/errata.tex.txt

\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<65>
and enhanced. A new one is included on the diskette. If you had<61>
set custom privilege levels and locks (P= and L=) you will need<65>
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''<27>
when entering or replying to messages. The feature consists of a<>
new Message Section command, a new command in the message editor,<2C>
and enhancements to two existing message editor commands.

It works like this: while you are reading messages, you may find<6E>
one that you want to reply to that has a number of points within<69>
it you want to address in your reply. Instead of taking notes,<2C>
with the new W)rite-Buffer command (below) simply take a snapshot<6F>
of the message. At any time before you disconnect, you can enter<65>
a new message, and read that snapshot into your message, where<72>
you can delete any parts that you don't want, which has been made<64>
a lot easier with the message editor enhancements.

Be warned: it is very easy to overuse message quoting, and<6E>
generate huge and hard to read messages. A little goes a long<6E>
way.

The edit buffer is a disk file named MSG.BUF; if the command line<6E>
switch /I is used, the filename is modified in the same way as<61>
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<74>
the newly-coined ``edit buffer''. There is only one buffer, so<73>
only the most recent use of the W)rite-Buffer command is<69>
remembered. The contents of the Edit Buffer is cleared when a new<65>
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<6F>
can include the original author's message as reference. The<68>
R)ead-Buffer command lets you ``quote'' each line with a ``{\tt<74>
>}'' character to make quoted lines stand out.

For callers privilege 4 and above, the W)rite-Buffer command<6E>
asks:

\example{File to write to [CR=Buffer]:}

Allowing you to save messages in a file you specify instead of<6F>
the default buffer file. In this case, subsequent writes are<72>
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<68>
Edit Buffer into your message, as if you had typed it manually.<2E>
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<6F>
are quoting stand out. The second is unfortunate, and is meant to<74>
help you compensate for messages generated by programs that do<64>
not properly support standard ``word wrap'' file format. First<73>
try it without it; if paragraphs look terrible (ie. a series of<6F>
long lines followed by a short line, over and over) then delete<74>
the lines and try again with ``force word-wrap'' YES.

Because R)ead-Buffer reads in the entire edit buffer, you will<6C>
need to delete the lines you don't want; see the D)elete-Line<6E>
enhancement, below.

If you are privilege 4 or higher, R)ead-Buffer asks you an<61>
additional question:

\example{File to read from [CR=Buffer]:}

It will accept any valid pathname. The file better be a text<78>
file. Many uses come to mind -- canned answers for common<6F>
questions, etc.


\subheading{Additional Editor Changes}

Besides the R)ead-Buffer command addition, two very old commands<64>
in the message editor have been radically improved. 

D)elete-Line, which lets you delete a line from your message, now<6F>
accepts a ``range'' of line numbers, with which you can delete<74>
many lines at once. Previously, if you wanted to delete (for<6F>
example) lines 5 through 16, you had to enter ``D 5'' 12 times;<3B>
now you can do it with a single ``D 5-16'' command. 

I)nsert-Line was limited to inserting a single line in your<75>
existing text, too limited to be of much use. I)nsert-Line is now<6F>
a true text-insert command; starting at the line number you<6F>
specify, text is entered until you enter a blank line, as in<69>
normal text entry. Lines below your insertion point are ``moved<65>
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<6E>
L)ines; the little-used T)abs command removed in favor of always<79>
expanding tabs; M)ore command removed in favor of setting L)ines<65>
to 0. The interim G)raphics was removed.

Additions: I)nterface command. It is the so-far promised<65>
language/graphics interface. Please refer to the ``Language''<27>
section of this errata sheet for details. Please note that the<68>
default privilege for this command is very high; if you use<73>
additional languages or graphic interfaces you will want to lower<65>
it.


\subheading{New Main Section Command}
T)riggers are manual controls over event execution. You can<61>
assign triggers to events defined in EVENTS.INI; you can put the<68>
same trigger on any number of events. Events without triggers are<72>
always on, just as they are in previous versions.

There are 8 triggers, which can have one of three possible<6C>
settings: OFF, which means what it says; the trigger and any<6E>
events that use it are disabled. ON allows that event to run when<65>
it's time comes. ONCE does also what it sounds like; after the<68>
event runs successfully, the trigger is turned OFF. This allows<77>
you to setup an event to run one time only, without having to<74>
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<6F>
that event to run when the time becomes 9:00AM. An example would<6C>
be a special FidoNet event that sends mail to any system in the<68>
nodelist directly, for high priority mail, which you would enable<6C>
with a trigger set to ONCE.

The T)riggers command lists events for you to help you see what<61>
you are doing.

\section{Multi-Line Fido Installations}

There is now a way to run different modems on each of the<68>
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<6F>
CALLER.SYS, the caller file -- and does up to ten retries to open<65>
it successfully. So you never have to worry about losing caller<65>
data.

For two-line Fidos, under DoubleDOS, DESQview, etc, you can now<6F>
run both ``sides'' completely from within one ``FIDO''<27>
subdirectory. Events and areas can be assigned to only one<6E>
``task'', by a new option in AREAS.INI and EVENTS.INI, to allow<6F>
controlling which side executes what event, and additionally have<76>
message and file areas unique to a task.

Each systems task ID is the nnnn/I command line option; referring<6E>
to the manual, the /I number is the ``task ID'' that makes each<63>
side unique, and makes Fido create unique logfiles, and handle<6C>
message areas slightly differently.

For example, you have a two line Fido running, with sides<65>
numbered 1 and 2 (1/I and 2/I). The two systems are identical to<74>
the user, and you want to have only one side run FidoNet mail.<2E>
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<6E>
circumstances will side 2 ever execute that event. The second<6E>
event, a Page event, is shared; it has no ID number and therefore<72>
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<61>
identical manner. The other side will not be able to access the<68>
other sides areas. Areas without an ID= statement are shared by<62>
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<6F>
specify options by the first character only; ``O=F'' was<61>
equivelant to ``O=FidoNet'', and so on. I hope you weren't too<6F>
cheap with your typing -- as Fido now requires at least the first<73>
two characters now. This wasn't an arbitrary decision just to<74>
torment you -- the addition of the ``O=Private'' -- as opposed to<74>
the existing ``O=Public'' -- made this necessary. Sorry! SET-FIDO<44>
will inform you of your previous stinginess if necessary.

\example{O=ReadOnly}

Messages cannot be entered in this area, except by privilege<67>
level 7 (system operator).

\example{O=Private}

All messages entered in this area will be marked {\tt(PRIVATE)}.<2E>
This helps those who run BBSs that may have marginal message<67>
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<65>
Fido or other program that can generate .MSG files in this<69>
directory -- this is meant to be used on multi-line Fido<64>
installations, to prevent message file contention. (It is<69>
actually file-locking, done at the right level for a change.) It<49>
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<68>
.TLG timelog files. 

\example{netlog <YES, no>}

Controls whether or not FidoNet creates NETLOG.BBS and the .NLG<4C>
FidoNet call files.

\example{cont-interval <1-60>}

This controls how often CONT FIDONET events are run; in version<6F>
12Q it was fixed at one minute. Also allowed within FidoNet route<74>
language files. 

\example{system-path <pathname>}

Use this to define the pathname that \fido\ uses to locate the<68>
following files: CALLER.SYS, *.LOG, *.NDL, ROUTE.*, NODES.BBS.<2E>
Normally Fido looks for these files in the default directory.

When running more than one \fido\ with a multitasker utility, you<6F>
can now install each \fido\ in it's own subdirectory, but share<72>
critical files like the caller file, etc.

\example{rings <1 - 255>}

\fido\ normally answers the phone (well, modem\dots) on the first<73>
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\<5C>
ignores them. DCM ignores \fido's keywords -- so you can use<73>
FIDO.INI to specify both \fido\ and DCM's installation, saving<6E>
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<6E>
point address). Please see the section on POINTS below for<6F>
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<65>
removed. They have been replaced by the single {\tt text-path}.<2E>
This is where Fido will look for get all .HLP files and text .BBS<42>
files; quotes, WELCOMEs, BULLETIN.1 - BULLETIN.99, etc. 

If multiple languages are implemented, then {\tt text-path} is<69>
where Fido will look for text files not uniquely specified for<6F>
each particular language.

\example{node-path <pathname>}

Where Fido and FidoNet and the MAKELIST program will look for all<6C>
of the NODELIST.* files.

SET-FIDO will {\it not} create these two subdirectories for you;<3B>
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,<2C>
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<68>
language interface is simply an option within the C)hange<67>
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<68>
default settings, if any, are shown above in CAPS -- unless you<6F>
have a PARTICULAR REASON do not change the settings of these<73>
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<68>
be using. Fido will run fine with any multitasker, even one not<6F>
listed here; this is an option to potentially improve<76>
performance. You should see a slight performance increase.<2E>
Replace {\tt <number>} with one of the following: 0:Plain MSDOS;<3B>
1:DoubleDOS; 2:DESQview. Others may be defined later. (Please<73>
refer to the manual about the ``nnnn/I'' command line switch when<65>
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<69>
programs such as the uucp-to-FidoNet gateways software such as<61>
``UFGATE''. (The unix uucp-to-FidoNet gateway software -- ask Tim<69>
Pozar at 1:125/555 for details.)

It enables a program or a person to login normally, but run<75>
another program instead of Fido. There can be up to 10<31>
``external-logins'' at one time. When properly installed, a<>
caller that successfully passes the name and password section of<6F>
the Fido login exits \fido\ and runs a separate program, such as<61>
UFGATE. (It is up to the system operator to install the necessary<72>
programs and batch files to cause this to happen.)

You install this by first creating a batch file that runs your<75>
specified program via the DOS ERRORLEVEL convention. Then in<69>
FIDO.INI, you specify the {\tt external-login-A} ERRORLEVEL to<74>
match (``A'' can be any letter through ``J''). This tells Fido<64>
that when a caller logs in with External-Login A, to exit to DOS<4F>
with this ERRORLEVEL.

Next, for each program or person you wish to invoke the special<61>
login procedure, you assign a special attribute to an otherwise<73>
normal caller in the Fido caller file, ``CALLER.SYS''. This is<69>
done by setting the ADDRESS FIELD in the caller record to the<68>
{\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<65>
normally. The address field is all the separates special logins<6E>
from normal callers.

\example{dial-prefix ``string''}

The string is prepended to the phone number from the nodelist<73>
files before dialing. A space is added between the prefix and the<68>
phone number. Suggestions: put ``P'' for pulse or private PBX<42>
access in there, instead of in NODELIST.BBS with XlatList and<6E>
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<6E>
numbers. The script language is exactly the same as in FidoTerm,<2C>
a shareware telecomm program available from the Fido Software<72>
BBS, except that the screen and console oriented commands have no<6E>
effect or display on the screen.

A bucks character ``\$'' in a phone number invokes the script<70>
processor. The text following the ``\$'' is the script filename<6D>
and arguments, and anything before the ``\$'' is ignored. (That<61>
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<68>
usual ``\underbar{ }'' as defined for the nodelist file format is<69>
fine. 

\example{show-seen-by <yes,no>\hfill ;DEF.: YES}

This affects only users of echo-mail programs CONFMAIL and the<68>
like; if set to ``NO'', Fido suppresses the verbose ``SEEN-BY''<27>
list of nodes.

\example{quick-login <yes,no>\hfill ;DEFAULT: NO}

If ``YES'', the Q)uick-Login command at the local console logs in<69>
the first caller in the caller list (presumably the system<65>
operator). Very handy for local maintenance. Leave disabled if<69>
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.<2E>
In other words, Fido is usable only from the local console. 

{\tt modem-type 2} is for direct-connect installations. When the<68>
CD line goes true, Fido assumes the online and connected state,<2C>
at the baud rate set by {\tt maxbaud <number>} in FIDO.INI. DTR<54>
is used to disconnect. You must use the new script facility to<74>
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<53>
Courier-specific commands, and many ``generic'' 2400 baud modems<6D>
failed. This has been repaired; see modem type {\tt 25}.

{\tt modem-type (14, 16, 17)} have additional initialization<6F>
commands: {\tt AT\&H1\&R2}.

\section{Zmodem file transfer protocol}

This is a fully compatible, standard Zmodem implementation, with<74>
a few fancy features added. You can adjust Zmodems behavior with<74>
the two controls in FIDO.INI (details follow), because Zmodem can<61>
potentially accept data faster than your computer can handle. The<68>
default settings are quite conservative, and should work on all<6C>
machines. 

The block size used depends on the baud rate the connection is<69>
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<69>
halved; minimum block size is 64 bytes. Upon twenty consecutive<76>
blocks with no errors and no line noise junk characters, block<63>
size is doubled; maximum block size is 1024 bytes.

Keep in mind the whole point of having high speed modems and<6E>
protocols is so that you can run as fast as your machine allows;<3B>
a modem capable of 1500 characters per second doesn't make your<75>
computer any faster, all it guarantees is that it won't hold you<6F>
back anymore.

Now that a few months has gone by since ZMODEM was fist installed<65>
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!)<29>
hard disk, DOS 3.3, and an extremely fast modem, such as a US<55>
Robotics Dual Standard, locked at 38,400 baud. Even this<69>
combination is capable of doing 11,500 baud under good<6F>
conditions. There is no need for even ``AT'' type hardware for<6F>
high performance. (At least for file transfer speed alone.)

If you use a multitasker such as DoubleDOS, DESQview, Multilink,<2C>
etc., and you experience high data error rates or lost data, then<65>
under these conditions please DO NOT USE Zmodem Receive full<6C>
streaming. (See {\tt zm-rx-type}.)

\subheading{Zmodem Controls}

The receive controls affect only how your Fido\slash FidoNet or<6F>
FT program receives files; if someone else calls in to download<61>
files, Zmodem will go as fast as their Zmodem tells Fido or FT to<74>
go. (They may have done something like this on their end as<61>
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<74>
at maximum possible data rate, ie. full streaming. This is meant<6E>
for machines that can accept data at ``high speed'', whatever<65>
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<6F>
sending, Fido/FT will do whatever the receiver says.) This is<69>
extremely conservative, and probably only needs to be used in<69>
extreme circumstances, such as under a heavily loaded<65>
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<6E>
files, and the receiver says it can accept full streaming Fido/FT<46>
will send data in full streaming mode, as long as it receives<65>
acknowledges from the receiver every so many [blocks]. The<68>
receiver sends occasional acknowledges, and the sender checks for<6F>
them, without pausing the data flow. If the sender doesn't see an<61>
acknowledge it will stop and wait for one.

At 2400 baud and below, this has all the speed of full streaming,<2C>
with improved error recovery. The slight penalty is the reverse<73>
channel does get used, which could slow some high-speed modems<6D>
down. 

Since the window size is stated in blocks, the size of the window<6F>
depends on the baud rate and error rate; if many errors occur,<2C>
Zmodem shrinks the block size, and hence the window shrinks too;<3B>
if the error rate is exceptionally good, the block size increases<65>
as Zmodem increases block size. Higher baud rates start with<74>
larger blocks.

\goodbreak
\example{window size = [blocks] * block size}

Try starting with [blocks] at 6, which works out to be a 1.5K<EFBFBD>
byte window at 300 and 1200 baud, 3K at 2400, and 6K at 9600 and<6E>
beyond.

HINT: Don't look at the Senders modem activity lights when<65>
adjusting window size; look only at the Receivers lights. The<68>
senders activity can be misleading; for example, the US Robotics<63>
HST has a 32K byte internal buffer, so Zmodem fills it quickly<6C>
then sits and waits for window synchronization; don't let this<69>
fool you into thinking you could make it faster, you can't. Data<74>
can only flow out of the modem into the phone line as fast as it<69>
goes, all that increasing the window size will do is make error<6F>
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<6B>
the same as the previous method, except the size of the window is<69>
fixed, and specified in Kbytes. An 8K window is an 8K window,<2C>
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<6E>
what the receiver can handle. On extremely bad phone lines, it<69>
may take too many errors to get the block size down to one that<61>
works; above 2400, where the block size starts at 1024 bytes, it<69>
will take 16 errors (block size halved every four errors, four<75>
times) to get the 64 byte packet that may work best. 

This option lets you specify the largest block size to start the<68>
transfer with. Try 128 or 64 if you have many errors due to phone<6E>
line noise; if the connection is good, then after every 20 blocks<6B>
the block size will double, and performance improve. 20 blocks<6B>
doesn't take very long when the blocks are 64 bytes each! 

This controls only the starting block size; the block size can<61>
still increase in the normal manner if there are no errors, as<61>
outlines in the beginning of this section.

Please make sure that you use only the following values: 64, 128,<2C>
256, 512, 1024. 

\section{Miscellaneous Additions}

{\bf New command line switch /C}, forces Fido to simply end any<6E>
outstanding FidoNet event, caused by either a reboot while Fido<64>
running (CTL-ALT-DEL) or when using the new {\tt keep-packets}<7D>
option in FIDO.INI.

{\bf New system files: NODELIST.ZDX and NODE\-LIST.NDX} Fido can<61>
access any system listed in the nodelist with an average 
worst-case of four small disk reads -- performance with 10,000<30>
nodes is much faster than most previous versions with only 500<30>
nodes.

MAKELIST creates these, and Fido and all of the supplied tools<6C>
use them. It is an additional index, and contains all the HOSTS<54>
and REGIONS and ZONES in the system. The existing NODELIST.IDX<44>
file has not changed in format nor use; external programs that<61>
use it are not affected.

{\bf WELCOME3.BBS, WELCOME4.BBS and WELCOME5.BBS} are displayed<65>
right after the point where it now displays WELCOME2.BBS.

{\bf Incompletely uploaded or received files} (carrier loss,<2C>
Control-X abort, timeout, etc) no longer clutter the directories;<3B>
Fido kills 'em.

{\bf New option at the {\tt More[c,Y,n]} prompt}: C ==<3D>
Continuous, ie. suspend the ``more'' function until the next<78>
prompt for input.

{\bf NODELIST.SYS is not used} anymore. MAKELIST.EXE used to<74>
generate it, and FIDO.EXE read it. Fido now uses NODELIST.BBS<42>
directly.

{\bf .BBS text files:} When Fido comes across certain control<6F>
codes embedded in .BBS text files such as WELCOME1.BBS, it<69>
performs certain special functions (Page 26 in the manual). The<68>
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<65>
within MsgMgr script files:

\example{LOGFILE {\it logfilename}}

Normally MsgMgr logs it's activity in FIDO.LOG, the standard Fido<64>
log file. With this command, you can route log activity to any<6E>
file or pathname or device, or to eliminate it entirely, to the<68>
device ``NUL''.

You can now specify the name of the script file that the message<67>
manager is to use, instead of just the default ``MSGMGR.INI''.<2E>
For example, you could renumber/purge only your FidoNet area<65>
right before mail time, and then use MsgMgr in the usual manner<65>
after FidoNet.

MsgMgr will also now translate ``LASTREAD'' and ``HW.DAT'' files<65>
if they exist in each message area.

\enddoublecolumns



\pagebreak

\section{FidoNet}

With version 12Q came a rather radical simplification of overall<6C>
FidoNet operation. Gone are all the confusing FidoNet event-type<70>
options. Since there are people looking at this who haven't seen<65>
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<69>
program adhere to the basic FSC001 protocol standard, and we all<6C>
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<6F>
view, was kind of a jumble of complex options in EVENTS.INI and<6E>
less than satisfactory when trying to run continuous outgoing<6E>
mail -- ie. to have packets ready for pickup at any time. I think<6E>
it is safe to say that all of these problems have been fixed. You<6F>
no longer need to have a zillion events throughout the day, and<6E>
newly entered messages no longer sit around until one of those<73>
zillion events comes by. 

The FidoNet event types you specify in EVENTS.INI were completely<6C>
revamped. The previous method involved complex and obscure<72>
options that confused even me -- it was poorly thought out. There<72>
are now only three types of FidoNet event (described below).

There is what I think a good sample installation that should<6C>
cover most peoples needs described below. It should be easy to<74>
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<74>
only FidoNet mail. 

\subheading{Rush FidoNet}

\example{RUSH  2:00  60 FIDONET A}

Very similar to the previous ``vanilla'' FidoNet event, except<70>
that when there is no more mail to send, ie. all the packets have<76>
been delivered or the maximum number or tries has been reached,<2C>
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<74>
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<6B>
packets, and have them available for pickup or delivery at any<6E>
time, while allowing human callers to access Fido freely.

When there is no human caller occupying Fido, and there are<72>
packets to deliver (according to route language files) FidoNet<65>
will make calls once per {\tt dial-interval}.

Other FidoNet systems can call in at any time (well, assuming<6E>
it's not in use), deliver FidoNet mail, and pick up packets<74>
addressed to it.

If a human or a FidoNet mailer generates a message in the FidoNet<65>
message area, FidoNet will immediately add it to an existing<6E>
packet or create a new one; and deliver the packet as per normal<61>
FidoNet routing controls.

\subheading{QUICK FidoNet Option: Obsolete}

The QUICK option is no longer used. All FidoNet events are now,<2C>
by definition, ``QUICK''. This means that you {\it must} run SET-FIDO if you change any of your ROUTE.* files. Which was strongly<6C>
reccommended anyways. So now it's mandatory.

\section{A Sample Installation}

The following is a very good starting point for a full featured<65>
\fido\ installation for a node in the amateur FidoNet network. It<49>
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<74>
from top to bottom, and runs the first event it finds that is<69>
runnable. The RUSH FIDONET event will only run (and therefore<72>
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<6E>
we'll assume usually turned OFF. (When OFF, the event is inert<72>
and will not run.) When turned ON, FidoNet will repacket<65>
according to the route file; in this example, it will make<6B>
packets for messages within our own zone (SEND-TO MYZONE),<2C>
without host routing (NO-ROUTE MYZONE), and dial otu to deliver<65>
those packets as fast as possible (SEND-ONLY). It will stop when<65>
(1) if there were no messages to deliver, (2) as soon as all<6C>
messages are delivered, or (3) the maximum number of tries is<69>
reached.

The second event, FIDONET A, is the normal, mandatory, FidoNet<65>
``ZMH''. SEND-TO ALL simply means enable mailing to all nodes in<69>
the nodelist (note that for inter-zone messages, the contents of<6F>
ROUTE.DEF (elsewhere\dots) will route messages to the proper<65>
zonegate). This event will run until completion; in this example,<2C>
from 2:00AM til 3:00AM.

The third event, CONT FIDONET L, is the ``background'',<2C>
continuous FidoNet event. It will run whenever the previous two<77>
are not. It will make packets according to the route language for<6F>
tag L: packets only to your zone (SEND-TO MYZONE), no default<6C>
host routing (NO-ROUTE MYZONE). FidoNet will make phone calls<6C>
only to nodes in your own net -- HOLD ALL NOT MYNET.

Assume now that it's in the afternoon, and CONT FIDONET L is<69>
running. You are, for example, 1:125/0, the host for net 125.<2E>
1:161/12345 calls and delivers a packet with a message destined<65>
for 1:125/7. If there were messages for 1:161/12345 it would be<62>
on HOLD -- it is outside your net (HOLD ALL NOT MYNET) -- and it<69>
could be picked up at this time.

After it disconnects, Fido unpackets the message. FidoNet then<65>
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,<2C>
immediately calls it and delivers the packet. If '7 were busy,<2C>
then Fido would run and wait for a caller. While Fido remains<6E>
idle (no one calls in), every {\tt dial-interval} FidoNet will<6C>
run, and attempt to deliver that packet to '7.

And further: assume a human caller connects now, with that packet<65>
to '7 still undelivered, and goes into the FidoNet netmail area,<2C>
and enters some messages: another to 1:125/7, one to 1:161/12345,<2C>
and another to say 2:500/5. When the caller disconnects, FidoNet<65>
will packet those messages: the first will go into the existing<6E>
packet for 1:125/7, the second to (say) a new packet for<6F>
1:161/12345, and the third will not be packeted at all -- you<6F>
said SEND-TO, NO-ROUTE MYZONE so it just sits.

With the packets then updated, FidoNet runs again. It calls '7,<2C>
connects, and delivers the packet. (The messages and packet can<61>
then be deleted.) The packet for 1:161/12345 is not delivered,<2C>
since it is outside your net. FidoNet relinquishes control to<74>
Fido, allowing human or FidoNet callers in. 

\section{Points}

\fido\ now (12N) includes basic Point addressing support. Later<65>
versions will provide complete ``boss node'' functions, so that<61>
\fido\ will be able to perform any possible FidoNet mailer<65>
function; zone gate, zone host, net/region host, ordinary node,<2C>
point boss, point node.

\fido\ properly handles all point-addressed messages; it will<6C>
scan for TOPT and FMPT Kludge lines, and incorporate them into<74>
the message address display. 

When reading existing messages, Fido locates the TOPT and FMPT<50>
IFNA Kludge lines, like it always has for INTL lines, and<6E>
incorporates them into the displayed address. To the user or<6F>
sysop, there's nothing to even think about.

When entering a message, node address entry is as it always was,<2C>
but you can add ``{\tt .<1 - 32767>}'' to the node number, or<6F>
just the dot followed by the point number, to send to points<74>
within your own point network. For example: as 125/111, entering<6E>
.33 would address a message to 1:125/111.33, etc. Same syntax and<6E>
behavior as default net, etc.

When replying, Fido does the same as it does with nodes; the<68>
message is To: the From: node, unless it is the same as ``us'' in<69>
which case it reverses the addresses.

Internally, Fido generates TOPT and FMPT lines as the second and<6E>
third lines in the .MSG file; INTL still comes first. Fido will<6C>
locate any of these three lines as long as they occur within the<68>
first 256 bytes of text following the message header.

Note that Fido will display point numbers only if the point<6E>
number is NOT zero. 1:125/111.555 will display that way; .0 will<6C>
display as 1:125/111 only.

\section{Wazoo Protocol}

\fido\ now supports two network protocols automatically. One is<69>
``FidoNet'', known in some circles as ``FSC001'', after the<68>
filename of the standards document generated by Randy Bush. Fido<64>
has supported this protocol since 1985.

The other, newer protocol is called ``Wazoo'', and was originally<6C>
implemented in Wynn Wagner's Opus program, and now it seems the<68>
most popular program supporting Wazoo is ``BinkleyTerm''. Both<74>
also do FSC001 style FidoNet. Wazoo operates in a similar manner,<2C>
but uses Zmodem for it's transfers and can support ``file<6C>
requests'', where the call originator can ``download'' files from<6F>
the remote computer without the intervention of an operator to do<64>
``file attaches''. (With appropriate controls, etc.)

There is no impact on existing \fido\ installations regarding<6E>
security, setup or installation, etc. The choice of Wazoo vs.<2E>
FidoNet is made automatically, though the system operator can<61>
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<65>
incoming message(s) and/or file(s), 

\example{keep-packets <yes,no>}

{\tt keep-packets} can provide much better FidoNet performance<63>
improvement for some systems.

When Fido is first run, and there is an active FidoNet event,<2C>
FidoNet is invoked to create all the packets, if any, that will<6C>
be delivered or picked up by other nodes. It then either runs the<68>
event until completion, or returns control to Fido (during CONT<4E>
events).

If you are also using DOS errorlevels (mail- or file-errorlevel,<2C>
external-logins, etc) FidoNet ends the event before returning to<74>
DOS; the undelivered packets deleted, and a log file summary is<69>
made, before Fido returns to DOS.

Upon return from the DOS errorlevel processing, Fido then<65>
recreates the so-far undelivered packets, and attempts to deliver<65>
them or hold them for pickup, as determined by the event.

All of this packet/unpacket activity can take signifigant amounts<74>
of time, especially if you have many packets to deliver, or your<75>
system executes many DOS errorlevels per schedule.

{\tt keep-packets yes} makes Fido not delete the packets when<65>
executing a DOS errorlevel; therefore the time it took to do 
end-schedule work, plus recreate the packets upon reentry to<74>
Fido, is saved. 

(FidoNet will always do end-schedule processing if you type<70>
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<72>
are outstanding packets, the nodelist files and the .OUT and .FLO<4C>
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)<29>
while Fido was running, the nodelist files and packet files will<6C>
not be updated properly. 

\item{2} MAKELIST will not let you process a new nodelist if<69>
there are packets outstanding, since it needs to create new<65>
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<68>
log file, and leave the nodelist files free:

\example{FIDO /C}

With /C, Fido will end any outstanding event, and then return to<74>
DOS. You should use {\tt FIDO/C} before running automatically<6C>
MAKELIST, or in your AUTOEXEC batch file, if you are using {\tt<74>
keep-packets}. 

You can use {\tt FIDO/C} even if there are no packets<74>
outstanding, or if {\tt keep-packets} is NO.


\example{system-name}

An optional 60 character string that is the ``name'' of your<75>
system. Fido transmits this name to the remote computer during<6E>
Wazoo sessions. {\tt session-password} may be required for<6F>
connecting to some other Wazoo-based systems; please make<6B>
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<6E>
FidoNet FSC001 protocol compatibility. Unfortunately in the real<61>
world there are varying levels of compliance to FSC001; the<68>
default is pretty ``loose'', for maximum compatibility. {\tt<74>
fsc011 yes} lets \fido\ accept so-called ``DIETIFNA'' protocol,<2C>
which means it can skip the slow MODEM7 filename; however SEAdog<6F>
does not accept TELINK blocks and file attaches will then fail.<2E>
{\tt wazoo no} forces Fido to do only FSC001, ie. pre-12M<32>
compatibility. {\tt multi-tsync no} forces Fido back to 11W style<6C>
single TSYNC character; there is nearly no reason to do this.<2E>
{\tt fsc001 yes} makes FidoNet and it's XMODEM protocol driver<65>
conform to 
letter-of-the-law FSC001 specifications; alas, not many FidoNet<65>
``compatible'' systems will then work, including many \fido\<5C>
programs!

\section{File Requests}

Fido now supports file request in either FSC001-type or Wazoo<6F>
FidoNet sessions. A file request is a file transfer originated by<62>
the calling system, that requests one of more files by name; the<68>
called system then transmits the requested files in that same<6D>
session.

The receiving system has full control over what it will and will<6C>
not allow to be requested; this is to prevent the obvious ``file<6C>
request *.*'' getting copyrighted programs, critical data files<65>
(caller lists anyone?) and other problems.

There are shareware and free programs that will automatically<6C>
generate a file request, given only the desired filenames and the<68>
node address to request from. What follows is the technical<61>
description of how it works.

A file request consists of a file with a special name sent to the<68>
receiving system, the one that will possibly honor the request.<2E>
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<62>
00010002.REQ; a request to 125/111 would be 007D006F.REQ.

Inside this file, one per line, are the file(s) to be requested.<2E>
Each line ends with a CR or CR/LF. Filenames can be any length,<2C>
and may not contain pathnames or drive letters. (Fido will ignore<72>
them.) Filenames can include wildcards.

\subheading{Generating File Requests}

You can request files from within Fido; it is an option in the<68>
message editor in the FidoNet message area. You can enter any<6E>
number of filenames, with wildcards, as will fit on the line.<2E>
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<73>
of files that may be requestable from the system. Initially only<6C>
two sample files are requestable (see below), and the system<65>
operator needs to add to this list all files that you wish to be<62>
requestable remotely.

As provided by Fido Software, there are only two requestable<6C>
files: ``ABOUT'', which is a short description of what your<75>
system is ``about'', and ``FILES'', which is the list of files<65>
requestable from your system. In the hobbyist FidoNet network, it<69>
is traditional (and useful!) to have these two files requestable<6C>
at all times, so that other system operators can find out about<75>
your BBS without having to manually call and ask. 

You can also restrict File Requests to specific hours, with the<68>
event type FILEREQUEST, in EVENTS.INI:

\example{ALL  3:00  1380  FILEREQUEST}

This allows file requests at any time except between 2:00 and<6E>
3:00AM, the Zone Mail Hour. A file request made while it is<69>
disabled will send the contents of the file ``NOFILEREQ.BBS'' to<74>
the requesting system as file XXXXYYYY.FRQ, where XXXXYYY is the<68>
requesting node's address, as described under the .REQ file.<2E>
Presumably you'd list in NOFILEREQ.BBS the reasons the file<6C>
request was not honored.

\subheading{The FILEREQ.INI File}

This file is used to control how \fido\ handles file requests. It<49>
is a plain ASCII text file, that you create and maintain, that<61>
contains the list of files and directories you wish to have<76>
available for other systems to file-request with their FidoNet<65>
type mailer.

You can also put comments into this file; comments are any line<6E>
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<65>
short.

All other lines in the file define requestable directories or<6F>
specific files. The most popular method is to make the contents<74>
of a directory requestable. This is easy; simply list the<68>
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<72>
requestable. There is one odd side effect; if the filename you<6F>
request exists in more than one directory, \fido\ will send you<6F>
every single one. Too bad. For example, ``FILES.BBS''. Fido will<6C>
transmit, just as you asked, FILES.BBS from all directories that<61>
contain it. Too bad if that's not what you MEANT, that's what you<6F>
SAID.

Note also that ``FILE'' can contain wildcards; ``*.*'' for<6F>
instance. It will of course return every single requestable file<6C>
stored in your system. (Ugh.)

It is also useful to have ``logical'' file requests; for example,<2C>
you want to announce that requesting the file ``NODELIST'' will<6C>
always return the very latest nodelist file, no matter what it is<69>
really named, without having to constantly rename the file: 

\example{NODELIST=LISTS/NODELIST.*}

Whenever someone requests the filename ``NODELIST'', (the name to<74>
the left of the ``='' equals sign) Fido will send them your file<6C>
(after the ``='' equals sign), that matches ``LISTS/NODELIST.*''.<2E>
This lets files be requested by their logical names, no matter<65>
where they may reside on your disk. (For revenge, you can have a<>
file called ``CALLER.SYS'' that returned something nasty instead<61>
of the actual caller file.)

You can use this in other ways: you could respond to a request<73>
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<6C>
name. For example, if you wanted to have a ``kit'' of files for<6F>
new system operators requestable, you could convert the request<73>
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<65>
that match all requests. 


The third method is for when you want to make single files in<69>
arbitrary subdirectories available. For example, you might want<6E>
to make certain files in your ``/FIDO'' directory available, but<75>
still maintain absolute security. Entering ``FILENAME=FILENAME''<27>
works, but is tedious and redundant. There is a short form for<6F>
when you just want to make a file requestable with it's original<61>
name, and not necessarily provide multiple files, etc:

\example{C:/LIST/NODELIST.099}

A file request for the filename portion (``NODELIST.099'') causes<65>
your system to send that file, period. The pathname is used<65>
locally, in your system only; it is not requestable nor<6F>
accessible. This shorthand lets you generate lists of files and<6E>
place them, as-is, into FILEREQ.INI.


\subheading{Nodemaps}

\fido\ saves nodemaps it creates for each FidoNet schedule tag.<2E>
(Nodemaps are what the Router produces by reading the ROUTE.*<2A>
routing language files, and applying them to the file<6C>
NODELIST.NMP.) There is one nodemap file (NODEMAP.tag) per<65>
schedule tag, and each file is four bytes per node in the<68>
nodelist -- or 24K per schedule you use for a 6,000 node<64>
nodelist. FidoNet generates a nodemap the first time each event<6E>
runs -- after that changing FidoNet schedules is nearly<6C>
instantaneous. (You can disable this (why?!) with the FIDO.INI<4E>
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<68>
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<61>
change default behavior, mainly NET and ZONE. BEGIN saves the<68>
current state, and END restores them. NET and ZONE changes within<69>
a BEGIN/END group are local to that group; after the END, the<68>
values of NET and ZONE are restored to what they were at the time<6D>
the BEGIN statement was executed. You can nest BEGIN and END up<75>
to four levels deep.

\smallskip

The one-argument commands POLL, PICKUP, NO-ROUTE, ACCEPT-FROM,<2C>
HOLD, SEND-TO can be ``stacked'' together, for faster execution.<2E>
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<61>
once (when the ``All'' is read) instead of one at a time. ``ALL''<27>
makes the router apply the commands to all nodes in the nodelist;<3B>
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<74>
the current ROUTE-TO command, you can force all messages routed<65>
to the alias node, regardless of other routing or files attached.

For example, you exchange mail with a person who runs a node with<74>
more than one alias address; for example 105/6, 105/0, 1/2 and<6E>
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<6C>
it does a ``route-to'' as part of it's action, it is a new<65>
command entirely. Route-to only does one level of indirection;<3B>
alias-as adds a second. Alias-as can be thought of as a kind of<6F>
``route-to route-to''. 

Route-to defines to what destination node a message goes to,<2C>
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<6E>
processes ROUTE.DEF before looking for ROUTE.(tag) and/or<6F>
ROUTE.BBS. This lets you do routing controls in common with all<6C>
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<6F>
agree it is an excellent idea. It does what you think it does.<2E>
You now have an alternative to all those scroungy little<6C>
ROUTE.<tag> files; put them all into ROUTE.BBS (maybe keep<65>
ROUTE.DEF, it partitions that nicely and doesn't slow things<67>
down) for ease in maintenance.

If no IF-SCHEDULE statements are used, then FidoNet processes the<68>
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<74>
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<6E>
before it (if any). Processing is as you'd expect.

If you have commands to execute for all schedules (say, PICKUP<55>
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<65>
node; the supplied ROUTE.DEF file implements IFNA type zone<6E>
gating. There is no restriction on Fido's ZoneGate. For example,<2C>
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<62>
issued before this event starts. This is intended for special<61>
modems such as the TrailBlazer where you might want to enable<6C>
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<6C>
specified zone.

\enddoublecolumns
\bye