TOPS-20 RELEASE 5
                            
Congratulations on your purchase of the finest operating system available,
TOPS-20.  If treated properly, TOPS-20 will give you many years of service. 
The developers commend you for your discriminating taste, but ask that you read
the rest of this document before opening the carton.
  
This is our system. We designed it, we built it, and we use it more than you
will. If there are some features you think might be missing, if the system
isn't as effective as you think it could be, TOUGH. Give it back. We don't need
you. See fig. 1.
                 
 
                  ______________________________________
                  |                  _                 |
                  |                 ( )                |
                  |                 | |                |
                  |                 | |                |
                  |              .-.| |.-.             |
                  |            .-|  | |  |-.           |
                  |            | |       | ;           |
                  |            `\          ;           |
                  |              |        :            |
                  |              |        |            |
                  |              |        |            |
                  |                                    |
                  --------------------------------------                
                                  Figure 1.
                                
Let's  take  a  look  at  some  of the features  of  the  TOPS-20 operating
system.
                                                                     
1) Options. We've got lots of them.  So many, in fact, that you need two strong
men to carry the TOPS-20 Software Notebooks around. So may that it will be a
cold day in hell before even half of them are used. So many  that we used to
hire students to try different combinations of them to see what would happen.
They had so much fun playing "what if" that they thought up more options than
they tested. The number of options doesn't count, however, because we picked
some interesting values for our options and called them...
  
2) Defaults. We put a lot of thought into our defaults. We like them.  If we
didn't, we would have made something else be the default,  wouldn't we? So keep
your cotton-picking hands off our defaults.  Don't  touch.  Consider them
mandatory.  "Mandatory defaults" has a nice ring, doesn't it? If you change
them and your system crashes, tough. We don't care.  See fig. 1.
  
3) Language Processors.  They work just fine. They take in source, and in most
cases build object files as a reward for your efforts. In some cases the object
file produced is useful. If not, too bad. If you can do a better  job, hop to
it. We've got assemblers; write your code in them. One is supported, and one we
use. The developers of that product think a lot like we do. They said "See fig.
1."
  
4) Error Logging. Ignore it. Why give yourself an ulcer? You won't give us
preventative maintenance time, and we can't fix it anyway. Oh, and if something
breaks between 17:00 and 18:00 or 9:30 and 10:30 or 11:30 and 13:30 or 14:30
and 15:30, don't waste your time calling us. We're out. See fig. 1.
  
5) Front End Processor. This is a concept developed by the Software Engineering
Group in Marlborough. Take the stuff we had trouble with in the KA  and
distribute it outward where we don't have to think about it. It's a  convenient
thing to hide behind, and all sorts of bugs will float around out there before
someone can pin it on us. If someone tries, we can say "maybe  RSX20-F didn't
send it right, so go away and see fig. 1."
  
6) Host System. This is a concept developed by the Real Time and Communications
Group. That's what that group was called, by the way, back when we had to
pretend we gave a damn about real time. We told the real time users to see fig.
1. a long time ago. We used to call them the "Communcations Processor Group;"
now we just refer to them as part of TOPS-20 Operating Systems Development,
when we refer to them at all.  Anyway, RT&C thought up the Host as a way to
absolve them from any responsibility for the actual processing of any data they
might happen to pass through. If something disappears the host lost it, and
that's all there is to it.  The line of demarcation between the Host and the
Front End has gotten hazy since  the inception of VDH (very deeply hidden)
routines. In fact, many of the host  people were tricked into working on VDH 
and associated activities   (they  thought  they  were writing games for a
microcomputer).  Everyone forgot who they were deferring problems to, and for a
while both  sides worked with no bugs. That's been fixed.
  
In conclusion, here's your system.  Love it or leave it. But don't complain.