1138 lines
48 KiB
Plaintext
1138 lines
48 KiB
Plaintext
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
|
||
|
||
|
||
<20>
|
||
-----------------------------------------------------------------
|
||
|
||
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<6E>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), <20>nicamente con el prop<6F>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<63>n:
|
||
|
||
El nombre de sus sistema (14 letras m<>ximo)
|
||
El nombre del operador (su Verdadero nombre)
|
||
El n<>mero telef<65>nico del Sistema (data)
|
||
Localizaci<63>n del sistema (Ciudad y Estado)
|
||
Su n<>mero telef<65>nico de voz
|
||
Horas en que su sistema funcionar<61>
|
||
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<69> a FIDO que envie el mensaje directo en
|
||
lugar de enviarlo por las rutas al "Host", donde quedar<61> como un
|
||
mensaje huerfano porque no contiene un n<>mero de Nodo v<>lido.
|
||
Eventualmente me ser<65> enviado pero esto tomar<61> mas tiempo del
|
||
necesario.
|
||
|
||
Una vez yo reciba su petici<63>n, verificare los n<>meros telef<65>nicos
|
||
de su FIDO y le eviare su nuevo n<>mero de Nodo por FIDOmail.
|
||
Cualquier petici<63>n procesada antes del miercoles de cada semana,
|
||
aparecer<65> 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___________________________
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|