pozar@hoptoad.uucp (Tim Pozar) (02/09/88)
Volume 5, Number 5 1 February 1988
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief Dale Lovell
Editor Emeritus: Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
Contributing Editors: Al Arango
FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1987 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
A Message off Usenet ..................................... 1
AUTOECHO A ECHOMAIL Utility Version 1.00 ................. 2
The Binkley Chronicles ................................... 3
The Search For The BitNet Gateway ........................ 11
Fido's Net, Would he have wanted it this way? ............ 12
Como Obtener un Numero de Nodo ........................... 14
POLICY4 Suggestions from Bob Hartman ..................... 16
2. WANTED ................................................... 19
3. NOTICES .................................................. 21
The Interrupt Stack ...................................... 21
Latest Software Versions ................................. 21
FidoNews 5-05 Page 1 1 Feb 1988
=================================================================
ARTICLES
=================================================================
From ptsfa!vixie!uunet!steinmetz!davidsen
Fri Dec 18 10:05:56 1987
Return-Path: <ptsfa!vixie!uunet!steinmetz!davidsen>
Date: Wed, 16 Dec 87 12:30:20 est
From: uunet!steinmetz!davidsen(William E. Davidsen Jr)
Message-Id: <8712161730.AA04733@steinmetz.steinmetz>
To: hoptoad!pozar
Subject: Re: FidoNET Newsletter, Volume 4, # 46
Newsgroups: comp.org.fidonet
In-Reply-To: <3623@hoptoad.uucp>
Organization: General Electric CRD, Schenectady, NY
I really must point out the incomplete nature of the article on
archivers, and question the concluson reached. There may be
people who have disks full of EXE and COM files, but after
checking a few home machines and some business machines at work,
I conclude that many people have at most 50% files of this type.
These files are very dense and show little improvement by
compression, as the tests show.
A more meaningful test would include databases, lots of text,
both letters and source code, and a representative sample of
other non-executable files. This would be more informative and
useful.
The issue of portability was very lightly mentioned. Some
archivers are limited to MS-DOS by virtue of being written in
assembler. Some will not run on OS/2 (except in compatibility
mode). If the intension was to present information on which the
reader could base a decision, I feel that it was inadequate. The
user interface was not mentioned.
Finally, the DWC archiver was not even considered. As PKARC it is
limited to DOS currently, but the source is available and it is
not shareware. My benchmarks show that it slightly faster than
PKARC and produces slightly smaller archives, but I would like to
see a test on the specific test files used for the other
programs.
I can't claim the the conclusions in the article were wrong, but
I do believe that they were based on a very small number of data
points, omitting both file type and programs. The tst should be
repeated and the results posted.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------------------------------------------
FidoNews 5-05 Page 2 1 Feb 1988
Ben Mann / Paul Pappas
OPUS 151/1000
AUTOECHO(tm)
AutoEcho version 1.00 has now been released. Thanks to all
the "beta" testers. Your bug reports and suggestions have made it
all worth while.
AutoEcho is a program that stems from the needs of all
ECHOMAIL HOST and HUB sysops. It allows a NODE to send a message
to the HOST system and turn on and off ECHO's that he/she would
like to recieve or not recieve without the intervention of
the HOST system sysop.
A message is sent to AUTOECHO with a password in the subject
field. This password MUST agree with a password the HOST system
defines in a file called AUTOECHO.PWD. The body of the message
contains the ECHO's the requester wants turned on or off. If
the ECHO is preceeded by a minus sign the ECHO is turned off. If
no sign is there the ECHO is turned on.
AutoEcho then modifies the HOST systems AREAS.BBS or
ECHO.CTL file and adds/deletes the ECHO being sent to that
requestor.
It also send a message to the requestor informing him/her
what action was taken. A message is also send to the "SYSOP" of
the HOST system or to his "real name" if environment varable
SYSOP=[your name] is set.
The orginal message is marked RECEIVED and will NOT be
procesed by AutoEcho again.
If the requestor enters QUERY on the first line of the
message, AutoEcho send the requestor a list of echos available.
AutoEcho now supports "levels" in the AUTOECHO.PWD file.
This makes it so you can make certain echos unavailable if
desired.
All actions taken by AUTOECHO can be redirected to a log,
AUTOECHO >> AUTOECHO.LOG, so the HOST sysop can tell what ECHO
has been picked up or deleted.
AUTOECHO.A00 may be requested from 151/1000 or 151/100. A
.DOC file and examples are included.
Can you say "AUTOECHO?", I thought you could.
-----------------------------------------------------------------
FidoNews 5-05 Page 3 1 Feb 1988
Cards on the table
This is about Binkley from a personal perspective. It would
not be fair to call it a review, because I am hardly an
unbiased observer. I use Binkley, and beta test it.
Hopefully, this will be the first column of a series on
Binkley and Opus related information. We are looking for
volunteers! Get in touch with me at 321/202 if you are
interested.
Yet another front end
You've probably heard people talking about BinkleyTerm as a
front end. You've probably asked yourself: "Why would we
WANT another front end?"
Binkley is a terminal program or BBS/Point front end that
unifies the two different technologies of session protocol in
the network -Bark, and WaZoo. It handles WaZoo flawlessly,
and handles Bark quite well. Binkley is descendant from
OpusLink, by Wynn Wagner III, which was incorporated into
OConnect, by Bob Hartman, which eventually was gobbled into
BinkleyTerm, by Vince Perriello, later re-joined by Bob
Hartman. The package draws heavily on sources released by
Wynn Wagner, with contributions by others. It is
distributed on about the same terms as Opus - that it must be
used in a lawful and friendly manner.
Rather than say what Binkley is, perhaps we should spend a
little time saying what it is not. Binkley is NOT a full
featured mail package, or point system. It is a mailer in
the purest sense. It has no packing, unpacking, routing, or
message browsing/composition features. You will need some
sort of a message editor: RoverMsg, Dutched, Sirius, Mail, or
anything similar.
Binkley is a terminal plus a whole lot more. To quote an
opening screen, BinkleyTerm is "A Companion Package for
communicating with the Opus CBCS". But that's not all ..
it's also "A Public Domain FidoNet Compatible Mail Utility".
General Features
Full Screen Interface
One of the major features of Binkley is a full screen
interface while in mailer mode. While most other mailers
just scrolls information by, Binkley puts it in windows.
Full Source Code
Perhaps the most important feature of Binkley is the release
FidoNews 5-05 Page 4 1 Feb 1988
of 100% of the source code with the package.
Be warned, however, that Binkley was developed using MS-C
4.0. Due to some size differences in the MS-C 5.0 library,
the program will not link under 5.0. The program, which was
done in small model, is VERY close to the edge of memory, and
the differences push it over. Bob and Vince eagerly await
some person taking the source and solving the problem! (The
next "official" version of Binkley will probably be
overlaid.)
Unlike Opus, very little of Binkley is in assembly. And it
uses the MS-C libraries, not the WWIII version thereof!
Improved Documentation
Alan Applegate reworked the documentation. Where even
experienced users had problems with the old docs, they should
find the 1.20 docs to be quite usable. (I have talked to a
couple of other sysops who have said that as good as they
are, they are still not what a beginning sysop would need.)
Multitasker Aware
Binkley detects a number of popular multitaskers, and
releases time slices to them.
Session Level Information
Protocols, etc. Supported
Bark
Binkley supports Bark file requests 100%, on the inbound
side. Since Binkley uses Opus' outbound message structure,
there is no mechanism for initiating an update request.
Depending on your definition, Binkley does qualify for the XP
flag.
WaZOO
This will come as no news to someone who runs pure Opus - but
for those of us who ran SEADog over Opus, or TBBS, (or RBBS
...) the difference is breathtaking. Especially at 9600
baud.
SEALink with Overdrive
This is one of the weaker features of Binkley. For some
connections, it works fine. In others, it breaks down.
FidoNews 5-05 Page 5 1 Feb 1988
According to Bob Hartman, the timing problems between a
SEADog (in SLO) and Binkley are largely due to the
differences in code, mandated by the flexibility maintained
on the Binkley side.
Remember, though, that SLO only kicks in at 9600, and it can
be disabled in Binkley.Cfg.
Restartable Transfers
Binkley supports restartable file transfers in a WaZOO
session. If you get 200K of a 300K file, and lose carrier,
so long as the chunk you have and the file sent are not
changed, Binkley will pick up where it left off.
This will be supported in Opus 1.10 as well, and is partially
supported by Opus 1.03. The method used is NOT the same as
is being used by Dutchie 2.80, and is not known to be
compatible with any other mailers on the streets.
Scripting
Binkley also supports scripting. I am not at all familiar
with this, we are hoping that in a future version of the
"Binkley Chronicles", we will have an extensive example of
how to use Bink's scripting.
Magic File Names
Binkley supports "magic file names". For example, the
current version of Binkley (executable) can be obtained from
most any Binkley distribution point under the name "BINKLEY".
Magic file names may expand to more than one file, and may
have passwords associated with them.
Security
Binkley uses Opus style session security. If passwords are
being used between two nodes, they are exchanged before ANY
mail is transferred, and if they are incorrect, the session
is terminated.
Configuration
A Hybridization of Control Style and Operation
Binkley is in most respects, a hybridization of the
technologies extent in the network. Binkley is potent partly
because its authors have had the value of 20/20 hindsight-
they have been able to look over the design decisions in this
product and that, and combine the best of them into one
FidoNews 5-05 Page 6 1 Feb 1988
product.
Binkley has a very nice, simple set of controls. The primary
one is Binkley.Cfg, which is very similar to SEADog's
Config.Dog. There are some differences, however. For the
most part, "security related" information is isolated outside
of the primary files. For example, session level passwords
are contained in OpusNode.Pwd, and file level passwords are
contained in the OKFile.Lst file. This makes it much simpler
to package a copy of one's files to give to another sysop as
an example.
While this SEADog user was far more comfortable with
Binkley's style of defining and running events (as opposed to
Opus'), there are some important and powerful differences.
Binkley gives you the ability to exit with a specified
errorlevel the first time an event is encountered, a
different one when mail is taken in, and yet another when
arcmail is taken in. These errorlevels can be uniquely
specified on an event by event basis, or omitted.
There is also more control over the handling of events
"passed over" due to a long transfer, or some other down
time. Where SEADog will execute each and every event (very
time consuming with all the packing and unpacking), Binkley
will only execute those events classified as "forced".
Otherwise, it simply jumps into the "current" event.
Combined with less time spent packing and unpacking, my
system is left with (much) more uptime, and much less wear
and tear. (Although in all fairness, my system is weirder
than most. When it was running SEADog, it ran events every
20 minutes, 24 hours a day.)
Binkley.Cfg
The Binkley.Cfg file is editable with a simple text editor,
much the same as SEADog's (and the new Fido's, or so I'm
told.) This is ALL that Binkley proper needs to operate,
other than an Opus format nodelist.
BT_CTL
A program is provided with Binkley, BT_CTL, which takes the
Binkley.Cfg file and cranks out the .PRM and Mail.Sys files
you need to run echomail and oMMM. You can live without this
if you are running Opus proper.
FOSSIL driver
Like Opus, Binkley has no inboard ability to talk to the comm
ports (or the screen or keyboard, for that matter.) All such
processing is handled by an externally installed FOSSIL
driver. The FOSSIL driver of choice for most PC users is
FidoNews 5-05 Page 7 1 Feb 1988
X00, by Ray Gwinn.
oMMM as a packer
As mentioned before, you need some kind of a packer to take
the messages out of the mail area(s) and put them into the
holding directory that Binkley uses. Binkley works just like
Opus in this respect - it looks for files with various
extensions, and sends them on the basis of the file name part
or the contents. All scheduling and routing is accomplished
by changing the extensions and arcing packets bound for a
common destination into a single arc.
oMMM (the Opus Matrix Message Masher) is the tool generally
used to do this.
There have been some efforts made to allow other packers to
be used, particularly Dutchie's, but there are some problems
on that front.
OpusNode flavor nodelists
Binkley uses Opus flavor nodelists. This means you will need
OpusNode to compile your nodelists, and either the latest and
greatest XlatList, or the quasi-released ParseList.
The session level security is handled using OpusNode.Pwd,
just as it is with Opus.
If you are using Dutched or Mail as your message editor, you
will need nodelists for them, in addition to your Opus style
list. If you are running in a true point configuration, it
is worth your while to have a "dummied" nodelist with just
your Boss for OpusNode, and a full nodelist for your editor.
Otherwise, you will need to kiss off an extra quarter to half
a megabyte.
Opus Style File Access Controls
The file request information is handled Opus style. An
"OKFile.Lst" style file is used to determine what files may
be downloaded, and what passwords must be used for them.
There is an extension for "magic file names", where the magic
name is prefixed with an @ sign.
Binkley also supports the "ABOUT" file, and the "FILES" files
in the same manner as Opus.
Terminal Features
ANSI Terminal Emulation
FidoNews 5-05 Page 8 1 Feb 1988
Binkley will do a very good job of emulating a VT-100 if you
have a complete ANSI driver installed. FANSI-CONSOLE is
mentioned as the driver of choice, as it takes care of
remapping keys as well as remapping video strings.
Many file transfer protocols
In the terminal mode, Binkley supports a wide range of file
transfer protocols - all the protocols that are "core" to
network mail transfers in any flavor.
Who should use Binkley, and who should not?
People who should consider Binkley
Any system serving both Bark and WaZoo systems
If you run a system that supports a mixture of Bark and WaZoo
systems, you would do well to consider running Binkley as
your front end. By doing so, the systems you support will
have to do that much less work to request files, etc.
Power Point talking to a barefoot Opus
If you have a "power user" acting as a point, and you are
running Opus or Binkley over Opus, you might consider having
that point use Binkley as his mailer. This is particularly
true if high speed modems are involved. Dutchie is written
in Turbo Pascal, and is not fast enough to support 9600 baud
transfers at full speed.
Anyone wanting more security than SEADog offers
Currently, SEADog ONLY secures the handing out of mail. It
will TAKE mail from anyone. With Binkley, as with Opus, any
and all sessions can be secured. Although relatively minor,
every little bit helps.
People who might be better off with something else
Most point users
At the current time, most point users would be better off
using an integrated, fully functional package, such as
Dutchie or SEADog. Being a point is a complex enough task
without having to integrate a whole bunch of different tools,
some of which are not documented quite as well as they could
be.
Highly mobile point users
FidoNews 5-05 Page 9 1 Feb 1988
SEADog has a wonderful ability - to handle phone number de-
prefixing (stripping the 1- and 1-aaa) at the MAILER, as
opposed to nodelist compilation phase. Binkley does not have
this ability, and I've been told it never will. While you
can override the number for your boss node in the Binkley.Cfg
file, if you want to be truly and correctly mobile without
recompiling nodelists all the time, you're better off with
SEADog.
Anyone happy running Opus barefoot
Any sysop who is happy running a barefoot Opus is probably
better off staying that way. If Bark requests are not
important to you, all you will add with Binkley is a 20
second loading the Opus software delay to annoy your users.
Anyone using their system for Real Business
Binkley is part of the BBS project. As such, it is available
on an as-is basis. If you are using your system to do real,
commercial work that requires 100% functionality, you should
think twice about using ANY unsupported tools.
People who are still in a quandary
TBBS Users
There have been varying reports on whether or not Binkley
works with TBBS. There is reputedly at least one system on
the net that is running this combination, but MANY who have
tried it and failed. There is apparently a conflict between
some FOSSIL drivers and TBBSDVR.
The authors are very interested in supporting TBBS. They are
looking for a few good beta testers on that front. If you're
interested, send netmail here - Bob and Vince are in the
crunch phase now, in more ways than one.
Other "Funny" BBS's
Most of the gateways to other BBS's make some assumptions
along the lines of Fido/SEADog style message packing.
Adaptations have to be made somewhere along the line to
compensate for these assumptions. To the best of my
knowledge, Binkley is not yet being used as a front end for
anything other than "traditional" net compatible BBS's.
(PLEASE PROVE ME WRONG!) It's only a matter of time ...
Conclusions and the sad state of political affairs
Binkley is a superb technical statement. It's actually a
FidoNews 5-05 Page 10 1 Feb 1988
shame that it is also a point of controversy, posed as
competition for this package or that. It's rather depressing
that one must consider political positions in viewing such a
wonderful technical statement. Binkley is not a "third camp"
of mailer. Binkley is not "something different" that some
accuse the "WaZoo types" of trying to do. It's an attempt to
demonstrate that quite a bit can be accomodated in 100K or so
of code.
-----------------------------------------------------------------
FidoNews 5-05 Page 11 1 Feb 1988
The Search for the BitNet Gateway
By Chris Candreva
107/35
I've got this little problem: I'm addicted to FidoMail.
This was no problem until last September, when I went to
college. See, us lowly Freshmen can't have phone lines in our
rooms, which makes it almost impossible to call BBSs.
But, it seems there is a possible solution! Stevens (the
college I attend) has a rather large networked VAX system,
which is hooked into Bitnet. Now, rumor has it that there is a
FidoNet <=> Bitnet Gateway. This would be great! I could send
mail to my friends on PHALSE and Excalibur back home. The
computer dept. would even allow me to have the space to receive
Echo conferences, assuming we could work out the technical
problems of routing. Fantastic!
Except, I can't for the life of me FIND this gateway! I
remember reading FidoNews articles on it a while ago, but my
collection of old FidoNews is a little unorganized, and I
haven't been able to find the article I am thinking of. If
someone out there knows where the nearest FidoNet<=>Bitnet
gateway is in the New York/New Jersey area (or if you actually
ARE this gateway), would you please drop me a line at PHALSE
QBBS 107/35? I would be very grateful!
Thanks for taking the time to read this. And have fun --
that's what we're here for, right?
-----------------------------------------------------------------
FidoNews 5-05 Page 12 1 Feb 1988
Ben Mann
151/0
FIDOSNET
As alot of you know region 18 went thru alot of flexing
and turnoil in the last several months. For those who don't
know, our regional coordinator was replaced without hardly a
wisper in the middle of the night. We had no say. The zone
coordinator said it and it was done.
The new region 18 coordinator is a nice guy. Means well
and all that, but I have to wonder if FIDO would have wanted
it that way. I mean you know what happened in Boston some
years ago. Something about the rights of the governed.
Well I didn't like it AND don't like it now. I would
like a say in who I work with AND who I don't.
If the regional coordinator wasn't doing his job then
don't you think that I should have know? I was one of the 28
network coordinator that work with him for the last three
years. 22 of which still support him as being the regional
coordinator. And I was always satisfied of the responce times
and decisions made, even if I didn't agree with them.
I thought FidoNet was a sort of big club. Run by and for
the members. NOT a dictatorship. Run from the top, with
little, or no, reguard for the members.
Well I found out real F-A-S-T.
I just have to ponder:
"Would Fido have wanted it that way?".
-----------------------------------------------------------------
FidoNews 5-05 Page 13 1 Feb 1988
-----------------------------------------------------------------
FidoNews 5-05 Page 14 1 Feb 1988
Editor's note: While FidoNews articles only include the ASCII
characters space through tilde, I am allowing
this one to be printed due to its nature.
---------------------------------------------------------------
Juan Davila
Node 367/1
The article below is meant for a new sysop and describes how to
go about getting a node address in Net 367. It is written in
Spanish and is an example of the type of work we are doing in the
LatinoNet. We are engaged in many other projects as well, some
of which we'll be telling you all about during the coming weeks.
Most of our work is coordinated through our echo, LATINO. We are
passing messages twice weekly and if you would be interested in
participating please let me know. You can also contact either
Pablo Kleinman (368/1) or Travis Good (102/851) for more infor-
mation.
Como obtener un n#mero de Nodo
en FidoNet 367 (RED de Puerto Rico)
===================================
FidoNet 367 en la actualidad tiene 5 Nodos activos alrededor de
todo Puerto Rico. Si usted esta comenzando un sistema FIDO o uno
compatible en Puerto Rico o areas limitrofes y tiene interes en
obtener un n#mero de Nodo, env!e un mensaje privado v!a FIDOmail,
desde su sistema al Operador del Nodo 367/1. Si necesita
cambiar el n#mero de Nodo inicial (-1/-1) porque su programa no
le permite utilizar este n#mero, entonces utilice el n#mero
(367/-1), #nicamente con el prop"sito de enviar este mensaje. No
utilice un n#mero de Nodo ya existente o previamente otorgados a
otro Nodo.
Su mensaje debe incluir la siguiente informaci"n:
El nombre de sus sistema (14 letras m ximo)
El nombre del operador (su Verdadero nombre)
El n#mero telef"nico del Sistema (data)
Localizaci"n del sistema (Ciudad y Estado)
Su n#mero telef"nico de voz
Horas en que su sistema funcionar
La velocidad m xima que puede aceptar su sistema
Que equipo utiliza su sistema
Cualquier otra cosa que usted crea importante
Cuando envie su mensaje tiene que enviarlo con un archivo
"FALSO" adjunto, para poder evitar la rutina interna de FIDO
que evitara que dicho mensaje llegue directo al 367/1. Para
adjuntar un archivo "FALSO", conteste que "Si" a la pregunta,
"Attach File?", del FIDO, y asigne un nombre de un archivo que no
FidoNews 5-05 Page 15 1 Feb 1988
exista. Esto instruir a FIDO que envie el mensaje directo en
lugar de enviarlo por las rutas al "Host", donde quedar como un
mensaje huerfano porque no contiene un n#mero de Nodo v lido.
Eventualmente me ser enviado pero esto tomar mas tiempo del
necesario.
Una vez yo reciba su petici"n, verificare los n#meros telef"nicos
de su FIDO y le eviare su nuevo n#mero de Nodo por FIDOmail.
Cualquier petici"n procesada antes del miercoles de cada semana,
aparecer en el nuevo listado de Nodos de ese viernes.
Si tiene alguna pregunta adicional sobre este procedimiento, deje
un mensaje dirigido al Operador.
Juan D vila
Operador y Coordinador
RED 367 de Puerto Rico
-----------------------------------------------------------------
FidoNews 5-05 Page 16 1 Feb 1988
Ed note: This is one of several proposals consisting of
suggestions for the new POLICY4 document which is being
published for review by FidoNet Sysops and the
subcommittee of Membership Services. Publication of
these proposals will take place in FidoNews weekly
until they have all been seen.
Discussion regarding the new POLICY4 is taking place in
the POLICY4 EchoMail conference.
---------------------------------------------------------------
EZ-POLICY FOR FIDONET
by
Bob Hartman, Sysop 1:132/101
This document is meant to be a starting point for further
discussion on FidoNet Policy and Procedures. It is a draft of
what could later be accepted as the official FidoNet Policy and
Procedures Guide, and comments/suggestions are not only welcome,
but encouraged.
SECTION I: LEVELS OF FIDONET
The FidoNet Network is broken down into many different levels
much as the hierarchy within any efficient organization. Thru
past history, the following hierarchy has developed:
1. All System Operators (SysOps) taken collectively (FidoNet).
This is the topmost level of the structure, and represents the
entirety of FidoNet.
[NOTE: During the resolution of a dispute involving the
expenditure of money, only those Sysops representing the
minority that would have to spend the money are allowed to vote
on the issue. An example would be a dispute on whether or not
Network Coordinators are responsible for forwarding the NODELIST
to all of the nodes in their network, or whether it is
acceptable to have the nodes poll to get the NODELIST. This
issue clearly is a dispute that involves money being spent by
the Network Coordinators or other SysOps. The Network
Coordinators are the smaller group, and therefore only SysOps in
that position are eligible to vote on the outcome. If the
reverse were true, the larger number would almost inevitably
vote not to spend their money, but rather have the smaller group
shoulder the burden.]
2. International FidoNet Association (IFNA) Board of Directors.
This group is elected so as to be broadly representative of the
views of the SysOps of FidoNet.
3. IFNA Executive Committee. Because of the size of the IFNA
Board of Directors (necessary to maintain reasonable
representation for all parts of the world), it is necessary to
have this small working group to take on the everyday operations
of IFNA.
FidoNews 5-05 Page 17 1 Feb 1988
4. IFNA Vice President - Technical Coordinator (VP-TC). This
is an Officer of IFNA position that is filled in accordance with
the Articles and By-Laws of IFNA. This Officer is responsible
for the maintenance and distribution of the master FidoNet
nodelist, and ensuring the smooth operation of FidoNet.
6. Zone Coordinator (ZC). This position oversees one Zone of
FidoNet and is responsible for the smooth functioning of FidoNet
within that Zone.
7. Regional Coordinator (RC). This position oversees one
Region within a Zone and is responsible for the smooth
functioning of FidoNet within that Region.
8. Network Coordinator (NC). This position oversees one
Network in one Region and is responsible for the smooth
functioning of FidoNet within that Network.
9. SysOp. This is the singular unit of FidoNet. The SysOp
runs his or her own FidoNet capable software such that their
system can function as part of FidoNet within the guidelines
imposed by the various levels of FidoNet above the SysOp level.
Those guidelines are formulated over time as defined in this
document.
SECTION II: RESOLUTION OF DISPUTES
In FidoNet it is very often necessary to resolve a dispute
between SysOps at various levels of the hierarchy. For the
purposes of this section, the following terms need to be
defined:
PLAINTIFF - The SysOp lodging a complaint against another SysOp.
DEFENDANT - The SysOp against whom a complaint has been lodged
by a plaintiff.
MEDIATION LEVEL - One level in the FidoNet hierarchy ABOVE the
level of the defendant.
All disputes in FidoNet have the parties defined above. Using a
"sliding window" of authority, any dispute can be heard and
solved at any level of the hierarchy. The procedure is as
follows:
1. Plaintiff files an official complaint against the Defendant
by informing the Mediation Level of the problem.
2. The Mediation Level hears the complaint and asks for as much
information as possible from all concerned parties before making
a judgement.
3. The Mediation Level issues a "verdict" in the case.
4. If the Plaintiff feels slighted by the "verdict", the case
may be appealed with the new Defendant being the combination of
FidoNews 5-05 Page 18 1 Feb 1988
the original Defendant, and the original Mediation Level, and
the process starts over again at number 1. At this point the
complaint is being heard two levels above the original Defendent
- effectively the authority for making the decision has been
shifted via a "sliding window" to the next level.
5. If the Defendant feels slighted by the "verdict", the case
may be appealed with the new Defendant being the original
Mediation Level, and the process starts over again at number 1.
Both 4 and 5 have the effect of moving the outcome of the
complaint up the chain of command.
All decisions at the topmost level are final and can no longer
be appealed. All disputes are solved in this manner.
SECTION III: POLICIES
The Policy at each level of the FidoNet hierarchy is formed
through the resolution of disputes. When a dispute is finally
resolved, the policies of all levels below the level making the
final compromise are affected. For this reason, each level of
the hierarchy is responsible for maintaining a "Case Law"
document of policies and procedures that have been created at
that level. In no case may a "Case Law" document from one level
be in conflict with any of the "Case Law" documents at higher
levels. However, "Case Law" documents at the same level need
not be the same. For example, Region 16 may have it in their
case law that each Network Coordinator must have the latest
issue of FidoNews available for pickup by any of the nodes in
the network, while Region 10 case law may say that it is not
necessary for the Network Coordinators to have FidoNews on-line.
If however, FidoNet acting as a whole has in the case law book
at the top level that Network Coordinators must have FidoNews
available for pickup, then the rule in Region 10 is in conflict
and is therefore superceded.
-----------------------------------------------------------------
FidoNews 5-05 Page 19 1 Feb 1988
=================================================================
WANTED
=================================================================
-- VIRUS QUERY --
Reporter writing an article for the NY Times on the threat of
"virus' ("mole,) "worm" and/or trojan horse "attack code"
programs seeks reports of real experiences with these often
distructive, sometimes playful, devices. I'm interested in any
reports about incidents involving PCs, minis or micros.
Please forward replies to Vin McLellan at Fido 101/154, (voice)
617-426-2487, or Snail
: 125 Kingston St., Boston, Ma. 02111.
-----------------------------------------------------------------
FidoNews 5-05 Page 20 1 Feb 1988
TRW Real Estate Information Systems, in Anaheim, CA is seeking a
creative Senior Programmer/Analyst to aid in the analysis,
design and implementation of a new generation of micro/mainframe
systems running in an IBM PC-AT compatible multitasking
environment.
We are looking for motivated, independent thinker with a minimum
of two years MS-DOS micro programming in C or Macro Assembler
and two years mini/mainframe programming. Experience in
structured development techniques and systems analysis/design
required. Familiarity with micro-mainframe communications,
micro hardware, and networks is desirable. Direct customer
interface is common, so good written and oral communication
skills are needed.
Please forward your resume with work history and references to:
TRW Real Estate Information Systems, Professional Employment,
Dept. DL-101, 2000 S. Anaheim Blvd., Suite 100, Anaheim, CA
92805. An equal opportunity employer.
-----------------------------------------------------------------
FidoNews 5-05 Page 21 1 Feb 1988
=================================================================
NOTICES
=================================================================
5 March 1988
The Area Code for Southern Colorado changes to 719. Be sure to
change your script files as necessary.
-----------------------------------------------------------------
The Interrupt Stack
19 Feb 1988
Start of the International FidoNet Associations Board of
Directors meeting in St. Louis. Meeting runs through the 21st.
25 Aug 1988
Start of the Fifth International FidoNet Conference, to be
held at the Drawbridge Inn in Cincinnatti, OH. Contact Tim
Sullivan at 108/62 for more information. This is FidoNet's big
annual get-together, and is your chance to meet all the people
you've been talking with all this time. We're hoping to see
you there!
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
Latest Software Versions
BBS Systems Node List Other
& Mailers Version Utilities Version Utilities Version
Dutchie 2.80* EditNL 3.3 ARC 5.21
Fido 12e* MakeNL 1.10 ARCmail 1.1
Opus 1.03a Prune 1.40 ConfMail 3.31*
SEAdog 4.10 XlatList 2.85* EchoMail 1.31
TBBS 2.0M MGM 1.1
BinkleyTerm 1.30*
* Recently changed
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 5-05 Page 22 1 Feb 1988
__
The World's First / \
BBS Network /|oo \
* FidoNet * (_| /_)
_`@/_ \ _
| | \ \\
| (*) | \ ))
______ |__U__| / \//
/ Fido \ _//|| _\ /
(________) (_/(_|(____/ (tm)
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays a specified annual membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications.
Member Name _______________________________ Date _______________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Baud Rates Supported ____________________________________________
Board Restrictions ______________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Send this membership form and a check or money order for $25 in
US Funds to:
International FidoNet Association
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, Hawaii 96813-4112
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The first elected Board of Directors
was filled in August 1987. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
-----------------------------------------------------------------
FidoNews 5-05 Page 23 1 Feb 1988
INTERNATIONAL FIDONET ASSOCIATION
ORDER FORM
Publications
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
Hardcopy prices as of October 1, 1986
IFNA Fido BBS listing $15.00 _____
IFNA Administrative Policy DOCs $10.00 _____
IFNA FidoNet Standards Committee DOCs $10.00 _____
SUBTOTAL _____
IFNA Member ONLY Special Offers
System Enhancement Associates SEAdog $60.00 _____
SEAdog price as of March 1, 1987
ONLY 1 copy SEAdog per IFNA Member
Fido Software's Fido/FidoNet $100.00 _____
Fido/FidoNet price as of November 1, 1987
ONLY 1 copy Fido/FidoNet per IFNA Member
International orders include $10.00 for
surface shipping or $20.00 for air shipping _____
SUBTOTAL _____
HI. Residents add 4.0 % Sales tax _____
TOTAL _____
SEND CHECK OR MONEY ORDER IN US FUNDS:
International FidoNet Association
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, HI. 96813-4112
USA
Name________________________________
Zone:Net/Node____:____/____
Company_____________________________
Address_____________________________
City____________________ State____________ Zip_____
Voice Phone_________________________
Signature___________________________
-----------------------------------------------------------------
--
=======================================================================
| ...sun!hoptoad!\ Tim Pozar |
| >fidogate!pozar Fido: 1:125/406 |
| ...lll-winken!/ PaBell: (415) 788-3904 |
| USNail: KKSF 77 Maiden Lane San Francisco CA 94108 |
=======================================================================