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