1240 lines
47 KiB
Plaintext
1240 lines
47 KiB
Plaintext
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<75>
|
||
COMMANDS.INI file before you can upgrade to Fido/FidoNet version<6F>
|
||
12R. It will add the new commands in the proper place plus add<64>
|
||
other version-identifying information. (It is safe to run the<68>
|
||
program more than once, and you can peek with your editor to see<65>
|
||
what it has done -- it's not a secret!)
|
||
|
||
Replying and Quoting
|
||
|
||
A new major feature has been added to Fido; "message quoting"<22>
|
||
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.
|
||
|
||
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<68>
|
||
newly-coined "edit buffer". There is only one buffer, so only the<68>
|
||
most recent use of the W)rite-Buffer command is remembered. The<68>
|
||
contents of the Edit Buffer is cleared when a new caller<65>
|
||
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 ">"<22>
|
||
character to make quoted lines stand out.
|
||
|
||
For callers privilege 4 and above, the W)rite-Buffer command<6E>
|
||
asks:
|
||
|
||
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.
|
||
|
||
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:
|
||
|
||
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<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 try<72>
|
||
it without it; if paragraphs look terrible (ie. a series of long<6E>
|
||
lines followed by a short line, over and over) then delete the<68>
|
||
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:
|
||
|
||
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.
|
||
|
||
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 many<6E>
|
||
lines at once. Previously, if you wanted to delete (for example)<29>
|
||
lines 5 through 16, you had to enter "D 5" 12 times; now you can<61>
|
||
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.
|
||
|
||
New Change Sub-command
|
||
|
||
A new command has been added to the C)hange command menu;<3B>
|
||
G)raphics. It is meant to allow the sysop to install an<61>
|
||
additional set of .BBS text files (WELCOME2,BBS, etc) that<61>
|
||
contain graphic or other information, that can be chosen by each<63>
|
||
caller.
|
||
|
||
Alas, this feature isn't used yet -- hence the default privilege<67>
|
||
of 7 -- because I thought it out poorly and had to yank it at the<68>
|
||
last minute. Profuse apologies! I promise I will make it up to<74>
|
||
you soon!
|
||
|
||
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:
|
||
|
||
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.
|
||
|
||
--------------------------------
|
||
|
||
Multi-Line Fido Installations
|
||
|
||
Once again, multi-line operation has been improved. There is now<6F>
|
||
a way to run different modems on each of the different systems;<3B>
|
||
See the new FIDO.INI option, system-path. Thanks go to Ken<65>
|
||
Ganshirt for this one.
|
||
|
||
It was never mentioned before, but Fido/FidoNet does file locking<6E>
|
||
on CALLER.SYS, the caller file -- and does up to ten retries to<74>
|
||
open it successfully. So you never have to worry about losing<6E>
|
||
caller data.
|
||
|
||
For two-line Fidos, under DoubleDOS, DESQview, etc, you can now<6F>
|
||
run both "sides" completely from within one "FIDO" subdirectory.<2E>
|
||
Events and areas can be assigned to only one "task", by a new<65>
|
||
option in AREAS.INI and EVENTS.INI, to allow controlling which<63>
|
||
side executes what event, and additionally have message and file<6C>
|
||
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:
|
||
|
||
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.
|
||
|
||
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<68>
|
||
first character only; "O=F" was equivelant to "O=FidoNet", and so<73>
|
||
on. I hope you weren't too cheap with your typing -- as Fido now<6F>
|
||
requires at least the first two characters now. This wasn't an<61>
|
||
arbitrary decision just to torment you -- the addition of the<68>
|
||
"O=Private" -- as opposed to the existing "O=Public" -- made this<69>
|
||
necessary. Sorry! SET-FIDO will inform you of your previous<75>
|
||
stinginess if necessary.
|
||
|
||
O=Private
|
||
|
||
All messages entered in this area will be marked (PRIVATE). This<69>
|
||
helps those who run BBSs that may have marginal message contents;<3B>
|
||
snoopy types simply cannot see anything, so you don't have to<74>
|
||
worry about getting caught.
|
||
|
||
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.
|
||
|
||
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<74>
|
||
the following files: CALLER.SYS, *.LOG, *.NDL, ROUTE.*,<2C>
|
||
NODES.BBS. Normally Fido looks for these files in the default<6C>
|
||
directory.
|
||
|
||
When running more than one Fido/FidoNet with a multitasker<65>
|
||
utility, you can now install each Fido/FidoNet in it's own<77>
|
||
subdirectory, but share critical files like the caller file, etc.
|
||
|
||
rings <1 - 255>
|
||
|
||
Fido/FidoNet normally answers the phone (well, modem...) on the<68>
|
||
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;<3B>
|
||
Fido/FidoNet ignores them. DCM ignores Fido/FidoNet's keywords<64>
|
||
-- 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<6E>
|
||
point address). Please see the section on POINTS below for<6F>
|
||
details.
|
||
|
||
help-path <pathname>
|
||
bbs-path <pathname>
|
||
node-path <pathname>
|
||
|
||
IMPORTANT NOTE: There may be a change in the way Fido/FidoNet<65>
|
||
uses the help-path and bbs-path pathnames -- they may become<6D>
|
||
"obsolete" to allow a decent implementation of the G)raphics<63>
|
||
command. The change will be no worse than simply using another<65>
|
||
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<72>
|
||
Fido will look for all text .BBS files; quotes, WELCOMEs,<2C>
|
||
BULLETIN.1 - BULLETIN.99, etc. Certain .BBS files remain are<72>
|
||
exempt: NODELIST.BBS, NODES.BBS, ROUTE.BBS, TIMELOG.BBS and of<6F>
|
||
course all the FILES.BBS'. node-path is where Fido and FidoNet<65>
|
||
and the MAKELIST program will look for all of the NODELIST.*<2A>
|
||
files.
|
||
|
||
SET-FIDO will not create these subdirectories for you; you must<73>
|
||
create them manually and copy the files into them. This is not<6F>
|
||
necessary; it only allows you to keep a less cluttered FIDO<44>
|
||
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<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.
|
||
|
||
multi-tasker <number> ;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 <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.)
|
||
|
||
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 "external
|
||
logins" at one time. When properly installed, a caller that<61>
|
||
successfully passes the name and password section of the Fido<64>
|
||
login exits Fido/FidoNet 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 external-login-A ERRORLEVEL to match<63>
|
||
("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<69>
|
||
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 done<6E>
|
||
by setting the ADDRESS FIELD in the caller record to the exact<63>
|
||
string below:
|
||
|
||
external-login A
|
||
|
||
Letters "A" through "J" identify which of the External-login<69>
|
||
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.
|
||
|
||
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.
|
||
|
||
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<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 and<6E>
|
||
arguments, and anything before the "$" is ignored. (That lets you<6F>
|
||
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 "_" 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<68>
|
||
like; if set to "NO", Fido suppresses the verbose "SEEN-BY" list<73>
|
||
of nodes.
|
||
|
||
quick-login <yes,no> ;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.
|
||
|
||
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.<2E>
|
||
In other words, Fido is usable only from the local console.
|
||
|
||
modem-type 2 is for direct-connect installations. When the CD<43>
|
||
line goes true, Fido assumes the online and connected state, at<61>
|
||
the baud rate set by maxbaud <number> in FIDO.INI. DTR is used to<74>
|
||
disconnect. You must use the new script facility to accomplish<73>
|
||
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.<2E>
|
||
This has been repaired; see modem type 25.
|
||
|
||
modem-type (14, 16, 17) have additional initialization commands:<3A>
|
||
AT&H1&R2.
|
||
|
||
--------------------------------
|
||
|
||
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 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<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/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!)<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 high<67>
|
||
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 zm-rx-type.)
|
||
|
||
Zmodem Controls
|
||
|
||
The receive controls affect only how your Fido/FidoNet or FT<46>
|
||
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.)
|
||
|
||
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<74>
|
||
at maximum possible data rate, ie. full streaming. This is meant<6E>
|
||
for machines that can accept data at "high speed", whatever that<61>
|
||
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<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.
|
||
|
||
TRANSMIT: VARIABLE WINDOW
|
||
|
||
FidoTerm: ZTXTYPE 1 - 64/U
|
||
Fido: zm-tx-type 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.
|
||
|
||
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.
|
||
|
||
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<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.
|
||
|
||
TRANSMIT: START BLOCK SIZE
|
||
|
||
Fido: zm-tx-start 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.
|
||
|
||
--------------------------------
|
||
|
||
Miscellaneous Additions
|
||
|
||
New system files: NODELIST.ZDX and NODELIST.NDX Fido can access<73>
|
||
any system listed in the nodelist with an average worst-case of<6F>
|
||
four small disk reads -- performance with 10,000 nodes is much<63>
|
||
faster than most previous versions with only 500 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.
|
||
|
||
WELCOME3.BBS, WELCOME4.BBS and WELCOME5.BBS are displayed right<68>
|
||
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<64>
|
||
kills 'em.
|
||
|
||
New option at the More[c,Y,n] prompt: C == Continuous, ie.<2E>
|
||
suspend the "more" function until the next prompt for input.
|
||
|
||
NODELIST.SYS is not used anymore. MAKELIST.EXE used to generate<74>
|
||
it, and FIDO.EXE read it. Fido now uses NODELIST.BBS directly.
|
||
|
||
.BBS text files: When Fido comes across certain control codes<65>
|
||
embedded in .BBS text files such as WELCOME1.BBS, it performs<6D>
|
||
certain special functions (Page 26 in the manual). The following<6E>
|
||
were added:
|
||
|
||
Control-D Fido immediately displays a "More" pause prompt.
|
||
|
||
Control-X Suspends auto-line wrap until the next CR is found.<2E>
|
||
This allows embedding long ANSI sequences without word wrap<61>
|
||
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<69>
|
||
MsgMgr script files:
|
||
|
||
LOGFILE 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". For<6F>
|
||
example, you could renumber/purge only your FidoNet area right<68>
|
||
before mail time, and then use MsgMgr in the usual manner after<65>
|
||
FidoNet.
|
||
|
||
MsgMgr will also now translate "LASTREAD" and "HW.DAT" files if<69>
|
||
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<6E>
|
||
compatibility should be just about "all there".
|
||
|
||
With version 12Q comes 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/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<61>
|
||
adhere to the basic FSC001 protocol standard, and we all tested<65>
|
||
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.
|
||
|
||
--------------------------------
|
||
|
||
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<74>
|
||
only FidoNet mail.
|
||
|
||
Rush FidoNet
|
||
|
||
RUSH 2:00 60 FIDONET A
|
||
|
||
Very similar to the previous "vanilla" FidoNet event, except that<61>
|
||
when there is no more mail to send, ie. all the packets have been<65>
|
||
delivered or the maximum number or tries has been reached, the<68>
|
||
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<30>
|
||
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<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 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.
|
||
|
||
QUICK FidoNet Option: Obsolete
|
||
|
||
The QUICK option is no longer used -- though SET-FIDO will not<6F>
|
||
(for now) complain. All FidoNet events are now, by definition,<2C>
|
||
"QUICK". This means that you must run SET-FIDO if you change any<6E>
|
||
of your ROUTE.* files. Which was strongly reccommended anyways.<2E>
|
||
So now it's mandatory.
|
||
|
||
--------------------------------
|
||
|
||
A Sample Installation
|
||
|
||
The following is a very good starting point for a full featured<65>
|
||
Fido/FidoNet installation for a node in the amateur FidoNet<65>
|
||
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<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:
|
||
|
||
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...) 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", continuous<75>
|
||
FidoNet event. It will run whenever the previous two are not. It<49>
|
||
will make packets according to the route language for tag L:<3A>
|
||
packets only to your zone (SEND-TO MYZONE), no default host<73>
|
||
routing (NO-ROUTE MYZONE). FidoNet will make phone calls only to<74>
|
||
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 dial-interval FidoNet will run, and<6E>
|
||
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.
|
||
|
||
--------------------------------
|
||
|
||
Points
|
||
|
||
Fido/FidoNet now (12N) includes basic Point addressing support.<2E>
|
||
Later versions will provide complete "boss node" functions, so<73>
|
||
that Fido/FidoNet will be able to perform any possible FidoNet<65>
|
||
mailer function; zone gate, zone host, net/region host, ordinary<72>
|
||
node, point boss, point node.
|
||
|
||
Fido/FidoNet properly handles all point-addressed messages; it<69>
|
||
will scan for TOPT and FMPT Kludge lines, and incorporate them<65>
|
||
into 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 ".<1 - 32767>" to the node number, or just the<68>
|
||
dot followed by the point number, to send to points within your<75>
|
||
own point network. For example: as 125/111, entering .33 would<6C>
|
||
address a message to 1:125/111.33, etc. Same syntax and behavior<6F>
|
||
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.
|
||
|
||
--------------------------------
|
||
|
||
Wazoo Protocol
|
||
|
||
Fido/FidoNet now supports two network protocols automatically.<2E>
|
||
One is "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 also<73>
|
||
do FSC001 style FidoNet. Wazoo operates in a similar manner, but<75>
|
||
uses Zmodem for it's transfers and can support "file requests",<2C>
|
||
where the call originator can "download" files from the remote<74>
|
||
computer without the intervention of an operator to do "file<6C>
|
||
attaches". (With appropriate controls, etc.)
|
||
|
||
There is no impact on existing Fido/FidoNet installations<6E>
|
||
regarding security, setup or installation, etc. The choice of<6F>
|
||
Wazoo vs. FidoNet is made automatically, though the system<65>
|
||
operator can make changes. The defaults will work fine in all<6C>
|
||
cases.
|
||
|
||
There are FIDO.INI options that were added to control things.<2E>
|
||
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<65>
|
||
FSC001 protocol compatibility. Unfortunately in the real world<6C>
|
||
there are varying levels of compliance to FSC001; the default is<69>
|
||
pretty "loose", for maximum compatibility. fsc011 yes lets<74>
|
||
Fido/FidoNet accept so-called "DIETIFNA" protocol, which means it<69>
|
||
can skip the slow MODEM7 filename; however SEAdog does not accept<70>
|
||
TELINK blocks and file attaches will then fail. wazoo no forces<65>
|
||
Fido to do only FSC001, ie. pre-12M compatibility. multi-tsync no<6E>
|
||
forces Fido back to 11W style single TSYNC character; there is<69>
|
||
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<65>
|
||
"compatible" systems will then work, including many Fido/FidoNet<65>
|
||
programs!
|
||
|
||
system-name is an optional 60 character string that is the "name"<22>
|
||
of your system. Fido transmits this name to the remote computer<65>
|
||
during Wazoo sessions. session-password may be required for<6F>
|
||
connecting to some other Wazoo-based systems; please make<6B>
|
||
arrangements with the person requiring it.
|
||
|
||
--------------------------------
|
||
|
||
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:
|
||
|
||
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<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.
|
||
|
||
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.
|
||
|
||
Controlling File Requests
|
||
|
||
The receiver has a file called "FILEREQ.INI", that is the list of<6F>
|
||
files that may be requestable from the system. Initially only two<77>
|
||
sample files are requestable (see below), and the system operator<6F>
|
||
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 files: "ABOUT", which is a short description of what your system<65>
|
||
is "about", and "FILES", which is the list of files requestable<6C>
|
||
from your system. In the hobbyist FidoNet network, it is<69>
|
||
traditional (and useful!) to have these two files requestable at<61>
|
||
all times, so that other system operators can find out about your<75>
|
||
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:
|
||
|
||
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 "NOFREQ.BBS" to the<68>
|
||
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.
|
||
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<6E>
|
||
maintain, that contains the list of files and directories you<6F>
|
||
wish to have available for other systems to file-request with<74>
|
||
their FidoNet type mailer.
|
||
|
||
You can also put comments into this file; comments are any line<6E>
|
||
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<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.
|
||
|
||
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/FidoNet will send<6E>
|
||
you
|
||
every single one. Too bad. For example, "FILES.BBS". Fido will transmit, just as you asked, FILES.BBS from all directories<65>
|
||
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.<2E>
|
||
It will of course return every single requestable file stored in<69>
|
||
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:
|
||
|
||
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 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:
|
||
|
||
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 new<65>
|
||
system operators requestable, you could convert the request for<6F>
|
||
"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<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"<22>
|
||
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
|
||
name, and not necessarily provide multiple files, etc:
|
||
|
||
C:/LIST/NODELIST.099
|
||
|
||
A file request for the filename portion (here, "NODELIST.099")<29>
|
||
causes your system to send that file, period. The pathname is<69>
|
||
used 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.
|
||
|
||
Nodemaps
|
||
|
||
Fido/FidoNet saves nodemaps it creates for each FidoNet schedule<6C>
|
||
tag. (Nodemaps are what the Router produces by reading the<68>
|
||
ROUTE.* 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 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<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.
|
||
|
||
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:
|
||
|
||
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<61>
|
||
once (when the "All" is read) instead of one at a time. "ALL"<22>
|
||
makes the router apply the commands to all nodes in the nodelist;<3B>
|
||
stacking in this example is twice as fast.
|
||
|
||
ALIAS-AS <alias>, <nodes...>
|
||
|
||
A powerful new route language command ALIAS-AS: Similar to the<68>
|
||
current ROUTE-TO command, you can force all messages routed to<74>
|
||
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 it<69>
|
||
does a "route-to" as part of it's action, it is a new command<6E>
|
||
entirely. Route-to only does one level of indirection; alias-as<61>
|
||
adds a second. Alias-as can be thought of as a kind of "route-to<74>
|
||
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.
|
||
|
||
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:
|
||
|
||
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.
|
||
|
||
IF-SCHEDULE A
|
||
schedule A statements ...
|
||
END-IF
|
||
|
||
If the currently executing schedule is "A", then the statements<74>
|
||
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<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.
|
||
|
||
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:
|
||
|
||
;
|
||
;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<6C>
|
||
specified zone.
|