                 Changes & Enhancements not in the Book

                       Fido/FidoNet version 12R
                            7 November, 1989

            Fido Software, Box 77731, San Francisco CA 94107
               voice: 415-764-1688    data: 415-764-1629

New Commands

You will need to run the program "12R.EXE" to upgrade your¨
COMMANDS.INI file before you can upgrade to Fido/FidoNet version¨
12R. It will add the new commands in the proper place plus add¨
other version-identifying information. (It is safe to run the¨
program more than once, and you can peek with your editor to see¨
what it has done -- it's not a secret!)

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.

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 ">"¨
character to make quoted lines stand out.

For callers privilege 4 and above, the W)rite-Buffer command¨
asks:

	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.

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:

	Prefix each line with ">"? (y,N):
	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:

	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.

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.

New Change Sub-command

A new command has been added to the C)hange command menu;¨
G)raphics. It is meant to allow the sysop to install an¨
additional set of .BBS text files (WELCOME2,BBS, etc) that¨
contain graphic or other information, that can be chosen by each¨
caller.

Alas, this feature isn't used yet -- hence the default privilege¨
of 7 -- because I thought it out poorly and had to yank it at the¨
last minute. Profuse apologies! I promise I will make it up to¨
you soon!

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:

	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.

--------------------------------

Multi-Line Fido Installations

Once again, multi-line operation has been improved. There is now¨
a way to run different modems on each of the different systems;¨
See the new FIDO.INI option, system-path. Thanks go to Ken¨
Ganshirt for this one.

It was never mentioned before, but Fido/FidoNet 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:

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.

msgarea= msg    D="Messages"    O=FidoNet ID=1
filearea= inbound U=outbound    D="Files" O=FidoNet ID=2

Options in AREAS.INI 

Please note that previously, 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.

	O=Private

All messages entered in this area will be marked (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.

	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.

	O=Anon

When a new message is created, it is marked From: Anon.

	O=Public

Makes Fido not ask Private? (y,N); all messages are public.

--------------------------------

New keywords in FIDO.INI

system-path <pathname>

Use this to define the pathname that Fido/FidoNet 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/FidoNet with a multitasker¨
utility, you can now install each Fido/FidoNet in it's own¨
subdirectory, but share critical files like the caller file, etc.

rings <1 - 255>

Fido/FidoNet normally answers the phone (well, modem...) on the¨
first ring; this lets you change it to something else. 

directory
key
aka
system
sysop
point
log
flag

These are DCM (Dutchie's Conference Mailer) keywords;¨
Fido/FidoNet  ignores them. DCM ignores Fido/FidoNet's keywords¨
-- so you can use FIDO.INI to specify both Fido/FidoNet and DCM's¨
installation, saving all that clutter and extra editing.

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.

help-path <pathname>
bbs-path <pathname>
node-path <pathname>

IMPORTANT NOTE: There may be a change in the way Fido/FidoNet¨
uses the help-path and bbs-path pathnames -- they may become¨
"obsolete" to allow a decent implementation of the  G)raphics¨
command. The change will be no worse than simply using another¨
keyword. It will be easy, and worth it.

These control from where Fido will access system files.  help­
path is where Fido will get all .HLP files. bbs-path is where¨
Fido will look for all text .BBS files; quotes, WELCOMEs,¨
BULLETIN.1 - BULLETIN.99, etc. Certain .BBS files remain are¨
exempt: NODELIST.BBS, NODES.BBS, ROUTE.BBS, TIMELOG.BBS and of¨
course all the FILES.BBS'. node-path is where Fido and FidoNet¨
and the MAKELIST program will look for all of the NODELIST.*¨
files.

SET-FIDO will not create these subdirectories for you; you must¨
create them manually and copy the files into them. This is not¨
necessary; it only allows you to keep a less cluttered FIDO¨
directory.

zm-rx-type <number>	;DEFAULT: 0
zm-tx-type <number>	;DEFAULT: 0
zm-tx-start <number>	;DEFAULT: 1024

Please refer to the "ZMODEM" section in this errata sheet.

keep-nmp <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. 

multi-tasker <number>	;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 <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.)

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/FidoNet 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 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 exact¨
string below:

	external-login A

Letters "A" through "J" identify which of the 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.

	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.

	NUMBER		PREFIX	RESULT
	297-9145	(none)	ATDT2979145
	297-9145	P..	ATDTP..2979145
	642-1034	$DIAL	$DIAL 6421034
	$dial_642-1034	(none)	$DIAL 6421034
	$dial_642-1034	P..	P..$DIAL 6421034

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 "_" as defined for the nodelist file format is fine. 

	show-seen-by <yes,no>	;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.

	quick-login <yes,no>	;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.

	modem-type 0	;no modem
	modem-type 2	;Direct connection
	modem-type 8	;POPCOM 2400
	modem-type 13	;Multitech 224e
	modem-type 12	;see below
	modem-type 21	;Hayes V-series no ASB
	modem-type 22	;ditto, locked 9600
	modem-type 23	;ditto, locked 19,200
	modem-type 24	;USR HST, locked 38,400
	modem-type 25	;USR Courier 2400,
			;Hardware Handshake

modem-type 0 prevents Fido/FidoNet from using the modem at all.¨
In other words, Fido is usable only from the local console. 

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 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.

modem-type 8 is for the Prentice POPCOM 2400 baud modem.

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 25.

modem-type (14, 16, 17) have additional initialization commands:¨
AT&H1&R2.

--------------------------------

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 zm-tx-start).

	Block Size	Baud Rate
	1024		over 2400
	512		2400
	256		1200 & below

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/FidoNet, 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 zm-rx-type.)

Zmodem Controls

The receive controls affect only how your Fido/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.)

REC'V: FULL STREAMING

	FidoTerm:	ZRXTYPE 0 or 0/D
	Fido:		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. 

REC'V: FULLY ACK'ED

	FidoTerm:	ZRXTYPE 1 or 1/D
	Fido:		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.

TRANSMIT: VARIABLE WINDOW

	FidoTerm:	ZTXTYPE 1 - 64/U
	Fido:    	zm-tx-type 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.

	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. 

TRANSMIT: FIXED SIZE WINDOW

	FidoTerm:    ZTXTYPE 1024 - 65536
	FidoTerm:    1024 - 65536/U
	Fido:        zm-tx-type 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.

TRANSMIT: START BLOCK SIZE

	Fido:    zm-tx-start 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. 

--------------------------------

Miscellaneous Additions

New system files: NODELIST.ZDX and NODELIST.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.

WELCOME3.BBS, WELCOME4.BBS and WELCOME5.BBS are displayed right¨
after the point where it now displays WELCOME2.BBS.

Incompletely uploaded or received files (carrier loss, Control-X¨
abort, timeout, etc) no longer clutter the directories; Fido¨
kills 'em.

New option at the More[c,Y,n] prompt: C == Continuous, ie.¨
suspend the "more" function until the next prompt for input.

NODELIST.SYS is not used anymore. MAKELIST.EXE used to generate¨
it, and FIDO.EXE read it. Fido now uses NODELIST.BBS directly.

.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:

Control-D    Fido immediately displays a "More" pause prompt.

Control-X    Suspends auto-line wrap until the next CR is found.¨
This allows embedding long ANSI sequences without word wrap¨
messing you up. (Remember mechanical typewriters? This is a¨
"margin release"!)

Control-Z    Fido treats this as the end of the file.

MsgMgr.EXE options added: New keyword that can be used within¨
MsgMgr script files:

	LOGFILE 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.

----------------------------------------------------------------

FidoNet

Once again, the FidoNet portion of Fido/FidoNet has received a¨
major overhaul. At this point (12q) performance, simplicity, and¨
compatibility should be just about "all there".

With version 12Q comes 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/FidoNet since version 11, I'll sum up the changes here:

	- True three-level addressing (v12)
	- Continuous incoming mail (v12)
	- Wazoo/Zmodem protocol (v12m)
	- Usable continuous outgoing mail (v12m)
	- File Requesting (v12m)
	- True continuous outgoing mail (v12q)
	- Incremental packeting (v12q)
	- Basic point support
	- 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.

--------------------------------

FidoNet Events

There are three types of FidoNet events, each described below. 

Normal FidoNet

	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. 

Rush FidoNet

	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¨
T)rigger; you can define an event to run all day long ( 0:00¨
1440), and use it to manually override normal scheduling.

Continuous FidoNet

	CONT  2:00  60  FIDONET A

True continuous outgoing mail. This causes Fido/FidoNet 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 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.

QUICK FidoNet Option: Obsolete

The QUICK option is no longer used -- though SET-FIDO will not¨
(for now) complain. All FidoNet events are now, by definition,¨
"QUICK". This means that you must run SET-FIDO if you change any¨
of your ROUTE.* files. Which was strongly reccommended anyways.¨
So now it's mandatory.

--------------------------------

A Sample Installation

The following is a very good starting point for a full featured¨
Fido/FidoNet installation for a node in the amateur FidoNet¨
network. It is described in detail below:

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:

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...) 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 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. 

--------------------------------

Points

Fido/FidoNet now (12N) includes basic Point addressing support.¨
Later versions will provide complete "boss node" functions, so¨
that Fido/FidoNet will be able to perform any possible FidoNet¨
mailer function; zone gate, zone host, net/region host, ordinary¨
node, point boss, point node.

Fido/FidoNet 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 ".<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.

--------------------------------

Wazoo Protocol

Fido/FidoNet 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/FidoNet 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.

There are FIDO.INI options that were added to control things.¨
Most of the options should be left as-is. 

fsc011 <yes,no>      ;default: NO
wazoo <yes,no>       ;def.: YES
multi-tsync <yes,no> ;def.: YES
fsc001 <yes,no>      ;default: NO

These 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. fsc011 yes lets¨
Fido/FidoNet 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. wazoo no forces¨
Fido to do only FSC001, ie. pre-12M compatibility. multi-tsync no¨
forces Fido back to 11W style single TSYNC character; there is¨
nearly no reason to do this. 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/FidoNet¨
programs!

system-name is an optional 60 character string that is the "name"¨
of your system. Fido transmits this name to the remote computer¨
during Wazoo sessions. session-password may be required for¨
connecting to some other Wazoo-based systems; please make¨
arrangements with the person requiring it.

--------------------------------

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:

	XXXXYYYY.REQ

Where: XXXX is the receiving system's net number, in 
four-digit hexadecimal, and 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.

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.

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:

	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 "NOFREQ.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.
The FILEREQ.INI File

This file is used to control how Fido/FidoNet 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:

;
;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.

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/FidoNet 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: 

	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:

	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:

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:

	C:/LIST/NODELIST.099

A file request for the filename portion (here, "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.

Nodemaps

Fido/FidoNet 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 keep-nodemaps no.)

--------------------------------

Routing Language Additions

    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.

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:

	Send-To All, PickUp All

They can now be stacked onto one argument, as in:

	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.

	ALIAS-AS <alias>, <nodes...>

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.

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:

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. 

IF-SCHEDULE A
 	schedule A statements ...
END-IF

If the currently executing schedule is "A", then the statements¨
between the IF...END are executed, otherwise they are ignored.

IF-SCHEDULE M
	schedule M statements ...

IF-SCHEDULE B
	schedule B statements ...

IF-SCHEDULE D
	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.

	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:

;
;Do IFNA Kludge type Zone Gating
;
Zone 2 ZoneGate 1:1/2
Zone 3 ZoneGate 1:1/3

	DIAL-TRIES n
	CONNECT-TRIES n

Maximum number of times to dial each node. (Default is "dial-
tries" and "connect-tries", respectively, in FIDO.INI)

	MYZONE

A modifier keyword, meaning All nodes in my own zone.

	THISZONE

Another modifier keyword, meaning All nodes in the currently¨
specified zone.
