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 :


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