892 lines
26 KiB
Plaintext
892 lines
26 KiB
Plaintext
|
Fido/FidoNet version 10K errata sheet T. Jennings 9 July 85
|
|||
|
|
|
|||
|
|
10K has very few changes over 10I. Mostly one bug<75>
|
|||
|
|
fixed, a fairly obscure one: Fido would allow the entry of,<2C>
|
|||
|
|
but would not transmit, a message destined to <region>/0. It<49>
|
|||
|
|
worked correctly for <net>/0.
|
|||
|
|
|
|||
|
|
One addition, a command line switch:
|
|||
|
|
|
|||
|
|
/Y Disable path display
|
|||
|
|
|
|||
|
|
By default, Fido will display the pathnames of the<68>
|
|||
|
|
various message and file areas, plus the DIR.BBS<42>
|
|||
|
|
descriptions. This supresses all path displays. The path<74>
|
|||
|
|
information is pretty much useless anyways.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Fido/FidoNet version 10I errata Sheet T. Jennings 10 May 85
|
|||
|
|
|
|||
|
|
I apologize for the size of this errata sheet; time<6D>
|
|||
|
|
constraints prevent me from creating a new manual. (The<68>
|
|||
|
|
usual excuse.)
|
|||
|
|
|
|||
|
|
Most of the changes were bug fixes, and wont impact<63>
|
|||
|
|
anything. The biggest change has been in the FidoNet network<72>
|
|||
|
|
system. There is an entire section here about the changes.
|
|||
|
|
|
|||
|
|
If you are running a private-only network, the<68>
|
|||
|
|
changes are no big deal. If you are running in the public<69>
|
|||
|
|
domain FidoNet, you should get a copy of:
|
|||
|
|
|
|||
|
|
NODELIST.EXE
|
|||
|
|
|
|||
|
|
Manages the nodelist for you; it will strip/add area<65>
|
|||
|
|
codes, dialing prefixes, adjust message costs, etc.,<2C>
|
|||
|
|
eliminating all manual editing.
|
|||
|
|
|
|||
|
|
ROUTEGEN.EXE
|
|||
|
|
|
|||
|
|
Generates ROUTE files of any arbitrary complexity<74>
|
|||
|
|
from an english language like script.
|
|||
|
|
|
|||
|
|
These programs can be obtained from Fido #31 in Los<6F>
|
|||
|
|
Angeles.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The quote file wont repeat itself over and over. The<68>
|
|||
|
|
position last used in the quote file is saved in SYSTEM.BBS<42>
|
|||
|
|
(its size increases to 212 bytes) and used every time Fido<64>
|
|||
|
|
is run. The first time it will start at the beginning of the<68>
|
|||
|
|
file.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The Fido log file (SYSOP.LOG) has changed. The same<6D>
|
|||
|
|
information is logged, only its appearance has changed. This<69>
|
|||
|
|
should make the log smaller and easier to search with<74>
|
|||
|
|
software. Extraneous words were removed, and the data<74>
|
|||
|
|
displayed in a more compact form. Each line starts with a<>
|
|||
|
|
specific character. (Most do, anyways.) The characters are:
|
|||
|
|
|
|||
|
|
+ user name and time on
|
|||
|
|
! errors of all sorts
|
|||
|
|
= download and upload info
|
|||
|
|
- line between entries
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The /I command line switch now accepts a numeric<69>
|
|||
|
|
argument:
|
|||
|
|
|
|||
|
|
<task>/I Set multi-task environment
|
|||
|
|
|
|||
|
|
This does only two simple things: it changes the<68>
|
|||
|
|
names used for the log files, and affects the way messages<65>
|
|||
|
|
are created.
|
|||
|
|
|
|||
|
|
The names for the logs will incorporate the task ID<49>
|
|||
|
|
number; ie. if you specify 9/I the log files will be:
|
|||
|
|
|
|||
|
|
SYSOP9.LOG
|
|||
|
|
MAILER9.LOG
|
|||
|
|
|
|||
|
|
You cannot use 0 as a number. The other effect of<6F>
|
|||
|
|
setting a task ID is to force Fido to recount the messages<65>
|
|||
|
|
before saving a new one. This hopefully prevents duplicate<74>
|
|||
|
|
message numbers making a mess of things, or at least<73>
|
|||
|
|
minimizes it. It has the unfortunate side effect of greatly<6C>
|
|||
|
|
slowing down saving messages.
|
|||
|
|
|
|||
|
|
If you use /I in test mode, you will not be able to<74>
|
|||
|
|
see anything. Do not use /I with /T.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Four new modem types:
|
|||
|
|
|
|||
|
|
9 Ventel MD212 with WECO option
|
|||
|
|
10 GDC modem
|
|||
|
|
11 DC Hayes Smartmodem 2400
|
|||
|
|
12 US Robotics Courier 2400
|
|||
|
|
|
|||
|
|
The Hayes 2400 is a terrible modem. It will be OK<4F>
|
|||
|
|
for an autoanswer application, but very annoying for general<61>
|
|||
|
|
use.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
FidoNet messages have an audit trail: whenever a<>
|
|||
|
|
Fido passes a msg on further (ie. a host) it adds to the<68>
|
|||
|
|
bottom the line:
|
|||
|
|
|
|||
|
|
"Via Fido net/node"
|
|||
|
|
|
|||
|
|
Each Fido a given msg passes through will add its<74>
|
|||
|
|
own audit trail line.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Alternate node ID (net/node) has been added; each<63>
|
|||
|
|
node potentially has two independent net and node number<65>
|
|||
|
|
pairs. The current one will apply like it does now; all<6C>
|
|||
|
|
messages will be marked with the regular net/node numbers.<2E>
|
|||
|
|
The alternate is mainly for hosts, who are a node in a<>
|
|||
|
|
specific net, and node #0 as well. The normal case will be<62>
|
|||
|
|
where both node and net numbers are the same. In the host<73>
|
|||
|
|
case, the numbers will be set like:
|
|||
|
|
|
|||
|
|
Node : nn
|
|||
|
|
Net : mm
|
|||
|
|
Alt Node: 0
|
|||
|
|
Alt Net : mm
|
|||
|
|
|
|||
|
|
This says that this system is node nn in net mm, and<6E>
|
|||
|
|
is also node 0, the host. It can also be used as:
|
|||
|
|
|
|||
|
|
Node : nn
|
|||
|
|
Net : mm
|
|||
|
|
Alt Node: oo
|
|||
|
|
Alt Net : pp
|
|||
|
|
|
|||
|
|
So that the node is in two different nets; mm/nn and<6E>
|
|||
|
|
pp/oo.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
File attach capability has been given to EXTRA<52>
|
|||
|
|
privilege users, instead of only SYSOPs. Be careful, it<69>
|
|||
|
|
still allows access to the entire system, including *.*.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
No longer will FidoNet call millions of times for<6F>
|
|||
|
|
systems that dont answer. The maximum is now 20 tries per<65>
|
|||
|
|
node per event.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
10H now allows 300, 1200 and 2400 for all<6C>
|
|||
|
|
operations; whether your modem can or not is your business.<2E>
|
|||
|
|
This applies to baud rate detect for users as well as<61>
|
|||
|
|
Fidonet incoming and outgoing calls.
|
|||
|
|
|
|||
|
|
Due to a peculiarity in the UARTs used on all serial<61>
|
|||
|
|
ports, at 2400 baud whacking CR will not work to determine<6E>
|
|||
|
|
baud rate; you must hit the space bar instead. Fido will<6C>
|
|||
|
|
accept CR or space at all baud rates, but you must use space<63>
|
|||
|
|
at 2400. It is not a software problem but a hardware one.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The file K)ill command now works. It will prompt for<6F>
|
|||
|
|
a filename, accept wildcards, and will delete the names from<6F>
|
|||
|
|
FILES.BBS.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The Novation SmartCat works now. The problem was<61>
|
|||
|
|
that Novation radically changed the command structure, and<6E>
|
|||
|
|
provided a manual errata sheet; I did not have the errata<74>
|
|||
|
|
sheet. The 300 baud only Hayes should work as well; the<68>
|
|||
|
|
problem was that the modem sends all results with odd or<6F>
|
|||
|
|
even parity, and Fido did not strip it when looking for<6F>
|
|||
|
|
result codes.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
For those who care, the packet names for Fidonet<65>
|
|||
|
|
messages and file lsts has changed. The new format is:
|
|||
|
|
|
|||
|
|
mmmmnnnn.OUT
|
|||
|
|
mmmmnnnn.FLO
|
|||
|
|
|
|||
|
|
Where:
|
|||
|
|
|
|||
|
|
mmmm is the Net #, in Hex, zero filled, and
|
|||
|
|
nnnn is the Node #, in hex, also zero filled.
|
|||
|
|
|
|||
|
|
For instance, a packet destined for Node #56 in Net<65>
|
|||
|
|
#78, the packet name is:
|
|||
|
|
|
|||
|
|
004E0038.OUT
|
|||
|
|
004E0038.FLO
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
On the same subject, a new keyword has been added to<74>
|
|||
|
|
the route list, beyond the changes mentioned below. This is:
|
|||
|
|
|
|||
|
|
EXTERNAL-MAIL
|
|||
|
|
|
|||
|
|
This causes FidoNet to not delete it's packets and<6E>
|
|||
|
|
file lists, and mark all mail packeted as (SENT), or Killed<65>
|
|||
|
|
as necessary. This is specifically for the case where<72>
|
|||
|
|
FidoNet messages are transferred manually through some sort<72>
|
|||
|
|
of gateway, such as a mainframe. This entire process can now<6F>
|
|||
|
|
be automated by:
|
|||
|
|
|
|||
|
|
(1) Creating a schedule to handle the mail that is to be<62>
|
|||
|
|
shipped in an abnormal fashion. Make the schedule only one<6E>
|
|||
|
|
minute long.
|
|||
|
|
|
|||
|
|
(2) Make an External schedule terminate with some<6D>
|
|||
|
|
detectable value, immediately following the special Fidonet<65>
|
|||
|
|
schedule.
|
|||
|
|
|
|||
|
|
(3) In the route list for that schedule, add the keyword<72>
|
|||
|
|
EXTERNAL-MAIL.
|
|||
|
|
|
|||
|
|
|
|||
|
|
This complicated process causes Fidonet to create<74>
|
|||
|
|
the packets and file lists for the specified node(s),<2C>
|
|||
|
|
leaving them on disk, and marking the messages as if they<65>
|
|||
|
|
were sent normally. The external event must be used to<74>
|
|||
|
|
"mail" the packets. When this external mailing is complete,<2C>
|
|||
|
|
Fido can be returned to normal operation, either to Fido<64>
|
|||
|
|
mode or another FidoNet event.
|
|||
|
|
|
|||
|
|
Please note that if you "blow it", and lose the<68>
|
|||
|
|
packets, the process cannot be repeated for the same<6D>
|
|||
|
|
messages, as FidoNet will marked them as sent as if they<65>
|
|||
|
|
were mailed in the usual fashion. Packets should be deleted<65>
|
|||
|
|
when complete. MMMMNNNN.FLO is a string of pathnames; it can<61>
|
|||
|
|
be fed to a comm. program to transfer any attached files as<61>
|
|||
|
|
well. The receiving end will need to correlate the lists of<6F>
|
|||
|
|
files with the message packets.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Changed the message status display from (FORWARDED)<29>
|
|||
|
|
to (IN TRANSIT). Much more meaningful. Only the message is<69>
|
|||
|
|
changed.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
FidoNet message entry (picking a node number) has<61>
|
|||
|
|
changed, and there is a new help file; NODES.HLP. This is<69>
|
|||
|
|
displayed by entering ? at the prompt for a net/node number<65>
|
|||
|
|
at the E)nter message prompt in the FidoNet section.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
PREVIOUSLY UNDOCUMENTED:
|
|||
|
|
|
|||
|
|
"New" questionaire: QNEWUSER.BBS. Answers go into<74>
|
|||
|
|
ANEWUSER.BBS.
|
|||
|
|
|
|||
|
|
This is in the new-user signon loop. This is for new<65>
|
|||
|
|
or existing users who don't get to log on. (Either a private<74>
|
|||
|
|
system, or they forgot their password.)
|
|||
|
|
|
|||
|
|
There are now two ways to handle this case; the<68>
|
|||
|
|
first is the current way: NOPWD.BBS is displayed, the user<65>
|
|||
|
|
gets to enter a message to the sysop, then is logged off.
|
|||
|
|
|
|||
|
|
Now however, if the questionaire QNEWUSER.BBS<42>
|
|||
|
|
exists, the get to fill out the questionaire instead of<6F>
|
|||
|
|
NOPWD.BBS, and then logged off immediately, instead of a<>
|
|||
|
|
message to the sysop. The questionaire can be only displayed<65>
|
|||
|
|
text, for the case where you do not want any input from new<65>
|
|||
|
|
users.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
PREVIOUSLY UNDOCUMENTED:
|
|||
|
|
|
|||
|
|
For all .BBS text files (bulletins, etc) two control<6F>
|
|||
|
|
characters allow disabling and enabling users Control-C and<6E>
|
|||
|
|
Control-K:
|
|||
|
|
|
|||
|
|
^B Prevent Control-C aborts
|
|||
|
|
^C Allow Control-C aborts
|
|||
|
|
|
|||
|
|
If ^B is found, the caller cannot abort the display<61>
|
|||
|
|
of a .BBS text file. ^C reenables it. The default is<69>
|
|||
|
|
enabled.
|
|||
|
|
|
|||
|
|
EXAMPLE:
|
|||
|
|
|
|||
|
|
^B
|
|||
|
|
This cannot be canceled with Control-C
|
|||
|
|
^C
|
|||
|
|
This and all following text can be canceled with<74>
|
|||
|
|
Control-C.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
PREVIOUSLY UNDOCUMENTED:
|
|||
|
|
|
|||
|
|
At the prompt for entering a node number, a disk<73>
|
|||
|
|
file can be specified instead of a node number. (This was<61>
|
|||
|
|
SYSOP only in previous versions.) The disk file name must<73>
|
|||
|
|
not start with a digit. The disk file is assumed to contain<69>
|
|||
|
|
a list of node numbers, as would be entered manually. The<68>
|
|||
|
|
limit is 300 characters maximum.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The following structures have been changed. The<68>
|
|||
|
|
route table has been deleted, and its functions moved into<74>
|
|||
|
|
nmap. Most other changes consist of using previously zero<72>
|
|||
|
|
fields.
|
|||
|
|
|
|||
|
|
Starred items were filled in as zeros in previous<75>
|
|||
|
|
versions.
|
|||
|
|
|
|||
|
|
/* Message header structure. The message text is just a long<6E>
|
|||
|
|
string. */
|
|||
|
|
|
|||
|
|
struct _msg {
|
|||
|
|
char from[36]; /* who from, */
|
|||
|
|
char to[36]; /* who to, */
|
|||
|
|
char subj[72]; /* message subject, */
|
|||
|
|
char date[20]; /* creation date, */
|
|||
|
|
int times; /* number of times read, */
|
|||
|
|
int dest; /* destination node, */
|
|||
|
|
int orig; /* originating node */
|
|||
|
|
int cost; /* actual cost of msg */
|
|||
|
|
* int orig_net; /* originating net */
|
|||
|
|
* int dest_net; /* destination net */
|
|||
|
|
int caca[4]; /* extra space, */
|
|||
|
|
unsigned reply;
|
|||
|
|
int attr; /* message type, below */
|
|||
|
|
int up;
|
|||
|
|
};
|
|||
|
|
|
|||
|
|
|
|||
|
|
/* MAIL.SYS file structure */
|
|||
|
|
|
|||
|
|
struct _mail {
|
|||
|
|
int node; /* local node number, */
|
|||
|
|
float fudge;
|
|||
|
|
int rate; /* baud rate */
|
|||
|
|
char mailpath[80]; /* path to find mail in */
|
|||
|
|
char filepath[80]; /* mail file path */
|
|||
|
|
int net; /* net number */
|
|||
|
|
int alt_node;
|
|||
|
|
int alt_net;
|
|||
|
|
};
|
|||
|
|
|
|||
|
|
The net field was added, and the node (.number)<29>
|
|||
|
|
field has a special meaning when the net number is -1.
|
|||
|
|
|
|||
|
|
NET NODE
|
|||
|
|
-1 xx NODELIST.SYS revision
|
|||
|
|
xx 00 Defines a HOST
|
|||
|
|
|
|||
|
|
The first entry in NODELIST.SYS is the revision<6F>
|
|||
|
|
record. Fido 10I checks for a correct revision marker, and<6E>
|
|||
|
|
if it does not match, Fido recompiles NODELIST.SYS.
|
|||
|
|
|
|||
|
|
/* Node descriptor. (NODELIST.SYS) */
|
|||
|
|
|
|||
|
|
struct _node {
|
|||
|
|
int number; /* node number, */
|
|||
|
|
int net; /* net number */
|
|||
|
|
int cost; /* cost per minute to call */
|
|||
|
|
int rate; /* baud rate */
|
|||
|
|
char sched; /* schedule tag */
|
|||
|
|
char name[14]; /* node name */
|
|||
|
|
char phone[40]; /* phone number */
|
|||
|
|
char city[40]; /* city and state, */
|
|||
|
|
};
|
|||
|
|
|
|||
|
|
/* Message packet header. */
|
|||
|
|
|
|||
|
|
#define PKTVER 2
|
|||
|
|
|
|||
|
|
struct _pkthdr {
|
|||
|
|
int orig_node; /* originating Node # */
|
|||
|
|
int dest_node; /* destination node */
|
|||
|
|
int year,month,day,hour,minute,second;
|
|||
|
|
int rate; /* baud rate */
|
|||
|
|
int ver; /* packet version */
|
|||
|
|
* int orig_net; /* originating net number */
|
|||
|
|
* int dest_net; /* destination net number */
|
|||
|
|
int extra[17];
|
|||
|
|
};
|
|||
|
|
.pa
|
|||
|
|
FidoNet network organization change
|
|||
|
|
T. Jennings
|
|||
|
|
10 April 85
|
|||
|
|
|
|||
|
|
This covers the new capabilities of Fido version<6F>
|
|||
|
|
10I. Please do not implement net numbers yet! In order to<74>
|
|||
|
|
use net numbers, we have to get the entire net swapped over<65>
|
|||
|
|
to this new software, and issue net numbers.
|
|||
|
|
|
|||
|
|
If you do not do so already, please make sure you<6F>
|
|||
|
|
read FidoNews, the FidoNet newsletter. All network changes<65>
|
|||
|
|
are being discussed there. Get back issues if necessary.<2E>
|
|||
|
|
This is extremely important if you are part of the public<69>
|
|||
|
|
domain FidoNet.
|
|||
|
|
|
|||
|
|
FidoNews can be downloaded from Fido #375, where it<69>
|
|||
|
|
is published, or from most Fido systems, such as #1 or #51.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
10H starts a new type of FidoNet organization. It is<69>
|
|||
|
|
backwards compatible, but we will be swapping over to the<68>
|
|||
|
|
new method as soon as possible. This new organization allows<77>
|
|||
|
|
organizing the net and the node list on a region by region<6F>
|
|||
|
|
basis, instead of the monolithic centrally managed list,<2C>
|
|||
|
|
though there will still be a central list.
|
|||
|
|
|
|||
|
|
In previous versions, each different system was<61>
|
|||
|
|
identified by a single number, the node number. This works<6B>
|
|||
|
|
just fine, and the number of nodes that can be accomodated<65>
|
|||
|
|
is 32,767.
|
|||
|
|
|
|||
|
|
The new way allows a second identifier, the net<65>
|
|||
|
|
number. There can be 32,767 nets, each with 32,767 nodes.<2E>
|
|||
|
|
Not likely we'll use up all the numbers!
|
|||
|
|
|
|||
|
|
One annoyance when trying to enter a Fidonet message<67>
|
|||
|
|
on old Fidos is if you type "?" at the E command prompt, you<6F>
|
|||
|
|
get 250 node listings ... not exactly what most people like<6B>
|
|||
|
|
to see. The prompt now asks:
|
|||
|
|
|
|||
|
|
?=Help, #=List NODES /=List NETS
|
|||
|
|
|
|||
|
|
Entering / will list all the local nets; you will<6C>
|
|||
|
|
probably get no more than 20 listings, a very manageable<6C>
|
|||
|
|
number. Once you select a net, you can then enter # to list<73>
|
|||
|
|
the nodes in that net; once again, a very manageable number,<2C>
|
|||
|
|
the biggest net is SoCal, with 30 something nodes.
|
|||
|
|
|
|||
|
|
It also allows you to enter a specific net/node<64>
|
|||
|
|
combination all at once, like:
|
|||
|
|
|
|||
|
|
55/66
|
|||
|
|
|
|||
|
|
Which means Net #55, Node #66. Handy if you send<6E>
|
|||
|
|
mail to a specific node all the time.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Before everyone gets a copy of 10H, the net will<6C>
|
|||
|
|
operate as it does now. Everyone will belong in Net #1. Busy<73>
|
|||
|
|
areas such as SoCal and STL will eventually become their own<77>
|
|||
|
|
nets; they will be assigned one net number for the entire<72>
|
|||
|
|
region, and after that they can pick node numbers as they<65>
|
|||
|
|
please.
|
|||
|
|
|
|||
|
|
STL will pass out net numbers as it now does node<64>
|
|||
|
|
numbers. Each local net will generate its own node list,<2C>
|
|||
|
|
with routing tables, etc just like Fido 51 in STL does now.<2E>
|
|||
|
|
The format will be axactly the same. STL will then merely<6C>
|
|||
|
|
take those local nodelists, stick them all together, and<6E>
|
|||
|
|
pass it out.
|
|||
|
|
|
|||
|
|
Nodes that dont fall into any local net will remain<69>
|
|||
|
|
part of Net #1, just like it is now. If there is only one of<6F>
|
|||
|
|
you in East Overshoe, you wont be burdened with the extra<72>
|
|||
|
|
work involving a local node list.
|
|||
|
|
|
|||
|
|
|
|||
|
|
NODE LIST CHANGES
|
|||
|
|
|
|||
|
|
The node list has to be changed as well. The change<67>
|
|||
|
|
here is also pretty minimal. There has to be some way to<74>
|
|||
|
|
specify which net a node belongs to.
|
|||
|
|
|
|||
|
|
The current scheme assumes we are in the same net.<2E>
|
|||
|
|
(Well, we ARE, and we will remain so.) An example old<6C>
|
|||
|
|
fashioned node list entry looks like:
|
|||
|
|
|
|||
|
|
....
|
|||
|
|
0050 25 1200 Crystal_Caver1-512-263-5805 Austin.........TX
|
|||
|
|
0051 25 1200 DECUS_Central1-314-432-4129 St_Louis.......MO
|
|||
|
|
0052 25 1200 TOPCC 1-805-499-8378 Thousand_Oaks..CA
|
|||
|
|
0053 25 1200 S.E._Prof_Fid1-404-928-1876 Woodstock......GA
|
|||
|
|
....
|
|||
|
|
|
|||
|
|
All of the nodes are in numeric order as well. The<68>
|
|||
|
|
new scheme involves two changes:
|
|||
|
|
|
|||
|
|
(1) Placing all of a local net's nodes in the
|
|||
|
|
same place in the node list,
|
|||
|
|
|
|||
|
|
(2) Specifying the local nets host at the top of
|
|||
|
|
the list.
|
|||
|
|
|
|||
|
|
IMPORTANT: It is an absolute no-no to "sort" the<68>
|
|||
|
|
node list. This will totally wreck everything. The order of<6F>
|
|||
|
|
the node list is now an important part of its structure. DO<44>
|
|||
|
|
NOT CHANGE THE ORDER OF THE NODE LIST! There were two major<6F>
|
|||
|
|
reasons for doing this, both not needed any more: (1) to put<75>
|
|||
|
|
your own node at the top of the list, so Fido wouldnt be so<73>
|
|||
|
|
damn slow listing message. Repaired: Fido wont list the node<64>
|
|||
|
|
name and location if it is YOUR NODE. (2) sorting by city<74>
|
|||
|
|
and state to make the list manageable. The organization<6F>
|
|||
|
|
itself takes care of this.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Two keywords has been introduced into the node list;<3B>
|
|||
|
|
the word "HOST" and "REGION", these change the meaning of<6F>
|
|||
|
|
the node list entry it is on. Both are handled the same, but<75>
|
|||
|
|
HOST automatically does routing that used to be done in the<68>
|
|||
|
|
route lists. More on this later.
|
|||
|
|
|
|||
|
|
A sample entry for a local net is shown below. Note<74>
|
|||
|
|
that all of the St. Louis nodes follow one another; they can<61>
|
|||
|
|
no longer be sprinkled through the node list.
|
|||
|
|
|
|||
|
|
The special line before the normal listing for node<64>
|
|||
|
|
4 defines the local nets host. The "2" is not the node<64>
|
|||
|
|
number, but the net number. It says that all node entries<65>
|
|||
|
|
that follow it belong to net #2, until another HOST line is<69>
|
|||
|
|
found.
|
|||
|
|
|
|||
|
|
Note also that the host is also a regular node, 51.<2E>
|
|||
|
|
The HOST line merely defines who is the host. This entry, as<61>
|
|||
|
|
you might expect after thinking about it, does affect<63>
|
|||
|
|
routing; this is covered below. A host is also treated as<61>
|
|||
|
|
"node 0", so that it is possible to send a message to "host"<22>
|
|||
|
|
or 51, and the message will get there. This is a special<61>
|
|||
|
|
case, and has a special meaning also covered below.
|
|||
|
|
|
|||
|
|
|
|||
|
|
HOST 2 25 1200 DECUS_Central1-314-432-4129 St_Louis.......MO
|
|||
|
|
0004 25 1200 Bulldog 1-314-441-9297 St_Louis.......MO
|
|||
|
|
0010 25 1200 MDC_RCC 1-314-234-1462 St_Louis.......MO
|
|||
|
|
0016 25 1200 Mikes_Board 1-314-726-3448 St_Louis.......MO
|
|||
|
|
0017 25 1200 DCA_BBS 1-314-962-0395 St_Louis.......MO
|
|||
|
|
0022 25 1200 PCLUG 1-314-576-2743 St_Louis.......MO
|
|||
|
|
0051 25 1200 DECUS_Central1-314-432-4129 St_Louis.......MO
|
|||
|
|
|
|||
|
|
|
|||
|
|
HOW THIS AFFECTS ROUTING
|
|||
|
|
|
|||
|
|
The routeing works as previously documented; the<68>
|
|||
|
|
only real change is that Fido will do some of it<69>
|
|||
|
|
automaticaly now instead of having to be put into the route<74>
|
|||
|
|
list.
|
|||
|
|
|
|||
|
|
HOST basically causes automatic routing to be done<6E>
|
|||
|
|
by Fido, instead of requiring route lists as in previous<75>
|
|||
|
|
versions.
|
|||
|
|
|
|||
|
|
Once we swap over to the new method, you will not<6F>
|
|||
|
|
need to pecify the routing for hosts. When you enter a<>
|
|||
|
|
message to say Fido #4, Fido will automatically route it to<74>
|
|||
|
|
Fido #51 for you.
|
|||
|
|
|
|||
|
|
REGION does not do any of this automatic routing; it<69>
|
|||
|
|
only affects how messages are entered and listed.
|
|||
|
|
|
|||
|
|
Mail within your own net is never affected by this<69>
|
|||
|
|
special routing; if you and another node are both in the<68>
|
|||
|
|
same net, then mail you send there will go directly, just as<61>
|
|||
|
|
in previous versions. (You can of course specify routing<6E>
|
|||
|
|
still in the route list, but you have to do it on purpose.)
|
|||
|
|
|
|||
|
|
ROUTE LISTS
|
|||
|
|
|
|||
|
|
Route lists are the ROUTE.BBS, ROUTE.A, ROUTE.B, etc<74>
|
|||
|
|
files.
|
|||
|
|
|
|||
|
|
You can still specify routing as necessary, like<6B>
|
|||
|
|
before. The only difference is that if the nodes are not in<69>
|
|||
|
|
your own net, you will have to specify the net number as<61>
|
|||
|
|
well as the node number. This is described in detail below.
|
|||
|
|
|
|||
|
|
Fido also understands a special "node number", the<68>
|
|||
|
|
word "ALL". This means "all nodes in all nets". This is<69>
|
|||
|
|
useful for incoming hosts, to allow routing mail from any<6E>
|
|||
|
|
node in the world to their own local nodes. For instance:
|
|||
|
|
|
|||
|
|
send-to 4,16,17,22,10,76
|
|||
|
|
accept-from all
|
|||
|
|
|
|||
|
|
... allows Fido #51 to receive mail from the world<6C>
|
|||
|
|
and send it to it's own local nodes.
|
|||
|
|
|
|||
|
|
|
|||
|
|
There is also a new keyword that Fido understands,<2C>
|
|||
|
|
its use will become obvious later:
|
|||
|
|
|
|||
|
|
Net N
|
|||
|
|
|
|||
|
|
Assume Net #N as the default net for all following<6E>
|
|||
|
|
route list statements. This is only to allow easy entry of<6F>
|
|||
|
|
lots of net/node number combinations. This will be explained<65>
|
|||
|
|
further below.
|
|||
|
|
|
|||
|
|
|
|||
|
|
NET/NODE NUMBERS
|
|||
|
|
|
|||
|
|
Previous versions accepted only node numbers on<6F>
|
|||
|
|
route statements, such as "send-to 11,22,33,44" or "schedule<6C>
|
|||
|
|
B 66,77,88,99", etc. These forms are still accepted, but<75>
|
|||
|
|
Fido assumes that the node numbers belong to your own net.
|
|||
|
|
|
|||
|
|
To specify nodes not in your net, you must use the<68>
|
|||
|
|
"long form" of node/net, such as "send-to 4/11,4/22,4/33" or<6F>
|
|||
|
|
"schedule B 100/66,100/77,100/88", etc.
|
|||
|
|
|
|||
|
|
When you specify the same net number a lot, you can<61>
|
|||
|
|
use the new "NET" keyword. What it does is set the default<6C>
|
|||
|
|
net to NN, instead of assuming your own net number. One of<6F>
|
|||
|
|
the above lines could be done as:
|
|||
|
|
|
|||
|
|
Net 100
|
|||
|
|
schedule b 66,77,88,99
|
|||
|
|
|
|||
|
|
.........................................
|
|||
|
|
|
|||
|
|
DECOUPLED MODE
|
|||
|
|
|
|||
|
|
Fido 10h also has a new mode to accomodate seperate<74>
|
|||
|
|
networks; decoupled mode. Decoupled here means that instead<61>
|
|||
|
|
of knowing all about all nodes in a different (from the one<6E>
|
|||
|
|
you are in) net, it will allow mail to nodes within a<>
|
|||
|
|
different net knowing only the host.
|
|||
|
|
|
|||
|
|
Currently, when you enter a node number, Fido checks<6B>
|
|||
|
|
it againts the list; if not found, Fido complains. This<69>
|
|||
|
|
requires that all nodes in all nets be in the nodelist.
|
|||
|
|
|
|||
|
|
In the future, this may be impractical, especially<6C>
|
|||
|
|
for "private" nets. Decoupled mode basically tells Fido to<74>
|
|||
|
|
not care if it can't find a specific node in a specific net.
|
|||
|
|
|
|||
|
|
Note that this only affects different networks; Fido<64>
|
|||
|
|
still requires knowing all about nodes within the current<6E>
|
|||
|
|
network.
|
|||
|
|
|
|||
|
|
In decoupled mode, when a node number entered cannot<6F>
|
|||
|
|
be found in the list for that net, Fido sends it to node #0,<2C>
|
|||
|
|
the host for that net. The host must be in the nodelist. If<49>
|
|||
|
|
when routing a message that does not appear in the node<64>
|
|||
|
|
tables, it will be sent to the host as well.
|
|||
|
|
|
|||
|
|
Decoupled mode is enabled with /C on the command<6E>
|
|||
|
|
line. Please do not use it for normal FidoNet operation.
|
|||
|
|
|
|||
|
|
--------------------------------------------------------
|
|||
|
|
|
|||
|
|
Fido Version 10C Errata Sheet
|
|||
|
|
T. Jennings 25 Jan 85
|
|||
|
|
|
|||
|
|
These are changes made in version 10c from previous<75>
|
|||
|
|
version 10's. Note that this may conflict with what the<68>
|
|||
|
|
manual says; please note the changes.
|
|||
|
|
|
|||
|
|
|
|||
|
|
MESSAGE AREAS
|
|||
|
|
|
|||
|
|
Finally, yes finally, Fido understands the idea of<6F>
|
|||
|
|
'Last Message Read'. You no longer have to memorize where<72>
|
|||
|
|
you left off reading messages since you were last on.
|
|||
|
|
|
|||
|
|
Fido now remembers the last message you read in the<68>
|
|||
|
|
LAST NINE MESSAGE AREAS, not all of them. This is because<73>
|
|||
|
|
that is all the extra space I could find in the user<65>
|
|||
|
|
records. It should be fine for most Fidos.
|
|||
|
|
|
|||
|
|
When you enter a message area, Fido will tell you:
|
|||
|
|
|
|||
|
|
"Highest msg is HH, last one you read was LL"
|
|||
|
|
|
|||
|
|
This will tell you if there are any messages there<72>
|
|||
|
|
that you haven't read. A little known fact of previous Fidos<6F>
|
|||
|
|
was that "*" meant HIGHEST MESSAGE; when you entered "R *"<22>
|
|||
|
|
it read the highest message.
|
|||
|
|
|
|||
|
|
* now means "The one after the last one you read".<2E>
|
|||
|
|
So, to start reading where you left off, just enter:
|
|||
|
|
|
|||
|
|
R *
|
|||
|
|
|
|||
|
|
And if the last message you read was 50, it will<6C>
|
|||
|
|
start displaying messages at 51. You can enter * anytime<6D>
|
|||
|
|
Fido asks you for a message number.
|
|||
|
|
|
|||
|
|
SYSOPS:
|
|||
|
|
|
|||
|
|
The renumber command (8) will correct the message<67>
|
|||
|
|
numbers now stored in the user list. The old program,<2C>
|
|||
|
|
RENUM.EXE, will not handle the message numbers stored in the<68>
|
|||
|
|
user list; everyone will be confused. Do not use it anymore.
|
|||
|
|
|
|||
|
|
|
|||
|
|
.........................................
|
|||
|
|
|
|||
|
|
MODEMS
|
|||
|
|
|
|||
|
|
Fido is a lot smarter about modems now. Since it<69>
|
|||
|
|
already knows what type of modem you are using (the /J<>
|
|||
|
|
switch) it might as well initialize the modem the way it<69>
|
|||
|
|
wants, instead of forcing you to use the complicated<65>
|
|||
|
|
FIDOMDM.BBS.
|
|||
|
|
|
|||
|
|
Fido will initialize the modem for you<6F>
|
|||
|
|
automatically; AFTER THAT, it will do the initialization<6F>
|
|||
|
|
with FIDOMDM.BBS as specified in the manual. This allows you<6F>
|
|||
|
|
to override Fido's default initialization if yuo want; 99%<25>
|
|||
|
|
of all installations will not need to however. You can now<6F>
|
|||
|
|
(and should) DELETE FIDOMDM.BBS.
|
|||
|
|
|
|||
|
|
The IBM PC Junior has it's own modem type, and<6E>
|
|||
|
|
Novation SmartCat will work properly, even with XMODEM.
|
|||
|
|
|
|||
|
|
NEW MODEM TYPES
|
|||
|
|
|
|||
|
|
These are the modem types specified with the /J<>
|
|||
|
|
switch.
|
|||
|
|
|
|||
|
|
1 Hayes
|
|||
|
|
2 DF03
|
|||
|
|
3 Racal Vadic VA212
|
|||
|
|
4 Novation SmartCat
|
|||
|
|
5 US Robotics
|
|||
|
|
7 Prentice POPCOM
|
|||
|
|
8 IBM PC Junior
|
|||
|
|
|
|||
|
|
NOTE: For PopCom and GDC modems, and all modems that<61>
|
|||
|
|
are a "superset" of the Hayes, any additional initialization<6F>
|
|||
|
|
must be done in FIDOMDM.BBS.
|
|||
|
|
|
|||
|
|
.........................................
|
|||
|
|
|
|||
|
|
FIDONET ROUTING:
|
|||
|
|
|
|||
|
|
These changes afect only those Fidos acting as hosts<74>
|
|||
|
|
for other Fidos. If you are not a host, then ignore this, or<6F>
|
|||
|
|
maybe read it out of curiosity.
|
|||
|
|
|
|||
|
|
Some very substantial changes were made here. If you<6F>
|
|||
|
|
are a host, you will have to make changes; however, the<68>
|
|||
|
|
changes should be a pleasant suprise instead of a pain.
|
|||
|
|
|
|||
|
|
MULTIPLE ROUTE LISTS:
|
|||
|
|
|
|||
|
|
Instead of just the single route list, ROUTE.BBS,<2C>
|
|||
|
|
Fido will support one route list per schedule. It is simple:
|
|||
|
|
|
|||
|
|
Schedule A ROUTE.A
|
|||
|
|
Schedule B ROUTE.B
|
|||
|
|
... ...
|
|||
|
|
Schedule W ROUTE.W
|
|||
|
|
|
|||
|
|
The way it works is: Fido first looks for the<68>
|
|||
|
|
specific route list, if it doesn't find it, it uses<65>
|
|||
|
|
ROUTE.BBS as before.
|
|||
|
|
|
|||
|
|
|
|||
|
|
NEW ROUTING COMMANDS
|
|||
|
|
|
|||
|
|
The contents of the route list have been changed,<2C>
|
|||
|
|
too. One keyword was dropped, and one more added.
|
|||
|
|
|
|||
|
|
FORWARD-TO No longer supported
|
|||
|
|
|
|||
|
|
SEND-TO node node node node ...
|
|||
|
|
|
|||
|
|
Now by default, ALL NODES ARE MARKED "FORWARD-TO".<2E>
|
|||
|
|
The ACCEPT-FROM list is the only thing that controls which<63>
|
|||
|
|
messages go out. It turns out that the FORWARD-TO was<61>
|
|||
|
|
totally redundant in every working route list examined; I<>
|
|||
|
|
won't go into the details here why. Any FORWARD-TOs found<6E>
|
|||
|
|
will be totally ignored.
|
|||
|
|
|
|||
|
|
The big problem was that a host needs to run more<72>
|
|||
|
|
than one schedule, and there was only one route list. This<69>
|
|||
|
|
meant that there had to be conflicting or overlapping<6E>
|
|||
|
|
ACCEPT-FROMs and FORWARD-TOs; with the new multiple route<74>
|
|||
|
|
lists, there are no more conflicts.
|
|||
|
|
|
|||
|
|
Also, since when you are editing a route list, you<6F>
|
|||
|
|
only have to think about the one schedule; you will find<6E>
|
|||
|
|
that they are now very small, and easy to read.
|
|||
|
|
|
|||
|
|
The new keyword, SEND-TO is like SCHEDULE: it means,<2C>
|
|||
|
|
"In this schedule (whatever it is) send mail to these nodes"<22>
|
|||
|
|
followed by a list of nodes. For instance, if it is schedule<6C>
|
|||
|
|
B, and you are to send mail to your local nodes, you would<6C>
|
|||
|
|
say "SEND-TO node node node node ...". It is the same as<61>
|
|||
|
|
saying (in this example) "SCHEDULE B node node node node<64>
|
|||
|
|
...". You can think of it as doing "SCHEDULE (the current<6E>
|
|||
|
|
schedule) node node node ...".
|
|||
|
|
|
|||
|
|
SPECIAL NODE NUMBER:
|
|||
|
|
|
|||
|
|
A special "number" has been added, and can be used<65>
|
|||
|
|
anywhere that you would put a list of node numbers:
|
|||
|
|
|
|||
|
|
ALL all nodes in the list
|
|||
|
|
|
|||
|
|
For instance, if you route all your mail to a single<6C>
|
|||
|
|
outgoing host, instead of putting in all possible numbers<72>
|
|||
|
|
(tedious, when there are 150 nodes), you can now do:
|
|||
|
|
|
|||
|
|
ROUTE-TO xx ALL
|
|||
|
|
|
|||
|
|
This works with SCHEDULE, SEND-TO, ACCEPT-FROM and<6E>
|
|||
|
|
ROUTE-TO.
|
|||
|
|
|
|||
|
|
AN EXAMPLE:
|
|||
|
|
|
|||
|
|
You are both incoming and outgoing host for nodes<65>
|
|||
|
|
101, 102, and 103. You are node 200. (This used to be the<68>
|
|||
|
|
worst thing possible; the way you had to to it before was<61>
|
|||
|
|
ACCEPT-FROM all and FORWARD-TO all; this meant it would send<6E>
|
|||
|
|
anyones mail anywhere!).
|
|||
|
|
|
|||
|
|
SCHEDULES:
|
|||
|
|
B 12:30AM - 12:59 AM local to host
|
|||
|
|
A 1:00 - 2:00 AM national
|
|||
|
|
C 2:01 - 2:30 AM host to local
|
|||
|
|
|
|||
|
|
|
|||
|
|
ROUTE.B:
|
|||
|
|
|
|||
|
|
(empty, host is read only)
|
|||
|
|
|
|||
|
|
|
|||
|
|
ROUTE.A:
|
|||
|
|
|
|||
|
|
ACCEPT-FROM 101 102 103
|
|||
|
|
ROUTE-TO (the usual route-to's)
|
|||
|
|
|
|||
|
|
ROUTE.C:
|
|||
|
|
|
|||
|
|
ACCEPT-FROM ALL
|
|||
|
|
SEND-TO 101 102 103
|
|||
|
|
|
|||
|
|
|
|||
|
|
Nice and simple. Make sure there is no ROUTE.BBS.<2E>
|
|||
|
|
ROUTE.B does nothing in the host; since it's only waiting<6E>
|
|||
|
|
for mail from the locals, it doesnt need (or want!) to send<6E>
|
|||
|
|
to anyone. It is just gathering messages that may be sent<6E>
|
|||
|
|
during Schedule A.
|
|||
|
|
|
|||
|
|
ROUTE.A says it's OK to send out mail only from it's<>
|
|||
|
|
local nodes, plus obviously any mail entered at the host.<2E>
|
|||
|
|
The ROUTE-TOs are the ones out of the node list. Since only<6C>
|
|||
|
|
the locals are listed under ACCEPT-FROM, mail from say node<64>
|
|||
|
|
#1 will not be sent, but marked as ORPHAN.
|
|||
|
|
|
|||
|
|
ROUTE.C says forward mail from any node (ACCEPT-FROM<4F>
|
|||
|
|
...) but send only to the locals 101, 102, 103.
|
|||
|
|
|
|||
|
|
|
|||
|
|
I think I hear some groaning out there, but the<68>
|
|||
|
|
changes will be worth it. It means that you can now<6F>
|
|||
|
|
implement any network of any complexity and number of levels<6C>
|
|||
|
|
with no worries of forwarding mail you do not want to.
|