What is TNOS?
This is a reprint of a paper printed in the
Proceedings of the 1994 TAPR Annual Meeting, with some
information updated
Many have been asking for a description of what are
the distinctive fetures of Tampa NOS (TNOS), and what
makes it different from JNOS. I will try here to address
these questions with an overview and some specifics.
There was no original intention to
start a "TNOS" project. I stumbled onto GRINOS
and found it to be FUN and CHALLENGING. This caused me to
look around and I found JNOS, which was more complete and
stable. After initial testing, I ws ready to replace the
AA4RE BBS that I was running at our club station. I asked
the operator of the BBS that was feeding me traffic to
hold off for a few days while I made the change.
All went well, everything was in
place, users were happy. So I told the BBS SYSOP to start
feeding me traffic. BOOM! CRASH! POW! POP! There were 30
second (and greater) delays changing into certai message
areas that held more than 500 messages. Messages selected
for forwarding never left the system, since the other BBS
was timing out waiting for my system to FIND what I
wanted to send.
And trying to remotely SYSOP left
me frustrated, since very few commands could be executed
without going into remote sysop mode, and back again.
And so the sleepless nights
started! I became labeled by those helping with the
project as the "programmer that never sleeps"!
Mad dashes through the code were made to make temporary
adjustments to bring the performance up to an acceptable
level.
After getting several in the Tampa
area to serve as beta-testers (in addition to the
original club BBS), I then set out to clean up the rubble
and make sense of it.
Then (while on a roll) I decided to
enhance many of the existing features, including the
Conference Bridge. Additional servers were added. A few
GUI "frills" were added. A few adjustments were
made to make it work better with ROSE, since that is what
our local network uses.
Thus begat TNOS! Several were
critical that I did not let the world get their hands on
it earlier, but since this was never MEANT to be anything
other than a personal project, I did not see that I had
the time to put into supporting a project in turmoil. I
waited until it was stable (relatively) and not
undergoing daily changes. I'm sorry if that didn't please
everyone, but (to paraphrase the song), "It's my
code and I'll release when I want to".
TNOS is based on the previous
works of KA9Q, WG7J, and many others. Any copyrights or
other restriction by these authors are still in effect.
In addition, all TNOS additions, extensions, and re-works
are copyright 1994-95 by Brian A. Lantz and are made
availble under the same conditions.
As of release 3.00, TNOS is released under the GNU General
Public License (GPL). Since KA9Q NOS was re-released under the
GPL, the current and future versions of TNOS will also be GPL'ed.
TNOS is provided AS-IS, with
absolutely no promises, warranties, or illusions of
grandeur. Let the non-buyer beware!
I will not get into the minor changes
that have been made to TNOS in this place; there are
many. To summarize a few of the most important:
TNOS supports three different
forms of distributed mailing options, which at first
glance seem to be redundant, but in fact serve different
purposes.
Aliases have been around xNOS
for some time. The only change here comes in addressing.
Originally a message that was sent to an alias of
"them", would explode out to a different
message for each person defined for that alias, but they
would each be addressed to "them", not to the
person whom you wished it sent. This was fine if the
person was served by the local system or had his/her mail
POPed off from the area. Where this REALLY suffered is
when the message is to be sent out via PBBS forwarding.
In TNOS, aliases are expanded as
before, except that the new message are addresed to the
users whose names are specified in the alias list.
The strength of aliases is also
its weakness; the SYSOP maintains control. This is good
for the SYSOPs sake, but it allows the use NO flexibility
in using them, unless the SYSOP has set up an alias that
meets the user's needs.
The Remote Mailer (RMAIL),
originating from the RATS guys, allows the user to send
what looks to the network to be a personal message. When
it is received at the distant BBS, it is exploded into
the list of users that is imbedded in the RMAIL message.
The sender listed these users when he sent the message.
This method gives complete
control of the expansion to the originator of the
message. It requires NO SYSOP intervention to allow a new
distant expansion.
TNOS's Groups are just good old
fashioned Internet Mailing Lists. The TNOS Request Server
(mentioned later) works with the GROUP MANAGER to allow
remote subscription and unsubscription to a group. The
SYSOP still maintains control, since no new groups can be
started except by a user with SYSOP permissions.
This method allows the users to
self-maintain their own mailing lists. By users sending a
single message to :
nerf@ko4ks.ampr.org
it is exploded to many message,
to the members of the group "nerf". New users
are added and removed without SYSOP intervention.
The Internet TIME and DAYTIME
servers are provided, allowing you to set or syncronize
time between machines. The Internet QUOTE OF THE DAY
server provides a way to pass on pearls of wisdom, or in
my case, Star Trek quotes;-) Also provided is a RLOGIN
server, which simply provides an easier way to get into a
Command Session remotely to SYSOP a machine. All of the
normal security measures are there.
There is support for ANSI color graphics
for most interactive servers. It is selectable by the
user. It properly flushes out buffers to keep from
splitting an ANSI control sequence across physical
packets. The original graphic is displayed as it was
intended to be viewed.
The SYSOP has the advantage of a useful
STATUS LINE. The STATLINE contains the time, and a place
for tracking the first 10 interactive sessions. If a
session exists, its session number is displayed in the
STATLINE. If it is the active session, its number is
highlighted. If any session contains new incoming data,
its number flashes, to call your attention to it. This
allows you to carry on several sessions and appear to by
placing your sole attention on each one. There is more
detailed information in the Command Session's STATLINE,
with the number of different types of users (how many BBS
users, how many FTP users, etc.), and the most recent log
message. Each session can toggle on/off the use of the
status line for that particular session.
And there is in TNOS a built-in screen
saver. No, there's no elaborate pictures or fireworks,
just a slowly moving message letting you know that TNOS
lerks behind the mostly blank screen.
While there is still no REAL editor
(where you gonna get the additional memory for it for the
MS-DOS version?), TNOS does provide minimal editing
chores while you compose messages in the BBS. The
Mini-Editor hasn't undergone many changes since it's
initial implimentation.
TNOS Mini Message Editor Commands
/Abort Exits message editor; no message is sent
/Bye Exits message editor; message is complete and sent
/Copy user@addr Sends a copy of message to "user@addr"
/Delete [num] Delete last 'num' lines (defaults to one line)
/Exit Exits message editor; message is complete and sent
/File filename Adds contents of 'filename; to current message buffer
/Help Displays this list of commands
/Message num Adds contents of message "num", in current area, to message
/Original Print message being replied to (only with SR command)
/Print Print current contents of input message buffer
/Quit Exits message editor; message is complete and sent
/Signature Toggles whether your signature is added to this message
/Verbose Print message with headers being replied to (only SR command)
//text To begin a line with a '/', use 2 '/'s (first 1 discarded)
/? Displays this list of commands
. Exits message editor (same as /ex); message complete and sent
The current version of the TNOS
Request Server (REQSVR) is a sub-set of the standard
REQDBF commands with extensions to support message
distribution. You send a command to REQSVR by sending a
message to REQSVR@HOST. The desired command is given as
the subject for the message. Only the Upload command has
any data, so all other types have a blank body for the
message. The response from the server will return the
same subject line, following a status description. If no
errors are found, this will be "Accepted",
followed by your REQSVR command. While a few commands
have been added to the REQSVR recently, the REQSVR Command Summary
hasn't changed much.
The Conference Bridge was expanded in
several ways. The first was to provide alias commands for
people who were used to similar commands on other
conference systems that used a different name for the
same function. Secondly, there were several functions
added for no other reason than FUN! Thirdly,
functionality was added to make it more useful for
running formal and informal nets on the Conference
Bridge. And lastly, much effort was taken to make the
TNOS Conference Bridge as compatible as possible with the
Tampa PingPong (TPP) Convers server. In addition to these
changes and improvements, much time was taken to improve
the stability and security of the Conference Bridge. The various commands of the
Conference Bridge have been changing very rapidly in
recent releases.
The TNOS Information servers are
Hypertext menu-based systems that allow ytuorials, help
systems, on-line surveys, etc. to be easily added to
TNOS. Sub-directories can be added to allow sub-menus
within each Server. Each entry on a menu can be either a
sub-menu or a script file.
These servers are based on the TScript
scripting language, built into TNOS. These scripts can do
a wide variety of functions. The Command Session
"script" command allows you to execute a
TScript script on demand, which (used with the
"at" command) can be used for some very complex
operations, such as maintaining network switches,
unattended file transfers, etc.
There are also several 'hooks' in the
BBS, that attempt to call special TScript files at
certain spots in the BBS, to allow greater flexibility
for the SYSOP without the need to re-compile TNOS.
The Information Servers and TScript
were documented in detail in the 1993 ARRL Computer and
Network Conference Proceedings. A Hypertext link to the
content of this paper will be added here in the future.
The current TScript
specification can be viewed, as well.
Last updated: Sunday, 25-Jan-2004 14:50:28 UTC
| 