💾 Archived View for gemini.spam.works › mirrors › textfiles › programming › comrap.pro captured on 2020-10-31 at 14:49:35.
-=-=-=-=-=-=-
--==: COMRAP'S :==--
GUIDE TO REMOTE DATABASE SYSTEMS
For New Users
==================================
Copyright (c) 1985 by COMRAP
Committee for Remote Database
System Rights and Practices
INTRODUCTION:
~~~~~~~~~~~~~
COMRAP welcomes all new users of remote database sys- tems. As a participant
in this rapidly expanding means of high-tech communications, you are at the
forefront of the general public's movement from voice-based and "hard copy"
com- munications to digital telecommunications.
Remote database systems (RDBSs) are non-commercial public or semi-public
computer systems, operating over standard telephone lines, which provide remote
information access and interchange. Originally known as "BBSs", they include:
1. Message-oriented systems, including remote bulletin board systems (RBBSs
or BBSs - also known as public access message systems or PAMS.)
2. Public domain software exchanges (PDSEs - often known as remote CP/M
systems or RCPMs.)
3. Special interest groups (SIGs), including those on commercial systems
like The Source and CompuServe as well as those operated as stand-alone RDBSs.
4. Mixed systems providing a variety of message, text, and software exchange
(known by any of the above names, but best described by the generic term RDBS.)
If you take the time to read and understand the information in this document,
you should be able to sign on to a remote database system, take steps toward
becoming a validated user of that system, read and write messages, perhaps do
some file transfers, and anything else the system may allow. You will be safe
in the knowledge that you are doing all of this without making any serious
mistakes, such as accidentally accessing the NORAD computer and launching a
flock of ICBMs toward the Soviet Union! (Incidentally... recent motion
pictures notwithstanding, there is no way you or anyone else could break into
the Defense Department's missile launching systems by mistake. They aren't
even tied in to standard telephone lines.)
As with everything else that is good in the world, there are responsibilities
that go along with your telecommunications activities. Always remember that
you are using someone else's computer system; YOU ARE A GUEST! Each system has
its own unique set of rules, so your first priority is to find out what those
rules are and then obey them when you are on that system! Most RDBSs are run
on personal computers by private individuals who dedicate a great deal of time,
expense and equipment for our common benefit. You are the guest of those
SysOps (System Operators) -- always remember to act with courtesy and respect.
NEVER ACT IN A MANNER THAT COULD BE DETRIMENTAL TO THE SYSTEM. DO NOT
ATTEMPT TO CRACK OR CRASH AN RDBS OR ANY OTHER REMOTE COMPUTER SYSTEM! In
almost every jurisdiction in this country, the act of accessing a computer
system without authorization is either a misdemeanor (like breaking and
entering) or a felony (computer fraud.) And someone who "legally" accesses a
system and then attempts to disrupt or do damage to that system is equally
guilty of committing a crime.
Having said that, let us put your mind at ease. Most systems are set up with
enough security measures that mistakes by new users have absolutely no effect
on the system's integ- rity whatsoever. If you screw up, don't worry about it.
In the rare case where it appears you may have caused a serious prob- lem (the
computer automatically logged you off, or the display went blank and you
couldn't figure out how to recover it,) just hang up and call right back. Then
you should send an electronic note to the SysOp letting him/her know that YOU
realize that you "pushed the wrong button." SysOps are aware of the fact that
it takes a while for new users to learn the ropes. They can tell from their
records of your activity that you weren't attempting to do their system any
harm. (And if you follow these guidelines -- written by two SysOps with lots
of exper- ience with new users -- you'll certainly minimize those mistakes!)
- - - - - - - - - - - - - - - - - - - - -
LET'S GET STARTED!
~~~~~~~~~~~~~~~~~~
A. "I've got a computer and a modem, what now?"
One of the first problems you'll encounter is "Who can I call???" Getting
that "first" phone number can be fairly easily accomplished by contacting a few
computer retailers, or just asking your friends or business associates (all of
whom have computers and modems, right?!) Then, once you've gotten on a system,
you are likely to find a few messages about other RDBSs -- and many systems
even have included a comprehensive list of RDBS's in your area that is
available for you online. The Source and CompuServe also contain extensive,
nation-wide listings. However, both of these are subscription services that
charge an hourly fee when you're logged on. Your best bet is to try your local
sources.
Pretty soon, you'll have a fairly large list of your own, and it won't take
long to determine which systems you like best or which offer you the most
desirable features. Smaller systems go up and down like flags, and some of the
numbers you get may no longer be valid. If you encounter this situation, THROW
THE NUMBER AWAY! It may have been re-assigned by the phone company to another
individual who knows nothing about computers, and it is very irritating to pick
up the phone and get a modem tone in your ear! If someone answers "voice",
it's courteous to pick up your receiver and ask them if there is a RDBS
operating at that number. If not, apologize for the wrong number and scratch
it from your list. Then contact the person you got the number from (SysOp of
an RDBS, computer retailer, friend) and inform him (or her) that the number is
NOT an RDBS any more and should not be given out to anyone else.
Before you make your first call, though, a word of warning: THE TELEPHONE
SERVICE KNOWN AS "CALL-WAITING" CAN BE VERY HAZARDOUS TO YOUR
(TELECOMMUNICATIONS) HEALTH! Call- waiting is a very useful service,
especially to families with teenaged children. But the "beep" that signals
that a caller is waiting acts as a "break" tone and usually causes one or both
modems to disconnect. Try to avoid using a modem on a line with call-waiting
except during periods of low telephone usage (late evening, for instance.)
Also, some "clever" users have devised schemes to dis- able call-waiting.
These schemes include attaching voltage- producing devices to the telephone
line and "busying out" one of the lines by dialing Telephone Company test
loops. These methods are NOT approved and may result in very serious conse-
quences. (By adding non-FCC approved equipment to the phone line, these users
can be held personally liable for any damage caused to phone company
equipment.) If call-waiting is that much of a problem, the only two recommended
solutions are to have call-waiting removed (which will save you a few cents a
month anyway) or to add another line for the computer (which is a luxury not
everyone can afford, but is really the best way to go in the long run.)
B. Connection: You're on-line!
All right, so you've made contact with a RDBS. What now? Depending on the
type of program the system uses, and the machine it's being run on, signing in
(logging on) is accom- plished in various ways. For example, if you've
accessed an IBM-PC running the popular "RBBS-PC" program, you would press
<Enter>, two or three times, s l o w l y, until it recognizes your presence.
(RBBS-PC calls the <Enter> key "C/R", for Carriage Return.) This allows the two
computers to match up with each other so that communication can begin. The
process of entering one or more carriage returns upon getting a CONNECT is very
common, although some systems do not require it. From that point on you will
be "prompted," or asked what you want to do next.
1. Signing on (logging on, logging in, etc.)
Now you will be asked certain questions that you must answer in order to be
"validated," or allowed to use the system. It's good practice to enter only
accurate, honest information. Usually, it goes something like this: FIRST
NAME then LAST NAME (or sometimes FULL NAME); CITY and STATE you're calling
from; a valid voice phone number where you can be reached; and your PASSWORD.
a. First and Last names.
This information is probably the most important. This will be how you're
known to the SysOp and other users, and will be the name to which private
messages ("E-mail") are addressed. Some RDBSs allow the use of phony names,
"handles", aliases, etc. Check out the rules of the system to see if this is
permitted. In just about EVERY case, however, you will be required to disclose
your true identity to the System Operator. We recommend that you sign on with
your own name first. If you later learn that aliases are allowed, and you wish
to use one, ask the SysOp to alter your record accordingly. (SysOps of many of
the more sophisticated systems around the country will not validate a person
who logs on with an alias, even if s/he gives the correct name later. Right or
wrong, they feel that aliases are a sign of immaturity and thus that the pros-
pective user might just cause problems rather than make a positive
contribution.)
b. City and State.
This information is not usually that critical, unless you are calling out of
state, but it must be entered. A few SysOps mail passwords to newly validated
users, so a complete mailing address may be required.
c. Telephone number.
Some systems require this information one-time only; some use it as part of
your password. Some System Operators will not allow you full (or even ANY)
access to the RDBS until they have called you "voice" to verify your vital
information.
d. Your password.
Sometimes the SysOp will assign the password that you'll need for further
access, and either leave it on the system for you to find the next time you
call in, or phone you "voice" and give it to you. Usually, though, you will be
asked to type in the password you wish to use. Sometimes the system will ask
you to type it again, and this second time you will see symbols instead of
letters (like "......." or "$$$$" or "12345678". This is a security
feature, so that in the future you can type your password with people looking
over your shoulder. (All they will see is symbols.) Make your password clever
enough so that no one can figure it out, but not so clever that you forget it!
It's very difficult to prove to a System Operator that you really "lost" your
password, and you're not actually some nefarious person trying to gain un-
authorized access. WRITE IT DOWN and put it in a safe place where nobody else
is likely to see it.
== AND THAT BRINGS UP A VERY IMPORTANT POINT. ==
In case you feel a little nervous about giving all this private information
to some stranger, let us try to calm your fears. YOUR PERSONAL DATA IS HELD IN
THE STRICTEST CONFIDENCE! Of course, there are some bad SysOps, just like
there are bad users. And very occasionally accidents do occur, sometimes with
unfortunate results. But this is VERY rare, and any SysOp who is foolish
enough to betray the confidence placed him/her will VERY soon have a system
with no users on it! It is also a wise practice to use a DIFFERENT password on
each and every system that you access. That way, if someone discovers your
password it will only affect ONE system... a situation that is not all that
difficult to deal with. In addition, some users like to change their passwords
at regular intervals. The already slim chance for abuse is reduced even
further!
2. A new user's first log-on information.
Most systems include a new-user message. This is nor- mally seen only the
first time you get on a system. It may contain a greeting, a summary of
commands, instruc- tions, system news, or the rules that you will be expected
to observe on that particular system. READ IT THOROUGHLY! As a general
practice, you should have your "capture buffer" open or your printer turned on
each time you log in to a new system. This allows you to study the rules and
procedures of that system before you log in again. (See your communications
software instructions for information on how to capture data to disk or the
printer.)
Note that this information is always on-line when you log in, so if you've
forgotten anything and don't have the printed copy handy, just type "H" or "?"
at the main command prompt and you will see how to access the new user
information. (See below.)
C. The Main Command prompt and Menus.
Almost every system in use has a main command prompt, and a main menu from
which you can select what you want to do. The latter will list the commands
that you may use, and these may provide access to one or more files that are
designed to assist you. Known as "help files", they are usually accessed by
entering "H", or "?", or ".HELP", etc., depending on the particular RDBS. WE
CANNOT STRESS THE IMPORTANCE OF THESE HELP FILES ENOUGH. In fact, you should
always print them out (or write them down) so that you can easily refer to them
until you become comfortable with the system. Some other common commands are:
"E" (or "P") for Enter (or Post) a message; "R" for read messages; "G" for
Goodbye; "F" for the file transfer area, and so on. EACH TYPE OF SYSTEM IS
DIFFERENT, SO TAKE THE TIME TO LEARN THE COMMANDS EACH SYSTEM USES. For
instance, some systems allow you to leave a private message for the System
Operator at any time during your session. Others ask you if you would like to
do so when you log off. It won't take long before you develop a "feel" for
each type of system.
NOTE: Experienced users make it a practice to log on to a new system,
"capture" all of the bulletins, help files, and so forth, and then log off
without actually USING the system (except to provide whatever information is
required for future access.) Then the expert users STUDY the help files until
they have a fairly good idea of how the system operates. This pro- cedure is
all the more important with systems dedicated to software exchange, the
procedures of which can be very complex. If this is a good practice for
experts, it's an even better practice for novices!
D. Respect the time the SysOp must devote to the RDBS and try not to add to
it!
There is nothing more irritating to a System Operator than a brand-new
caller, usually a novice, who immediately switches the terminal to "Expert"
mode and then starts stumbling around the system, totally lost. ("Expert"
mode, found on most systems, is for the user who has mastered that system and
no longer needs the majority of the menus or other assistance.) After becoming
completely confused, the user will then either "page" the SysOp, which means
try to get the operator to type directly to him/her on-line, or leave personal
notes to the SysOp like, "I can't get this thing to work," or "What's wrong
with the message area?" THE INFORMATION YOU NEED IS IN THE HELP FILES OR THE
SYSTEM'S BULLETINS! (If it's not, it's not much of a system.) If all else
fails and you can't get an answer to a legitimate question, by all means try to
contact the SysOp... but think of it as a last resort measure.
Also, concerning the "Page" or "Operator" command: this is a feature found
on most RDBS's which signals the SysOp that a user wishes to "chat" (or type
directly back and forth). It does so by causing the host computer to beep,
thus alerting the operator. One quick way to get on a SysOp's bad side is to
engage this function time after time after time. Usually, once is enough! If
the operator does not respond, s/he is either not around or does not wish to be
disturbed. In that case, simply leave a Comment (or Feedback, etc.) for the
SysOp. If your question or comment requires an answer, you'll usually get one.
Some things that will not get a response are questions about system commands or
procedures. As stated above, everything you need to know should already be
included in help files or bulle- tins. Bear in mind that each message, comment
or reply takes up precious disk or memory space, and smaller systems have a
very limited amount of room. Make your comments count. If you sin- cerely are
confused about something and need help, most SysOps (and users, for that
matter) will bend over backwards to help you out. After all, we were all
beginners once!
E. File transfer.
This refers to moving "files" from the host computer (the system you're
logged onto) to your computer, and vice-versa. Many RDBS's have a variety of
games, utilities, text files and even applications programs which are in the
public domain or which the copyright holder has allowed to be freely distri-
buted for non-commercial purposes. These may be shared freely among users. Do
not expect to find commercial (store-bought) software available for you to
download, but some of the so-called "freeware" is better than its slick,
expensive counterparts and can be found for almost any brand of computer that
you can think of. By the same token, do not attempt to upload programs that
you have purchased or suspect might be "pirated" from legitimate sources. This
type of activity could lead to serious legal problems. Systems with a download
section normally contain a "directory" of files which are available to you.
(Some systems require you to upload a certain amount of software in proportion
to the amount that you download... the idea being that you should contribute
as well as benefit. This is how "freeware" gets distributed and it is
important that it be a two-way street.)
You will need to use a communications program that offers uploading and
downloading capabilities in order to transfer files back and forth. Refer to
the instructions packaged with your communications program for the specific
procedures. In order to transfer files error-free, you will need to use one of
many error-checking systems built into most communications programs. The most
common system is called XMODEM, or sometimes Christensen Protocol (after Ward
Christensen who developed the protocol in 1978). There are a number of other
protocols avail- able, but none enjoys the wide-spread use of XMODEM.
F. Reading and posting messages.
The typical RDBS is message-oriented, hence the term "bulletin board system"
or "public access message system." One of the major benefits of RDBSs is that
they provide the user with the ability to exchange information with friends or
others with common interests. (There are a number of RDBSs around the country
that limit membership to those in some profession or field of interest, such as
silicon engineering, medicine, law, politics, photography, real estate, and so
forth. In other cases, there may be a sub-section on the RDBS for such SIGs,
or Special Interest Groups, which may require a sepoarate valid- procedure
before you can obtain access.
When reading messages, we suggest that you use the continuous or "non-stop"
mode if the system offers it. (After the first message, you will usually be
prompted by something like "CONTINUE? YES, NO, N/S". N/S refers to
"non-stop".) On very busy systems, especially at 300 bps, you may barely have
time to capture all the messages to disk or printer before your time has
expired. Even on those with longer time limits, it is courteous to read
messages "off-line" rather than tying up sys- tem time to do so. Then, if you
see something that you wish to reply to, you can do so during your next
session.
If you wish to send a short message of just a few lines, the normal procedure
is simply to type the message while on-line. However, for long messages or for
messages which may take time to compose, or for those of us who are
hunt-and-peck typists, type your messages off-line and then "upload" them to
the system. (The slower modems "type" at about 300 words per minute, the
faster at up to 2400 wpm. The average person of moderate typing ability can
type at 30-45 wpm; with time out to compose one's thoughts, that speed is
reduced to about 15-20 wpm.) Don't tie up 15 minutes of system time typing a
long message that could be uploaded in 15 seconds!
In any case, avoid "playing games" within messages. Control characters,
ASCII graphics (drawings of Darth Vader or what- ever), repeated carriage
returns and tabs or spaces before ending the message, and other "excess
baggage" is usually frowned upon by SysOps and users alike. The reasons are
not aesthetic, but relate to the time it takes to scroll through the message
(at 300 bps) or the fact that bunches of C/Rs cause the text to scroll off the
screen faster than people can read/scan (at 1200 bps or faster.) And it is
particularly disturbing to those using hardcopy terminals or who capture
everything to their printers.
NOTE: Some systems (especially PDSEs) are primarily for file transfers and
actively DISCOURAGE message activity except for information and questions about
computer hardware and/or soft- ware. A few large PDSEs don't even HAVE a
message base: the only person with whom one can communicate is the SysOp.
G. "Pay" systems.
Although the majority of RDBSs in existence today are "free" to the user, the
trend is to require a small annual donation for system maintenance and
upgrading. The typical small system may be run on the SysOp's personal
computer during hours when neither the computer nor the voice line is in use.
The additional cost of running the system is usually an occa- sional service
charge for drive alignment. Usually the SysOp is more than happy to pay this
for the enjoyment of operating his/her own RDBS.
Larger and more complex systems are another thing entirely! Often using
sophisticated custom operating systems and bulletin board programs, with hard
disks of 10 to 140 megabytes, and with one or more telephone lines dedicated to
the system, these RDBSs are expensive and very time consuming to operate.
Systems like PDSEs (which are primarily a source of "freeware") require that
the operator spend a certain amount of time and money on long distance phone
calls to OTHER systems to ensure that s/he has the latest and best software
available.
These sophisticated systems will often charge $10 to $30 per year for user
access. A few are not worth the price of a phone call, but many are well worth
the money, and offer a viable and much less expensive alternative to commercial
sys- tems such as CompuServe and The Source. And even at $30 per user, the
income rarely exceeds the cost of maintenance and upgrading.
IN CONCLUSION:
~~~~~~~~~~~~~~
You are now involved with one of the most fascinating and far-reaching
developments in the history of man: instant, world-wide personal
telecommunications. You may wish to use it for fun, for learning, for
business, for on-line shopping and banking, for obtaining free software
(freeware) - virtually any form of communication or information exchange you
can imagine. Being a good, responsible user can be summed up in one sentence:
"Learn how to USE a system to its full potential and never ABUSE a system in
any way." There are laws in existence now (and new ones being passed all the
time) concerning what you may and may not do with your computer and modem. And
violators ARE being prosecuted. (Not to worry: COMRAP is trying to keep a
close watch on these laws. So far, as long as a user doesn't violate the
rights of others, s/he's safe. That's the way it should be.)
When in doubt, feel free to try out the commands available from the system
menus. You don't have to worry about harming the remote system; all good RDBSs
have security features built in to protect the system as well as YOU. As you
learn more about how to take advantage of the various features offered by
RDBSs, your enjoyment will continue to increase.
Use your modem to pass this information on to your computing friends... and
H A V E F U N ! ! !
~~~~~~~~~~~~~~~~~~~~~~
- - - - - - - - - - - - - - - - - - - - -
GLOSSARY OF TERMS:
~~~~~~~~~~~~~~~~~~
ACCESS: To get onto a system or into a particular area of a specific system.
BBS: Bulletin Board System. Usually message-oriented RDBSs.
BPS: Bits per second. This is a measurement of how fast data is travelling
between two modems. Eight bits is one single character or space. Typical
speeds for modems using standard tele- phone lines are 300, 1200, and 2400 bps.
This is also refered to as "baud rate", which is techni- cally incorrect, but
in common usage.
BAUD RATE: Frequently used to represent the speed at which data is
travelling. (See BPS.)
BREAK: A 200 to 600 millisecond tone usually used when connected to remote
mainframe computers. If used with most RDBSs, it is likely to cause the remote
to disconnect. An incoming call on a telephone line with "call-waiting" has
the same effect.
BULLETIN: Text information that the System Operator wishes you to be aware
of. Bulletins may appear directly before or directly after log-on, or may be
accessible at any time from the main command level. You should always read new
Bulletins.
CALL-WAITING: A telephone company service that lets the tele- phone user
know when there is an incoming call when the line is in use. This will usually
result in a modem being disconnected.
C/R: Carriage Return; the <Enter> key.
CARRIER TONE: The high pitched "squeal" made by the modem. Different
pitches enable two modems to "under- stand" each other.
CHAT: Type directly back and forth with the System Operator while on-line.
Usually a very slow and inefficient way to communicate.
COMMAND: An instruction to the remote system to do some- thing. Entered in
response to a PROMPT.
COMMENT: Usually a personal message to the System Oper- ator. (See
FEEDBACK.)
COMRAP: A not-for-profit organization involved in pro- moting and protecting
the interests of RDBS users and operators.
DATA LINE: A telephone line more-or-less permanently con- nected (dedicated)
to a computer via a modem. May be either a standard telephone line (dial- up)
or a leased "data-grade" line. Most RDBSs use standard telephone lines.
DIRECTORY: A listing on the remote computer of the files available for
downloading, placed there by the SysOp. On some systems, the directory is
auto- matically updated to include files contributed by users.
DOWNLOAD: Transfer a file from a remote system to your computer. It comes
"down" the line to you.
E-MAIL: Electronic Mail. Personal message from one user to another. A
private message.
ENTER: The <Enter> key or Carriage Return (C/R) key on your computer.
EXPERT MODE: Available on most remote systems. Suppresses most menus and
help files for more advanced users. (If you aren't, don't!)
FEEDBACK: Usually a personal message to the SysOp. Same as COMMENT.
FILE: A computer program or volume of text.
FILE TRANSFER: The uploading and downloading of files.
FREEWARE: Software that may be freely distributed for non- commercial
purposes. Usually copyrighted and sometimes accompanied by a request from the
author that the user donate a small amount of money to him/her if the program
turns out to be useful.
HANDLE: An alias; phony name. Some systems allow them.
HOST: The (remote) computer that you're calling. Can be a micro, mini, or
mainframe system.
ICBM: Inter-Continental Ballistic Missile.
LOG OFF: End your session. You must log off by using the proper command in
order for your personal user file to be updated properly! Repeated failure to
properly log off will almost always result in the SysOp "devalidating" you.
LOG ON: Gain access to a remote computer system.
MODEM: MOdulator-DEModulator. A device that connects your computer to other
computers across stan- dard telephone lines. The remote computer must also be
connected to its own modem.
NORAD: North American Air Defense Command. The Air Force.
PAGE: Alert the System Operator that you wish to com- municate directly with
him/her by typing. (See CHAT.)
PAMS: Public Access Message System. (See BBS.)
PASSWORD: Your secret code word that identifies you to the remote system.
PDSE: Public Domain Software Exchange. A new term that is more generic than
the old term (RCPM), which leaves the impression that the system offers only
CP/M software. (See RCPM.) Software may be public domain or freeware.
PIRACY: The act of knowingly obtaining, sharing, trading or copying
proprietary software to avoid having to pay for it.
PROMPT: A signal from the host computer indicating that it is waiting for
you to tell it what action you desire it to take. May be a symbol (>, ?, etc.)
or a word, sometimes accompanied by a beep.
PUBLIC DOMAIN: Software that is not copyrighted and which you may freely
share with other users. Often this term is incorrectly used to refer to ANY
sof- tware that is distributed free or for a very small donation. (See
"Freeware".)
RBBS: Remote Bulletin Board System. Also the name of a number of related
bulletin board programs.
RCPM: Remote CP/M system. Primarily a place for soft- ware exchange; the
caller is actually using the host computer as if s/he were at the local
keyboard. Even though the host is usually run- ning the CP/M operating system,
you can rou- tinely find software for most other operating systems.
RDBS: Remote Data Base System. Though usually associ- ated with systems
that offer more features than a simple Bulletin Board System (BBS), the term
encompasses all forms of non-commercial public and semi-public remote computer
databases. (RBBSs, BBSs, PAMSs, PDSEs, RCPMs, even SIGs on commercial systems
like The Source and Compu- Serve.)
SIG: Special Interest Group. Usually a section of an RDBS or a commercial
database that is devoted solely to discussion and information on a spec- ific
topic (most often, a specific type of com- puter or a specific programming
language, but can be anything from antiques to zoology.)
SYSOP: System Operator. S/he's in charge.
UPLOAD: Transfer a file from your computer to a remote system.
USER: Anyone who logs on to a remote computer system.
USER GROUPS: Organizations of computer users centering around a particular
computer type or programming language. Often the basis of SIGs (see above.)
Many UGs operate their own RDBSs for the benefit of their members; in some
cases they are open to the general public.
VALIDATION: The process of granting system access to pro- spective users.
VOICE LINE: A standard telephone line used primarily for voice
communications. Many RDBS users use their voice line for data communications
as well.
=========================================
COMRAP wishes to express its sincerest appreciation to the following two
system operators, who devoted much time and energy to the writing and
publication of this Users' Guide.
DAVE SCOTT, SysOp: Zephyr RDBS Communications
CHRIS MITCHELL, SysOp: =Silent Side= RDBS
==========================================
This document is Copyright (c) 1985 by The Committee for Remote Database
System Rights and Practices (COMRAP). COMRAP grants the reader the right to
copy and distribute complete and un- altered copies of this document by
electronic means only and without charge to the recipient, for non-commercial
purposes. (You may adjust the margins to fit on systems with different column
widths.) However, in no case may any portion of this document be altered or
distributed in hardcopy form without the written consent of COMRAP. Commercial
organizations should contact COMRAP if they wish to incorporate this document
in any other publication. Typeset printed copies in book form are available to
user groups and other non-profit organizations for a nominal fee. Just contact
us in writing or through the COMRAP RDBS with your requirements.
COMRAP
P.O. Box 8696
Scottsdale, Arizona 85282
-----------------
COMRAP operates the COMRAP Remote Database System 24 hours a day, 7 days a
week at (602) 253-4269. The system is accessible at 300 or 1200 bps, with
immediate access for all new callers.