



















               ͸
 ; Wildcat Version 3.0 - Avoiding "Future Shock" ͸
  A users' re-education guide to the changes and features of Wildcat! V3.0  
 ͸Kevin Brokaw - Walden Puddle BBS (607)-687-6193;
               ;




                          Revision 1.02 - 09/02/91













































                              Table of Contents.......

                   0.0 - Disclaimer................................1
                   1.0 - What happened here??......................2
                     1.1 - Features that have been added...........2
                     1.2 - Features altered from V2.55.............3
                   2.0 - Rummaging around..........................3
                     2.1 - The initial logon.......................3
                     2.2 - Main menu commands/options..............3
                     2.3 - Message menu commands/options...........6
                     2.4 - File menu commands/options..............8
                     2.4.1 - File transfer protocols..............10
                   3.0 - Optional Features external to Wildcat!...14
                     3.1 - Netmail/Echomail revealed..............14
                     3.2 - Becoming a TOMCAT! Power user..........16
                     3.3 - Doors and Drops........................17
                   4.0 - In conclusion............................18





















        Wildcat 3.0 - Avoiding "Future Shock"                        Page i


     0.0 Disclaimer....
           This document was produced independantly without prior knowledge
       or consent of Mustang Software. While all efforts have been made to
       ensure it's accuracy, the Author accepts no responsibility for any
       ommissions or inaccuracies. The information contained in this document
       is intended as a GUIDELINE ONLY for users of the WILDCAT! BBS system,
       and is not to be construed as a manual of any kind. If you feel it is
       of value to you, please consider a small contribution of $1.00 to the
       Author. If you are a reader from outside the United States, instead of
       a dollar, my children would LOVE to see postcards from other countries!
           This document is Copyrighted 1991 by Kevin Brokaw and the Walden
       Puddle BBS, and is not to be reproduced in whole or in part (exclusive
       of the distribution policy shown below) without prior written consent
       of the Author. The author may be contacted in the following manner:

              Postal Service: Kevin Brokaw
                              The Walden Puddle BBS
                              1026 Day Hollow Road
                              Owego, NY 13827, USA

              BBS:            Walden Puddle Wildcat
                              (607)-687-6193/6049 24 hrs 1200-9600(V32) baud
                              Send message to Sysop or Kevin Brokaw

              FIDOnet:        Kevin Brokaw @ 1:260/450
              MAGnet :        Kevin Brokaw @ 100:910/0
              UUNET  :        gandalf@paladin.owego.ny.us

     A word about shareware.....
           Although Wildcat is a commercial product copyrighted by Mustang
       Software Inc, many of the "external" programs and features that a
       typical sysop will use and install on his or her Wildcat system are
       distributed under the concept know as SHAREWARE. This allows the sysop
       to "test-drive" a version of the program or utility, often fully
       functional, for a limited period of time prior to actually purchasing
       it via mailing a "registration" of some set dollar amount. I would
       ask users of all BBS's to consider the expense that a sysop incurs
       in operating a BBS (my personal contribution is in the thousands, and
       I am not unique), and assist the sysop in registering the programs that
       you use and enjoy on the system. Even if subscriptions or fees are not
       required for use of a BBS, most money-depleted sysops will welcome an
       individual contribution. With all the features that most high-quality
       BBS's offer, a 10 or 20 dollar check seems to be money well spent.

     Distribution policy of this document....
           This document may only be re-distributed in its' ORIGINAL COMPLETE
       FORM, electronically or in print, provided it remains unaltered, and
       no charge is levied for its' distribution. It may not be incorporated
       as a component of any other product, service, or archive, whole or in
       part, without express written consent of the author.






        Wildcat 3.0 - Avoiding "Future Shock"                        Page 1

     1.0 What Happened here?

           If you have been used to using a Wildcat version 2 system before,
       things may look just a bit different to you the first time you log
       on to a version 3 system. It still SEEMS like the Wildcat you've come
       to know and love, but it feels somewhat different. Rest assured, this
       is because new and wonderful things lurk beneath the covers....

     1.1 Features that have been added

           The first thing you may have noticed, if it wasn't there before,
       was that Wildcat didn't answer the phone when you called! You may have
       received some cryptic message calling itself FrontDoor, D'Bridge,
       BinkleyTerm, or some other unfamiliar name, and demanding that you
       either start hitting the ESC key on your keyboard, or wait 10-15
       seconds. This is because one of the most exiting things added in
       Wildcat V3 is the ability to share network mail with thousands of
       other BBS's, and hundreds of thousands of users all over the world.
       These "odd looking" front-end-answering machines are actually electronic
       "postmen", and exchange the mail you may send or receive or wish to
       read between each other. Names like FIDOnet, MAGnet, EGGnet, and many
       others may become familiar to you in time, and "addresses" consisting
       of cryptic numbers, colons, and slashes will be advertised to you.
       These programs are required to exchanging mail of this type (also
       called FIDO format, or FTSC netmail/echomail). Of course, there are
       other formats and technologies for exchanging mail, such as TNET, but
       these methods are not obvious to the caller, as they do not involve
       "front end" answering machines. More on Netmail/Echomail will be
       discussed in a later chapter.

           Another feature that may have caught your eye is that Wildcat now
       knows "in advance" if you are using a color monitor, or have ANSI
       color enabled. You don't have to tell Wildcat if you want color.. it
       knows. Of course, you may always tell it go back to the non-color
       mode of screen disply if you wish; Wildcat has not forgotten how to
       listen!

           Other new features include a fullscreen editor for entering your
       messages, The ability for you to use your favorite alias (or "handle")
       in some or all of the message bases (if the sysop so configures the
       system), The ability to attach messages and files together so that a
       file to download may accompany a message, The implementation of
       conferences (sort of like "boards within the board") where special
       topics may be discussed, special files may be available, and special
       rules may prevail, The ability to list and mark multiple files for
       later download, along with vastly enhanced description capabilities
       for files, and many other wonderful "toys" to play with!

           As you use the Wildcat V3 system, I think you will agree that it
       has just about everything you could want, and maybe even a few things
       that you didn't know you wanted! At any rate, read on for a tour of
       some of the new and changed features.





        Wildcat 3.0 - Avoiding "Future Shock"                        Page 2


     1.2 Features altered from Wildcat V2.55

           Very few of the features available in Wildcat V2 are radically
       altered or removed in V3. Gone is the "message folder" concept,
       replaced with the more powerful "conferences" described previously.
       Protocols like Zmodem and Kermit are available internally, and batch
       uploads as well as downloads are permitted. Issuing scans of new
       messages and/or files provide much more flexibility in information
       displayed, as well as how it can be used or manipulated. More
       about that later, in the Message and Files section overviews.

     2.0 Rummaging around
           Ok, now we are ready for a brief tour of the system, and its'
       functions. Remember, Wildcat is still one of the most highly flexible
       BBS packages around, so all features referred to here may or may not
       be enabled or available at the sysops' descretion, and menu selection
       characters (the ones in the brackets "[]") may have been changed by
       the sysop, in the customization process.

     2.1 The initial logon
           You have started your favorite terminal program on your PC and
       dialed your local Wildcat V3 system. If it isn't busy <grin>, you
       will connect either with a front-end mailer (if the system is part
       of a "FIDO-format" network), or with Wildcat directly. After hitting
       the ESC key (for mailers) or a brief 1-5 second wait (for Wildcat),
       you will see the welcome screen, and Wildcat will send a special signal
       to your PC to see if it supports ANSI color codes. If sucessful,
       Wildcat will respond that it has detected ANSI color, and will turn
       on color capability. You will be prompted for your name and password,
       and will then be presented with the usual assortment of "hello" screens
       that you may have seen before (these are purely optional to the sysop,
       and may or may not be displayed. Up to 9 may be configured by the
       sysop). Once the intro screens have been displayed, you may be
       presented with the bulletin menu, or merely asked if you wish to see
       it (again, configurable by the sysop). After completing the bulletin
       menu process, you will be notified of new personal mail waiting,
       and notified in what conferences it is located. All new personal mail
       is flagged so that you may read only it if you wish via the [U]nread
       personal mail option of the message read command. Unread personal mail
       stays flagged until you read it, even if you log off, Wildcat remembers.

     2.2 Main menu commands/options
           Here is where you begin exploring... you have may options available
       to you, so we will go over them in detail...

       [B] - Display the menu of bulletins. This is usually a listing of
       files of general interest for reading, such as statistics, or scores
       for online games. Select the display file # you want from the menu.








        Wildcat 3.0 - Avoiding "Future Shock"                        Page 3

       [C] - Comments. This allows you to enter a message to whomever is
       listed as the conference sysop of the conference you are presently
       joined to.

       [D] - Doors menu. If online programs or games are available on this
       system, they will be selected here, via a menu.

       [F] - Files menu. Go to the menu for the system's file areas.

       [G] - Goodbye. Log off the system. It should be noted here that
       this is the best and most courteous way to exit any BBS. Simply
       "hanging up" may cause unpredictable errors, with the next person
       wishing to use the system as the victim, either through corrupted
       data or an unavailable BBS. Please be courteous and use the appropriate
       logoff command for ANY BBS you use, no matter what software is run.

       [H] - Help level. Rather than provide general help, this option
       merely allows you to select the amount of "help" you want with menu
       selections. Select:
                 [N] for Novice level. Full menus and prompts provided.
                 [R] for Regular level. No menus, but a command line giving
                     all available one-letter menu commands is displayed.
                 [E] for Expert level. No menus or command lines. Just a
                     command prompt ("[ ]")

       [I] - Initial welcome screens. This re-displays all screens that are
       usually viewed upon entering your password at logon, up to the
       bulletin menu prompt.

       [J] - Join a conference. Allows you to switch between specific subject
       conferences. When Joined to a particular conference, messages and
       comments entered will be in this conference message area. Also, a sysop
       may only make certain file areas available with certain conferences.
       If the conference you select to Join is a conference supporting Aliases,
       you may select an alias by using main menu option [Y]. Aliases may only
       be set by FIRST joining a conference supporting them, then selecting
       option [Y]. If option [Y] is selected from a non-alias conference, no
       opportunity to set an alias will be offered.

       [M] - Go to the menu for the system's message area.

       [P] - Page sysop. This option will page the sysop via a beep on HIS
       system's end, requesting him to enter into an online live chat with
       you. If the sysop has set specific hours where chat requests may be
       honored, the page will only be made during these hours. If the sysop
       has completely turned off paging, no attempt will be made. In cases
       of the page attempt being refused or the sysop not answering, you
       are notified of the outcome.

       [Q] - Questionnaires. Presents a menu of Questionnaires and Surveys
       available for user participation. Select the questionnaire # you
       wish to answer.





        Wildcat 3.0 - Avoiding "Future Shock"                        Page 4

       [S] - System statistics. If a system stats bulletin is generated, it
       will be displayed to you if you select this option. If not, you will
       be given a brief rundown of the size and use of the system.

       [T] -  Talk across nodes (Multi-node systems only). Lets you have an
       online live chat with another user presently logged on another node,
       providing the other user a) is available for chat (not using a door
       program or transferring a file), and b) responds to the chat request.
       When a chat request is made, the target user is not interrupted,
       but merely sent a one-line message that you have requested a chat,
       and how to accept the request. If they choose to ignore the request,
       they may continue on as before.

         Once you have paged the other user for a multi-node chat, please
       relax and give them time to finish up on whatever they may be doing,
       and respond to your chat request. You willl be notified when they
       answer your chat request, and are ready to communicate.
         While in multi-node chat, a few special command options are available
       to you. These may be typed at any time, and are not displayed to the
       other person(s) involved in chat:

            /USERS    - Gives you a listing of all users on the BBS and their
                        status (identical to the [W] main menu command)

            /HELP     - Provides on-line help for the multi-node chat facility.

            /QUIT     - Exits multi-node chat.

       Main menu command [Y] can be used to make youself unavailable for chat.

       [U] - User listing. This displays a listing of all users on the system.
       (whether logged on or not, so this may be a VERY long listing...)

       [V] - Verify a single user. If you want to know if Mary Smith is a
       user on this system, issue the [V] command, and enter MARY SMITH
       at the prompt. If she is, you will be told when she last called.

       [W] - Who is online (multi-node systems only). Shows you the status
       of all nodes, and who is using them at that time.

       [Y] - Your user settings. Here is where you tailor your logon options
       to suit you. You may change your password, your computer type, or any
       other personal information (some sysops restrict the ability to alter
       your birthdate or home phone number, as a security measure). Also,
       here is where you may select an alias for yourself if you are presently
       joined to a conference that supports aliases.

       [?] - Command help. This option provides online help on the commands
       available to you, and how they are used.

       Other menu options may be implemented by your sysop - Wildcat provides
       for additional external programs or commands to be executed via unused
       menu command letters. In addition, any command letter default (defaults
       are show in this document) may be changed (ie, using [O] rather than
       [Q] to call the Questionnairre menu, if the BBS operator is a business
       using questionnaires as order vehicles.

        Wildcat 3.0 - Avoiding "Future Shock"                        Page 5


     2.3 Message menu commands/options

       [D] - Delete a message. Allows you to delete a message addressed
       to or from you specifically, whether public or private.
         ** NOTE: On many systems this command is reconfigured to use the
         [K] key for "[K]ill a message".

       [E] - Enter a message. Allows you to enter a message. You may either
       enter the message in the conference you are presently joined to (the
       default), or select another conference for your message, without
       having to join another conference first. You will be prompted for
       the recipient (or ALL), the subject of the message, and whether or
       not it should be private mail (a conference may be configured by the
       sysop to be either public-only, private-only, or either, so this
       choice may or may not be offered within different conferences. You
       may also be prompted for whether or not you wish to use the full-screen
       editor, again dependant upon the system configuration, and what options
       YOU have selected via [Y]our personal options in the main menu.
         You will always have the option of aborting a message at any time up
       until you [S]ave the message. If you use the fullscreen editor, you
       may use the cursor positioning (arrow) keys to move freely about your
       message as you edit it, and commands such as insert, overtype, line-
       deleting/inserting, quoting and more are available to you. Full help
       on all functions is just a keypress away.
         ** NOTE! Some communications programs assign their own values to
       certain keys on your computer keyboard, and do NOT pass the keystrokes
       for these on to the BBS you are logged on to. If you cannot re-map your
       keys to avoid this, or if your communications program does NOT offer a
       "doorway" mode where all keypresses are sent to the BBS, you may be
       forced to use the line editor instead of the fullscreen editor.

         Also, if a conference has been configured as an ALIAS conference by
       the Sysop, you will not be able to enter messages until you have
       selected an alias by [J]oining an alias conference, and using main menu
       command [Y] to update your user record. If you do not wish to use an
       alias, you must enter your real name as an alias.

       [F] - Files menu. Go to the menu for the system's file areas.

       [G] - Goodbye (log off system). See MAIN MENU commands section for
       detail.

       [H] - Help Level (menu prompts). See MAIN MENU commands section for
       detail.

       [J] - Join a conference. See MAIN MENU commands section for detail

       [N] - Net-mail. Where available, this command allows access to an
       external program for message or mail access. One such commonly used
       program is the TOMCAT mail door (explained in a later chapter).
         ** NOTE: On many systems this command is reconfigured to use the
         [D] key for "[D]ownload/Upload mail using TOMCAT".

        Wildcat 3.0 - Avoiding "Future Shock"                        Page 6


       [Q] - Quit this menu. Returns you to the Wildcat main menu.

       [R] - Read messages. This option alllows you to read messages, using
       a number of tailorable options. You may read new messages, all messages,
       individual messages, or unread personal messages, in either the current
       conference you are joined to, all conferences, or the ones selected
       via the [U]pdate option.

       [S] - Scan messages. Allows for a quick scan of the message bases,
       displaying message numbers and subject lines to you for later reading.
       There are many options that allow you to "tailor" your scan:
                 [F]rom       : (default is ALL, or enter a user name)
                 [T]o         : (default is ALL, or enter a user name)
                 S[U]bject    : (default is ALL, or select a subject line)
                 Msg [B]ody   : (default is ALL, or select a search word)
                 [N]umber     : (default is ALL, or select a starting number)
                 [D]irection  : (default is FORWARD, or select BACKWARD)
                 [C]onference : (default is CURRENT, or select ALL or SELECTED)
       Once all tailoring options are set, you may begin the search by pressing
       the [S] key.

       [U] - Update conference scan list. This allows you to build a list of
       conferences which you are interested in following, and ignore those that
       you are not interested in. After building a scan list, you may use the
       [S]elected conferences option of the Check, Read, or Scan functions to
       only look for messages in the conferences you are interested in.
       This list is "remembered" each time you log on to a Wildcat system, and
       may be altered at any time in the future by issuing this command again.

       [?] - Command help. This option provides online help on the commands
       available to you, and how they are used.


























        Wildcat 3.0 - Avoiding "Future Shock"                        Page 7


     2.4 File menu commands/options

       [D] - Download a file. This command will inititate the download
       process, either on a marked list of files you created with the [E],
       [N], or [L] commands, or via prompting you for the filename(s) you
       wish to receive from the BBS. You will be given the opportunity
       to select a protocol for your download if you do not have a default
       protocol assigned via main menu option [Y]. You may return to the
       BBS after completion of the download, or have the BBS auto-log you
       off the system upon completion.

       [E] - Edit marked list. This command allows you to manipulate a list
       of marked files for downloading. The list can be created via the [E]
       command directly, or can be initially created via marking files from
       a [N]ew files scan or [L]ist files scan. Files may be added or removed
       from the list prior to actually performing the download.

       [F] - File transfer help. Provides a bit of a tutorial on file transfer
       and protocol usage/selection.

       [G] - Goodbye (log off system). See MAIN MENU commands section for
       detail.

       [H] - Help Level (menu prompts). See MAIN MENU commands section for
       detail.

       [I] - Information on a file. Shows you all info available for a file
       you specify, such as who uploaded it, date/time uploaded, description
       of the file, estimated download time, etc.

       [J] - Join a conference. See MAIN MENU commands section for detail

       [L] - List available files. Allos you to view what files are available
       on the system for downloading. List "tailoring" options are available
       to you, including listing/selecting the areas you wish to view files in,
       as well as the degree of descriptive information you wish to view
       ( one-line descriptions, 2-line descriptions, or full info on the file).
       Once the listing has begun, at every screen pause, you may issue one
       of a number of commands:
                 [C]ontinue the list
                 [H]elp
                 [N]onstop listing
                 [M]ark file for later downloading
                 [D]ownload
                 [I]nfo on a file
                 [V]iew an archive (.ZIP, .ARC, .LZH, etc)
                 [S]top the listing

       [M] - Go to the menu for the system's message area.

       [N] - New files listing. This is essentially the same as [L] above,
       but it allows you to specify a target date for the listing to begin
       at, ignoring all files older than that date. The default date is the
       date you last issued the [N] command previously.



        Wildcat 3.0 - Avoiding "Future Shock"                        Page 8


       [Q] - Quit this menu. Returns you to the Wildcat main menu.

       [R] - Read a text file. Allows you to read on-line any clear text
       file. DO NOT USE THIS OPTION ON PROGRAM FILES OR ARCHIVES! Archives
       (typically ending with a .ZIP, .ARC, .PAK, .LZH, or .ARJ extension)
       may only be viewed via menu option [V] below.

       [S] - Statistics on Uploads/Downloads. This gives you a display of
       statisitics for the system's file area.

       [T] - Text search. Allows you to search the file areas by Keywords,
       descriptions, or file names, producing a listing of files matching
       your search arguments.

       [U] - Upload a file. Allows you to send a file to the BBS, selecting
       a protocol, and providing a description of each file uploaded. Batch
       uploads of more than 1 file at a time are available using the Zmodem
       and Ymodem protocols (possibly more, depending upon what external
       protocols the sysop has installed).

       [V] - View an archive. Most systems will provide for some form of
       viewing the contents of an archive file. It may range from a simple
       display of the archives' member files to an ability to individually
       view, read, or download any member file in the archive. This all
       depends upon the methods and programs the sysop uses to implement
       the [V]iew archive function.

       [?] - Command help. This option provides online help on the commands
       available to you, and how they are used.




























        Wildcat 3.0 - Avoiding "Future Shock"                        Page 9


     2.4.1 File transfer protocols

           When uploading or downloading a file, you must select a file
       transfer protocol. Protocols are the manner in which two computers
       transfer data between each other. The protocol define the size of
       each data "block" (a block is an element of file data packaged and
       sent between computers), as well as what type of error checking is
       performed to ensure that the data arrives at the other computer in
       the same form as it left the sender. Many, many protocols abound, and
       a number of them are available in the Wildcat system internally. I
       will describe some of the most popular ones used, and how they differ.

       The XMODEM Protocol

           XMODEM is one of the oldest protocols for data transfer available,
       and as such is available almost universally on every BBS and PC terminal
       emulator program. However, that is basically where the advantages of
       XMODEM end.
           In the days when computers conversed primarily at speeds of 300
       baud, XMODEM was ideally suited to data transfer - since it sent data
       in 128 byte blocks, there was relatively little data to resend if a
       problem occurred while transferring a block - a big plus considering
       how long it took to trasfer 128 bytes of data at 300 baud. Error
       checking consists of a "checksum" byte at the end of each block, which
       provided about a 96 percent probability that an error would be detected,
       and if so detected, the block was re-sent.
           Unfortunately, in these days of higher speed modems, XMODEM has
       become dreadfully inefficient. The overhead involved in sending a small
       block of data, waiting for the other end to acknowledge its' receipt,
       then proceeding with sending the next block is staggering, and can
       impact the potential speed of your file transfer, lengthing it by
       20 percent or more. For example, a 2400 baud caller can reasonably
       expect a file transfer rate of 235 characters per second maximum on a
       noiseless telephone connection, using a full streaming protocol (more
       about that later, and 235 is not the theoretical maximum... just
       an average). This caller, when performing a file transfer using XMODEM,
       will probably not see a rate of more than 199-200 characters per second.
       This means the same caller is spending 15 percent longer on the phone in
       order to receive a file using XMODEM.
           XMODEM is also a single-file protocol, allowing for no more than
       one file to be transferred per upload or download session. The upload
       or download function must be re-invoked for each transfer.
           Based upon the above information, I would not recommend the use of
       the XMODEM protocol in any circumstances where other choices are
       available. Some terminal programs, however, only support XMODEM for non-
       text downloads and uploads, so you may find yourself forced to use it
       if this is the case. Since there are literally dozens of good share-
       ware or commercial terminal programs available, though, it should not
       be too hard to find a full-featured replacement for what you have.
       Hopefully, the only XMODEM download you will ever have to perform is
       one to obtain a "better" terminal program, supporting protocols other
       than XMODEM.





        Wildcat 3.0 - Avoiding "Future Shock"                        Page 10


       XMODEM Variants

       XMODEM/CRC
           XMODEM/CRC was the first "hybrid" of XMODEM. It is essentially
       the same 128 byte blocksize XMODEM protocol, however an enhanced error
       checking ability (called a "cyclic redundancy check") has been employed
       over the simpler (and less reliable) checksum routine of XMODEM. The
       issue of performance still exists, though, and throughput is essentially
       unchanged when using XMODEM/CRC versus the older XMODEM.

       XMODEM/1K  (also referred to occasionally as non-batch YMODEM)
           XMODEM/1K was the first attempt to improve substantially the
       throughput of XMODEM by increasing the blocksize of the data transfer
       from XMODEM's 128 bytes to 1024 bytes. This increases the characters
       per second transmitted, since less time is spent waiting for acknowl-
       edgment of packets by the receiver (ACKS are sent every 1024 bytes
       rather than every 128). CRC error checking is employed for essentially
       error-free transfers, assuring the file as received will be the same
       as the copy sent. The drawback of XMODEM/1K is that since is employs
       1024 byte blocks, any error in a transmitted block requires a resend
       of all 1024 bytes, as opposed to 128 bytes in XMODEM. Consequently, on
       a telephone connection of poor quality (a "noisy" connection), your
       actual transfer time may be longer using XMODEM/1K is a number of
       blocks have to be resent.
           Note: Some confusion existed in the earlier days of XMODEM/1K, and
       it was often referred to as YMODEM at that time. "True" YMODEM is
       a batch-transfer protocol, and not wholly compatable with XMODEM/1K.
       Some older communications programs (such as Procomm 2.4.2) which are
       still in use, incorrectly identify XMODEM/1K as YMODEM. Later versions
       of these programs added a new protocol called YMODEM-Batch. This latter
       protocol is the onlu "true" YMODEM, and if you find trouble using
       YMODEM on a communications program, try selecting XMODEM/1K from the BBS
       side. One "dead giveaway" for a mis-names YMODEM is if the PC terminal
       program you use allows you to select YMODEM as a protocol, but then
       asks you to type the name of the file you are receiving. If this is the
       case, chances are it isn't really YMODEM, but XMODEM/1K. True YMODEM
       transfers exchange the file name in the data, and the user does not have
       to tell the PC terminal program the file name.

       ASCII

           ASCII transfer is only usable when sending and receiving clear text
       files on a very noise-free phone connection, as no error checking is
       done of any type. It is essentially a re-direction of the TYPE command
       over the modem to the other end, and you may specify options such as
       whether or not to insert or strip carriage returns or line feeds, or
       what type of speed control (called "pacing"), if any, should be done.
       ASCII is only usable in my opinion to upload prepared messages into a
       BBS message editor from your PC. However, if the BBS you use supports
       an offline mail door like TOMCAT, you should probably use it and leave
       ASCII alone. Program files downloaded using ASCII will almost definitely
       be destroyed, since ASCII treats everything as character data. ASCII
       will alter the format of an executable or an archive file, makeing it
       unusable. If you can't read a file online, don't download it with ASCII!



        Wildcat 3.0 - Avoiding "Future Shock"                        Page 11


       Batch transfer protocols

           Many of the more recently developed protocols in use today
       allow for more than one file to be transferred in a "batch", with
       each file carrying a header identifying its' name, size, etc. You
       may instruct the BBS to send you 4 or 5 (in the case of Wildcat, up
       to 99) files, and then log you off when completed. You start the
       appropriate batch transfer protocol on your end as well, and your
       files will be received and stored on your PC.

       The YMODEM (or YMODEM-batch) protocol.

           YMODEM was the first batch protocol, essentially adapting XMODEM
       for batch files. YMODEM can employ a block size of from 128 to 1024
       bytes (Wildcat's YMODEM uses 1024 byte blocks), and employs CRC error
       checking on the blocks. Throughput with YMODEM is essentially the same
       as XMODEM/1K, and is subject to the same exposures on not-too-good
       phone connections. I would recommend using YMODEM over all XMODEM
       implementations if ZMODEM is not available on your PC terminal program,
       as there is simply less typing involved. Even for a single file
       transfer, you don't have to tell your PC the filename.
          YMODEM-G is a special version of YMODEM with all error-checking
       REMOVED. You may ask "why this would I want to use it?" Basically,
       it is only of use to people who use error correcting modems (provided,
       of course, the BBS you are calling also has an error correcting modem.
       Wildcat will not offer YMODEM-G to a caller without an error correcting
       session establised between themselves and the BBS). Error correcting
       modems support the Microcom Networking Protocol (typically called MNP
       for short), and all data sent between the modems is examined for errors
       BEFORE it is passed to your PC. Therefore, since all the errors have
       been corrected before the data gets to you, having a protocol that again
       checks for errors is a bit of overkill, and can introduce delays in
       total throughput due to redundant error checking.
           Note: Many modem manufacturers refer to MNP-compatable modems in
       different terminology. For example, some would return a connect string
       of (for example) CONNECT 2400/MNP when establishing an error correcting
       session. Others, such as U.S. Robotics modems, use the characters ARQ
       instead of MNP. Still others, such as IBM modems, use ECL in place of
       MNP. Consult your modem manual for the correct terminology. If you do
       not have an error correcting modem and are considering buying a new
       modem, do yourself a favor and spend the 30-40 dollars more for an
       MNP-compatable modem. Your BBS connections will be much "cleaner",
       and you will save money on phone bills! Cleaner connections means less
       resends of data you can't read or your protocols can't receive.













        Wildcat 3.0 - Avoiding "Future Shock"                        Page 12


       The ZMODEM protocol

           ZMODEM was developed by Chuck Forsburg of Omen Technologies,
       and the basic functional specification for ZMODEM was released to the
       public domain. Essentially, ZMODEM does everything that YMODEM-batch
       does, only faster and more efficiently. ZMODEM employs a rudimentary
       for of data compression on-the-fly that more efficiently transfers
       data, decreasing total transfer time, and it also allows for changes
       in blocksize to accomodate good or poor telephone connections, from
       128 bytes on very poor connections to as high as 8192 bytes, although
       most BBS implementations do not exceed 1024 bytes. Also, no block-level
       acknowledgments are exchanged, thus keeping the data flowing as much as
       possible. ZMODEM employs a 16 or 32 bit CRC for error correction, and
       only notifies the sending end if it enounters an error, telling it what
       byte of the file to start re-sending at. This allows for the most
       efficient data transfer in a non-MNP environment (YMODEM-G is still
       faster in an MNP environment, as a straight data stream is sent with
       no block interruptions). Typically, ZMODEM is the best all-around
       protocol to use (in my opinion). Although I posess an MNP modem, I
       still use ZMODEM just for the sake of continuity.

       Other Protocols

       The KERMIT Protocol

           Primarily used for mainframe data exchanges, KERMIT is rarely used
       in a BBS environment. While it is extremely flexible, and can handle
       virtually any modem speed and data format, is is also one of the slowest
       protocols available, and not well suited to the BBS environment. In 5
       years of running and using BBS's, I have only ever encountered one use
       of the KERMIT protocol, however the wonderful folks at Mustang decided
       to include it internally in Wildcat just in case <grin>.

       Various and sundry

           Of course, data transfer protocols abound, and new ones (all try to
       wrestle ZMODEM from the top of the efficiency "heap") pop up it seems
       every day. A Wildcat sysop may install any additional protocols he/she
       wishes externally, so by all means experiment! I myself have found the
       MPT protocol by Mathew Thomas (formally called PUMA) to be essentially
       as efficient as ZMODEM, and very colorful to boot, giving me graphic
       displays of file/batch progress, as well as a reading on the effective
       transfer rate in characters per second. I am sure that implementations
       of ZMODEM contain this capability... I just have not yet used one.













        Wildcat 3.0 - Avoiding "Future Shock"                        Page 13


     3.0 Optional Features external to Wildcat

           There are many, many external programs that a sysop may implement
       alongside Wildcat to further enhance the enjoyment of the users of his
       or her system. Most of these programs are developed by fellow sysops
       mostly out of a love for BBS-ing, and very few are commercially sold.
       Many are distributed under the afformentioned Shareware concept,
       enabling the sysop to continually try new vehicles of entertainment
       or enhancements to usage of the system. While mant fine games and user
       programs are available, space prevents me from listing them all here.
       I will merely give you some insight into what type of features may
       be made available to you as the user. Remember, these types of features
       are NOT part of the Wildcat system, and should not be considered to be.
       Many, such as TOMCAT, are so intricately meshed with the Wildcat system
       that they may not seem to be individual programs... just another system
       option. This is perhaps the highest form of praise for a utility
       programmer!

     3.1 Netmail/Echomail Revealed

           Let us imagine a vast pool of humanity, spread out over the
       world, congregating at remote central locations where they may
       converse amongst themselves and share information, stories,
       experiences, or just simply relax and socialize. An individual BBS
       is one of those types of places - many, like yourself, call in from
       mostly local areas, to share messages, play games, or trade software.
           No one, however, survives in a vacuum for long. The primary option
       available to the BBS user is to begin expanding their scope of contact;
       he or she begins calling more BBS's, perhaps at greater distance, and
       also perhaps not locally, incurring expense in the form of long distance
       telephone bills. Eventually, the user may feel stagnation as they
       reach their limit of expense ot knowledge of the existance of other
       BBS's. Also, the users of other systems may not share the same ideas,
       hobbies, or interests that he or she does. A limit has been reached,
       and a wall encountered.
           With the advent of BBS networking, however, his or her local BBS
       may join a network of other BBS's, and exchange personal or public mail
       woth the other users of those BBS's. Common subject message areas are
       created, and in the case of the largest networks like FIDOnet, hundreds
       of thousands of other BBS users have access to these message areas,
       generating a veritable flood of opinions, information, and diversity of
       culture. Such is the promise of a BBS network.

           The technical concept of a BBS network is actually rather simple.
       Your local system bands together with any number of other BBS's, local
       or otherwise, and establish a NETWORK. They assign unique network
       identifiers, or ADDRESSES, to each BBS in the network, and establish
       a set of common message bases (in some cases, these are referred to as
       ECHOs, and the messages posted to them as ECHOMAIL). Each BBS in the
       network maintains a local copy of each common message base, allowing
       its' own users to read and write the contents, and as each new message
       is added locally, it is copied out to all other BBS's in the network
       which belong to that common message base by packing up the local
       messages and transmitting them amongst themselves, usually in the wee



        Wildcat 3.0 - Avoiding "Future Shock"                        Page 14


       hours of the night. All this is done "under the covers", so that when
       you, as the BBS user, logs on the next day, a fresh new batch of
       messages from many other BBS users has been added to your message bases.
           In this manner you may, by placing only a local telephone call to
       a local networked BBS, converse with many other people (in some cases
       such as FIDOnet, literally around the world), for free!. Some BBS's
       also offer a private person-to-person message service (called NETMAIL)
       allowing you to send electronic letters (again in some instances across
       the world) to another individual, again for free.
           Of course, there is expense involved in this process, but it is
       usually borne by the sysop of your BBS, perhaps being offset by fees
       or contributions from users like you, although this is not always the
       case. In order to keep costs low, most larger networks establish local
       HUBS, which serve as a collecting point for messages from all BBS's in
       the network that are part of that local geographic area. Hubs are
       usually higher-capacity computers with higher speed modems, and they
       exchange messages amongst themselves, re-distributing messages to the
       local systems they serve. An active BBS hub can often cost the sysop
       running it hundreds of dollars a month in long distance charges to
       transmit the mail. Why do we do it? Perhaps we're crazy, but most of
       us simply love the hobby that much.
           There are many software methods of accomplishing this transfer
       of networked messages and mail, and these go by many names, such as
       TNET, FrontDoor, BinkleyTerm, QNET, etc - different networks (and there
       are dozens of them) set different technical software standards. This
       accounts for the rich diversity of networks, and the enjoyment of all.
       You may find yourself logging on to one local BBS that is part of
       FIDOnet, another that belongs to MAGnet, still another that is part
       of ILINK, etc, in much the same way as you may belong to or frequent
       different social clubs or read a variety of periodicals.
           There is so much to experience and learn in BBS networks... if your
       sysop does not belong to one, encourage him or her to try it out!

























        Wildcat 3.0 - Avoiding "Future Shock"                        Page 15


     3.2 Becoming a TOMCAT power user

           In this handbook I will address one of the external programs
       made available to Wildcat sysops, which I and my users have found to
       be the almost a must-have. This is the TOMCAT mail system by Technique
       Computer Systems of Vancouver, BC, Canada.

           While for many BBS users the phone call to their favorite BBS is
       free, their use of the system is not unlimited. Time limits exist for
       all BBS users, and this serves to in some cases limit the ability of
       the caller to participate in active message bases. I have often found
       myself ignoring subject threads for lack of time, or doing a non-stop
       dump of all messages in a particular base to a capture file on my PC,
       only to fill up a disk or accidentally overwrite the last one I made,
       which I had not yet read. TOMCAT allows the Wildcat BBS user to fully
       participate in ALL message bases for which they have an interest,
       regardless of their daily time limits (provided the time limits the
       sysop imposes are reasonable). Using TOMCAT, a BBS caller may enter
       the TOMCAT program, pack up all messages in all message areas they
       wish to follow into a compressed archive (called a QWK packet), and
       download this packet to their PC, taking up MUCH less space and time
       than a non-stop screen dump. In addition, a new files listing and
       all updated bulletins can be included in the packet. The BBS user
       merely logs off once the packet is received, and at their own leisure,
       uses an offline QWKmail reader-replier (such as EZ-READER, Deluxe,
       or Technique's own Silly Little Mail Reader (SLMR)) to read and compose
       replies or new messages. Then, at a later time, the BBS user calls the
       BBS back, enters the Tomcat door again, and uploads their prepared
       reply packet, and all their messages are inserted into the appropriate
       BBS message areas. In most cases, the entire time spent online to
       download mail and then later upload replies can often be only 5 or 10
       minutes (or less), leaving the BBS user time to download files, play
       online games, or in the case of long distance callers, SAVE MONEY.
       I personally use Tomcat to follow up to 100 message bases on a single
       BBS, keeping me on top of everything I'm interested in, using a total
       of about 5 minutes of phone calls ever day or 2. I've been able to learn
       more, enrich myself, and meet literally hundreds of other people I may
       have otherwise never known. This is what telecommunications is all
       about!

           The bottom line is, if your Wildcat Sysop does not have the
       TOMCAT program available, ask him or her to try it.. it is available
       on the Central Wildcat support board, as well as (along with SLMR)
       on the Technique Support BBS, Vancouver BC (604)-598-1546.














        Wildcat 3.0 - Avoiding "Future Shock"                        Page 16


     3.3 Doors and drops

           A "Door" is a term for a seperate program made available to callers
       on a BBS via an interface that allows the software of the BBS to run
       another DOS program. While most door programs are entertainment
       oriented, others serve functions such as dating, database searches,
       mail reader/packers, and many other functions. While I cannot go into
       what is available out there, there is one cardinal rule of conduct for
       the BBS caller to remember when running a door program or a DOS drop
       program:
              PLEASE DO NOT HANG UP INSIDE A DOOR PROGRAM UNLESS YOU YOURSELF
              ARE HUNG (sorry for the shouting). Remember, most door programs
              are written by other BBS sysops, who for the most part are NOT
              professional programmers, and many doors have a devil of a time
              figuring what to do when a caller suddenly hangs up (or "drops
              carrier"). I have had door programs indescriminately overwrite
              portions of the data on my disk drive in the worst cases, or
              simply sit out in space waiting for me to notice the computer
              isn't doing anything at all. In either scenario, the BBS was
              unavailable to others who wished to use it as a result of
              one users' lack of patience. My advice to you is please don't
              hang up just because a game is boring or you don't understand
              it! Most sysops make door program docs available to their users,
              so read them before you decide to battle the evil empire or
              go to the gambling casino. Of course, if you find the door
              program "frozen" and not talking to you, or (god forbid) you
              should suddenly see a DOS prompt staring back at you, go ahead
              and hang up (in the case of seeing the DOS prompt, IMMEDIATELY!).
              The hard drive you save may be worth 2 or 3 months salary to a
              BBS sysop!




























        Wildcat 3.0 - Avoiding "Future Shock"                        Page 17


     4.0 In conclusion

           I hope this document will be of assistance to you in your general
       understanding of BBS's, as well as your specific use of Wildcat. If
       I could be permitted to impart upon you some advice, I would like to
       add some personal observations:

       1)  When using a BBS, take the time to explore it fully! Don't just
       head for the file area and download everything you haven't seen, never
       to visit the message areas or the online programs.. if you do, you are
       depriving yourself of some potentially interesting, informative, or
       entertaining experiences.

       2)  If you are a user who truly does not enjoy participating in the
       message areas of a system, at least make a point to read the system
       newsletter or bulletins the sysop creates for the notification of his
       or her users... many times I have answered the same question over and
       over (such as "Why was the system down this morning?" asked by folks
       who only ever play doors or download files. After the 15th or 20th
       redundant reply, it can be pretty discouraging. Remember that the
       sysop serves in some cases hundreds of active users, and does not always
       have the time to spend on re-hashing the same questions. I personally
       spend 2-3 hours a day on my BBS, and often find no time for many of the
       enhancements or projects I wish to work on.

       3)  Please don't be a "chat-hound". Using the [P]age sysop key can be
       a wonderful way to communicate, but please don't do it just because you
       are bored or almost out of time! Also, contrary to popular belief,
       BBS sysops DO require at least a few hours of sleep daily, and it can
       be a harrowing experience having to deal with a page bell going off
       at 3 or 4 AM every night... your hours may not necessarily be the
       same as mine! I realize I could turn off the pager, but then I make
       myself more unavailable than I wish to be, only being reachable when I
       remember to turn the pager back on, so I prefer to leave it on. I
       tend to average about 10 requests to chat per day, and the average chat
       lasts for 15-20 minutes, so you see it can be a real time-burner! If
       you are in the mood for casual conversation, please try the message
       areas first. Also, on a multi-node BBS, 2 or 3 concurrent chat requests
       can be a real exercise in multi-tasking for a sysop!

       4)  Finally, if you have any comments, critisism, or suggestions, or
       if you want to see a particular program available, or even if you think
       everything is just fine, please send the sysop a comment to let him or
       her know how they're doing! After all, as a sysop, nothing makes me
       happier than knowing I am making my users happy. Constructive critisism
       is ALWAYS welcome on my board, and I'm sure all other sysops feel the
       same way...











        Wildcat 3.0 - Avoiding "Future Shock"                        Page 18


           Well, that should just about do it for getting you started on your
       way with Wildcat V3! If you have any comments or questions regarding
       this booklet, please let me know! I can be reached in the following
       ways:

              Postal Service: Kevin Brokaw
                              The Walden Puddle BBS
                              1026 Day Hollow Road
                              Owego, NY 13827

              BBS:            Walden Puddle Wildcat
                              (607)-687-6193 24 hrs 1200-9600(V32) baud
                              Send message to Sysop or Kevin Brokaw

              FIDOnet:        Kevin Brokaw @ 1:260/450
              MAGnet :        Kevin Brokaw @ 100:910/0
              UUNET  :        gandalf@paladin.owego.ny.us









































        Wildcat 3.0 - Avoiding "Future Shock"                        Page 19

