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<74>
|
|||
|
|
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<6C>
|
|||
|
|
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<61>
|
|||
|
|
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<65>
|
|||
|
|
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.
|