Simtel MSDOS 1992 June

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / bbs / wildcata.arc / WCDOCS.EXE / lha / WILDCAT!.DOC < prev

Wrap

Text File | 1989-11-01 | 522KB | 11,763 lines

╒══════════════════════════════════════╕ │ │ │ WILDCAT! TEST-DRIVE │ ├──────────────────────────────────────┤ │ │ │ Released 11/1/89 │ │ │ │ │ ╘══════════════════════════════════════╛ Copyright (c) 1987, 1989 Mustang Software, Inc. Post Office Box 2264 Bakersfield, CA 93303 ╒═════════════════════════════════╤═════════════════════════════╕ │ Office/Technical Support │ ORDERS ONLY │ │ (805) 395-0223 │ 1-800-999-9619 │ ╘═════════════════════════════════╧═════════════════════════════╛ WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Table of Contents What is WILDCAT! TEST-DRIVE...............................6 Included with registration..............................6 TEST-DRIVE Features.....................................8 Security...............................................10 System Requirements....................................10 Technical Support......................................11 Limited Warranty.......................................12 Distribution Policy and Copyright......................13 The Source Code........................................13 Background and Databases...............................15 Chapter 3 - Installation.................................17 Quick Start............................................17 Other Requirements.....................................18 Chapter 4 - MAKEWILD Program.............................19 General Information ...................................21 Sysop's name........................................21 BBS name............................................22 Sysop paging hours..................................22 Date of first call..................................22 Total number of calls received......................22 WILDCAT! registration number........................23 Frame 3 - Modem Information - Part 1...................24 Which communications port do you want to use........24 Maximum number of seconds to wait for carrier.......25 Enter the string to reset your modem................25 Modem startup string # 1-3..........................25 Modem initialization after every call...............25 Modem delay #1-3....................................26 Initialize your modem at which baud rate............27 Lock the DTE setting at the initialized baud rate...27 Frame 4 - Modem Information - Part 2...................28 Answer phone using Ring Detect?.....................28 Determine baud rate using Result Codes?.............28 Numeric codes for each baud rate....................29 Command to place modem Off-hook.....................29 Command to [place modem on-hook.....................29 Number of milliseconds to delay before PRELOG file..29 Does your modem support CTS/RTS flow control?.......29 Frame 5 - New User Defaults............................31 Are you running a closed board......................31 New user default security level.....................32 Ask for their phone number..........................32 Ask for their birthdate.............................32 Ask for their computer type.........................32 Force new users to fill out the questionnaire.......32 Time limit for first call...........................33 Number of lines per page............................33 Place them in these message folders.................33 Frame 6 - Security Information.......................35 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 2 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Allow remote sysops to drop to DOS..................35 Verify telephone number after every xx logons.......35 Verify birthdate after every xx logons..............36 Minimum security level to overwrite on uploads......36 Should the sysop screen public messages.............36 Can users leave private messages....................37 Minimum security to read sysop (and private) mail...37 Total number of different security levels...........37 Echo the user's password on the screen..............37 Display password protected files in file listing....37 Security level for MASTER sysop.....................37 Frame 7 - System Configuration - Part 1................39 Allow 300 baud callers..............................39 Is the bulletin menu optional.......................39 Time compensation ratio on uploads..................39 Display the quote of the day........................40 Display a download/upload ratio warning at xx.......40 Will you be offering color ANSI menus...............40 Total number of Bulletins offered...................40 Place the modem off-hook when WILDCAT! is down......41 Message range is xx to yy...........................41 Path for menu files.................................41 Path for help files.................................41 Path for display files..............................42 Path for external protocols.........................42 Path for bulletins..................................42 Frame 8 - System Configuration - Part 2................44 How many message folders do you have................44 Number of different File areas......................44 Number of external file transfer protocols..........44 Maximum logon time limit............................45 Monitor type........................................45 Screen foreground attribute.........................45 Automatically clear screen before menus.............45 Drop WILDCAT! to Errorlevel 60 after each call......45 Frame 9 - Message Folder Setup.........................46 Frame 10 - File Section Setup..........................47 Frame 11 - Main Menu Definition........................48 Activity............................................48 Call letter.........................................49 Description.........................................49 Sequence............................................49 Security............................................49 Frame 12 - Message Menu Definition.....................51 Frame 13 - File Menu Definition........................52 Frame 14 - Sysop Menu Definition.......................53 Frame 15 - Security Level Definition...................54 Message & download access...........................56 Daily time limit....................................56 ANSI menus..........................................56 Frame 16 - Security Level Definition Con't.............58 Upload area access..................................58 Download bytes and number of files..................58 Frame 17 - File Path Definitions.......................60 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 3 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Frame 18 - External Protocol Definition................61 Chapter 5 - Initial Operation & File Definition..........63 Checkout...............................................63 Local keyboard control keys............................65 Internal files used by WILDCAT!........................69 Display files used by WILDCAT!.........................71 ANSI Color.............................................82 Customized files.......................................82 Embedded codes.........................................83 Using MPE (Mustang Personal Editor)....................85 Using THEDRAW..........................................86 Chapter 6 - WILDCAT! in Action...........................88 Batch file operation...................................88 Signing on the first time..............................89 MAIN menu commands.....................................90 MESSAGE menu commands..................................94 FILE menu commands.....................................99 SYSOP menu commands...................................102 Chapter 7 - Advanced Features...........................107 Creating Events.......................................107 Event X............................................108 Event Y............................................108 Events A - J.......................................108 Call processing Event (errorlevel 60)..............110 Event timing.......................................111 Remote drop to DOS....................................112 Using remote DOS...................................114 External Protocols....................................116 Operational overview...............................116 Batch file creation................................116 Download example...................................117 Upload example.....................................119 Viewing compressed files..............................122 Net and EchoMail......................................124 Chapter 8 - WILDCAT! Support Programs...................127 ADDFILES...........................................127 CONVERT............................................129 MAKEQUES...........................................132 WAIT! & WAITFOR!...................................138 FIX Series.........................................139 Chapter 9 - Registered Feature Overview.................140 DOORS.................................................140 Implementation.....................................141 Cautions, concerns, and caveats....................143 Carrier detect monitoring..........................143 Ctrl-Break lockout.................................144 User verification on return........................145 Multi-line Operation .................................148 Overview...........................................148 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 4 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── How it works.......................................148 Hardware...........................................149 Local area networks..............................149 Slave Cards......................................150 DESQview.........................................150 Software and structure.............................151 Novell...........................................156 Peer-to-peer networks (LANtastic, etc.)..........158 Slave cards......................................159 DESQview.........................................160 Operational considerations.........................162 Chapter 9 - Appendices..................................166 Appendix A - Modems...................................166 General Modem information..........................166 Hardware error checking............................166 Modem related connection problems..................166 Modem switch and register settings.................167 Modem-specific settings............................170 Appendix B - ANSI codes and DOS colors................172 Appendix C - Distribution for Profit..................173 Appendix D - Errors and troubleshooting...............174 Appendix E - Record formats...........................176 INDEX ..................................................178 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 5 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── What Is WILDCAT! TEST-DRIVE? This TEST DRIVE version of WILDCAT! is a full-featured BBS system. It is designed to allow the user to be able to evaluate WILDCAT! and determine if it meets their needs. The TEST DRIVE release is not the latest release of the program, however, and does not include all the features of the REGISTERED USER VERSION. This TEST DRIVE release includes full documentation and information on obtaining the REGISTERED USER VERSION. Print the file VENDOR.DOC and READ.ME for additional information. INCLUDED WITH YOUR FULL REGISTRATION: - A copy of the latest release of the REGISTERED USER VERSION; - A more comprehensive, updated, typeset operations manual; - 90 days free technical support by phone between 9:00am and 4:30pm pacific time; - Automatic notification of any major program updates; - A card redeemable at any time for $50 toward any Mustang Software product or service. This includes, but is not limited to future updates, enhanced versions of WILDCAT!, supplemental programs such as the PRO! Series, extended support, or other Mustang Software products. - Additional program updates at a significantly reduced rate. - Access to proprietary utility programs, written by both Mustang and other authors, which enhance and add features. - 24-hour access to the private multi-line Registered Users BBS at Mustang Software. The REGISTERED USER VERSION version of WILDCAT! has many features not found in the TEST DRIVE release. These features include but are not limited to: - Full support for multi-line operation of 250 nodes; - Capability for running DOORS, with configurable security level restrictions for each; - Enhanced Net & EchoMail operation for callers and the sysop. - Enhanced Message Area functions, including abilities to read folder-specific mail from previously opened Mail folders and Mark mail while Scanning, for reading later; - Capability to lock DTE at up to 38,400 baud, which can actually increase throughput, even with a 2400 baud connection; - Custom NON-color as well as color menus; - Increased support for more embedded control codes, including codes to reflect "Who's on-line" on your other Nodes (Multi-Line operation); - Up to 50 definable security levels, 32 more than the TEST DRIVE version. - AND MANY MORE! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 6 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── A registration form is supplied on disk in the text file REGISTER.FRM. You can print this file with the command COPY A:REGISTER.FRM PRN You may also call our toll-free ORDERS ONLY HOTLINE at 1-800-999-9619 to place your order with VISA, MasterCard, American Express, or even COD. For information, technical support or other questions please call 805-395-0223. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 7 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── THE WILDCAT! BBS SYSTEM At first glance, WILDCAT! may look like just another bulletin board program. This was by design. Much effort was spent incorporating popular features of other BBS systems, including many of the command options, although that is where any similarity ends. Powerful extended features have been added to what at first appear to be familiar routines. Other features and utility functions of Wildcat! are precedent-setting in a BBS environment. This TEST DRIVE version is a fully-functioning Bulletin Board System designed to give newcomers to the WILDCAT! arena a taste of the REGISTERED USER version of WILDCAT!. Features of this TEST-DRIVE version include: - Fast B-Tree indexed access to all data files including Users, Files and Messages. - Easy set-up via an interactive installation program which configures system defaults. - Dynamically-built menus based on security level definitions in the configuration file. - Three Color Menu Levels allow you to only show options to your users that they have access to. - Flexible security for users and files, 18 levels available. - Date of Birth and Phone Number available as security check items. - Include/exclude 300 baud calls based on sysop preference and system needs. - Supports up to 19,200 baud modems, including data transfer over normal phone lines. - More than 100 customizable display files, including placement of any available system information in user defined displays. - Message features include Reply, Forward, Carbon Copy, Return Receipt and Print. - 26 Message Folders available, including Comments to the sysop within messages. - Wastebasket message Folder which holds deleted mail until killed by sysop. - Ability to move messages from folder to folder. - ANSI graphics support in menus, file descriptions, messages and system prompts. - Multiple line file descriptions, including download time based on the callers baud rate - Automatic caller notification of bulletin updates based on bulletin file date and time. - Multiple questionnaire files available, including one for new users, and others selected by menu choice. - The MAKEQUES.EXE program to create branching questionnaires with free-form or formatted output. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 8 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── - Questionnaire pre-formatted to accept dates, SS #, Visa/MC, AMEX, text strings, multiple choice and Yes/No with branching. - Remote event timer support for scheduled activities outside of the WILDCAT! system. - Configurable screen pauses based on each callers screen length. - System and Menu help files available, both in normal and ANSI color mode. - Stackable menu commands available in many areas for advanced users. - Most sysop functions available from remote sysop log-on, including system update and maintenance. - Additional upload and download support, including multiple file transfer using external protocols (KERMIT, YMODEM-G, YMODEM Batch, ZMODEM, etc.) - Net & EchoMail support for the sysop. - Hot Key entry of single-character caller selections. - Default User Up/Download protocol. - Prelog display file sent prior to any other information. - Drop to DOS capabilities and return. - Closed System option configurable with special questionnaire, forced comment or immediate log off. - Birthday message display file sent on users birthday! - Ability to View a compressed file contents from the Files menu. - Easy reading of any ASCII text file from the Files menu. - Support for up to 2 billion users, files and messages, limited only by disk space. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 9 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── WHAT ABOUT SECURITY? After reviewing the first few pages of the installation procedure, you will undoubtedly begin to think that WILDCAT! is preoccupied with security. If so, you're absolutely right. Although WILDCAT! is perfectly capable of serving the needs of the hobbyist telecommunications enthusiasts, it was designed with a business environment in mind, an environment in which the integrity of information is of paramount importance. WILDCAT!'s security is second to none. Since it's first release in 1986 the security provisions have never been overcome as the result of a software deficiency or compromise of the program code. The file database structure allows sensitive non-BBS data to reside on the same hard disk as the WILDCAT! system, since ONLY the specifically authorized database files are ever allowed access. The system operator has full control of the security setup. SYSTEM REQUIREMENTS WILDCAT! was written on the premise of being used in business applications. No attempt has been made to make the product compatible with single or dual floppy drives and computers with limited memory capacity. It is necessary that your memory and storage areas are capable of accommodating the many files and work areas that are required by the code during normal run-time. Mustang Software has no plans of changing the program to accommodate systems with minimal capacity. The following list represents the minimum configuration your system should have to be capable of properly maximizing the potential of the program. - IBM Personal Computer (or true compatible) with 384K (minimum) RAM, 200K free for Wildcat! - PC-DOS or MS-DOS, Ver. 3.0 or later (other operating environments such as DESQview may be used, see the appendices for details.) - Asynchronous communications (serial port) adapter - RS-232 cable with the standard 9 pins connected (some modem cables do not have all the pins hooked-up). - Intelligent AT command set modem - 80 column monochrome or color monitor - Voice-grade telephone connection for modem - Hard disk drive ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 10 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── TECHNICAL SUPPORT WILDCAT! was designed for ease of use, and this manual should contain the answers to most of your questions. Read it first and check the appendices for trouble-shooting procedures. If you're still stumped, technical support is only a phone call away. You may first want to call our own WILDCAT! Public-access system at 805-395-0650 for valuable insight by other sysops. Feel free to look around, download any files on the system that may be of use to you, or leave a [C]omment to the Sysop if you need a question answered. This method of obtaining support is especially good if you want expert guidance regarding the more advanced features. Another alternative is CompuServe where we are a part of the PC Vendor Support Forum. You reach us by typing GO PCVEN and then selecting Sub Topic 9. Our PIN is (75236,3312). We also have Regional Support Centers all over the world for those users outside of the United States. Current locations are in the United Kingdom, Holland, Australia, and Canada. At the time of this writing we are looking into locations in Japan, Switzerland, and West Germany. If any or all of these Regional Support Centers are of interest to you, feel free to call or write and we will mail you our current Regional Support Roster. If you are unable to find the answer to a question or just need a quick explanation, please give us a call between 9am and 4:30pm PST. You can reach technical support at (805) 395-0223. We must, however, limit tech calls to those problems not resolved after reading this manual. Technical support is not (and should not) be a substitute for this manual. Bear in mind that most other software companies will not even support a product until it is registered. We want to extend special support to users of this TEST-DRIVE release, but need your cooperation in checking the manual first. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 11 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── LIMITED WARRANTY This product is provided "as is" without warranty of any kind. The entire risk as to the results and performance of the program is assumed by you. Should the program prove defective, you (and not Mustang Software, Inc. or it's dealers) assume the entire cost of all necessary servicing, repair or correction. Further, Mustang Software, Inc. does not warrant, guarantee, or make representations regarding the use of, or the results of the use of this program in terms of correctness, accuracy, reliability, currentness, or otherwise; and you rely on the program and it's results solely at your own risk. Mustang Software, Inc. cannot accept responsibility for system damage, loss of profit, or any other special, incidental, or consequential damage resulting from the use or inability to use this product. Mustang Software, Inc., DOES warrant to the original licensee of a REGISTERED product that the program disk(s) on which the program is recorded be free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of delivery as evidenced by a copy of your receipt. Mustang Software, Inc.'s entire liability and your exclusive remedy shall be replacement of the disk not meeting Mustang Software, Inc.'s Limited Warranty. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 12 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DISTRIBUTION POLICY AND COPYRIGHT COPYRIGHT Regardless of the method of marketing, WILDCAT! is not in the public domain. It is copyrighted by Mustang Software, Inc.. All rights are reserved. Copying, duplicating, selling or otherwise distributing this product except as expressly permitted in the TEST-DRIVE Distribution Policy below is a violation of the Law. However, we grant you the right, in fact encourage you to make and distribute as many copies of this TEST-DRIVE version as you wish, using any acceptable medium of exchange, with the following provisions: -- TEST-DRIVE Distribution Policy -- 1. Please feel free to distribute this TEST-DRIVE version as often as you like, to any interested parties. 2. Please do not distribute the program without all of its original related files, addendum files, and documentation. 3. Please obtain our written permission prior to distribution with any "Bundled" software packages. 4. Please do not accept payment for the program; a copying fee of $10.00 per diskette may be charged when distributed by a non-profit user-group. 5. Please do not alter the program or documentation in any manner. 6. NOTE - Individuals, groups, vendors, or other software distribution companies which market diskettes containing shareware or other TEST-DRIVE programs for profit must obtain written permission from Mustang Software, Inc. prior to distribution. See Appendix C for an easy-to-process application form. DISTRIBUTION of the REGISTERED USER version of the program is in violation of license agreements and copyright Law! REVIEWS Mustang Software, Inc. is always in need of your opinion on all our products so that we may continue to improve our software. We encourage you to evaluate this TEST DRIVE version of WILDCAT! and let us know of your findings. Printed reviews by user groups or other publications may be mailed to us at P.O. Box 2264, Bakersfield CA 93303-2264 and marked to the attention of Rick Heming, VP Marketing. THE SOURCE CODE The source code for WILDCAT! is not available. This decision gives us the ability to guarantee the integrity of our product in ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 13 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── this era of software contamination. It is not available either under the TEST DRIVE concept, or as a Commercial product. To those who may have security concerns about running a BBS program without being able to see or alter the code we can only offer this assurance: ┌───────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ "Mustang Software has every intention of │ │ continuing to strengthen our position │ │ as a supplier of quality computer software. │ │ │ │ To do so, we must rely heavily on our │ │ reputation in the international electronic │ │ community. We would not compromise that │ │ reputation for anything! │ │ │ │ You can trust that WILDCAT!'s source code │ │ has no undocumented features which could │ │ compromise the security aspects of our product." │ │ │ │ │ │ - Mustang Software, Inc. │ │ │ │ │ │ │ └───────────────────────────────────────────────────────┘ ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 14 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── BACKGROUND WILDCAT! combines flexibility and security, but when these two factors are mixed in a thoughtless manner, the security loses. It is possible to intentionally or mistakenly reduce WILDCAT!'s built-in security to that available on the cork bulletin board at the neighborhood grocery store! This is mentioned as a first caution to check your installation security settings very carefully prior to taking your first call. During the installation process reviewed in this manual you will be provided with representations of the actual configuration screens to serve as guides in setting up your own custom BBS application. To guard against mistakes you are strongly encouraged to study the default information provided, and if you change any option, the first thing to do is to test the results of that change in your application. The second thing to do is to test it again! This may seem redundant and time consuming, but experience has shown that this is the fastest route to successful bulletin board operation. The operation and setup of a WILDCAT! system requires understanding several concepts which may be new even to the most experienced BBS operator. A thorough reading of the following information on databases and the folder concept will ease the installation process. DATABASES WITHIN WILDCAT! WILDCAT! uses an internal database system to keep track of three major groups of system information, USERS, FILES and MESSAGES. Each of these databases is independent, and is ONLY able to be updated from within the program. Each consists of a data file (.DAT) as well as up to three index files (.IDX) to speed up searches. All database files are composed of records, which can be thought of as index cards containing information about any ONE User, File or Message. When a WILDCAT! system is first started, all database files are empty. Database entries can be made in a number of ways which are discussed below under the appropriate database type. The USER database is just what it sounds like; a file containing records for each and every user on the system. The first record added will most often be the system operators name, a process that is more fully described later in this manual. Other user database entries are usually made automatically as new users call the system, but names may be added manually by the sysop. As users are added the database expands, and as they are deleted, the space is made available for new users. The FILE database may be a new concept to even experienced BBS sysops. Although many BBS programs track the lists of files available on the system as text listings, WILDCAT! uses the ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 15 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── database method. File organization in this manner has many advantages, not the least of which is additional security and flexibility. No file on your computer system may be accessed through WILDCAT! unless it is first listed in the file database. Each record in the file database contains a file name, size, date added to the system, file area letter (which tells where it is located and what security is required), a 2 line description, as well as other information. Since the file database is empty on a new WILDCAT! system, file records must be added either manually by the sysop or by using our file addition utilities CONVERT, ADDFILES or, with the Registered version, the PRO! Series. CONVERT will read a standard text file listing used by a number of BBS programs or the DIR command, and place the information into the WILDCAT! file database. ADDFILES is an easy method of adding the filenames already on your disk and optionally entering the descriptions as they are added. F-PRO!, one of the PRO! Series utilities for the Registered version of WILDCAT! also manipulates the file database. See the appropriate sections of this manual for details about CONVERT & ADDFILES. Changes made to the file database cause the appropriate changes to be made on disk, if indicated. For example, changing the file name will cause DOS to actually rename the file on disk, and deleting a database entry optionally allows deletion of the file on disk also. A change of the file area letter will cause the file to be copied to the new drive & subdirectory and then deleted from the old one. Although the file database uses letters of the alphabet as area identifiers, these identifiers are NOT related in any way to the message folder letters in the message database. The MESSAGE data file consists of groups of message lines, one after the other. The index files which are created and updated whenever a message is entered is used to locate the actual lines of any specific message within the database. As messages are deleted, the message data line space becomes available for other new messages. The index files keep track of where the message lines for each new message are located, an absolute necessity since they may or may not remain in a contiguous sequence. The user need not concern himself with the actual operation of the message database except to understand that there is ONLY ONE message database. The Message Folder Concept also makes use of index file to allow access to different groups of messages. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 16 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── QUICK START Although we strongly suggest that all operators become familiar with WILDCAT! by reading the entire manual prior to starting the program, we realize that many users may feel comfortable with other methods of learning the program features. For those already familiar with the disk operating system, paths, file handling and/or have run other bulletin board systems in the past, you may do the following: . Create a subdirectory to contain the WILDCAT! files; . Extract all WILDCAT! files into your new subdirectory; . Create or modify your CONFIG.SYS file according to "Other Requirements" on the next page; . Set your modem switches correctly (see appendix A); . Run MAKEWILD to set-up your configuration; . Run WILDCAT!; . Use the HOME key for function key assistance; . Use the F1 function key to logon and enter your SYSOP information (remember, you are a new user the first time); . At the Main Menu, use the function key F9 to upgrade your status to that of SYSOP; . Refer back to this documentation as a reference guide for more detail, for tips on special configurations, and for explanations of the various display files. This Quick Start procedure is ONLY suggested for those who feel comfortable learning on their own. A step-by-step startup procedure will be outlined in the chapters that follow. CREATING AN ENVIRONMENT FOR WILDCAT! There are many files generated either by the System operator or by the normal run-time requirements of the program. You should create a special sub-directory especially for WILDCAT! and it's peripheral programs and files. Each file is reviewed in detail later in this manual, but for now just provide a place for them to be stored once they are created. First, you should be at the root directory of your hard disk. Usually this means that you will be viewing "C:\>", but this depends on how your system is configured. To more easily determine your location, you may wish to type the following line from the command level: prompt $p$g <ENTER> where <ENTER> means press your [ENTER] or carriage return key. From this point, the <ENTER> will be assumed as being required following a typed entry unless otherwise indicated. Now, place the WILDCAT! files WILDCAT1.EXE and WILDCAT2.EXE in your newly ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 17 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── created directory. If you are unclear on how to create this directory, type in the following at your command-level prompt: Your screen You type ----------- ----------- C:\> MD\WILDCAT C:\> CD\WILDCAT C:\WILDCAT> WILDCAT1 C:\WILDCAT> WILDCAT2 Note: The two files WILDCAT1.EXE and WILDCAT2.EXE are self-extracting archive files. Typing the filename will cause the file to self-extract it's contents into the directory it was typed from. Be sure you copy these two files into the proper directory BEFORE you execute them!! OTHER REQUIREMENTS In order to work within the confines of DOS at maximum efficiency, WILDCAT! also requires that several system parameters be established. The following DOS changes should be done prior to actually running the program. Add the following lines AT THE TOP of the CONFIG.SYS file, located in the root directory of your hard drive; FILES=40 (failure to do so will result in an error) BUFFERS=40 WILDCAT! contains a built-in color driver, so installing ANSI.SYS is not required to run in color mode. Other programs will require your ANSI.SYS driver, however and no compatibility problems exist between the two. If your present CONFIG.SYS calls the ANSI driver, WILDCAT! will just ignore it. Note: If you do not have an existing CONFIG.SYS file, refer to your DOS manual for additional information. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 18 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MAKEWILD INSTALLATION A separate program called MAKEWILD.EXE is used to create and maintain the many options and menus available in WILDCAT!. To start the initialization routine, make sure that you are in the WILDCAT subdirectory that was previously created. Type "MAKEWILD". Once the program loads, it will search the existing directory for the files called CONFIGWC.BBS and MENUINFO.BBS. If these two files are not found (the first time MAKEWILD is run), they will be created, along with default values for the various entries in MAKEWILD. You should be viewing the following screen: ╔════════════════════════════════════════════════════════════════════════════╗ ║ WILDCAT! (tm) INSTALLATION PROGRAM Frame 1 ║ ║ ║ ║ TEST-DRIVE 11/1/89 ║ ║ ║ ║ Section Frame ║ ║ ║ ║ General Information about the Board & Sysop 2 ║ ║ Modem Information & Settings 3..4 ║ ║ New User Defaults 5 ║ ║ Security Information 6 ║ ║ System Configuration 7..8 ║ ║ Message & File Folder 9..10 ║ ║ Define your Dynamic (Smart) Menu's 11..14 ║ ║ Security Level Definitions 15..16 ║ ║ Define File Paths 17 ║ ║ Define External Protocols 18 ║ ║ Quit & Save This Installation 0 ║ ║ ║ ║ Which Page would you like to go to ? 2 ║ ║ ║ ║ Copyright (C) 1987, 89 Mustang Software, Inc. All Rights Reserved ║ ╚════════════════════════════════════════════════════════════════════════════╝ Select a Starting Page and Press F1 Insert Off At this point the user should decide which Frame he/she would like to start at. Simply choose a Frame Number and press the F1 key. It is recommended that the first-time installation begin with Frame 2. Moving around within Frames For purposes of contiguity, the frames will be presented in their natural order of occurrence. In actual use you may jump from one installation screen to another at any time without returning to Frame one just by using the Frame number an F1 combinations. Any ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 19 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── changes made to a particular Frame are automatically stored temporarily to a screen capture buffer. Editing Keys During Data entry while in MAKEWILD, the following editing keys are available: Left-Arrow Move left one space in current field; Right-Arrow Move right one space in current field; Up-Arrow Move to previous field; Down-Arrow Move to next field; Shift-Tab Move to previous field; [ENTER] Move to next field; Tab Move to next field; Home Position cursor on first character of field; End Position cursor at end of field; PgUp Proceed to previous Frame; PgDn Proceed to next Frame; Insert Toggles Insert/Overtype mode. A prompt at the lower-right of the screen indicates the present state of the toggle. In insert mode the characters starting at cursor position are pushed to the right. In over-type mode the characters under the cursor are replaced by those that are typed. Backspace Delete character to left of cursor; Delete Delete character immediately under cursor; Note: The Backspace and Delete keys work the same regardless of the status of the Insert key. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 20 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── GENERAL INFORMATION We will review each question in the screen represented below: ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 2 ║ ║ GENERAL INFORMATION ║ ║ ║ ║ ║ ║ 1. What is the SYSOP'S first name ? Jim ║ ║ ║ ║ 2. What is the SYSOP'S last name ? Harrer ║ ║ ║ ║ 3. What is the name of your BBS ? Mustang BBS ║ ║ ║ ║ 4. Sysop's Office <Paging> hours are from 08:00 to 17:00 ║ ║ ║ ║ 5. Date your board took its first call November 1, 1989 ║ ║ ║ ║ 6. Number of Total calls your board has received is 0 ║ ║ ║ ║ 7. Enter your WILDCAT registration number ? 00000 ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 1. What is the SYSOP'S first name ? Jim 2. What is the SYSOP'S last name ? Harrer The system operator's (SYSOP) name which is chosen here is reflected automatically in a number of places during the program's execution, a few of which are indicated below: Leaving comments to the Sysop; Paging the Sysop; Entering messages to the Sysop; Logging on to system locally as Sysop. Many first generation bulletin board programs used the term SYSOP to differentiate between the actual System Operator and the board's callers. A certain level of system security was built around word SYSOP, so in many programs it was the no-option default. Contemporary usage indicates a trend towards the System Operator using his or her actual name in lieu of SYSOP. Users will quickly adapt to either usage, as will WILDCAT!. The choice is up to the operator. If you elect to have the system operator known as SYSOP, you may leave the last name blank, but remember that these names ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 21 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── when coupled with your password are your keys to the system for both local and remote logons. 3. What is the name of your BBS ? Mustang SW Node 1 This is to identify the official name of your Bulletin Board System in various areas of the board. Be creative, but some thought should be given to a title that lends credence to the actual theme of the board. If a company or corporation has a title by all means use that name. Likewise in the event of multiple nodes or installations, suffix the name with the particular area or node ID. For example: XYZ Corporation BBS [primary installation] XYZ Corporation District 1 BBS [satellite] 4. Sysop's office <Paging> hours are from 08:00 to 17:00 In order to prevent unwanted work interruptions, the system operator's paging hours may be limited to only certain hours of the day. During other times, when a user requests that the system operator be paged, the user will receive a message indicating the appropriate hours that the system operator is available, and will be encouraged to leave a comment or message instead. These hours may be overridden at any time during program operation by use of the F4 key. During the quiet hours, the computer will inform callers that the Sysop is not available for page. If you don't mind the interruptions, leave the values set to 00:00 and 23:59, but remember that this puts you on call twenty-four hours a day! When paging is allowed, the sysop may elect to be paged via the system bell or silently with only a note on the display screen, by use of the F5 key. See the function key assignment section for details. 5. Date your board took it's first call November 1, 1989 The date of origin is to set a starting date for the board's operations. This establishes a starting date for any files that are dependent upon this information, such as a call reporting program or the system's user log. Operators who are converting to WILDCAT! from other BBS programs may retain their original start date. 6. Number of Total calls your board has received is 0 The number of calls your board has received defaults to 0, and should be incremented if you do not wish this value to be reflected to your users. An example might be switching from another BBS program, and not wanting Total number of calls to start all over again. Whatever value is placed ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 22 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── here, WILDCAT! will automatically increment it after each call. 7. Enter your WILDCAT registration number ? 00000 This question is only needed for registered versions of WILDCAT!. Anything entered into this field in the TEST- DRIVE version is ignored. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 23 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MODEM INFORMATION - Part 1 The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ MODEM INFORMATION - Part 1 Frame 3 ║ ║ ║ ║ 1. Which Communications Port do you want to use [ 1 .. 4 ] ? 1 ║ ║ 2. Maximum # of seconds to wait for carrier [ S7 Register ] ? 30 ║ ║ 3. Enter the string to reset your modem: ATZ ║ ║ 4. Enter Modem Startup String #1: ║ ║ ║ ║ 5. Enter Modem Startup String #2: ║ ║ ║ ║ 6. Enter Modem Startup String #3: ║ ║ ║ ║ 7. Enter the string to reinitialize your modem after every call: ║ ║ AT V0 M0 Q0 E0 S7=30 &C1 &D2 X1 ║ ║ 8. Modem Delays in Milliseconds: ║ ║ #1: 3000 #2: 1500 #3: 2500 ║ ║ 9. Initialize your modem port at which baud rate [ 300..19200 ] ? 2400 ║ ║ 10. Lock the DTE setting at the initialized baud rate [Y/N] ? N ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off Interfacing with many different modems is one of the most difficult areas of any program that deals with the computer's communication ports. If your WILDCAT! installation is not working the way you believe it should, more than likely the problem will be in this area. The default values represent those for a generic modem. WILDCAT! requires your modem adhere to the Hayes AT command set for proper operation. After completing your modem setup you may want to take the time to check each entry with information provided in your modem's user manual. This exercise will help to familiarize you with the modem initialization being used in your WILDCAT! system. 1. Which Communications Port do you want to use : [ 1 .. 4 ] ? 1 The system can use any communications port number available on your system from 1 through 4. Note: COM1 and COM3 make use of the same Interrupt (IRQ) line and COM2 and COM4 make use of another line. If you are making use of COM3 or COM4 you may NOT use COM1 or COM2 with the same IRQ numbers. Duplication of interrupt numbers will cause erratic operation. As an example, if you connect a mouse to a standard COM1 (IRQ 4) you may not set your internal modem to ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 24 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── COM3 which also uses IRQ4. Note that the REGISTERED USER version allows configuration of all com port IRQ lines and port addresses, even to other than standard assignments. The base port addresses for COM1 through COM4 are standardized, and this TEST-DRIVE release must use the standard addresses (03F8, 02F8, 03E8, and 02E8). 2. Maximum # of seconds to wait for carrier [ S7 Register ] ? 30 This setting indicates how long WILDCAT! will wait for a carrier signal (connect) from a caller. The default of 30 seconds is the standard for most modems, and is the recommended setting. This value represents how long WILDCAT! will wait before re-cycling, and MUST agree with your modem's S7 register. If it is changed to a lower or higher value, be certain to reflect the change by adding an appropriate S7=# command in the modem startup strings, as indicated below. 3. Enter the string to reset your modem: ATZ This is the command string that resets your modem to its default settings. This command should almost always be ATZ. 4. Enter Modem Startup String #1: This is the first of three possible modem startup strings which are sent ONLY upon startup of WILDCAT!. Usually these startup strings are only needed by modems making use of non-volatile RAM to store the setup values. All three startup strings are sent just once when WILDCAT! is started, and the last one should contain the command to save the settings, usually &W. These saved settings are then recalled from modem memory after each call with a short ATZ command. Most modems without non-volatile RAM will leave the 3 startup strings blank, and send the modem initialization string (line 7 below) after each call to ensure it is set properly. 5. Enter Modem Startup String #2: 6. Modem startup string #3: 7. Modem initialization after every call: AT V0 M0 Q0 E0 S7=30 &C1 &D2 X1 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 25 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Enter the command(s) that initialize the modem into its receive calls state. WILDCAT! automatically sends this initialization string following each logon, whether the logon was successful or not. The statement above means: ATV0 Turn on numeric result codes so Wildcat! can determine baud. M0 Turns off the modem speaker Q0 Result codes are displayed E0 Echo result codes to terminal S0=0 Disable auto-answer by modem and let Wildcat! monitor ring detect S2=255 Disable + + + as the modem attention string S7=30 Set # of seconds to wait for carrier to match your answer to question #2 X1 Extended result codes, needed to send a different result number for connections at each baud rate &C1 Have carrier reflect reality rather than be forced true all the time &D2 Have the modem react to the DTR (data terminal ready) line properly. This setting indicates that when the modem sees a lowering and raising of DTR is should go on hook (hang up) and return to command state. If you modem supports the X command, you should include the X1 or a similar extended result code value in this reinitialization string. Use the value that corresponds to the lowest number that sends a different result code for 300, 1200 and 2400 baud connections. This is usually X1. 8. Modem Delays in Milliseconds: #1: 3000 #2: 1500 #3: 2500 The above delays are necessary and vary from modem to modem. The goal is to enter the minimum value that operates properly. Delay 1 is the delay between sending each startup string in number 4-6 above. Delay 2 is the time before sending the modem reset string ATZ (#3 above) as well as the delay between the reset and the startup string (#4 above). We have determined that many modems need at least 1.1 seconds (1100 ms) to properly handle another command after an ATZ, and values below 1100 are not recomended. Delay 3 is used differently depending on whether WILDCAT! will answer the phone by use of Pin 22 (ring detect) or by allowing the modem to use the auto answer feature. This choice is selected in the next screen. If ring detect is used, the delay is the time between ring being detected and WILDCAT! sending an ATA answer command to the modem to tell it to answer the phone. In the case of auto answer being ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 26 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── used it is the time it waits after the modem answers the phone before it begins looking for carrier detect. 9. Initialize your modem port at which rate [ 300..19200 ] ? 2400 Some modems can step up to match the baud rate of an incoming call while others can only step down. If you are unsure about the modem's capabilities, enter the value that represents the modem's fastest baud rate. 10. Lock the DTE setting at the initialized baud rate [Y/N] ? N This choice is provided as an option to help you make full use of the new high speed 9600 & 19200 baud modems. It allows you to lock the link between your computer and your modem at a rate higher that the callers connection rate, usually 19200 baud. Choosing to lock your DTE (data terminal equipment) rate will result in WILDCAT! sending all data to your modem at the initialized baud rate, regardless of the connection rate. This allows faster throughput with some modems using hardware error checking by maximizing data transfer from the computer to modem. An example is the US Robotics HST which functions well with the communication port locked at 19200 baud and allows the modem to control data flow from your modem to the callers modem at the fastest speed possible, sometimes even exceeding the quoted modem speed. Locking the port can cause problems with some doors because the door expects the port to be at the baud rate of the caller rather than some higher rate. If you do not have a high speed modem you should not lock the baud rate. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 27 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MODEM INFORMATION - Part 2 The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ MODEM INFORMATION - Part 2 Frame 4 ║ ║ ║ ║ 1. Answer Phone By <R>ing or <A>uto Answer [ R or A ] ? R ║ ║ ║ ║ 2. Determine Baud rate by <C>/r's or <R>esult Codes [ C or R ] ? R ║ ║ ║ ║ If By Result codes enter your numeric result codes for: ║ ║ 300 : 1 1200 : 5 2400 : 10 9600 : 99 19200: 99 ║ ║ MNP: 300 : 14 1200 : 15 2400 : 16 9600 : 17 19200: 99 ║ ║ ║ ║ 3. Command to place your Modem Off-Hook: AT H1 ║ ║ ║ ║ 4. Command to place your Modem On-Hook : AT H0 ║ ║ ║ ║ 5. Number of Milliseconds to delay before displaying PRELOG file: 1500 ║ ║ ║ ║ 6. Does your modem support CTS/RTS Flow Control? N ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 1. Answer Phone By <R>ing or <A>uto Answer [ R or A ] ? R Most contemporary modems have the ability to Auto Answer the phone when ringing is detected. For this to happen however, either the auto answer dip switch must be set to on or you must have the command S0=1 (answer on ring 1) in your initialization string. Rather than set up your system for auto-answer, a better arrangement is to select Ring Detect and allow WILDCAT! to watch for the ring itself. In order to do this, WILDCAT! monitors the status of pin 22 on the modem connector. This is one of the reasons you must have the appropriate pins connected on your modem cable. If you elect to use ring detect, you should have S0=0 (zero) in your initialization string. If you intend to make use of doors (only available in the registered version) you are strongly advised to answer by ring detect. See the cautions regarding doors for additional information. 2. Determine Baud rate by <C>/r's or <R>esult [ C or R ] ? R The use of result codes is recommended. If your modem cannot generate numeric result codes that can be used by the software, it will be necessary to toggle this option to Carriage Returns. This choice means that the caller must enter one or more carriage returns and spaces after ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 28 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── connection in order for the system to determine the baud rate. The use of Result Codes is highly encouraged for accuracy and speed in completing a connection. When using numeric result codes WILDCAT! must know which codes to look for from your modem. The top line reflects the codes for a "normal" connection while the bottom line labeled MNP is ONLY used if your modem has built-in hardware error checking (see your manual). The regular codes are normally the same for all modems; 1 for 300 baud, 5 for 1200, and 10 for 2400 baud. If you modem supports MNP (Microcom Network Protocol) or ARQ (Automatic Repeat Request) you should also fill in the MNP line with the numeric codes your modem returns when it connects with another modem with the same hardware protocol. Our example is the US Robotics HST which returns 15, 16, and 17 when connected to another modem with MNP at 1200, 2400, and 9600 respectively. Use the number 99 for any unsupported connection rate such as 9600 and 19,200 on the top line since 9600 and 19,200 baud almost always make use of some form of hardware error control. For a standard modem without any MNP the top line would have 1, 5, 10 and everything else 99. 3. Command to place your Modem Off-Hook: AT H1 The default is AT H1, which any Hayes-compatible modem should be able to recognize as the command to go off-hook. This command is NOT sent when WILDCAT! answers the phone; rather, when the Sysop logs locally, terminates WILDCAT! via the F10 key, or WILDCAT! executes an event, such as internal event Y to dump the Wastebasket. If your modem speaker makes noise when F10 is pressed and WILDCAT! goes off-hook you may add the command M0 to turn off the modem speaker. 4. Command to place your Modem On-Hook: AT H0 The default is AT H0, which any Hayes-compatible modem should be able to recognize as the command to go on-hook. WILDCAT sends the command when coming back from an event, such as internal event Y to dump the Wastebasket. 5. Number of Milliseconds delay before PRELOG file: 1500 Some modems delay a short time after answering the phone and establishing a connection. If you find your callers are missing some of the PRELOG.BBS display file, or are not receiving the prompt for First Name properly, you may add a delay so the program will wait an appropriate amount of time. Try the default of 0, and if problems develop as indicated increase the value to 1500ms (1.5 seconds). 6. Does your modem support CTS/RTS flow control : N ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 29 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Many modems can make use of the Clear To Send (CTS) and Request To Send (RTS) signal to tell the other modem when data should be sent, and when to wait. CTS/RTS is used by the modems to tell one another when their respective send/receive buffers are full or empty. If your modem supports CTS you MUST enter Y to this prompt. Virtually all 9600 baud modems, as well as those supporting MNP/ARQ make use of CTS/RTS for flow control. FAILURE TO INDICATE THAT CTS IS AVAILABLE FOR MODEMS THAT SUPPORT MNP/ARQ WILL RESULT IN LOST DATA DURING TRANSMISSION, ESPECIALLY IF YOU HAVE LOCKED THE COMMUNICATION PORT AT THE INITIALIZED BAUD RATE. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 30 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── NEWUSER DEFAULTS The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ NEWUSER DEFAULTS Frame 5 ║ ║ ║ ║ 1. Are you going to run a closed board [ Y/N ] ? N ║ ║ ║ ║ a. Force caller to leave a comment then logoff ║ ║ b. Force caller to the Questionnaire then logoff ║ ║ c. Logoff immediately and don't add to the user base ║ ║ If closed, then select [ a..c ] ? ║ ║ ║ ║ 2. New Users Default Security Level ? 10 ║ ║ 3. Ask for their Phone Number [ Y/N ] ? Y ║ ║ 4. Ask for their Birth Date [ Y/N ] ? Y ║ ║ 5. Ask for their Computer Type [ Y/N ] ? Y ║ ║ 6. Force Newuser to fill out the Questionnaire [ Y/N ] ? N ║ ║ 7. Time Limit (in minutes) for first call ? 60 ║ ║ 8. Number of lines per page ? 23 ║ ║ 9. Place them into these Msg folders: ABCD ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 1. Are you going to run a closed board [ Y/N ] ? N "N" is the default. This means that all users will be allowed to logon on to the system and will be entered into the user database as they call. The user's "freedom" on the board will then be determined by the security values established in the various menu commands for each level of user. If this field is toggled to "Y", you are indicating that unless the user's name and password information is recognized by the system, that user will not be allowed into the system for any reason. A file names CLOSED.BBS will be displayed, and the caller will be logged off immediately, unless "a" or "b" is chosen, in which case the user will be first forced to leave a Comment or answer the Questionnaire (if it exists), respectively. Running as a closed board means that all user information must be added manually by the sysop for every user before they can gain access to the system. A CLOSED BOARD MUST FIRST BE SET AS OPEN TO ALLOW THE SYSOP TO LOG ON AND UPGRADE HIS OWN ACCESS. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 31 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── 2. New users default security level : 10 The number entered here will establish the level of security access every new, unknown caller has on your system. 3. Ask for their phone number [ Y/N ] ? Y By answering Y to this option, a new user is prompted to enter a phone number during their first logon to the system. Although the user is not allowed to ignore this prompt, a wrong number may be entered. The number entered here may also be used for periodic security checks. 4. Ask for their birth date [ Y/N ] ? Y If implemented this option will allow for periodic security updates, just like the prompt for phone number verification. In addition, WILDCAT! will convert the user's birth date to his or her actual age today when the user record is inspected (the system date must be set correctly for this to operate properly). This confidential information is stored in the user database, and is only available to the system operator. Many operators like to gather statistical data from information of this nature. "What is the median age of my users?"; "Who is the youngest and oldest user?" How about a surprise birthday greeting to the user? Or perhaps most important, allowing the user age information to serve as a guide to what files are maintained on the system, and establishing the tone and contents of your bulletins and editorials. WILDCAT! is hard-coded to prohibit a user from entering values which (when converted to age) mean that the user is less than six, or over ninety years old. 5. Ask for their computer type [ Y/N ] ? Y If implemented, users are presented a blank line on which to briefly describe their computer name and type. It assists the system operator in helping the user in the event of any compatibility problems while on the board. This information is presented alongside the user name in both the [L]ist users and [V]erify users options on the main menu. 6. Force new users to fill out the Questionnaire [ Y/N ] ? Y The questionnaire for new users will be further discussed in a separate section of the manual, along with instructions on generating the questionnaire. This option is a toggle to determine whether a new user will be asked to complete a special questionnaire during their initial logon to the system. It may be used whether or not the system is run as a closed board. If toggled to Y, every new caller will be presented with the new user questionnaire immediately after completing the basic logon information. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 32 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── 7. Time Limit (in minutes) for first call ? 60 Some bulletin board systems do not differentiate between a first time caller and a regular caller. Others require that a new user be screened prior to receiving access to various areas of the WILDCAT! system, such as leaving messages and up/downloading files. If you elect to have a screening procedure there may be no real need to allow a new user the same time limits as a regular caller. Since their privileges are limited, there will not be enough options available to the user to require a longer time limit. Be realistic in the value entered here. Many first-time callers are apprehensive, or perhaps slow typists. If you have all the other first-time caller options implemented, plus a questionnaire, it's possible that a new user will never get to the main menu in the allotted time! The provided default value indicated above is reasonable in such a case, but be sure to test this value in your own application. 8. Number of lines per page ? 23 The user is prompted during the initial logon to enter a value for the number of SCREEN lines per page. This value is used throughout the program to determine the appropriate position for automatic screen pauses. The value entered here is presented as the default value if the new user simply presses the ENTER key, and is correct for most PC users. 9. Place them into these message folders: ABCD Number two on this screen determines the security level assigned to a new user, and that security level determines which message folders will actually be accessible at the time of the first logon. To make learning the system easier for new callers you may automatically open folders for viewing by entering the folder letters here. You could also choose to auto-open additional message folders, including some to which new users are denied access until upgraded to a higher security level. This causes no problems since the user's security level will be the final determinant of which folders a user may actually view, regardless of whether they have been auto-opened. The values entered should typically include any folder that is available for general use by your regular users. The Z folder (comments) is included as a default here to guarantee that the sysop may leave replies to comments in folder Z, and that all users may read the sysop replies. The general rules governing message folders are that a user may leave a message or read public messages in any folder to which he has security access and has open. Users will be ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 33 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── advised of new personal mail in any folder, but cannot use the [R]ead command unless they have security access and it has been OPENED. The special folder Z is no exception to the above guidelines. The wastebasket (folder Y) is ever checked for personal mail. Personal messages placed in a folder to which a user has no access may not be read except via the [R]ead [M]arked mail command. It is therefore advisable to give all users access to the Z folder as a minimum. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 34 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── SECURITY INFORMATION The following is a screen representation ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 6 ║ ║ SECURITY INFORMATION ║ ║ ║ ║ ║ ║ 1. Allow remote Sysop's Drop to DOS [ Y/N ] ? Y ║ ║ 2. Verify Telephone Number after every 15 logons. ║ ║ 3. Verify Birthdate after every 30 logons. ║ ║ 4. Minimum Security Level to overwrite files on uploads ? 100 ║ ║ 5. Should the Sysop screen PUBLIC messages before they ║ ║ are posted on the system [ Y/N ] ? N ║ ║ 6. Can Users leave PRIVATE messages [ Y/N ] ? Y ║ ║ 7. Minimum Security to read SYSOP (and PRIVATE) Mail 100 ║ ║ 8. Total Number of different User Security levels [ 1..18 ] ? 7 ║ ║ 9. Echo the User's password on the screen [ Y/N ] ? N ║ ║ 10. Display Password Protected files in the file listing [ Y/N ] ? N ║ ║ 11. Security level for MASTER Sysop ? 1000 ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 11. Allow remote Sysop's Drop to Dos [ Y/N ] ? Y If this prompt is answered with "Y", and the caller's security is high enough to permit it (we suggest that only sysops be allowed this choice), the caller may actually exit WILDCAT! and assume control of the computer's operating system. It is unlikely that anyone other than the system operator, when calling in from a remote location, will ever need this option. Setting this value to "N" will prevent use of the Remote Drop to DOS option on the sysop menu. Caution: This is not only a powerful option but potentially a very dangerous one. Unless other safeguards are implemented, a caller has total and absolute control over your entire operations, including erasing the contents of your hard drive. Unless you are totally familiar with the operating system, batch files, and related areas, you are strongly encouraged to set this value to "N". 2. Verify Telephone number after every [xx] logons. Users of all bulletin board systems are encouraged to change their passwords regularly. This habit is the exception rather than the rule, however. Verifying a user's telephone ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 35 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── number after every [xx] logons is simply an additional security device to determine whether the person logged on is really the person he/she logged on as. Following [xx] logins, the caller is prompted to enter a phone number in addition to the usual first name, last name, and password. The phone number entered is then checked for validity against the user's record, and if the response is not the same as that contained in the database, the caller is automatically forced to the comments section of the system to explain the discrepancy before continuing with the logon. 3. Verify User's Birth Date after every [xx] logons The rationale for verifying a caller's birth date is the same as that of #2 above. Although the values of [xx] could be the same in both item numbers two and three, it is recommended that the values are staggered to present the illusion of a "random" pattern. When the security options are combined, the chances of an "illegal" user knowing a user's first name, last name, telephone number, and date of birth become increasingly unlikely. 4. Minimum Security to overwrite files on uploads ? xx Any user who a security level equal to or greater than [xx] is permitted to overwrite an existing filename during an upload session. This option is beneficial for a writer or programmer who may be periodically uploading a revised version of a file, or perhaps when two or more people are collaborating on revisions to a document. For normal operations, this value should be greater than that of a "normal" user; otherwise there may be serious consequences! Note: The user who originally uploaded a file is granted the authority to overwrite the same file. The user is prompted as to whether the file should be overwritten. WILDCAT! is coded in this manner to maintain continuity to file names and "refresh" dates. The only time it may be a problem is if the uploader proceeds to overwrite a file, then aborts the upload. The original file will be destroyed! 5. Should the Sysop screen PUBLIC messages before they are posted to the system [ Y/N ] ? N If this value is set to "N", any message entered to ALL users is posted on the system immediately. By setting the default to "Y", all messages intended for public viewing must be screened for content, then manually toggled from private to public by the system operator. Normally this value is set to "N", since most users are reputable. It is only in the event that a lot of users post public messages that contain information that is abusive, libelous, or ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 36 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── perhaps contain confidential information or profanity is this option needed. 6. Can Users leave PRIVATE messages [ Y/N ] ? Y By entering "N" to this prompt, a user is still permitted to enter messages to selected users, but the private flag is removed. Selecting "N" prevents any PRIVATE mail. This feature may be used at your discretion, and may be useful in certain applications. In most cases, you will probably want to leave the value as "Y". 7. Minimum security to read SYSOP (and PRIVATE) Mail 100 Normally, only the system operator should have a security level high enough to read sysop and private mail. 8. Total number of different User Security levels [ 1..18 ] ? 7 This is the physical count for the number of security levels. The actual security level values are established later in the configuration procedure. Any number up to eighteen may be entered here depending on your needs. Whatever value is entered will dictate the number of actual security levels that are entered later in the setup. 9. Echo the User's password on the screen [ Y/N ] ? N The default answer here is "N", indicating that as a caller types his password, it is displayed as dots on the host system screen. Some applications in a busy office setting may require this additional security while a home BBS may not. A "Y" response displays the caller's password locally as it is typed. Note that a callers password is always echoed back to him as asterisks. 10. Display Password Protected files in file listing [ Y/N ] ? N WILDCAT! has the ability to require a password to download a file, and the Sysop determines whether these files are listed along with the non-protected files or are hidden from view. If the "N" option is selected, users will not know of the existence of password protected files unless advised by a message or some other means. 11. Security level for MASTER Sysop ? 1000 Many system operators make use of more than one sysop to help maintain files, messages, and users. With this possibility in mind you are able to set aside one security level as MASTER sysop who has full system control. The specific area in which control is limited for sysops at other levels is the [U]ser database function within the sysop menu. Even if a co-sysop has access to this area, he will not have the ability to see other users passwords or to ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 37 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── add other users at the MASTER level. An example is a MASTER sysop level of 1000 and co-sysop at 900. When the sysop at level 900 views the [U]ser database, the passwords will display as a series of asterisks. Do keep in mind that users passwords may be changed by the non-master sysop, but a non-master sysop cannot log in as the user, or compromise his password without changing it. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 38 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── SYSTEM CONFIGURATION - Part 1 The following is a screen representation. ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 7 ║ ║ SYSTEM CONFIGURATION - Part 1 ║ ║ ║ ║ ║ ║ 1. Allow 300 BAUD Calls [ Y/N ] ? Y ║ ║ 2. Is the Bulletin Menu Optional [ Y/N ] ? Y ║ ║ 3. Time Compensation ratio on uploads is 2 to 1. ║ ║ 4. Display the quote of the day [ Y/N ] ? Y ║ ║ 5. Display a download/upload ratio warning above 20 to 1. ║ ║ 6. Will you be offering Color ANSI Menu's [ Y/N ] ? N ║ ║ 7. Total number of Bulletins Offered is ? 6 ║ ║ 8. Place the MODEM "OFF HOOK" when WILDCAT! is down [ Y/N ] ? Y ║ ║ 9. Message range is 1 to 0 . ║ ║ 10. Path for Menu Files : C:\WILDCAT ║ ║ 11. Path for Help Files : C:\WILDCAT ║ ║ 12. Path for Display Files: C:\WILDCAT ║ ║ 13. Path for Ext Protocols: C:\WILDCAT\PROTOCOL ║ ║ 14. Path for Bulletins : C:\WILDCAT ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 1. Allow 300 BAUD calls [ Y/N ] ? Y There are rather strong feelings among system operators as to whether or not to permit 300 baud callers. It is not the intent of this document to take issue with these sentiments either way. For those who wish to disallow 300 baud callers during certain time periods, the option is provided. The default allows 300 baud access at all times. 2. Is the bulletin Menu optional [ Y/N ] ? Y WILDCAT! automatically scans the file date and time of all bulletin files and compares this information to that in the caller's user record. If a bulletin has been updated since the caller's last logon, a message will inform the caller as to which bulletin(s) have been updated. Otherwise, the caller is informed that NO bulletins have been updated since the last call, and is prompted as to whether the caller would like to view the bulletin menu. If this option is set to "N", the caller is forced to view the bulletin menu, whether or not any bulletins have been updated. 3. Time Compensation ratio on uploads is 2 to 1. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 39 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── In order to encourage uploads, some system operators will grant a time bonus to those users who contribute to the system's program files. If the value is set to 2, the user is given twice the file transfer time in additional time allowed online for this particular call. For example, when set 2 to 1, if a file requires 5 minutes to upload, the user will be allowed 10 extra minutes on the system. A 1 to 1 ratio would compensate the user for the actual time of the upload, meaning that his time remaining would be the same before and after uploading. A 0 to 1 ratio would not allow any time compensation, in which case the upload time would be counted against the user's existing logon time. 4. Display the quote of the day [ Y/N ] ? Y The Quote of the day is an ASCII file created by the system operator. It may contain words of wisdom, quotes from famous people, cute sayings, insults, or anything else appropriate to the needs of the system. The file contents are presented sequentially starting with the first item in the file, and incremented by one following each new logon to the system. The quote appears just prior to the main menu. When the end of the file is reached, it starts again from the beginning. A quote consists of any number of lines of text, each of which is terminated by a carriage return. There must be a blank line (just a carriage return) between each quote since WILDCAT! assumes an individual quote has ended when it sees two carriage returns in a row. If this option is set to "Y", WILDCAT! will look for the file QUOTES.BBS. If the file is not found, the code will continue to run, but will generate an error message to both the local monitor and the caller. Until you have created this file, it is better to set the option to "N". For more information on creation of this file, refer to the Files Used by WILDCAT! section of the manual. 5. Display a download/upload ratio warning above 20 to 1. If a user exceeds the upload/download ratio above, a warning message will be scrolled to the user. Further downloads are NOT prevented; this functions only as a warning to the caller. 6. Will you be offering Color ANSI Menu's [ Y/N ] ? N You may elect to offer color ANSI menus to callers asking for color by toggling this choice to "Y". Dynamic menus will still be scrolled to those users not desiring color. If set to "N", dynamic menus will be generated for all callers. 7. Total number of Bulletins offered is ? 6 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 40 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── In order to inform the user as to which bulletins have been updated since the user's last logon, WILDCAT! must be informed of the number of bulletins that are available. This number limits the acceptable responses at the Bulletin menu prompt and must be set properly. WILDCAT! will automatically check the file date/time for each bulletin and make a comparison to the callers last call date/time for notification purposes. The maximum number of bulletins supported is 9,999. 8. Place the MODEM "OFF HOOK" when WILDCAT! is down [ Y/N ] ? Y When set to "Y", and the system is brought down for whatever reason, WILDCAT! will automatically send a message to your modem to place the phone off hook (busy). This would be advisable if your board were running on a dedicated phone line, since the caller will receive a busy signal and think that the system is busy rather than being off-line. 9. Message range is 1 to 0 These values should be left as default values. They are placed here in the event your message base should ever become severely contaminated, at which an auxiliary program called FIXMSG.EXE can reconstruct the damaged message base. Upon completion FIXMSG will indicate the current lowest and highest message number. You should then run MAKEWILD and check the values here. NOTE: Verifying the latest correct message numbers in MAKEWILD after running FIXMSG.EXE is very important, and must be done if FIXMSG is ever run! 10. Path for Menu Files : C:\WILDCAT This path should reflect the location of all menu files used by the program. It may be the same location as your WILDCAT! home path (the location of the program files), but may be different simply for organizational purposes. The files to be placed in this area include: MAIN.SCR MAINLO.SCR MAINMD.SCR MAINHI.SCR MESSAGE.SCR MESSAGEL.SCR MESSAGEM.SCR MESSAGEH.SCR FILES.SCR FILESLO.SCR FILESMD.SCR FILESHI.SCR SYSOP.SCR SYSOPLO.SCR SYSOPMD.SCR SYSOPHI.SCR Depending on your configuration, there could be up to 16 menu files in this area. The .SCR designator indicates a color menu, with non-color menus being Dynamically generated by WILDCAT!. 11. Path for Help Files : C:\WILDCAT ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 41 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── This path may also be the same as your home path if desired. If different, it should contain all files ending in .HLP. This will include the color ANSI menus including: MAIN.HLP (Non-color file) MAINC.HLP (Color file) MESSAGE.HLP (Non-color file) MESSAGEC.HLP (Color file) FILE.HLP (Non-color file) FILEC.HLP (Color file) SYSOP.HLP (Non-color file) SYSOPC.HLP (Color file) 12. Path for Display Files : C:\WILDCAT This category includes all files which are displayed to the caller for informational purposes which are not included in other categories. Both non-color and color ANSI files should be included. 13. Path for Ext Protocols: C:\WILDCAT\EP This file path is made as short as possible to maximize the number of files able to be sent. Since the DOS command line length is normally limited to 128 characters, it is sometimes impossible to pass all of the information required for external file transfers if this path exceeds 15 characters. When batch external transfers are requested, WILDCAT! must perform a shell (exec call) and pass the full protocol path + the name of your batch file + the com port # + the baud + seven filenames. Using maximum possible values here, the limit for the protocol path is about 15 characters. All files related to external file transfers should be placed in this area. These include the batch files specified in the Frame 18, and the actual file transfer programs such as DSZ, PCKERMIT, etc. Although you could place the program files (like DSZ) in the WILDCAT! home directory and have DOS locate them with a path statement, having them here guarantees that they will be found by the batch files and makes it easy to check your system for missing files. This path is not only used as the location where WILDCAT! looks for your protocol batch files, but is also the temporary holding location for all files sent and received via external protocols. For example, when a filename is requested for download using Zmodem, WILDCAT! places a duplicate copy of the file in this subdirectory for transfer. When the filename is passed to the batch file for sending by DSZ, no path to the main file location is included, and DSZ assumes the file is located in the current directory. After the transfer is completed, WILDCAT! will erase the temporary copy of the file from this area. This is done to avoid having to pass the entire path and filename for every file transfer requested, which would easily exceed the DOS command line length of 128 characters. 14. Path for Bulletins : C:\WILDCAT ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 42 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Place all files related to bulletins in this area, including: BULLETIN.BBS BULLET#.BBS BULLET#.SCR "#" being the actual number of the Bulletin to be displayed. Note that the number of Bulletins must agree with the Total Number of Bulletins selected in Question #7. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 43 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── SYSTEM CONFIGURATION - Part 2 The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 8 ║ ║ SYSTEM CONFIGURATION - Part 2 ║ ║ ║ ║ 1. How Many Message Folders do you wish to have ? 8 ║ ║ Note: Folder Y is reserved for Deleted Message ║ ║ Review or the "Wastebasket" and Folder Z is ║ ║ reserved for Comments to the Sysop. DO NOT Include ║ ║ these 2 folders in your answer. ║ ║ 2. Number of Different File Areas? 10 ║ ║ 3. Number of EXTERNAL transfer protocols? 0 ║ ║ 4. Maximum Log-on Time Limit? 60 ║ ║ 5. Monitor Type ([C]olor, [M]ono, [A]uto)? A ║ ║ 6. Screen Foreground Attribute? 7 ║ ║ 7. Automatically Clear Screen before menus? Y ║ ║ 8. Drop WILDCAT! with Errorlevel 60 after each call? N ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off 1. How many Message Folders do you wish to have ? 8 NOTE: Folder Y is reserved for Deleted Message Review or the "Wastebasket" and Folder Z is reserved for Comments to the Sysop. DO NOT Include these two folders in your answer. The minimum acceptable value in this option is 0. WILDCAT! has the last two folders (Y and Z) hard-coded for use as Comments to Sysop and Deleted Message Review, respectively. A value of 0 would then allow no additional message areas. A value of 1 would allow one additional area, to be named whatever you wish. Many systems only need a Main message folder with no other folders, in which case one would be sufficient. Alternately, as many as twenty-four additional folders (A-X) may be set up, each with its own security level restrictions which are assigned later. 2. Number of Different File Areas? 10 Do not confuse the file areas with the message folders. They do not share the same values or names, and are usually not related in any way. For example, you could have the three message folders as mentioned above, and still maintain up to twenty-six (A-Z) file areas. 3. Number of EXTERNAL transfer protocols? 0 The system needs to know how many file transfer protocols you will use that consist of programs that run OUTSIDE of the WILDCAT! code. Examples are KERMIT, ZMODEM, JMODEM, ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 44 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── etc. You will enter the complete specifications for these protocols later in this setup procedure. 4. Maximum Log-on Time Limit? 60 This is the MAXIMUM time ANY user will be allowed to stay on the system during a single call REGARDLESS of the time set for his security level. It is a time PER CALL. If it is less than the amount of time allowed for a callers security level time, the user may call back a second or third time the same day and get the balance of time remaining. 5. Monitor type ([C]olor, [M]ono, [A]uto)? A Although WILDCAT! has the ability to look at your system and tell what type of video card is attached, you may override this default selection. This may be necessary on some systems which have a single color monitor connected to a graphics controller card that does not display some colors properly. One example we have found it the AT&T 6300 series which requires a Mono setting. Most systems work best when set to Auto, and this is the recommended setting unless problems become evident. If a change is needed, toggle the available choice with the spacebar. 6. Screen Foreground Attribute? 7 This setting refers to the color displayed on the LOCAL monitor when the caller is in non-color mode, and during local logon. It may be any valid DOS color number from 1 through 15. See Appendix B for the list of DOS color codes. If the caller has selected ANSI color menus then the local monitor will reflect the same colors as the caller, and display them in whatever manner is possible for the local monitor. 7. Automatically Clear Screen before menus? Y Depending on your preference, you may clear the caller's screen prior to each menu being displayed. Experiment both ways and take your choice. Keep in mind that you also have the ability to embed a clear screen code (ASCII 12, the Form Feed character) at the beginning of your own menus, if desired. 8. Drop WILDCAT! with ERRORLEVEL 60 after each call? N This option is primarily implemented as a means of calling a front end program used to handle net and echo mail. It functions exactly like an external event that is run after every call, and will be referred to as the Call Processing Event. Most systems will not need to enable this feature. See the section on Netmail and EchoMail for additional information. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 45 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MESSAGE FOLDER SETUP The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 9 ║ ║ MESSAGE FOLDER SETUP ║ ║ ║ ║ Folder Folder ║ ║ LTR Description LTR Description ║ ║ - ------------------------------ - ------------------------------ ║ ║ Y Deleted Message Review Z Comments to the Sysop ║ ║ A General Mail Folder B Games Folder ║ ║ C Programming Folder D BBS Ads Folder ║ ║ E WILDCAT! Users Folder F WILDCAT! BETA TEST Folder ║ ║ G WILDCAT! ALPHA TEST Folder H Special Members Folder ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off The number of message folder letters available in this frame is determined by the value entered in SYSTEM CONFIGURATION, Frame 8, Question 1. In the default example, there were eight message folders requested. That value is automatically converted to folder letters "A" through "H" in this frame, plus the hard-coded "Y" and "Z" areas. To get a clearer understanding of this, while running MAKEWILD use your PgUp key to go back to SYSTEM CONFIGURATION, Frame 8. Change the value of Question one to "2". Then return to this screen and observe the results. You should find folder letters "A" and "B" plus "Y" and "Z" with their associated descriptions. Don't forget to change the value back to the actual number of different message areas you need. You may edit the descriptions to anything you feel is appropriate to describe a particular folder's contents, excluding those following letters Y and Z. For example, you may wish to change folder A from General Mail Folder to Main Message Area. Try it, using the editing keys described earlier. You can always change them back later. Also remember that no changes are permanent unless you choose to save your setup options upon exiting MAKEWILD. The folder names you enter here are displayed to your callers when they finish entering a message or reply. They are given a choice of folders in which to place the new message, limited by their security access to the folders (defined later). ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 46 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILE SECTION SETUP The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ FILE SECTION SETUP Frame 10 ║ ║ ║ ║ File Area File Area ║ ║ LTR Description LTR Description ║ ║ - ------------------------------ - ------------------------------ ║ ║ A Dos Utilities B Communication Software ║ ║ C Database & Word Processing D Turbo Pascal Utilities ║ ║ E Products From Mustang Software F Games for the IBM PC ║ ║ G WILDCAT! Bulletin Board System H WILDCAT! BETA Test Files ║ ║ I WILDCAT! ALPHA Test Files J For Jim Harrer Only UPLOADS ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off The number of File Area letters presented on this screen are determined by the value entered in SYSTEM CONFIGURATION, Frame 8, Question two. The descriptions may be edited just like the message folder setup, including the letters Y and Z. The file area letters A, B, etc. are in NO way related to your message folder letters. Files and messages just happen to both make use of letters of the alphabet for tagging the respective folders or areas. The descriptions you enter here will be the text that is displayed as titles of the file areas when the [L]ist files command is used. WILDCAT! allows you to group your files available for download by areas or categories, with the actual files for each category stored in a different subdirectory on your hard disk. The file area names should describe the files which are contained in each subdirectory. Later in this setup you will indicate the specific subdirectory names associated with each file area. If this is not yet clear to you, perhaps take a look at Frame 17 (use PgDn) before changing anything on this frame. You can then see that the descriptions entered here for each file area describes the actual files found in the subdirectories entered in the File Path Definitions screen. For example, area D is Turbo Pascal Utilities here, and the subdirectory path in Frame 17 for file area D is pointing to a subdirectory named TURBO where all the files are physically located. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 47 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR "MAIN" MENU The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR "MAIN" MENU Frame 11 ║ ║ Activity Call Ltr Description Seq Sec ║ ║ ------------------ - ---------------------------------- -- ---- ║ ║ Call Message Menu M [M].............Message Menu 1 5 ║ ║ Call File Menu F [F]...............Files Menu 2 5 ║ ║ Comment to Sysop C [C]....Comments to the SYSOP 3 1 ║ ║ Call Bulletin Menu B [B]............Bulletin Menu 4 5 ║ ║ Page the Sysop P [P]...........Page the SYSOP 5 5 ║ ║ Show Welcome Scrn I [I]...Initial Welcome Screen 6 5 ║ ║ Call Questionnaire Q [Q]............Questionnaire 7 5 ║ ║ Seek Active User V [V]............Verify a User 8 5 ║ ║ Change UserSetting Y [Y]............Your Settings 9 5 ║ ║ Board Information S [S]........System Statistics 10 5 ║ ║ List User Log U [U].............Userlog List 11 5 ║ ║ DOORS Menu D [D]....................DOORS 12 9999 ║ ║ Call Newsletter N [N]...............Newsletter 13 5 ║ ║ Goodbye & Logoff G [G]........Goodbye & Log-Off 14 1 ║ ║ Help Level H [H]...............Help Level 15 5 ║ ║ Call Help File ? [?].............Command Help 16 5 ║ ║ Call Sysop Menu R [R]....Reports for the SYSOP 17 1000 ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off This screen lists the menu choices for the main menu. WILDCAT! will permit a lot of flexibility in its run-time configuration. This includes the menu structure which may be completely customized. In this screen you will specify the names of the various menus choices as well as the keypresses used to activate those choices. Along with this power and flexibility comes an area for possible confusion, so the screen above will be elaborated upon in the following paragraphs. The five main screen sections represent the following: ACTIVITY This text field describes the actual function of the menu choice within the program. Each describes what is actually happening inside the code during the procedure that is listed, and they are never seen except when running MAKEWILD. They are listed here for your information so that you may decide the menu name and description that you will give to that specific menu function. Further details of each function are contained in the section "WILDCAT! in Action" later in the manual. Look ahead to that section if the brief activity description given here does not adequately explain what the menu choice actually does. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 48 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── CALL LTR The call letter for a particular option is definable. It represents the key a user must press on the keyboard to activate that menu choice. The call letter may be any ASCII character that your normal keys will produce. In addition, the Call Letter does NOT have to agree with the first letter in the description. For example, you might elect to change the call letter for [I]nitial Welcome Screen from I to W and then change the related description to Initial [W]elcome Screen, or just [W]elcome Screen. These call letters are active for both dynamic menus and color .SCR menus. Your text menu files must agree with the call letters entered here. DESCRIPTION The description is what you elect to call the activity on the dynamic menus as they are displayed to the screen. For example, you are free to change the [N]ewsletter call letter to S and redefine the associated description to [S]ystem News or News on system. However, notice that there now exists a conflict with two S call letter options, the other still being used for [S]ystem Statistics. MAKEWILD will NOT double-check for potential conflicts in this area and you are cautioned to work out your call letters and descriptions properly. The use of brackets is optional in the description line, but for clarity, you are encouraged to use some means of highlighting the user's screen options. Again, these descriptions will only be used for the dynamic menus generated by WILDCAT!. If you are making use of color menus, you will need to enter the descriptions in your or MAINxx.SCR files. Having the correct descriptions here is recommended since the dynamic menus are used if a text menu file cannot be located for some reason. SEQ NUN (Sequence) This option determines (1) the order in which the Description is presented on the dynamic menu screen when the dynamic menus are being used, and (2) the sequence of characters on the command line. Notice on the sample screen that the [M]essage Folder Area and [F]ile Sections are numbers 1 and 2, respectively. Users will use these options more often than the others indicated. For this reason, they have been given these sequences. You may change them to any sequence you wish, but be careful that no two commands have the same sequence number. SEC NUM (Security) ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 49 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Enter the minimum security level required to access each menu option in this field. All users with that level or above will be able to perform the menu function. If dynamic menus are being used, callers will only be shown the choices to which they have access by security level. In the screen above, if the security level for the [N]ewsletter option were raised to a value of 10, a user with a security of 5 would not only not be able to access the newsletter, he would not even see the option on his menu. If color ANSI menus are being used, the sysop must use the access rights in this frame to create the various MAINxx.SCR files, containing the correct menu choices for each security level. Caution: Regardless of the actual call letter and description given, be especially careful with the security level of the Call Sysop Menu activity. This function should be reserved for system operators only. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 50 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR "MESSAGE" MENU The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR "MESSAGE" MENU Frame 12 ║ ║ ║ ║ Call Seq Min ║ ║ Activity Ltr Description Num Sec ║ ║ ------------------ - ----------------------------------- -- ---- ║ ║ ║ ║ Call The Main Menu Q [Q]....Quit to the Main Menu 1 5 ║ ║ Select Folder U [U]..Update Folders for Mail 2 5 ║ ║ Read Messages R [R]............Read Messages 3 5 ║ ║ Scan Messages S [S]............Scan Messages 4 5 ║ ║ Enter Messages E [E]..........Enter a Message 5 5 ║ ║ Delete a Message D [D].........Delete a Message 6 5 ║ ║ Search Messages T [T]..............Text Search 7 5 ║ ║ Check Mail Box C [C]......Check Personal Mail 8 5 ║ ║ Goodbye & Logoff G [G]........Goodbye & Log-Off 9 5 ║ ║ Help Level H [H]...............Help Level 10 5 ║ ║ Call Help File ? [?].............Command Help 11 5 ║ ║ Call File Menu F [F].............FILE SECTION 12 5 ║ ║ Call ErrLevel 35 N [N].................Net Mail 13 9999 ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off The screen above is used to define the options available when a user chooses the [M]essage menu choice from the main menu. The menu options that exist here are the same as the main menu in the previous screen. Note that since this a separate menu, duplication of the main menu Call Letters are permitted. Let's use the first option as an example, just to further illustrate the menu options. Before: Call The Main Menu Q [Q]uit to the Main Menu 1 After: Call The Main Menu M Return to [M]ain Menu 5 Notice what has happened. The keypress letter that returns the user to the main menu has been changed from Q to M, and the brackets prompting for the option in the description have been edited. In addition, the location on both the message menu screen and command line will be repositioned. Using the power of the security levels in this manner can be very useful if used wisely. Be careful! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 51 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR "FILE" MENU The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR "FILE" MENU Frame 13 ║ ║ ║ ║ Call Seq Min ║ ║ Activity Ltr Description Num Sec ║ ║ ------------------ - ----------------------------------- -- ---- ║ ║ Call the Main Menu Q [Q]........Quit to Main Menu 1 5 ║ ║ Info on a file I [I]....Information on a file 2 5 ║ ║ List Avail. Files L [L].....List available Files 3 5 ║ ║ Call Download Proc D [D].......Download a File(s) 4 5 ║ ║ Call Upload Proc. U [U].........Upload a File(s) 5 5 ║ ║ New File Search N [N]......New Files since [N] 6 5 ║ ║ Text Search in File T [T]..............Text Search 7 5 ║ ║ Drive Status S [S]....Stats on Up/Downloads 8 5 ║ ║ Call Help Transfer F [F]......File Transfer Info. 9 5 ║ ║ Goodbye & Logoff G [G]........Goodbye & Log Off 10 5 ║ ║ Help Level H [H]...............Help Level 11 5 ║ ║ Call Help File ? [?].............Command Help 12 5 ║ ║ Call Message Menu M [M]..........MESSAGE SECTION 13 5 ║ ║ View an ARC file V [V].........View an ARC file 14 5 ║ ║ Read a Text File R [R].........Read a TEXT file 15 5 ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off By now you should be comfortable with the functions of the Activity, Call Letter, Description, Sequence Number, and Minimum Security parameters. If not, refer back to the main menu definition screen for a review. Meanwhile, let's explore another area of WILDCAT!'s power by using this frame for another example. Suppose you are assigning a new user a default security level of five. Further suppose you wanted your system to be friendly enough to allow the new user access to all options in the FILES area, except the ability to actually up and download files until such time the user is validated and upgraded by the system operator. What changes to the example frame above would be required? Simply change the security levels for the D and U options to a value higher than 5. Of course, the [F]iles section in the Main Menu Definitions should be set to 5 to allow the user access to this menu in the first place. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 52 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR "SYSOP" MENU The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR "SYSOP" MENU Frame 14 ║ ║ Call Seq Min ║ ║ Activity Ltr Description Num Sec ║ ║ ------------------ - ----------------------------------- -- ---- ║ ║ Call Main Menu Q [Q]....Quit to the Main Menu 1 1000 ║ ║ Drop to DOS D [D]..............Drop to DOS 2 1000 ║ ║ Print User File P [P]..Print the User Database 3 1000 ║ ║ List Schd Events L [L]....List Scheduled Events 4 1000 ║ ║ Create Schd Event C [C]..........Create an Event 5 1000 ║ ║ Update Schd Event E [E]............Event Updates 6 1000 ║ ║ Modify User Base U [U].......User Database Area 7 1000 ║ ║ Help Level H [H]...............Help Level 8 1000 ║ ║ Goodbye & Logoff G [G]........Goodbye & Log_Off 9 1000 ║ ║ List Activity Log A [A].....Activity Log Listing 10 1000 ║ ║ Del Activity Log K [K]....Kill the Activity Log 11 1000 ║ ║ Edit the File D.B. F [F].......File Database Area 12 1000 ║ ║ Database Status S [S]......Status of Databases 13 1000 ║ ║ Delete Wastebasket W [W].........Wastebasket Dump 14 1000 ║ ║ Re-Index Menu I [I]......Index Database Menu 15 1000 ║ ║ Call Help File ? [?].............Command Help 16 1000 ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off All of the editing options affecting other menus are applicable in the Sysop menu. A caution was issued back in the main menu options to always set the [R]eports to sysop (or whatever letter you've assigned to this option) to a value higher than any other security level. Notice that all the options in the Sysop menu have a security level of 1000. Regardless of whether other trustworthy users are granted Co- sysop access to the system, only the actual system operator should have absolute control over all parts of the system! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 53 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR SECURITY LEVELS The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR SECURITY LEVELS Frame 15 ║ ║ Lev Message Folder Access Download File Area Access DTL ANSI ║ ║ ---- -------------------------- -------------------------- --- - ║ ║ 1 Z 15 L ║ ║ 5 Z E 45 L ║ ║ 10 ABCD ABCDEF 45 M ║ ║ 20 ABCDE ABCDEFH 90 M ║ ║ 50 ABCDEF ABCDEFHI 90 H ║ ║ 100 ABCDEFGH ABCDEFHI 120 H ║ ║ 1000 ABCDEFGHYZ ABCDEFGHIJ 120 H ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off The number of lines available for security level entries on this screen will directly coincide with the value entered in SECURITY INFORMATION, Frame 6 , Question seven. Each screen line should contain (from left to right) a number representing a security level; a series of message folder letters to which that level will be given access; a series of file area letters from which that level will be able to download files; the Daily Time Limit (DTL) for that level; and the ANSI color menus displayed for that level. Each of the above items will be reviewed in detail in the following discussion. The first thing to do is decide the numbers you will use as designators for your security levels. These numbers will be used in the next few screens to assign access rights for callers at each level. In our example we have established seven levels, one for locked out users (those who have virtually no access due to some action), one for new users, four for regular users, and the system operator. The actual numbers used are of no particular significance, except that access to menu choices is extended on a minimum level required basis. For example, the ability to [E]nter a message may require a minimum level of 10, which indicates all levels at and above 10 may enter new messages. This minimum level required access is NOT used in this frame when assigning message folder and download area access. For example, note that our default example screen shows security level 20 with access to message folders A, B, C, D, and E, while level 10 only has access to A, B, C, and D, with NO ACCESS to E. Each level is an individual entity, with its own unique access rights to messages and files. THE ASSIGNMENTS ARE NOT CUMULATIVE; LEVEL 10 MAY HAVE MORE FOLDERS TO ACCESS THAN A HIGHER NUMBER LEVEL, AND MAY BE GIVEN ACCESS TO ADDITIONAL FILE AREAS WHICH LEVEL 20 DOES NOT HAVE. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 54 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── OUR EXAMPLE SHOWS EACH LEVEL WITH MORE ACCESS, BUT THIS STRUCTURE IS NOT REQUIRED. AS AN EXAMPLE, LEVEL 10 MAY BE GIVEN ACCESS TO MESSAGE FOLDERS A,B,D,F, AND G WHILE A HIGHER NUMBER LEVEL AT 15 MAY ONLY HAVE ACCESS TO FOLDER B. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 55 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MESSAGE FOLDER ACCESS & DOWNLOAD FILE AREA ACCESS Enter the letters of your previously defined message folders on each line, indicating those folders to which each level should be given access. Enter the letters without spaces or punctuation, and repeat this process to assign download area access for each level. Note that extending download access in a particular file area does not automatically allow callers at that level to upload files to the specified area. Further security definition in the next screen allows you to specify where callers may place uploaded files. A few additional words of explanation are in order here to prevent possible confusion. In the example above, access is granted to levels one and five to place messages in the Z folder which contains the Comments to the system operator. This access allows those callers to use the main menu [C]omments choice and for the sysop to place his replies in the Z folder for reading on the user's next call. Each level with Z access is also permitted to leave comments to the system operator from the message menu when entering a message by electing to save the message to the Z folder. All mail entered as [C]omments from the main menu are private, although messages from the message menu may be saved in Z by the caller as a public message, if desired. All levels with access to Z can also read mail placed in the Z folder by themselves or others, provided it is not private mail. DTL The caption DTL stands for Daily Time Limit, and sets the total number of minutes a user at the specific security level may be connected during a day. The number of minutes set for DTL may be split during any number of calls during the daily period, with the maximum PER CALL controlled by your answer to SYSTEM CONFIGURATION, Frame 8, Question 4. ANSI The final field, ANSI, relates to the COLOR (.SCR) available within WILDCAT!. Prior to entering any values here, a short discussion of menus is in order. There are four basic menus within a WILDCAT! system; MAIN, MESSAGE, FILE, and SYSOP. By default, when a caller reaches a menu prompt WILDCAT! examines the caller's security level and dynamically generates ONLY the choices to which the caller has access. Callers will not even know about menu functions to which they have no access. This dynamic menu generation is the default in WILDCAT!, but the Sysop may also allow the use of color menus. If you are offering color ANSI menus you must create .SCR menus. Since ANSI color .SCR menus are simply disk based files, if we have only one for the MAIN, MESSAGE, FILE, and SYSOP menus it must contain all menu choices. This is not really acceptable since our goal is to present callers only with choices to which ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 56 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── they have access based on their security level. Therefore we allow the sysop to create not one, but 3 different .SCR color menus for each of the MAIN, MESSAGE, FILE and SYSOP menus. The first of these three menus might be designed for a low security level such as 5, and would display only a those functions available to level 5 as defined later in MAKEWILD. Another may be designed for level 10 and would include all of the menu choices defined for level 10 in the dynamic menus. These menu files must be created by the Sysop, and should reflect the keypresses needed for each menu function as defined for the dynamic menus. Using the main menu as an example, the ANSI color menu files are named MAINLO.SCR through MAINHI.SCR, with the letters LO, MD, and HI differentiating each version. A sysop making use of ANSI color menus must become familiar with the creation and maintenance of text files containing the ANSI color codes. The section Display Files Used by WILDCAT! reviews the procedures for proper generation and naming of these files in depth. The ANSI menu field on this screen is used to indicate which of the 3 possible ANSI color menus will be used for each security level when a caller is using non-dynamic menus. If a user is supposed to receive one of these menus, WILDCAT! will attempt to locate the appropriate version of the menu for display. If the properly numbered menu file does NOT exist in the menu area, WILDCAT! will post a notice in the ACTIVITY.LOG and display the correct dynamic menu instead. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 57 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DEFINE YOUR SECURITY LEVELS Con't The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ DEFINE YOUR SECURITY LEVELS Con't Frame 16 ║ ║ Sec UPLOAD File Area Access DL's <- Maximum -> DL Bytes ║ ║ ---- -------------------------- ---- -------- ║ ║ 1 0 0 ║ ║ 5 J 5 300000 ║ ║ 10 ABCDFJ 5 500000 ║ ║ 20 ABCDFJ 10 500000 ║ ║ 50 ABCDFHIJ 10 1000000 ║ ║ 100 ABCDFHIJ 100 2100000 ║ ║ 1000 ABCDEFGHIJ 100 2100000 ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off You have previously defined the number of file areas for your system in SYSTEM CONFIGURATION, Frame 8, Question 2, and the file area descriptions in the File Path Definitions section. Each screen line here should contain (from left to right) a number representing a security level (using the same numbers as the previous screen); the file areas to which each level will be granted upload privileges; the maximum number of files that may be downloaded per day and the maximum number of Bytes that may be downloaded per day. UPLOAD FILE AREA ACCESS In the previous screen you specified the file areas from which each security level may download files. You may elect to allow callers the ability to place uploaded files in all these areas, or may instead limit uploads to only a few areas. The ability to restrict uploads to a particular area is a powerful feature that could save the system operator a considerable amount of maintenance time if properly implemented. Some system operators may prefer to place all uploaded files in an area of their choosing rather than allowing the uploader to possibly select an improper area. Others may want to test all uploads prior to making them available for downloading by other users. This is very easy! Assign a particular area as UPLOADS (or other wording); force all users to upload to that area only; and do not permit downloading from that area regardless of user level. The Sysop can then make use of the file database [M]atch function to quickly review only the files in the upload area and move the files to the correct areas after his review. DLs & DL BYTES ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 58 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The second part of this screen addresses the controls associated with downloads by each security level. The Sysop may specify maximum number of downloads permitted per day and the maximum Byte count allowed. If a value of 5 is entered in the DL's column, a caller at that level will be permitted to complete five downloads during a day, but will be prohibited from requesting a sixth. Likewise, if a value of 10000 is entered in the DL Bytes column, a caller will be allowed to proceed with a download request as long as the size of the current file request, when added to his current daily download Byte count, does not exceed 10K. Keep in mind that downloads will be disallowed as soon as a user reaches EITHER of these maximums. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 59 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILE PATH DEFINITIONS The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 17 ║ ║ FILE PATH DEFINITIONS ║ ║ ║ ║ File Area File Area ║ ║ LTR Path LTR Path ║ ║ - ------------------------------ - ------------------------------ ║ ║ A C:\WILDCAT\UTIL B C:\WILDCAT\COMM ║ ║ C C:\WILDCAT\DBMSWP D C:\WILDCAT\TURBO ║ ║ E C:\WILDCAT\MUSTANG F C:\WILDCAT\GAMES ║ ║ G C:\WILDCAT\BBS H C:\WILDCAT\BETATEST ║ ║ I C:\WILDCAT\ALPHATES J C:\WILDCAT\SPECIAL ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off The number of file paths shown on this screen correspond to the number of file areas requested in SYSTEM CONFIGURATION, Frame 8, Question 2. For the file area letter you must specify the path to locate the files in that area. In this example, all file paths are sub-directories below WILDCAT. This makes tracking your files easier, since everything concerning the bulletin board system is now in the same area of your hard drive. You may at your option place the directories anywhere you wish, including the root directory and/or another drive! For example, suppose you wanted all new uploads to go to a subdirectory named NEWFILES located directly below your root, all you would have to do is change the path for file area E above as follows: Before change C:\WILDCAT\MUSTANG\ After change C:\NEWFILES\ MAKEWILD will not check paths specified on this screen at the time of entry. If the path does not already exist it must be created prior to using WILDCAT!. Subdirectory creation is done from the DOS level. For additional information on setting up file paths, consult your DOS manual. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 60 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── EXTERNAL PROTOCOL DEFINITION The following is a screen representation: ╔════════════════════════════════════════════════════════════════════════════╗ ║ Frame 18 ║ ║ EXTERNAL PROTOCOL DEFINITIONS ║ ║ ║ ║ LTR Name Up .BAT Dn .BAT Batch ║ ║ - ------------ ----------- ------------ - ║ ║ ║ ║ ║ ║ ║ ║ If you wish to define External Protocols you must select the number ║ ║ of protocols you want to support in Frame 8 first! ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ F1 Returns you to the Main Menu, PGup & PGdn Advances the Page Insert Off If you wish to define External Protocols you must select the number of protocols you want to support in SYSTEM CONFIGURATION, Frame 8, Question 3. Briefly, external protocols make use of batch files outside the WILDCAT! program to execute a transfer program written by another company. This section establishes the batch file names which are called for each protocol. LTR The LTR column refers to the keypress which will activate the file transfer for each choice. The obvious choices are phonetic such as K for Kermit, Z for Zmodem, etc. Letters which conflict with internal file transfer choices are not allowed to be entered. Up.BAT & Dn.BAT These two fields should be filled out with the names of the batch files used for Uploads and Downloads. The UP.BAT filename will be executed whenever a user asks to UPLOAD a file to your system, and the DN.BAT will be executed whenever a download is requested. Batch The batch choice relates to the ability of the protocol to transfer multiple files with one request. If the protocol has this ability this field must be set to Y to enable multiple transfers. This is an advanced feature and is not a part of all externally written protocols. If set to yes, WILDCAT! will allow up to seven filenames to be entered for a single download request, providing the user's daily download count and Byte limit have not been exceeded. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 61 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── If you are not quite ready to tackle the setup of external protocols, you may leave this section blank and still have access to WILDCAT!'s internal transfer protocols. For details on the setup and use of External Protocols see the Advanced Features section. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 62 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── AFTER MAKEWILD You have completed the setup program and WILDCAT! is ready to run and take it's first call. You may very well find that some fine tuning is in order and you are encouraged to make changes to MAKEWILD as needed. COMMAND LINE SWITCHES WILDCAT! TEST-DRIVE may be started with a number of command line switches to enhance its operation. Several relate exclusively to NetMail operation, and are discussed in that section of the manual. Several others will be addressed here. WILDCAT!'s overlay file (.OVL) is normally kept in the same drive and subdirectory as WILDCAT.EXE, and most users can simply leave it there. If your system has Lotus-Intel-Microsoft (LIM 4.0) Expanded memory or AST's Enhanced Expanded memory with REMM.SYS installed, WILDCAT! will automatically copy the overlay file to expanded memory and access it from there rather than from disk. This process is automatic, and requires no action on the part of the sysop. In the event that you want to prevent this use of expanded memory, begin WILDCAT! with the command line switch /NOEMS. Another switch adjusts the amount of conventional memory used to hold overlay file code as the program needs it. By default WILDCAT! allocates 30K (30,000 bytes) of conventional memory to swap in portions of the overlay file from either disk or EMS. Increasing this number results in WILDCAT! taking up more conventional memory from your 640K, but having faster access to the procedures in the overlay file since more of them reside in memory at all times. You may increase the overlay buffer up to the maximum size of the overlay file which would place the entire overlay in conventional memory. An example is /M 60000 which would place 60K of the overlay file in conventional memory. IF YOUR HAVE EMS THERE IS NO NEED TO MAKE USE OF THE /M SWITCH SINCE WILDCAT! WILL USE THE EMS FOR THE OVERLAY CODE. STARTUP WILDCAT! should always be started with a batch file, such as the CAT.BAT example supplied with the program. Go to the WILDCAT! directory and type CAT to begin the CAT.BAT file and start the program. After the modem initialization is completed you should see the "waiting for calls" screen, and WILDCAT! is ready to take its first call. Before you embark on your first connection, take a minute to logon locally as the SYSOP and check the system out. Press the F1 key which begins a local logon using the first and last names specified as for the sysop in MAKEWILD. WILDCAT! will automatically enter your first and last names and then ask if you ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 63 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── are a new user. It may seem unusual, but at this point in time you are a new user since your name isn't yet in the user database. Answer "Y" and continue to answer the prompts until you have reached the Main Menu. NOTE: Your response to the password prompt is VERY IMPORTANT! Do not use the same password you use on other systems and DO NOT use simple names and phrases. In particular, refrain from using names of your children, spouse, pets, initials, or any other words which are commonly known to be associated with you. Remember, this one word is the key to YOUR ENTIRE COMPUTER SYSTEM! The best passwords combine numbers, letters and punctuation, and consist of more than 7 characters, such as JM5S7)HP. If that's too much for you to handle, try 2 unrelated words of 4 or more characters separated by punctuation such as AUTO$TIMBER. Once your login is complete and you have reached the main menu IMMEDIATELY use the F9 key to upgrade your access level to that of the MASTER sysop. You may then continue with the system logon or simply logoff and await your first call. If you intend to configure WILDCAT! as a closed system, you should now return to MAKEWILD and change it to indicate your preference. Remember, you may not set the program up as a closed system until AFTER you have logged on once and set your access to that of sysop! Due to the number of configurable parameters within WILDCAT! and MAKEWILD, we encourage new sysops to check out each available menu choice for each security level. The easiest method of performing such a check-out is to use the ALT-L command to logon locally under an assumed name such as TEST USER. Check each menu carefully. Once you have determined that the new user security level is set up properly, use the F9 key to change to the next highest level you have assigned. Again, review each menu choice at this new level for oversights or omissions. Repeat this upgrade and test procedure for every security level available on your system. Remember to delete TEST USER after testing is completed. Now is a good time to mention that the SPACEBAR may be used by the caller or the local sysop to stop the screen output of any WILDCAT! display file or menu, even the dynamic menus. Just keep it in mind. Your BBS is now operational, and will begin counting the number of calls received. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 64 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Keyboard Control Keys F1 System operator local logon. This key is used for logging onto the system from the local console, and automatically displays the SYSOP's name as defined in MAKEWILD. Use of this key will cause WILDCAT! to skip the HELLO screens and continue to the Bulletin menu prompt. The resulting logon is otherwise identical to use of either ALT-L or a remote access. This function may be initiated even while a caller is online, an will take effect after the current call is completed. The sysop is notified with an audible series of beeps. Note: The first time this function is used after system startup, the SYSOP is considered a new user since the name has not yet been entered into the user database. F2 DOS next. [SUPPORTED IN REGISTERED USER VERSION ONLY] This key is used while a caller is connected and the sysop wants to terminate the BBS after the caller logs off. A flag indicator appears on the status line at the bottom of the screen, and remains until the caller says goodbye. At that time the BBS stops running and returns to DOS, placing a busy signal on the line if previously instructed to do so in MAKEWILD. As the system is returned to DOS a distinctive series of beeps is played on the computer speaker to advise the sysop that the BBS is now down. F3 Printer on/off toggle. When toggled on, the printer will track of user's movements and activities while on the system. This same information is also recorded automatically in a file called ACTIVITY.LOG whether the print function is on or off. The program automatically checks printer status and if unavailable will toggle the F3 key off. F4 Page hour override on/off toggle. When ON, the SYSOP is indicating that he will accept pages from on-line users even if the current time is outside of his paging hours as set in MAKEWILD. When OFF, the page function either pages the sysop or informs the user that the sysop is not available, in accordance with his paging hours. F5 Page bell on/off toggle. When the Page Bell key is ON, the system will page by beeping using the local system's speaker. If toggled OFF, the speaker is silent and a screen display of the page request is the only notice given to the local system. F6 Screen writing on/off toggle. If screen writing is toggled off, the local monitor does not echo the connection activities. A screen notice indicates who is online along with a brief description of their activity at the moment. We strongly recommend that screen writing be turned OFF when ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 65 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── there is no need to monitor a caller's activity, especially on slower PC/XT systems. Processor resources needed to constantly update the screen can cause significant reduction of throughput to your callers. This toggle is especially useful when running WILDCAT! under a multi-tasking environment such as DESQView, where processor use is of utmost importance. F7 Start local chat with user or answer page. Used to begin a local chat session with the online caller, or to answer a page from the caller. F8 End local chat or page. Used to end local chat, regardless of whether it was started from a page or initiated by the sysop with F7. F9 Online user upgrade. When F9 is pressed while a user is connected to the system, the local screen displays a listing of defined security levels. The local operator is prompted to enter a new security level for the caller, which goes into effect immediately and becomes permanent. One of the first things a new system operator must do after logging on the first time is to use F9 to set his security level to that of the MASTER sysop as defined in MAKEWILD. Note: Although the user has the benefits of the upgrade during the current logon, the level is held in a temporary buffer and does not get written to the user database until the user logs off. If the user disconnects, drops carrier or otherwise terminates the current logon without exiting via the [G]oodbye option, the user's previous level will still be the default at any subsequent logon. F10 Terminate WILDCAT! This function may be considered the off or exit switch. It is active only during standby mode, not when a user is currently online. Just in case the key may have been pressed accidentally, a prompt is presented to double-check whether you really wish to quit WILDCAT!. Use of F10 to exit WILDCAT! sets the errorlevel to 0, enabling batch file branching. See the section on batch files in Advanced Features for additional information. The following keys, ALT-1 through ALT-0 result in the display of selected ASCII text files created by the sysop, if desired. The contents of each file is displayed both locally and to the caller when the corresponding ALT key command is invoked. ALT-1 Posts message ALT1.BBS to user; logs user off. ALT-2 Posts message ALT2.BBS to user; logs user off. ALT-3 Posts message ALT3.BBS to user; logs user off. ALT-4 Posts message ALT4.BBS to user; logs user off. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 66 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The user log-off resulting from issuing ALT-1 through 4 is temporary. The user may call back immediately providing the system is available. One of these four keys might be used to send a message to a caller indicating that he is being logged off automatically to allow you to perform some unscheduled maintenance that can't wait. ALT-5 Posts message ALT5.BBS to user. ALT-6 Posts message ALT6.BBS to user. ALT-7 Posts message ALT7.BBS to user. ALT-8 Posts message ALT8.BBS to user. ALT-9 Posts message ALT9.BBS to user. The use of ALT 5 through 9 does not cause the user to be logged off. One of these messages might be used to inform a caller that his time available was being reduced to 15 minutes to enable you to perform some maintenance. Another use would be as a standard response to be placed inside a message as you were entering it. ALT-0 Posts message ALT0.BBS to user, logs the user off, and locks the user name out of system for any future calls. (Note ZERO, not the letter O) Caution: The status caused by the use of ALT-0 takes effect immediately, and prevents additional logon under the user name. The locked out condition may only be reversed manually by the system operator by editing the user's record. ALT - (minus) Immediately disconnects the user with no warning, and no GOODBYE.BBS file. It is abrupt. ALT-D Drop to DOS (shell or exec call). This selection may be used while WILDCAT! is waiting for calls or while a caller is online. It attempts to leave WILDCAT! suspended in memory while invoking a second copy of the DOS Command processor (usually COMMAND.COM). If executed while waiting for calls, no calls can be answered while in the DOS shell, and if a caller was online that caller can do nothing but wait for your return. In order to operate properly the system must have enough memory to support both WILDCAT! and the second DOS shell. If there is insufficient memory for the shell to be invoked, WILDCAT! will inform the local operator and ignore the command. Once successfully enabled, the screen is cleared and the normal DOS prompt appears. Most DOS commands and programs operate properly, but remember that memory may now be ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 67 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── significantly limited. MAKEWILD should NOT be run from a DOS shell. After you have finished with your DOS session, type EXIT to return to WILDCAT! The DOS prompt is altered during the shell to remind you to type EXIT to return. You may type EXIT from any subdirectory on your WILDCAT! drive since the home path is automatically restored by the program. Be careful not to re-start WILDCAT! with CAT.BAT since it will load a second copy of the program when there is already one in memory!!! ALT-K Toggles keyboard on/off. When toggled ON, the sysop has the ability to enter keystrokes from the local console which are accepted by WILDCAT! as if they were entered by the caller. The default is OFF. This toggle is automatically set to ON when a local page is answered and when logging in locally with F1 or ALT-L. ALT-L Local logon. Similar to F1, this function is used for testing purposes or to allow local users other than the sysop access to the system. It allows the system operator to logon under any user name, along with the ability to see and test the top end procedures, such as the questionnaire, bulletins, and other information that a new or remote user would normally see, but which are by-passed when using the F1 function. It may be toggles even while a user is on-line and the sysop will be notified when the system is available with a series of beeps. ALT-W Full screen/status line toggle. Toggles window between full screen (user view) and having user status lines displayed at bottom of screen. Remember that whenever you make use of the two user status lines, your local screen will lose the top two lines of text that the connected user still has on his screen. HOME Display help menu. This key displays an abbreviated help menu explaining the various function keys. It may be used at any time, whether the system is waiting for calls or a user is online. If used while a user is active on the system, however, the user's screen will be frozen until the system operator toggles the help screen off again with ESC. Up Arrow Increases user time online by five minutes, updating the display in the user status box (if enabled). Dn Arrow Decreases user time online by five minutes. Note: The update of the user's time remaining in the status window may not appear immediately. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 68 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILES USED BY WILDCAT! The following files are automatically generated and updated by the program. No intervention is required by the system operator. ACTIVITY.LOG The activity log file contains information which traces the user's movement while online and notifies the sysop of operational errors that may need attention. It is automatically created by the program if it does not exist. This file should be checked periodically as an indicator of the usage patterns of the system. The activity log is also the basis for statistical compilation by call reporting programs such as S-PRO!. Caution: Options are available in the system operator's reports menu for both reading and deleting this file. Do not delete the activity log while outside the code, but do check the file periodically as it can grow quite large! CONFIGWC.BBS & MENUINFO.BBS CONFIGWC.OLD & MENUINFO.OLD These files contains all the run-time information required to initialize your particular custom configuration of WILDCAT!. They are created, viewed and modified automatically by MAKEWILD and WILDCAT!. CONFIGWC.BBS contains all the MAKEWILD settings as well as the High and Low message count. It is updated after each call by WILDCAT! with the number of calls taken and new message numbers. MENUINFO describes how your dynamic menus should be displayed and to which users/security levels they apply. It too is created by MAKEWILD. ERROR.LOG The ERROR.LOG is automatically created by WILDCAT! the first time any errors are encountered. If it exists it will contain information about the error. Errors are of two basic types, SYSTEM CRASH or NON-FATAL ERRORS. A system crash indicates that WILDCAT! was unable to recover from the error, and exited with an errorlevel of 1 to be restarted with CAT.BAT. Every crash indicates when it happened, a description of the problem, and often makes a suggestion of a repair procedure. Non-fatal errors do not cause WILDCAT! to stop operating, but reflect some problem that may need attention. Explanations are given when possible. The contents are this file may prove helpful to Mustang Software in evaluating the cause of the problem. The following files comprise the User Database files: USERINFO.DAT USERNAME.IDX The following files comprise the File Database files: ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 69 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILEINFO.DAT FILENAME.IDX FILEDATE.IDX FILEAREA.IDX The following files comprise the Message base files: MSGHEADR.DAT MSGINFO.DAT MSGNUMBR.IDX MSGTF.IDX SCHED.BBS This is the name of the schedule file. This file is accessed and updated from inside code. It contains the control elements for determining which event will take place and when. This file is located in the startup directory (where the node is started and the MAKEWILD settings reside). Events are more fully explained in the section on Creating Events. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 70 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── DISPLAY FILES USED BY WILDCAT! Each of the following files may be generated by any word processor capable of creating ASCII files. Although samples of most are supplied with the program, they may need to be edited by the system operator if they are to be used on the system. All of the display files are highly customizable and may contain special characters as defined by WILDCAT!. This list will review the purpose of each file without expanding on the tailor-made possibilities. See the section Custom Display Files which follows for tips and techniques to enhance the display files used on the system. Most display files may be of two types, ,non-color and those containing ANSI color codes. The standard extension for non- color files is .BBS while color uses .SCR During the following discussion the tag ".SCR" indicates the file is also available in color ANSI mode with the .SCR extension. Note that although your distribution diskette has an example of most files, it does not contain an example of every .SCR version. AFTERDOS.BBS This file is displayed to a caller after the sysop has returned from a local Drop To DOS using ALT-D. When ALT-D is pressed the caller is sent a message indicating that the sysop has dropped to DOS temporarily. When the sysop types EXIT to return to the session, the file AFTERDOS.BBS is displayed to the caller. ALT5.BBS through ALT9.BBS (.SCR) The text associated with these files is sent to the user when the ALT key is pressed along with the associated number key. The use of this group of files is optional. If one or more of the files is not found in the WILDCAT! sub- directory, the function associated with that particular key will simply not work. If found, each selection will deliver the previously written message contained in ALT#.BBS to the online user. The files may be of any length, but would typically be one sentence or paragraph. Each of these files is for the exclusive use of the system operator while at the local (non-remote) console. Each selection allows the system operator to display or dump the contents of the associated ALT#.BBS file to the user. For example, suppose you had previously created the following message using your word processor and named the file ALT5.BBS, and pressed ALT-5 while a user was at the Main Menu prompt: By pressing the ALT and 5 (not ALT-F5) keys, this message would have scrolled to the user who happened to be online at the time. These files will interrupt any process except uploading and downloading. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 71 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── ALT1.BBS through ALT4.BBS (.SCR) These files are similar to the ALT5.BBS through ALT9.BBS files, and are also optional, with one important difference. Upon completion of the file dump to the user, the user will then be automatically logged off the system. These are useful for a number of reasons. Perhaps the user in the example above failed to complete his activities, and appeared to have no intention of doing so. One of these keys would take care of the situation. Caution: The keys ALT-1 through ALT-4 are functional whether or not the associated file is found. If the ALT# key is invoked, and a corresponding file does not exist, the user will simply be logged off without a warning message, just as if the [G]oodbye menu option had been selected. ALT0.BBS (.SCR) The ALT-0 (zero) option works with a file called ALT0.BBS. This option is listed separately, since its function is to: Scroll the file to the user; Immediately log-off the user; LOCK OUT the user (prevent subsequent logons). Caution: This option will log-off and lock out the user whether or not the related file name exists, and also writes the locked out condition to the user database. The user is denied any further logons to the system. The status of the user may only be reversed by the system operator by entering the user database and manually toggling the locked out status of the user. For this reason, be careful in the use of this option. BADLIST.BBS Although this file is not a display file, it is created and maintained by the system operator. During logon, WILDCAT! will check this file for validity of the caller's first and last name. This is useful in helping avoid the CB handle names prevalent on many boards, if they are not desired. Each line of the file must contain a single name followed by a carriage return. Suppose the first few lines of BADLIST.BBS contained the following data: dude mrs. doe code bad cracker john When a user enters his or her first or last name, WILDCAT! quickly scans the BADLIST.BBS file for a match. The search is insensitive to case. Since this is another security device, a little extra attention will be spent on this ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 72 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── subject to assure your understanding of the procedure. Let's explore the benefits and possible short-comings of the sample listing above. Good - Any user who's name was Code Cracker or Bad Dude would be immediately logged off the system, without being permitted the chance to register, and without being written to the userlog. A record of the failed logon event will be written to the ACTIVITY.LOG or sent to the printer (if available). Good / Bad - A user who enters +++ (which is the standard modem attention command code) will also be logged off. The user may have done this in complete innocence, due to keystrokes intended for their own modem. On the other hand, it could be a potential board buster who's trying to take control of your modem and damage the system. This situation is not really a concern since the standard modem setup strings include a command to disable the +++ command (S2=255). Bad - Users with the names John Doe, James Code or Mrs. Abrams would also be logged off the system as mentioned above. This includes those users whose real name happens to be John Doe, etc., and worse, any user who's first or last name is John. Make your list with this in mind! BADNAMES.BBS This file is sent to any user whose login name is found in BADLIST.BBS, prior to logging them off. BEGCHAT.BBS (.SCR) This is the BEGIN PAGE display file. WILDCAT! by default prints a brief statement when the system operator answers a page or enters page chat, to introduce this activity to the user. BEGCHAT.BBS is an optional ASCII file which may be used to change the message scrolled to the user when CHAT is invoked. The code first looks for the BEGCHAT.BBS file, and if not found, scrolls the built-in default statement to the user. BIRTHDAY.BBS (.SCR) This file is displayed IF the user calls on the anniversary of the date entered as date of birth in the user file record. BULLETIN.BBS (.SCR) This file is in effect a sub-menu. It is displayed when the[B]ulletins option is selected from the main menu. This file should contain a listing of available bulletins, including the bulletin number, and a brief description of the contents of the associated bulletin. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 73 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The bulletin number listed in this file and description the bulletins must agree with both the number and content of BULL#.BBS, described below. BULLET#.BBS (.SCR) The # is the bulletin number, i.e. BULLET14.BBS would be bulletin number 14. The actual bulletin is an ASCII file of any length. WILDCAT! will handle the appropriate screen pauses. The value of # must agree with the numbering and description given in BULLETIN.BBS, and the total quantity of bulletins must agree with the value entered in MAKEWILD. CLOSED.BBS This is the file which is displayed in the event you have elected to run a closed system. The file will be displayed prior to taking the action defined in MAKEWILD. COMMENTS.BBS (.SCR) This file is displayed to a caller after electing to leave a comment to the sysop on the main menu. It might consist of a short notice reminding a user of the information required in a comment for proper registration, etc. DLIMIT.BBS (.SCR) This name stands for download limit, and is sent to a caller when denied access to a download due to already reaching the download limit for # of files. DLKLIMIT.BBS (.SCR) Download K limit is sent to a caller if a download request would cause the user to exceed the download K-byte limit as specified by security level. DOWNLDOK.BBS (.SCR) This file is displayed immediately following every download, if successful. It may contain any information you desire, so let your imagination run wild, especially after reading about custom displays later on! But considering where and how often it is displayed, the size of the file should be kept as short as possible and still convey your message. DROPDOS.BAT This batch file is located in the startup directory, and contains the commands to execute a remote drop to DOS. See the section Advanced Features for detailed creation instructions. ENDCHAT.BBS (.SCR) This file follows the same conditions as BEGCHAT.BBS, the difference being that it is scrolled to the user when the PAGE mode is terminated. EDITMSG.HLP ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 74 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Displayed when [?] is selected when editing messages. FILES.SCR and FILESLO.SCR through FILESHI.SCR This is the first example of a color menu display file. Color ANSI versions (.SCR) will not be required unless the sysop is offering color ANSI menus. If Color ANSI menus are being offered, the sysop must create FILE MENU ANSI text files ending in .SCR that exactly match the menu choices indicated in MAKEWILD. As you recall from the MAKEWILD discussion of security level assignments, you may specify up to three different menu files for each security level. These different menu files are designated by LO, MD, and HI. The menu file without LO, MD, or HI (FILES.BBS) is only used if a proper menu file is not found. The sysop must make sure that the appropriate menu file contains the appropriate menu commands that are desired for the security level assigned to that menu. Check the MAKEWILD screen for Frame 15 to refresh your memory as to the assignments made for each level. FILES.HLP The non-color help file for the FILE menu. The text in this file should match the menu choices used by the menu file. Modification may be necessary if any menu selections are changed within MAKEWILD. This caution is in order for all .HLP files on the system. FILESC.HLP Color version of File menu help file. GOODBYE.BBS (.SCR) The GOODBYE file is scrolled to the user just prior to logging off from the system. Although it may be of any length, it is recommended that it just contain a brief Thank you for calling... or equivalent. Otherwise a lengthy closing statement may cause a user to just hang up instead of logging off properly. This file is also optional, since WILDCAT! contains a hard-coded log-off statement. HELLO1.BBS through HELLO3.BBS (.SCR) This series of display files (one to three) is used to display your system's welcome messages. They may contain a logo, system information, or whatever you want to send to callers as they log in. They typically contain either text or ASCII characters, or a combination of both. The text might indicate the name of the board, perhaps the name of the system operator, date of origin, or other information that you wish to offer to distinguish your board from other boards. Consider them your show off screens. All 3 hello screens need not be used, and they may be added, updated, ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 75 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── and deleted as needed. The .SCR color versions are especially popular and allow for unlimited creativity. LASTCALL.BBS Created by WILDCAT! after each call and contains the name of the last caller (same as embedded code ^S^L). MAIN.HLP The non-color help file for the MAIN menu. MAINC.HLP The color help file for the MAIN menu. MESSAGE.SCR, MESSAGEL.SCR, MESSAGEM.SCR, and MESSAGEH.SCR The MESSAGE menu display files. See the full explanation of text color menu files under FILES.SCR MESSAGE.HLP The non-color MESSAGE menu help file. MESSAGEC.HLP The color help file for the MESSAGE menu. NEWSLTR.BBS (.SCR) This file coincides with the menu option called [N]ewsletter. It may contain text information other than a newsletter, but regardless of the contents of this file, or the menu title or prompt as a result of renaming the option, this file must always be named NEWSLTR.BBS in the directory in order for WILDCAT! to implement the function. NEWUSER.BBS (.SCR) The NEWUSER.BBS file is just what the name implies. The file is scrolled to a user only one time ever, that being the first time the user calls the system. Actually, during run-time the caller's name is compared to those contained in the user database, and if not found, WILDCAT! assumes the caller is a new user. This is mentioned for two reasons: In the event that a user is deleted from the system (for whatever reason), upon subsequent logon the system would treat that user as if he or she had never called before; As additional system security, WILDCAT! permits no more than one first/last name combination to appear in the user database, even if the users have totally different passwords. Here is an example of what would happen: First caller, a "regular" user, logs on, using the name "Jim Coleman". The system accepts this, then requests Jim Coleman's password. Then another "Jim Coleman" logs on. The WILDCAT! system then expects the password ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 76 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── of the first Jim Coleman, which of course the second caller does not know! The second Jim Coleman must then use a variation of his name (usually first name) to establish a separate identity for him. In this case, changing his first name to "James" would provide the necessary difference to establish his identity. While this situation is rare, it has happened, and it is mentioned here to make you aware of the potential and how to circumvent it. NO300.BBS (.SCR) If 300 baud users are excluded from the system as specified in the MAKEWILD configuration, the contents of the NO300.BBS files is scrolled to the caller immediately after logging on to the system. If this file is not found, a brief message is hard-coded into WILDCAT! which indicates to the caller that 300 baud is not permitted. PAGED.BBS (.SCR) The PAGED.BBS file is scrolled to the user under one of several conditions: KEYBOARD SWITCHES Page Off/Bell Off PAGED.BBS is displayed if a page is requested and there is no answer during office hours , or if a page is requested outside of the office hours. Page Off/Bell On Same as above but "beep" is heard if paging is done. Page On/Bell Off System Operator is paged regardless of the hour, (no "beep" heard), and if system operator fails to answer page, PAGED.BBS is displayed. Page On/Bell On System Operator is paged, (with audible "beep"), and if system operator does not toggle the page mode, PAGED.BBS is displayed. PREDOWN.BBS (.SCR) Displayed after a caller has requested a download, before any information about the transfer is requested. PRELOG.BBS PRELOG is displayed by WILDCAT! after each connection, immediately after the System ID and before asking for the caller's name. You may want to make this file uninterruptable by embedding a CTRL-C command at the beginning. See the section Additional Information on Files which follows for details. PREUP.BBS (.SCR) ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 77 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── This file is displayed after a user selects the [U]pload a file command from the file menu. It may be used to indicate the SYSOP's rules or preferences, such as only compressed files or "No Games". PROTOCOL.BBS Displayed when a new caller is asked to select their default protocol at initial logon, as well as when a current user asks to change the default protocol via the main menu. It may be altered to suggest a particular protocol. PROTOCOL.HLP The help file displayed to users requesting additional help with upload and download protocols from within the file menu using the command [F]ile transfer information. QDONE#.BBS (.SCR) These files consist of text and are displayed to the user upon completion of a questionnaire that matches the #. They must be created by the sysop if used. QDONECLO.BBS (.SCR) This text file is displayed to the user after completion of the QUESCLOS.BBS questionnaire. QSEC#.BBS (.SCR) Short for "Quick SECurity display file", this is an ASCII text file associated with a specific security level (#). This particular file is displayed only to those users whose security level match the value of "#", and only on the first call after the particular QSEC#.BBS is created. This is accomplished by displaying the file ONLY if the caller's last logon date precedes the file date of QSEC#.BBS. Example: If your regular users have a security level of "40", a file named QSEC40.BBS (if it exists) is displayed if the caller has not received it before. This file is not erased by the system, but rather is repeated for any callers meeting the criteria. Keep in mind that QSEC#.BBS will not display for any users whose security level is upgraded from one level to another due to the test for QSEC#.BBS file date. QUESCLOS.BBS This is the questionnaire file which is presented to a new caller IF the system is set up as a closed board and the closed board questionnaire is selected in MAKEWILD. The answers are in QUESCLOS.ANS. See Appendix F for additional information. QUESTION.BBS (.SCR) ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 78 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── This file is the text menu file which lists the questionnaires available on the system. It is created and presented in the same manner as the BULLETIN.BBS file and, in the REGISTERED VERSION, the DOORS.BBS file. QUES#.BBS These files are the questionnaire files generated by MAKEQUES.EXE. They may only be read and manipulated by the WILDCAT! code. The # is replaced by the appropriate number of the questionnaire as reflected in the QUESTION.BBS file. A later section contains complete instructions for the MAKEQUES program. QUES#.ANS These file(s) contain the user's typed-in responses to the QUES#.BBS inquiries. The file is automatically created by WILDCAT! if it doesn't exist, and is also appended by the code. These files may be manipulated by any word processor or, in the REGISTERED VERSION, the Q-PRO! utility. All answer files are located in the home path, where the MAKEWILD settings reside. QUESNEW.BBS This is the questionnaire file which is presented to every new caller to the system IF the new user questionnaire is selected in MAKEWILD. The answers are placed in QUESNEW.ANS. QDONENEW.BBS (.SCR) This display file is sent to users after completion of the QUESNEW.BBS questionnaire. QUOTES.BBS WILDCAT! expects to find this file if the QUOTES option is implemented in MAKEWILD. If not found, WILDCAT! will continue to run, but will generate an error message to the user and to the activity log. QUOTES.BBS is different than other display files, so some additional explanation is in order. The following criteria must be observed when creating the file: . The file may be created with any ASCII word processor; . The file may be of any length; . The first entry must begin on the first line of the file; . A particular quote may contained any number of lines, with each quote being separated by two consecutive carriage returns. Here is an example of the QUOTES.BBS file: This line is quote #1 <<C/R>> ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 79 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── <<C/R>> These lines are quote #2, and regardless of the length of the line would be displayed until two consecutive carriage returns are encountered.<<C/R>> <<C/R>> This is quote #3. <<C/R>> <<C/R>> ... and so on for the length of the file. During the first actual running, WILDCAT! is initialized with a pointer to the first record in the QUOTES.BBS file. Thereafter, during each new logon, the user is presented with the next sequential quote in the file. In other words, if your board receives 50 calls a day, and you have 50 different quotes in your QUOTES.BBS file, each caller would receive a different quote. Starting with the 51st caller, the file would recycle to the first quote in the file. The quote pointer is saved after each call and is reinitialized when started after a re-boot. RATIO.BBS (.SCR) The contents of RATIO.BBS will be displayed to the caller when the user's upload to download ratio has been exceeded. This ratio is set in MAKEWILD. SEC#.BBS (.SCR) Another ASCII text file, these particular file(s) are displayed only to those users whose security level match the value of "#". Example: If your regular users have a security level of "40", a file named SEC40.BBS (if it exists) is displayed before anything else after logon. This should be considered a special bulletin for a select group of users, and is displayed during every logon unlike QSEC#.BBS which is only displayed one time. SECERROR.BBS (.SCR) This file is displayed to a caller who fails to properly answer the verification on either birthdate or phone number. The default text asks the user to correct his user settings if the system records are incorrect. It is sent just prior to forcing the caller to the comments area for an explanation. SYSOP.SCR, SYSOPLO.SCR, SYSOPMD.SCR, and SYSOPHI.SCR The SYSOP menu color display files. See the full explanation of color menu files under FILES.SCR SYSOP.HLP The non-color help file for the SYSOP menu. SYSOPC.HLP ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 80 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The ANSI help file for the SYSOP's menus. UPLOADOK.BBS (.SCR) This file is similar to DOWNLDOK.BBS mentioned previously, except that it is displayed immediately following every upload. As in DOWNLDOK.BBS, it may contain any information you desire. USER#.BBS (.SCR) Refer to SEC#.BBS for usage syntax. Unlike the SEC file, however, the USER# file (if it exists) will display the contents of the file to an individual user whose record number in the user database (top of the screen) agrees with the value of "#". For example, assume that: 1. A user named "Rick Hartley" existed as a caller on your board; 2. A review of the user database indicated that Rick Hartley's user number was "123". 3. A file named "USER123.BBS" was created in the WILDCAT sub-directory; Then, during Rick's next logon, whenever that might be: 1. USER123.BBS file would be displayed to Rick (only); 2. A memo is recorded in the activity log (and printer) that the file USER123.BBS had been delivered; 3. The USER123.BBS file is then erased. Note that running FIXUSERS on the User database will cause the user record numbers to be reassigned. If this feature is used, the numbers must be checked if a database repair is completed. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 81 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Additional information on files ANSI COLOR WILDCAT! has the ability to include color and simulated animation in most display files by use of the ANSI color rendition codes. Under normal circumstances a computer system must be instructed how to interpret these codes by a configuration command placed in the CONFIG.SYS file. This setup is NOT required with WILDCAT! since an ANSI driver is incorporated into the code. ANSI files may be created with most text editors or word processors which can handle plain ASCII text, and can also place the ESC character (ASCII 27) into text. The codes to use for various colors are found in the appendix to older versions of DOS (prior to 2.0), and a subset is included in Appendix B of this manual for reference. The alternative to hand entering the codes into your WILDCAT! color files is to use one of a number of ANSI generators available as shareware. THEDRAW is a popular choice which was used to create many of the menus used by our own system. It provided an easy method of entering proper codes, even on a monochrome system. It is available through many public BBS systems with a nominal payment request. .BBS and .SCR Differences All display files may be created in a color ANSI version which will display in color to the caller. These files end in the extension .SCR and contain color codes in addition to text. For example, the file UPLOADOK.BBS is mentioned in the previous section with the tag (.SCR) after it indicating it may be created in color. You could create an ANSI version of this file and it would display in color. Use discretion in this matter, since it takes a lot of extra work to duplicate all of the coded specialty files, and on lesser files the results may not be worth the effort. A good rule of thumb would be to offer static files in color, static meaning those which do not change often. A "busy" file, such as a newsletter file that is updated often, would rarely be worth the effort of offering a color version. The SPACEBAR may be used to terminate the scrolling of any display file, either .BBS or .SCR, by either the caller or local SYSOP. This is mentioned here since many ANSI file take an extremely long time to complete a single display screen, and callers may want to abort such a screen. This may be overridden with a control sequence as explained later in this section. Customized Files It is also possible to "personalize" display files. The only requirement is to use a word processor that supports embedded ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 82 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── control codes such as the Norton Editor or our own MPE.EXE (Mustang Personal Editor). MPE is available for download from the Mustang Software Public BBS at no charge, and may be freely distributed. When an embedded control code is encountered in a display file during runtime, it will cause the system to extract the corresponding information from the system files. Listed below is a summary of the commands available. NOTE: Many editors are unable to produce some or all codes through keyboard entry. System Information: ^S^B Current system time (from clock) in format HH:MM ^S^D Current system date in format MM/DD/YY ^S^F Total number of files available on the system ^S^N Total messages on the system ^S^P Causes display of the -More- prompt immediately, regardless of the number of lines that have scrolled. It is ignored if the caller selects Non-stop scrolling. ^S^T Totals calls received by the system ^S^U Total number of users on the system User Information ^U^B User's birth date ^U^C User's computer type ^U^D User's total number of logons ^U^E User's time remaining this call ^U^F User's location (city, state) ^U^G User's total upload kilobytes ^U^H User's total download kilobytes ^U^J User's total number of downloads ^U^K User's first name ^U^L User's date of last call ^U^N User's full name ^U^O User's total number of uploads ^U^P User's phone number ^U^Q User's Memo date ^U^R Maximum downloads possible per day ^U^S User's date of first call ^U^T User's time on system this call ^U^V User's last [N]ew files search date ^U^W User's security level ^U^Y User's message folders joined General Codes ^G Beeps the speaker at the remote terminal only. ^C CTRL-C embedded in a file will turn off the user's ability to stop screen display. The file will scroll through to the end of the file, with page stops, ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 83 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── disabling the callers ability to use the spacebar to stop the display. When ^C is used the user will receive the appropriate page pauses, but the [S]top option will not be available. Place the Ctrl-C at the beginning of the file if you want it to affect the entire contents. ^B CTRL-B eliminates the "-More-" prompt line in display files. This would likely be used in your "fancy" graphics screens. No pauses are made. Both Ctrl-C and Ctrl-B are automatically canceled at the end of a display file, and need not be turned off unless you want the option to change back prior to the end. Some of these variables are updated during their call in the event of a dropped carrier. These are very powerful functions which when properly and thoughtfully implemented will provide additional enjoyment and assistance to your callers. ^L This code is actually the form feed character, an ASCII 12, and will clear the screen whenever it is encountered. Use it to clear the screen as the first character for any files you wish. It may be entered with many editors by pressing and holding the ALT key while pressing 1 and 2 on the NUMERIC KEYPAD. It usually displays as the medical symbol for the female, a circle with a cross on top. Note: Using ^U as an example, typing the carat (^) sign plus an "U" as "normal" ASCII text will not yield the desired results. It must be the control character represented by the key combination of your control key and the letter "U". Depending on the editor used to create your display files, control characters may or may not be represented on screen as a ^ with a letter next to it. Some editors use (sometimes curious looking) screen symbols for display purposes rather than ^. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 84 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Using MPE (Mustang Personal Editor) for codes. Although it is beyond the scope of this manual to provide detailed instructions regarding control code placement, a short explanation of control codes within the MPE program will be addressed. MPE is an ASCII editor that cannot place control codes directly into a document by simply pressing the control key and the letter. Pressing and holding Ctrl and S does NOT embed a ^S code. It can however add these codes with a special keystroke sequence which lets it know that a control code is desired. At the location in the text where a control code is wanted the user must first press Ctrl P (hold down the Ctrl key and press the letter P). This keystroke is NOT printed on the screen, but is remembered by MPE. It tells MPE that the very NEXT Ctrl and a letter is to be taken literally and placed into the document. For example, if we want to add the -MORE- prompt at a particular location we need to get TWO control codes into our text, a ^S and a ^P. First we locate the cursor at the desired position in our display file and then tell MPE that we want a control code by pressing Ctrl P. Nothing happens but MPE is now ready for the real code so we press and hold Ctrl while pressing the letter S. This Places a representation of the ^S in our text at the cursor position. Now we need to add the ^P, the second half of the needed embedded code. Again we first press Ctrl P to tell MPE to place the literal code into the text, followed by the code desired which just happens to be another Ctrl P. The second Ctrl P results in a representation of the code for ^P in the display file. If you are using MPE to place embedded codes in your ANSI color file, you should first create the files in color and then embed the codes with MPE as desired. Remember that some embedded codes take up a great deal of line space when expanded with the translated text, such as the full user name. Make space allowances accordingly. This method of placing codes into text is covered in the MPE documentation, and is also used by the Norton Editor. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 85 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Using THEDRAW (and other ANSI editors) A complete tutorial on ANSI editors is also beyond the scope of this documentation. However, there are a number of pitfalls, curiosities, and special characteristics of most ANSI editors which can be covered in this manual. Be certain to completely review the documentation to the ANSI editor in addition to this brief help file, since these comments may not apply completely to editors other than THEDRAW. When using an ANSI editor you may be given several options when saving your file to disk. If given choices you should select line lengths as long as possible, preferably 255 characters, and no clear screen (enter them with MPE). One of the most common problems encountered by new users is the creation a display file which is too long and gets a -MORE- prompt in the middle. This is due to the fact that almost all ANSI screens are saved as 25 lines, or as a screen which will fill a full monitor screen. The solution to this problem is rather simple, and consists of removing several ANSI codes from the end of the file. Here's how to do it: After completing the creation of the file in THEDRAW, you must edit it in a plain text editor such as MPE. When the file is viewed in MPE, several precautions must be taken to preserve the correct ANSI placement. The first is the margins should be set to 0 for the left and 255 for the right. You will quickly see that the color codes appear as codes and are not interpreted. The ESC character (ASCII 27) for example is seen as a highlighted left bracket ( [ ) and is followed by the actual bracket character and color codes as needed to produce the color desired. If you are unfamiliar with ANSI color codes take a look at Appendix B. The editing which needs to be performed consists of removing the ANSI codes at the very end of the display file. These codes are placed there by THEDRAW to locate the cursor on screen line 25 at position 1, an action we do NOT want. To get to the bottom of the file, use the down arrow or PgDn key to locate the last line, and then use the right arrow to go to the last character of the file. Once there look to the left and locate the last printable character that you actually want to appear to the caller. If your display file is composed of a message in a double-line border, this would be the lower right corner of the border. Place the cursor to the right of this last printable character and delete everything in the file from that point. The characters to be deleted will include a number of ESC codes (a highlighted bracket) followed by regular brackets, numbers and letters. When you have deleted the necessary characters, place a CR/LF (press ENTER) immediately after the last printable character to start a new line. Your file should now display properly. Test it with the DOS command TYPE FILE.SCR ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 86 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Other editing may now be done, including placement of embedded codes. The first thing you may want to do is place a clear screen code as the very first character in the file. Move the cursor to the first character of the file and enter a ^L. Remember, to enter a control character in MPE you first press the Ctrl key and hold it while tapping P, and then press Ctrl and the desired character. Embedded codes must always be added after a file is created with THEDRAW. If you place an embedded code in a file and then return the file to THEDRAW for color change or other editing, the embedded codes will be changed by THEDRAW. It places ESC characters in front of each code, causing improper display in WILDCAT!. Whenever you re-edit a color file you must use an editor such as MPE to check your embedded codes and delete the extra ESC codes in front of every control character. Remember, the ESC character displays as a highlighted [ in MPE, and will appear before each control code. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 87 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── WILDCAT! IN ACTION The previous chapters have dealt with system requirements, setup and file structure. We now move on to actual system operation and command structure. We will make note here that WILDCAT! will automatically monitor the "inactive" time while a user is logged in, and disconnect after 5 minutes. A warning is issued after 4 minutes. The exception is the message area where inactivity is extended to 10 minutes with a warning at nine minutes. BATCH FILE OPERATION Although WILDCAT! may be started by typing "WILDCAT" at the DOS prompt, proper operation requires that it be started from within a batch file. If the concept of batch files is unfamiliar, review your DOS manual for additional information. WILDCAT! is distributed with a sample startup batch file named CAT.BAT. Although this file may suit your needs as-is, you are encouraged to review it for proper syntax and operation within your system settings. Specifically, change the drive letter and subdirectory name in CAT.BAT to match your installation. The main advantage to batch file operation is automatic re-start of the program should power be interrupted or the program experience an unrecoverable error. In addition, some program features, such as remote drop to DOS, external events, and doors will not function without batch intervention. The most basic batch file may simply start WILDCAT! and then re- call itself, however this creates a loop from which there is no escape! At a minimum we recommend a cyclical file which calls itself, but allows escape from the batch file if WILDCAT! is terminated normally with the F10 key. The method of checking for a "normal" exit via F10 is through use of the DOS errorlevel command. An example follows: ECHO OFF prevents display to the screen CD \WILDCAT! changes to the proper directory WILDCAT starts the program IF ERRORLEVEL 0 GOTO END checks for normal exit CAT.BAT re-starts this batch file if errorlevel not 0 :END only gets here if errorlevel=0 ECHO ON end of file, turn on echo ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 88 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── When WILDCAT! is terminated with the F10 key, a DOS parameter called the errorlevel is set to zero (0) by WILDCAT!, which is the standard errorlevel for normal program termination. This errorlevel can be set to any number desired by any program when it terminates, and a batch file test may be used to determine the number and take some action. In the case above, we use the batch command IF ERRORLEVEL 0 GOTO END to tell the batch file to jump to the batch file label :END for the next command if the errorlevel is zero. If the errorlevel is not 0 (indicating an abnormal termination or error), the batch file does not branch to the :END label, but continues with the next line (CAT.BAT) which re-starts CAT.BAT all over again. If the sysop intends to make use of the remote drop to DOS, external event functions, or doors, additional batch commands must be added to work with errorlevels. These will be reviewed under the appropriate section in Advanced Features. Signing On the First Time The SYSOP may sign on by using the F1 key locally. This method of logging in bypasses the HELLOx screens and proceeds directly to the bulletin area. The FIRST time the new sysop signs on he (she) will be considered a new user since no names have been entered into the user database, which is created and maintained by the WILDCAT! program, not MAKEWILD. The sysop should therefore must proceed to answer the various questions asked of a new user, and continue to the Main Menu. Once the sysop's name is properly entered into the user database, he should immediately use the F9 key to upgrade his security level to that of the master sysop. Keep in mind that the new security level will take effect immediately, but will become permanent ONLY if a proper logoff is completed. Just as the user database has no records when WILDCAT! is started, the files and message databases are also empty. Users and messages are usually added on a continuing basis as the system takes calls, but the file database may need to be set up beforehand on many systems. We encourage you to proceed with this chapter to become familiar with the menu structure, but you may wish to establish your files database first. In the event that you have run a bulletin board program prior to WILDCAT!, a conversion program is included which will automate much of the data entry required. See "WILDCAT! SUPPORT PROGRAMS" for instructions on using the CONVERT & ADDFILES programs. Files may also be entered manually as described shortly in the Menu descriptions. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 89 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MENUS There are four major menus available in WILDCAT!, each containing a number of very straight-forward selection options. However, there are some options which are either unique to WILDCAT!, or handled differently than other bulletin board systems. The titles, prompts, text and descriptions for the various options under discussion for each menu could differ from one WILDCAT! installation to another, those discussed here represent the default WILDCAT! setup. In actual operation you may rename any menu function to your liking. MAIN MENU Since the MAIN menu is always the first encountered following logon, as well being a gateway to other areas of the system, the discussion will start here. The menu choice selections are presented in alphabetical order for easy reference, rather than the order in MAKEWILD. [B] Bulletin Menu When the B option is selected, the file called BULLETIN.BBS is displayed to the user. The Bulletin menu could be considered a sub-menu of sorts, in that it presents the user with the options of reading one or more bulletins by selecting a bulletin number, or re-listing the bulletins that are available for display, or simply returning to the calling menu, in this case the MAIN menu. If any bulletins have been updated since the user's last logon, the user will be presented a listing of those bulletins by number. [C] Comment to the sysop This choice enables users to enter a private message to the system operator. WILDCAT! makes these comments an integral part of the message base for easy reply, if desired. All comments are directed to a separate message folder (Folder Z), which means that the comment may not only be replied to, it may be moved to another message folder and made public if so desired. [F] Files Menu Presents the user with the Files Menu. [G] Goodbye & Logoff If a user's current help level is set to the NOVICE mode, using the Goodbye option gives the user a way to back out of the command, and entering this command brings up a friendly question, Are you sure you want to logoff?. If the user responds with a Y, then normal logoff procedures are begun. Otherwise, if the user enters N or just [ENTER], WILDCAT! will assume the command has been entered in error, and will return to the then current menu. Once a user has changed help levels to REGULAR or EXPERT, this extra prompt will no ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 90 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── longer be displayed. The program assumes that the user knows the commands well enough to deliberately wish to log off. The confirmation prompt may be overridden even in the novice mode of operation by entering G Y or G;Y. This method of stacking commands is available in many locations within WILDCAT, and will be pointed out where it is most commonly used. Note that command stacking may not be used with the hot key option. The Goodbye command is available in ALL major menus and performs exactly the same in each of them. [?] Help with Commands There is a help screen associated with each major menu in WILDCAT! which more fully explains the options available. Many users will select this option as a refresher course after having toggled their expert level to REGULAR or EXPERT. [H] Help Level The following sub-menu is presented: WILDCAT! supports three different levels of menu prompts. [N]ovice The first and the default value for new users is the Novice level. At this level, the user is presented with full dynamic menus with a command line prompt containing the name of current menu area, and the first character for a particular option in the current menu. Sysop created BBS menus or .SCR menus are displayed in their entirety. [R]egular The second level is the Regular level. At this level, menus show only the command line with the name of the current area of the system and the first letter option designators. No menus are displayed at this level. An example would be: MAIN MENU [M,F,C,B,P,I,Q,V,Y,U,N,H,?] [E]xpert The final and highest level is the Expert level. At this level, only the particular area of the system is indicated. No menus or letter designators are included. An example would be: MAIN MENU : _ The Help level command is available in ALL major menus and the usage is exactly the same in each of them. [I] Initial Welcome Screen ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 91 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Contents of the HELLO1 (one) through HELLO3 files are re- displayed to the caller, with screen pauses determined by manner set up in these respective files. Sometimes a user will stop the original display of one or more of these files using the space bar or CTRL-K, then later wish to review the contents of these entry-level display screens. The I option permits doing so without the user having to logoff and then call again. In addition, if you have a fancy color logo screen in one of your HELLOx files, you might be surprised at how many users will display the file over and over after logging on. [M] Message Menu The MESSAGE menu is displayed. [N] Newsletter Displays the contents of the NEWSLTR.BBS file to the user with screen pauses. As mentioned in the configuration/setup instructions, this option may be called anything you like, and the contents m!y "e anything you wish, but the display file itself must be called NEWSLTR.BBS. [P] Page the SYSOP This selection is used for the caller to page the system operator. It may be tested by the system operator while logging on locally (sitting at machine), the resulting effect being the same as if a remote user had initiated the page. In addition, answering the page with the F7 key may also be attempted (do this in private, since it looks strange to onlookers to see a person typing to him or herself...and answering!). The response of the local system may vary depending on whether the current time is within the sysop's paging hours, whether the page override toggle is on, and whether the page bell is turned on or off. If a page is answered the sysop can type directly to the caller from the local keyboard. [Q] Questionnaire The user is presented the screen menu QUESTION.BBS (similar to BULLETIN.BBS) for further prompting as to which questionnaire to answer. Sample Questionnaires are included. [R] Reports for Sysop The SYSOP menu is displayed. [S] System Statistics When chosen, a display is generated for the caller indicating basic information about the system, including the start date, number of callers, users and files. [U] Userlog List ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 92 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The caller is presented with the entire user list of the system, displayed in alphabetical order, along with the type of computer they are using, the date they last called and their calling point of origin. The usual screen pauses are in effect while using this option. A sysop may disable this (or any) menu option by setting the security level above that of any user. [V] Verify User A search can be made on any portion of a any user name on the system. Pressing V brings up a sub-prompt - Enter name or partial name: At the sub-prompt, enter all (or portion of) a user's first or last name. The more information that is provided at this prompt, the more detailed the resulting search. A search of Jim would find every user named Jim on the system, along with their calling city and state, and the date of their last call. A search of jim h would find, for example, both Jim Hightower and Jim Harvey, plus any others whose first name was Jim and whose last name begins with the letter H. Notice in this example that the search is also insensitive to case. [Y] Your System Settings The user is allowed to make changes to certain information in the User database. When [Y] is selected the user is presented with a screen showing his current settings. From the sub-menu, the user may alter the entries in item in the left column. The right column, which is maintained by the system or the system operator, is provided as information for the user, and may not be changed by the caller. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 93 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MESSAGE MENU [C] Check for Mail WILDCAT! scans and lists the numbers of all messages which are either from or to the caller. This is essentially an operation to determine if the caller has any messages waiting, whether new or old. [D] Delete Message This is a routine for erasing old messages directly from the MESSAGE menu. It requires that (1) the message to be deleted is either to or from the user who is attempting to erase same, and (2) that the message number is already known. Messages may also be deleted interactively while reading them in the message area. [E] Enter Message The message entry command has a number of features. Initially the user is presented with the prompt: To [C/R = ALL] At this prompt a specific user name may be entered and WILDCAT! will check the user database and allow the entry if the user name exists, otherwise the caller is informed to enter another name. If a specific name is entered the system then prompts whether a Return Receipt is required: Would you like a note dropped in your box confirming when ALAN LUCK receives this letter [Y/N] ? If Y is selected, WILDCAT! will watch for the message to be read by the recipient and automatically generate a message from the WILDCAT! Mail Room to the sender. This Return Receipt message indicates the date and time the message was received, and is addressed as private mail to the originator of the message. As soon as this Return Receipt message is read by the original sender on a later call it is automatically deleted by the Wildcat! Mail Room. Whether or not a Return Receipt is requested, the prompting continues and the caller is asked whether he wishes to send carbon copies to anyone: Send Carbon Copy #1 to ([ENTER] if none) : At this prompt a caller may enter additional names of additional recipients up to a maximum of 10. Each will receive a copy of the message with the notation cc: User Name appended to the bottom. Carbon Copies are always toggled private. The caller then is asked for the Subject of the message and may enter up to 40 characters. The final prompt prior to ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 94 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── message entry is whether to make the message private. Private mail is seen only by the sender, recipient and any users who have FULL sysop mail reading privileges as indicated in MAKEWILD. This prompt is skipped for mail addressed to ALL. Message text entry follows. Messages can be up to 150 lines long and a blank line (ENTER only) indicates the last line. The Message Entry prompt appears at the end of text entry: [A]bort Signals a desire to discontinue message entry and lose all text entered. A warning follows: Are you sure you want to abort? A yes answer return the caller to the message menu. [C]ontinue Returns to the message editor at the next available line. [D]elete Prompts for the first line to delete and then for the last line. Prior to performing the deletion the text of the lines to be deleted is displayed for confirmation. Deleted lines are removed and higher- numbered lines move up. [E]dit The message line editor is probably one of the most misunderstood functions in message entry. Because of the line-by-line nature of serial communications a full screen editor must make use of some type of terminal emulation such as VT-100 or ANSI codes. At the time of this release WILDCAT! does not include full-screen ANSI cursor movement. Instead, a search for text to be changed is followed by insertion of the corrected text. The terminology used is OLDSTRING for the text to be replaced and NEWSTRING for the new text. After asking for the line number to be edited, WILDCAT! needs to know what needs to be changed. The syntax used to implement this procedure is OLDSTRING;NEWSTRING (note the semicolon between the two words). This command is translated as Take the first occurrence of the characters OLDSTRING and delete them, then insert the characters NEWSTRING in the same location. For example, if the message line reads: "this is a message to shw how to use th Edit command." Obviously we need to change two errors, the word "th" for the and "shw" for show. First lets fix "shw" by using the command "shw;show" which scans for the word ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 95 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── shw and replaces it with show. Now the harder correction. Notice that the first occurrence of the incorrect text "th" is actually a part of correct text "this" in the 1st word. Therefore we can't simply use the command "th;the" or the new message will read "theis is a message....". The proper method is to broaden the OLDSTRING search to include additional unique text such as "use th;use the". Notice that we can replace any number of letters even with a shorter or longer NEWSTRING. After an edit the caller is presented with the corrected line and allowed to make more corrections, if needed. A blank [ENTER] terminates the Edit mode. [L]ist this command re-displays all message lines using appropriate pauses. [I]nsert Allows insertion of new lines in the text. The user is prompted for the line number where new lines should be inserted. The selected line number moves down, and a new line is added at the chosen number. Any number of new lines will be inserted as word-wrap creates more new lines as needed. [+] Subj Pressing the plus key (+) allows editing the Subject line of the message in the event that it is incorrect or misspelled. [S]ave After the message has been proofread and edited, the Save command will update the message base with the message and appropriate carbon copies, if requested. [F] Files Menu Presents the caller with the Files menu. This choice is available from both the Main menu and the Message Menu. [G] Goodbye & Logoff Refer to the [G] option discussion under MAIN menu. [?] Command Help Refer to the [?] option discussion under MAIN menu. [H] Help Level Refer to the [H] option discussion under MAIN menu. [N] NetMail This command is not available in TEST-DRIVE. See the section on Net & EchoMail for additional information. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 96 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── [Q] Quit to Main Menu Exits the current menu and returns to MAIN menu. [R] Read Messages A sub-menu is displayed with a number of choices. The caller's first choice is to read mail by number by entering any number between those listed, the first to last message available. If a number is entered it may optionally be followed by the minus sign ( - ) to indicate reading backwards from that message. Other choices are: [S]ince the last message read previously. [T]o the caller [F]rom the caller [M]arked, which displays messages marked for reading by WILDCAT! at the time of logon. It includes all messages addressed to the caller which have NOT been received, as long as the caller's high message pointer is NOT higher than the message. (it only operates with NEW mail). After a message is read the user has several possible options, depending on the nature of the message, his security level and whether the message is TO or FROM him. The complete range of possible options and the circumstances of their appearance is: ### After each message a user may branch to another message number in the same manner as when the Read command was initiated. [F]orward This choice allows sending a copy of the message to any other user on the system. It creates a private message to the new recipient with a note indicating that it was originally addressed to another person and forwarded by the reader. [R]eply This choice is available on all messages unless the user's security level prohibits message entry by definition in MAKEWILD. A reply generates a message FROM the caller addressed TO the sender of the original message. [K]ill The ability to kill (delete) a message is offered to the sender, receiver and those who have been given sysop mail reading privileges. When the kill option is used the selected message is actually moved to message folder Y, the Wastebasket. If you want to prevent all callers from deleting any messages (even their own), simply set the security required for the Message menu [D]elete messages option higher than any caller. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 97 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── [M]ove This command allows changing the message folder assignment for the current message. It is offered as a choice under the same circumstances as the [K]ill option. The user has the option of placing the message in any folder to which he has access. [N]onstop Selects nonstop message reading from that message forward. It may be used to capture messages to a file for reading off-line, or to quickly move forward in the message base. Nonstop reading can be terminated with a tap on the spacebar. [P]ublic/[P]rivate One of these two prompts is offered to the sender, receiver and sysop in order to toggle the message from Public to Private or vice-versa. After a change the message is re-screened. [S]napshot This choice is offered to any user who logs on locally, either using the F1 key or ALT-L. It prints a formatted copy of the current message to the printer. [S] Scan Messages Scanning messages differs from [R]eading in that the text of the messages is not displayed, only the header information. It is used in cases where a quick review of the messages is needed. [T] Text search in a Message Text search looks in messages which contain a user specified text string in the message header. The header information includes the TO:, FROM:, and SUBJECT: fields. The search is insensitive to case, and will locate the desired text anywhere within the fields searched. [U] Update Mail Folders This option is used to toggle message folders Open or Closed, and will only reflect folders to which a caller has access rights based on security level. A sub-prompt is displayed allowing the caller to open or close any message folder to which he has access. A caller may [O]pen or [C]lose a folder or number of folders at any time. The caller's updated selections will be maintained in the user database for all subsequent logons. To enter more than *one folder a caller may enter the folder letters one after the other, or separated by spaces or commas (ACDEF or A C D E F or A,C,D,E,F). If a particular folder is already open or closed the request is ignored. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 98 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILE MENU [D] Download File(s) Further prompts for transfer protocol (if no user default is active) and filename will follow. Some external protocols will allow up to seven filenames to be entered. Following a request for download and entering a protocol and file name(s) to download, the request is checked for validity. From that point forward it is up to the caller's communication program to properly begin the transfer and carry it to successful completion of the download. A pop-up window is displayed on the local monitor which indicates the present state of the download in progress, unless an external protocol has been selected. The screen display for external protocols varies depending on the protocol used. See Advanced Features for more details of external protocols and multiple file transfers. An in-depth explanation of the various protocols available in WILDCAT! is contained in the on-line help file PROTOCOL.HLP discussed below. [F] File Transfer Information Results in the display of a file called PROTOCOL.HLP. The usual screen pauses are in effect. This option provides a more detailed discussion to the user about the many differences in various upload and download protocols, in addition to assistance in uploading and downloading procedures. The text contained in the display file PROTOCOL.HLP should be edited to reflect not only WILDCAT!'s internal protocols, but any external protocols added by the system operator. [G] Goodbye and Log-off Refer to the [G] option discussion under MAIN menu. [?] Command Help Refer to the [?] option discussion under MAIN MENU. [H] Help level Refer to the [H] option discussion under Main menu. [I] Information on a file Results in a sub-prompt Enter file name, [ENTER] to Quit : At the sub-prompt the caller should enter the full filename to be checked. A display will show information about the file, including who was responsible for posting it on the system, number of downloads and more. [L] List available Files ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 99 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Presents a sub-prompt asking which file areas should be listed. File areas may be selected either alone or in groups. B;C;D will list the files available in areas B, C & D. Spaces may also be used as a delimiter in the sub-prompt or the letters may be entered one following the other, ie B C D or BCD. Files are displayed in order by file area, and in alphabetical order within each area. To view files by date order, use the [N]ew files command and select the starting date as desired. [M] Message Menu Presents the Message menu, without having to traverse through the main menu. [N] New files since last N Displays a sub-prompt requesting the date to use as a basis for the search. The default date is the last time the caller used this particular option, not the last logon. A new user's search date is always set to 01/01/80. A user can logon for weeks, even months, and providing the N option is not selected during a particular logon, the default date will not be changed. In addition to the automatic default date discussed above, a user may manually enter any date from which to start a new files search, allowing a display of all files added since any date desired. [Q] Quit to the Main Menu Exits the FILE menu and returns to MAIN menu. [R] Read a Text File A sub-prompt requests the name of any ASCII file listed in the file areas. The selected text file is displayed with appropriate screen pauses. Files which are obviously not in ASCII format such as .COM, .EXE, .ARC, .ZIP etc. are accepted at the sub-prompt, but a warning is issued that the file may be unreadable when displayed. Embedded codes are properly interpreted if found in the file. [S] Statistics on Files Statistics presents the caller with a complete summary of file information for both the system as well as his own file database activity and limits. [T] Text Search At the prompt the user is prompted for the specific file areas to be searched. File areas may be entered without spaces. This search is not case sensitive. The more characters entered the narrower the search criteria. For example, entering txt would find every occurrence of the characters txt in the file database, such as MYTXT.OVL, README.TXT, or YOUR-TXT.ZIP. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 100 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── This feature is a handy way of locating those files uploaded by a particular user. Simply enter a portion (or all) of a user's name at the prompt, and all of the files uploaded by that user will be displayed. [U] Upload Files The caller is prompted to specify the protocol desired, filename to send and other information. The TEST-DRIVE release does not support batch uploads although the REGISTERED version does. The caller is responsible for properly initiating the sending of the file on the other end. Uploads using External file transfer protocols are allowed, but are also limited to one file at a time. [V] View a Compressed File This selection is designed to allow viewing of a compressed file saved in one of a number of formats such as .ARC, .PAK, .ZIP or .ZOO. It causes WILDCAT! to shell to a second copy of the command processor and to execute VIEW_ARC.BAT. The filename selected is passed to the batch file using the %1 parameter. This batch file MUST be created by the sysop for proper operation. See Advanced Features for a more detailed explanation of this feature. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 101 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── SYSOP MENU [A] Activity Log Displays the contents of ACTIVITY.LOG in last-in, first-out order. Screen pauses are implemented. [C] Create Events This choice is used to create the events to be run automatically by WILDCAT!. A sub-prompt is displayed asking which event to create: Event #[x]? where x represents the next unused event letter. Pressing the [ENTER] key aborts with no change in events structure. Refer to the section Advanced Features, Creating Events for complete information. [D] Drop to Dos This choice is used to drop to DOS when calling in from remote ONLY. If selected while connected locally (non- remote), the caller is reminded that it is for remote use only, and the use of ALT-D is suggested. If the SYSOP has specified that Drop to DOS is allowed, WILDCAT! sets the errorlevel to 40 and terminates. The remote caller is then allowed access to the operating system through the communication port IF the proper batch files have been configured in advance. See Remote Drop to DOS in the chapter Advanced Features for additional information. Unless there is a very good reason for it, this option should be confined to the system operator or disabled! [E] Event Updates This choice is used for updating and changing previously established events. Selecting an event number (providing at least one exists), will permit toggling the event on or off, or changing other conditions of that particular event, including days of operation, etc. See the section Advanced Features for additional information. [F] File Database Area This selection is used to access and manipulate the file database within WILDCAT!. It is the command center for the listing of all files available for download on the system. Selecting this choice displays a screen showing the first file in the file databae. The system operator may change any of the entries by selecting the corresponding item number to edit. The sub- menu options perform the following operations: ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 102 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── [F]ind Prompts for full file name to locate a particular file. [S]earch Full or partial file name required for search, then provides option of saying yes or no to each successful find. [P]rev Previous - goes back one file alphabetically, matching the Match/Set criteria (see below) if being used for search criterion. [A]dd Allows manual entry of a new file. If the file already has been placed in the appropriate file path, WILDCAT! will bypass the prompt for both file date and size and make use of the correct information from the disk. [D]elete Allows deletion of an entry in the file database with an option to delete the file from the disk also. A file may be deleted only from the database, in which case it remains available on disk but may not be downloaded or otherwise accessed by anyone. [M]atch Match or Set File Area - permits entering a file area letter such as A or B as search criterion. All files contained in this area are displayed one at a time, in alphabetical order. Pressing C/R at the Match prompt resets the Match/set area to NONE, as does reaching the end of the files matching the criteria. The status of the Match/Set is indicated at the top of the screen. [R]ead This choice is the same as reading a text file from the file menu. It may be used to review or check the contents of ASCII files without leaving the sysop menu. [Q]uit Discontinue file database maintenance, return to sysop menu. [ENTER] Advances to the next file alphabetically, matching search criterion, if Match/Set has been requested. [G] Goodbye & Logoff Refer to the [G] option discussion under MAIN menu. [?] Help with Commands Refer to the command help discussion under MAIN menu. [I] Index Menu Choosing this option will result in the following sub-prompt being displayed: 1. Index the File Database 2. Index the Message Database 3. Index the User Database Enter Choice or [ENTER] to Quit ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 103 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Use this option when something is "just not right" in the message, file, or user database. For instance, if a user were to attempt a download and received a message that the file does not exist, it is possible that the index has been contaminated in some manner. [K] Kill Activity Log This is the proper method of erasing the ACTIVITY.LOG file when it becomes an unmanageable size. By responding Y to the confirmation sub-prompt, the activity log will be erased and a new copy of ACTIVITY.LOG started. [L] List Scheduled Events Listing the currently established events presents a screen showing the: number of the scheduled event; current status (enabled/disabled) of the event; length of time the event is to run; day of the week the event is to run; schedule identifier (Y , X, A, B, etc description of the event. It informs the system operator as to what automatic system events are to occur, and when. [P] Print the User File Prints to the printer a complete alphabetical listing of the user database, including all information known about that user. [Q] Quit to the Main Menu Exits the sysop menu and returns to MAIN menu. [S] Statistics on Databases This is an information option for the sysop, indicating the current status of the various databases. [U] User Database Area This choice is used to access the user database within WILDCAT!. Complete control over your system callers is available in this area. The system operator may change any of the entries by selecting the corresponding item number to edit. Keep in mind that some of these settings are generated by WILDCAT!'s internal operation such as the number of files uploaded, etc.. Use discretion when changing these values. Although most user database items are self-explanatory we will review a few of the fields for the sake of clarity. User Since - indicates the date and year of the user's first call to the system, and never changes unless altered here. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 104 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Viewing folders - lists the letters of the message folders ^LPage 104 that the user currently has open for viewing. This changes as folders are opened or closed. New Files - this date reflects the last time the user made use of the [N]ew files command from the File menu. Erase prompt - if toggled to "YES", the pause prompt at the end of the screen - More [C]ontinue, [S]top, [N]onstop is erased using the backspace character when a response is made. If set to "NO" the prompt will remain on screen and a new line will begin. The feature is present for systems that cannot handle the backspace character. Time remaining - reflects the number of minutes of use available at the end of the user's last call. It is reset if the next call come in on a new date. Memo date - this field is unused by WILDCAT!and is available to the system operator. It might be used to enter an expiration date for pay systems, or whatever else meets the sysop's needs. In the REGISTERED USER version this field can be manipulated with the U-PRO! utility program to easily handle subscription systems with automatic security level change and notification upon expiration. The sub-menu options perform the following operations. User Database Modification [F]ind Prompts for full user name to locate a particular user. [S]earch A full or partial user name is required for the search, and the sysop may decide whether or not to view each successful find. To abort a search simply answer Y when asked if the screen contains the user you wish to view.. [A]dd Manual entry of a new user. This is useful for pre-registration purposes. [D]elete Deletes the current record from the database. [P]rev Goes back one user record alphabetically, and follows the established search criteria set up by the Match/Set Level if being used. [M]atch (Match or Set Level) - permits entering a user security level as search criterion. All users matching this level are displayed one at a time. Pressing ENTER at the Match prompt resets the Match to NONE. The status of any Match/set is displayed at the top of the screen. [W]rite Creates a message addressed to the user without leaving the database screen. This feature is handy for leaving notification to users advising ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 105 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── them of updates or changes to their status. After message entry is completed the sysop is returned to the User database screen. [ENTER] Next alphabetical record in series, following the criteria set up by both Search and Match set, if any. [W] Wastebasket dump Results in the sub-prompt Do you want to Delete the messages in the Wastebasket? This option is necessary since when a given message is deleted (erased or killed) by a user, it is not really deleted. Instead, the message is transferred to the Y folder (the wastebasket) where it remains until option [W] is performed either manually or automatically in an event. After the wastebasket is dumped, the space occupied by that message may be used for the equivalent amount of space in another message. See also Schedule "Y" Note that performing a wastebasket dump does not reduce the size of your message database file MSGINFO.DAT. The space occupied by purged messages does become available for new messages, but file compression is not performed. The FIXMSGS program may be used if you find the message database file has an inordinate number of unused purged message records as the result of a mass deletion. See the documentation for FIXMSG in the section "WILDCAT! SUPPORT PROGRAMS". [H] Help Level Refer to the [H] option discussion under MAIN menu. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 106 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── ADVANCED FEATURES Creating Events Many of the more advanced features of a bulletin board system depend on the proper implementation of batch files. The WILDCAT! event scheduler is such a feature. If you are totally unfamiliar with the batch file concept, see your DOS manual. The event processor is used to have WILDCAT! perform certain tasks at predefined times during the day or evening. These tasks may range from doing system maintenance such as emptying the wastebasket to running an external utility to perform some system maintenance task. An event is an operation that occurs automatically from within or outside the WILDCAT! code, depending on how it is set up. These are commonly referred to as Internal or External events. Events automate certain activities, and if used properly can supports up to ten external events designated as events A through J, internal events X and Y, and a Call Processing Event at the end of each call. Events are indeed powerful and can perform a multitude of functions when creatively used. All events are created from the system operator's menu, except for the Call Processing Event which is scheduled from within MAKEWILD. The Call Processing Event shares most of the operational features of other external events and is discussed in detail later in this section. All other events are scheduled from the sysop menu using the [C]reate event choice. The sysop is asked to provide: 1. The number of the event. WILDCAT! will automatically increment to the next number in order to help prevent accidentally overwriting an existing event. 2. The starting time of the event. This should be entered in 24-hour format. 3. The time (in minutes) that the event will run. Most events are NOT time dependent, and a value of 1 minute is the standard time needed. WILDCAT! will not start- up again until the batch process is completed, even if the event takes longer than one minute. On the other hand, if it is possible that the event takes LESS than one minute, the sysop must use a delay timer in the event batch file to ensure that it runs longer than one minute to prevent WILDCAT! from running it a second time. See the WAIT! and WAITFOR! program documentation in the section "WILDCAT! SUPPORT PROGRAMS" later in this manual. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 107 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── 4. The tag letter for the event. This may be a letter from A through J for external events which occur outside of WILDCAT!, or the letters X or Y for internal events. The letter designations for external events are for identification only, and the sysop may use any desired. The X and Y represent specific internal functions. 5. The day of the week in which the event will occur. Take your choice from the options listed. We will first review event tags X & Y which are the internal events and require no additional sysop intervention to function properly. EVENT SCHEDULE X [REGISTERED VERSION ONLY] Event schedule X is hard-coded into the program and is referred to as an Internal Event. It's function is to renumber all messages starting with 1 and to update the last message read counter for every user record in the system. It is normally run after deleting the messages in the wastebasket (event Y), and keeps your message count from having large gaps due to deleted messages. Again, this renumber event is in the REGISTERED USER version only. Renumbering in this TEST-DRIVE is done from the SYSOP Menu. EVENT SCHEDULE Y Event schedule Y is also hard-coded into the program. Event Y instructs WILDCAT! to purge the deleted messages from Folder Y, the message Wastebasket. This process does not require very much time, but like event X, it should be scheduled to occur during a slow period of board activity. EVENT SCHEDULES A THROUGH J Schedules A through J are External Events which actually terminate WILDCAT! and perform an outside task using a batch file. Since WILDCAT! will actually exit to DOS, it must pass some indication to DOS of which event is to take place. This is accomplished by use of the ERRORLEVEL feature of DOS. Briefly, whenever a program terminates it has the ability to set a DOS parameter called ERRORLEVEL to any number. By convention an errorlevel is set to 0 (zero) if the program terminates normally, 1 if there is an error which causes termination, and any other number is non-classified. WILDCAT! makes use of this feature by setting a different errorlevel for each external event. By using the DOS errorlevel test command the proper event batch file can be invoked. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 108 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── These functions are especially useful and must be used in conjunction with batch files which in turn call up other utilities. Although powerful, they should be carefully thought out in advance and tested during a time that the system operator is available to intervene should something go wrong. WILDCAT! can set a variety of errorlevels when exiting to DOS, each of which should be used to call the appropriate batch file. Schedule A sets the errorlevel to 2, B sets it to 4, C sets it to 6...and J sets it to 20. The DOS batch file command IF ERRORLEVEL # FILENAME is used to test for the errorlevel and start the proper batch file. The # is replaced by the errorlevel number and the FILENAME is replaced by the batch file name to execute. The errorlevels associated with each external event are as follows: A 2 B 4 C 6 D 8 E 10 F 12 G 14 H 16 I 18 J 20 Notice how the errorlevel command is used in the following sample batch file. The batch file is called CAT.BAT and is actually used to start WILDCAT! and check for an external event upon completion. :RELOAD label to re-start when needed (batch labels must begin with a colon). CTTY CON: direct output to console in case we are returning from a remote drop to DOS WILDCAT starts the program. IF ERRORLEVEL 20 BAK.BAT calls up another batch file IF the errorlevel is set to 20, which is event J. In this example event J does a backup of some kind, perhaps of the WILDCAT! database. IF ERRORLEVEL 1 GOTO RELOAD sends batch processing to the label :RELOAD if the errorlevel is set to 1, an abnormal exit due to an error or other problem. The batch file reaches the end ONLY if the errorlevel is set to 0, indicating a normal exit with the F10 key. Notice that the errorlevel tests are done from highest number to lowest number. This is NOT accidental, and is necessary since ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 109 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── the DOS test for errorlevel returns either a True or False depending on whether the actual errorlevel is EQUAL TO OR GREATER THAN the number tested. Under the circumstances, testing for errorlevel MUST be done from highest to lowest possible numbers. Lets take a look at the batch files that are called by the CAT.BAT file when an event is detected in the errorlevel test. The following is the possible contents of BAK.BAT in the previous example. COPY *.DAT \WILDCAT\BACKUP copies all of the .DAT files to a subdirectory of WILDCAT! CAT.BAT restarts WILDCAT! again using the CAT.BAT batch file. Each Event batch file MUST terminate with this command! This event J might be set to operate every night to keep a constant backup of all of the database files used by WILDCAT! Other external events may be set up to run utility programs such as the PRO! series for the REGISTERED USER version. The key to remember is that CAT.BAT must test for the errorlevel that corresponds to the event tag letter; 2 for A, 4 for B, 6 for C and so on up to 20 for J. Then create the appropriate batch file name to perform the event task and make sure that it calls CAT.BAT as the final command. CALL PROCESSING EVENT The final topic under the category of external events is the special event which may be run after each and every WILDCAT! call, the Call Processing Event. MAKEWILD allows the errorlevel to be set to 60 after each call in the SYSTEM CONFIGURATION, Frame 8, Question 8. If set to Y, WILDCAT! will terminate after each call and allow your CAT.BAT file to test for errorlevel 60 and run some support program. This feature is included to allow sysops with special application needs to create their own programs to perform some action, often a NetMail or EchoMail front end program. The operational procedure is exactly the same as that for events A through J except that the batch line test must be for errorlevel 60. NetMail and/or EchoMail are only FULLY supported in the REGISTERED USER version of WILDCAT!. This TEST-DRIVE release will allow the sysop to set-up a Net or EchoMail system with a front-end program such as D'Bridge, but the mail received is only directly available for the sysop, not the callers. For a detailed explanation of Net & EchoMail installation see the NetMail documentation later in this section. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 110 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Errorlevel 60 may also be used for other purposes in the TEST- DRIVE release. EVENT TIMING AND FORCED OPERATION Since many Events are time dependent, WILDCAT! does everything in its power to ensure an Event takes place on schedule. WILDCAT!'s timetable and handling of calls during the period immediately preceding an event is as follows: * More than 120 minutes before an event: No notification of the pending event to the caller, and no action take to reduce the caller's time, even if the caller is allowed in excess of 120 minutes per call. * 120 minutes to 21 minutes before an event: The caller is notified of the pending event, and his time allowed online is reduced if necessary. Uploads via external protocols are disabled. Forced logoff takes place 3 minutes prior to the event. External protocols are disabled at this time to prevent a caller from beginning an upload of unknown length, and having WILDCAT! miss the event. Remember, WILDCAT! can't watch the clock during an external protocol since it is not in memory. * 20 minutes to 9 minutes before an event: The caller is notified of the pending event, his time allowed online is reduced, and he is asked if he wished to continue the logon process. Uploads via external protocols are disabled. Forced logoff takes place 5 minutes prior to the event. * 8 minutes to 1 minute before an event: No calls accepted, the phone should be off-hook. The forced logoff takes place regardless of the caller's activity. It will be preceded by a two minute warning, but takes effect even if the caller is in the midst of a download. This is in contrast to the forced logoff for time expired when an event is not pending, where a download is allowed to be completed prior to logoff. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 111 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── REMOTE DROP TO DOS The ability to access the Disk Operating System from a remote connection is one of the most exciting aspects of communications. This function, like external events, cannot operate properly unless WILDCAT! has been started with a properly designed CAT.BAT file. When this function is selected by a remote sysop, WILDCAT! will perform a number of actions to prepare for DOS access. All WILDCAT! files are closed and the errorlevel is set to 40 for testing by CAT.BAT. WILDCAT! then exits and passes control back to the batch file which invoked it (our example to this has been CAT.BAT). Proper execution now depends on CAT.BAT having the line IF ERRORLEVEL 40 DROPDOS.BAT. Assuming this is so, processing will be passed to DROPDOS.BAT. The contents of DROPDOS.BAT must redirect the system output and input to the correct communications port. CTTY COM1 changes the standard input/output devices from the keyboard and screen to the COM1 port. COM2 is also valid if used. The above example makes use of the program CTTY supplied with DOS to perform redirection. In reality, many IBM compatible computers are unable to perform redirection using this command. In these cases it is often necessary to use a redirection program written by a 3rd party to handle this process. Programs such as GATEWAY and DOORWAY may be used, and are shareware products available on many BBS systems, including the Public WILDCAT! BBS at Mustang Software. They function in much the same way as CTTY, but will often work even on computers where CTTY fails to properly redirect the text. To determine if you need an alternative to CTTY, have a trusted caller try a remote drop to DOS and watch your LOCAL monitor. After the DROPDOS batch file executes, see if you can still enter commands locally such as DIR. If you are able to use the local keyboard, then redirection did not take place. When properly executed, all future input (keypresses) and output (screen displays) should be re-routed to the COM1 port. This results in the remote sysop or caller receiving the DOS prompt C: (or whatever). Before we go any further we need to know how to return to WILDCAT! after a remote drop to DOS. To reverse the input & output we need to again redirect I/O, but this time to the standard keyboard and monitor. DOS calls these the CONSOLE, or CON for short. We need to execute the command CTTY CON, which changes the input/output from the COM1 back to the keyboard and screen. However, what we really want to do if calling in from remote is to re-start WILDCAT! and change things back at the same time. This is accomplished by issuing the CTTY CON command automatically as the FIRST command in CAT.BAT whenever it is called. That way a sysop in remote mode can simply change to the WILDCAT! subdirectory and type CAT.BAT to change the output back ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 112 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── and start the program. Lets take a look at a yet more complex CAT.BAT file to accomplish proper Remote Drop to DOS: :RELOAD label to restart program CD \WILDCAT assures that we are in the right directory for starting WILDCAT! CTTY CON Redirects input/output to the keyboard and screen if it has been changed by DROPDOS.BAT WILDCAT starts WILDCAT! IF ERRORLEVEL 40 DROPDOS.BAT calls up another batch file which redirects input/output to the COM port and allows remote drop to DOS. IF ERRORLEVEL 20 BAK.BAT calls up another batch file if the errorlevel is set to 20, which is event J. In this example event J does a backup of some kind, perhaps of the WILDCAT! database files. IF ERRORLEVEL 1 GOTO RELOAD sends batch processing to the label RELOAD if the errorlevel is set to 1, an abnormal exit due to an error or other problem. The batch file reaches the end ONLY if the errorlevel is set to 0, indicating a normal exit with the F10 key. As you can see, if DROPDOS.BAT is executed, the sysop must manually restart CAT.BAT to return to WILDCAT! Looking back at the CAT.BAT batch file, one of the first commands is to re-direct output to the CON or screen in case it is needed, which it will be after a remote DOS session. Since this is the first example of a user (or the sysop) returning to a previous WILDCAT! session, we will undertake a short discussion of the inside operation that allows this re- connection. When WILDCAT! prepares for remote drop to DOS or a door, (DOORS are available in the registered version of WILDCAT!) it is done with every intention that the caller will be returning to WILDCAT! after the door or remote task is completed. As a part of the preparation it creates a file named CALLINFO.BBS which contains information about the caller and system status. This file is available to the door program for identification of the caller, and is necessary for the user to return to WILDCAT! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 113 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── properly. After a proper return, CALLINFO.BBS is erased. It should never be present on your system unless a caller is currently in a door or drop to DOS. As the user returns to WILDCAT! (using CAT.BAT from DOS or from a door batch file calling CAT.BAT), WILDCAT! will load into memory and should find that the modem shows carrier is detected since the caller is still connected. Whenever carrier is detected on startup, WILDCAT! checks to see if CALLINFO.BBS also exists. If so, carrier will be maintained and the name in CALLINFO.BBS will be logged back into the system. If CALLINFO.BBS does not exist, then WILDCAT! attempts to lower carrier before setting up the system. During the return from a door or remote drop to DOS a user is asked to verify his identity with his password ONLY if the program is answering the phone using modem auto-answer. If ring detect is being used (auto-answer is disabled), there will be no prompt for password since there is no possibility that the caller is other than the person listed in CALLINFO.BBS. Using Remote Drop to DOS Due to the method in which the characters are transmitted over the COM port, many usual DOS and program functions are unavailable while connected to DOS from remote. Programs that use other than DOS function calls for video display or other processing will not usually function, and will cause a system lock-up. These include BASIC, almost all Word Processors (due to the direct video display), almost all games unless written specifically for COM port use, and a majority of commercial programs. The purpose of this option is to allow a sysop to make direct modifications to small files, directory structures, move files and check DOS status. CAUTION IN USE IS AN ABSOLUTE NECESSITY. Using DOORWAY or GATEWAY can extend the system's abilities while operating from remote, and is strongly recommended. Follow the instructions with the program for best results, and don't forget to register your copy with the author. Yet another alternative is the use of commercial programs such as CARBON COPY Copy or PC ANYWHERE Anywhere which allow operation of virtually any program from remote. These programs can be connected to WILDCAT! as doors or invoked from remote DOS access, and then WILDCAT! can be restarted after completing the session. Mustang Software, Inc. cannot assist in the troubleshooting of system problems related to operation of the CTTY command used in remote DOS operation. We will be happy to review a batch file process or other DOS implementation on the Public WILDCAT! BBS system. A FINAL NOTE ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 114 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── A common misunderstanding is that Remote Drop to DOS is related in some way to the ALT-D or Local Drop to DOS. As indicated previously, Local Drop to DOS operates by leaving WILDCAT! in memory (or dumping it to disk) and starting a second version of DOS which is made available. The EXIT command then returns to the original WILDCAT! DOS and program. Activation of Remote Drop to DOS actually causes WILDCAT! to remove itself from memory and connects the caller to the system by having the computer look at the COM port as it's keyboard or input device. Remote Drop to DOS is terminated with a restart of the CAT.BAT batch file. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 115 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── EXTERNAL PROTOCOLS (Fully implemented in TEST-DRIVE) This option is designed to allow implementation of file transfer error-checking protocols written by outside sources. Examples are KERMIT, used for transferring files between many different types of systems, and ZMODEM, used for speed and batch transfers. Note that an external protocol is not allowed as a choice for a user's default protocol since a user's record could reflect a transfer method that may no longer be available if a protocol was removed or changed. Those users wishing to take advantage of external protocols should set their default to allow selection of a protocol at the time a download is initiated. Not all external file transfer protocols are capable of sending multiple files in a batch mode. Each protocol is defined as either batch or non-batch during its definition in MAKEWILD, and the caller is prompted for one or more filenames accordingly. Operational Overview When a user selects an external protocol, perhaps [Z] for Zmodem, the user is prompted for the name of the first file to be sent. After checking the filename for validity WILDCAT! copies the file from it's regular directory to the path reserved for external protocols as specified in MAKEWILD. As each requested file is copied to the temporary transfer area, it is checked against the user's usual download limitations and also the disk space available in the transfer area. As each additional filename is requested, a copy of the file is made in the external protocol subdirectory. This duplication of the file in the external transfer directory allows all transfers to be made directly from that subdirectory, without specifying a full pathname. This reduces the length of the command line and allows up to seven files to be sent, if desired. If a non-batch protocol is used only a single filename is requested and there is no danger of exceeding the command line limit. Since copies of all of the files to be sent to the user are made in the external protocol directory, each protocol may complete the transfers necessary with no pathnames required. This is necessary since batch transfer of 7 files with full pathnames would almost always exceed the DOS command line limit of 128 characters. After the transfer is completed the transferred files in the external protocol directory are erased by WILDCAT!. An additional advantage of using the external transfer directory to hold the files is increased security, since external protocols may only transfer files which are contained in the protocol area. Batch File Creation ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 116 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── WILDCAT! allows up to 10 different external protocols to be established. For each the sysop must have first obtained a copy of the appropriate file transfer program such as PCKERMIT.EXE or ZMODEM (part of DSZ.COM or DSZ.EXE). The next step is to establish the batch files for passing parameters to the transfer program as needed. The actual contents of these batch files will depend on the specific protocols, but usually includes the program name with several command line arguments. Before we go into the actual creation of the batch files, lets spend a minute or two discussing what WILDCAT! does to prepare for an external file transfer. When an external protocol is selected, WILDCAT! performs an exec call or shell. This invokes a second copy of the command processor (usually COMMAND.COM), and leaves WILDCAT! resident in memory. Upon exit to the newly created DOS shell WILDCAT! passes at least three parameters to the DOS environment in the form of variable batch parameters. These parameters are available to a batch file through the use of the % batch command, and consist of the baud rate, communications port and the filename to send or receive. These three pieces of information are needed by most transfer programs. They are assigned to DOS batch commands %1 through %3 respectively. The baud rate is passed as %1, and is a number 300, 1200, 2400, 9600, or 19200. The communication port is passed as %2, and is an integer 1, 2, 3, or 4. The filename is passed as %3 with no leading or trailing spaces, and only the name (not the full path) is passed. In the case of multiple file downloads, additional batch parameters %4 through %9 also contain filenames for transfer. Refer to your DOS manual for details on use of the % command if needed. Download Example The batch files controlling both downloads and uploads must be located in the external protocol directory as specified in MAKEWILD. A typical batch file for ZMODEM download might look something like this: CD \WILDCAT\EP make sure that we are in the external protocol directory. DSZ port %2 speed %1 sz %3 %4 %5 %6 %7 %8 %9 starts the DSZ program and tells it which port, speed and the filenames to use IF ERRORLEVEL 1 COPY ALL.OK TRANSFER.BAD test for standard aborted errorlevel to indicate bad transfer ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 117 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── The translation of the above goes something like this. The first line changes to the directory where the transfer is to take place, the external transfer directory. Although we are already in that directory this is done to ensure that we are in the correct location. This directory is also the location of this batch file and the DSZ protocol program. Remember that this path is configurable in MAKEWILD. In the second line the DSZ.COM or DSZ.EXE program is given the command line arguments as follows: The word "port" is required by DSZ and is followed by the number of the communication port, 1 - 4. You may either follow it with the parameter %2 which WILDCAT! has set to your port as indicated in MAKEWILD, or you may save a space and enter the actual number such as 1. If you will never change your com port number you may want to use the number 1 or 2, but using %2 will ensure proper translation even if you change communications ports. The next word "speed" is also part of the requirements for DSZ, and is followed by the speed of the call. The speed is available in the parameter %1, and must be used since each call will vary. WILDCAT! knows the speed of the caller's modem and has loaded the %1 parameter accordingly. Note that DSZ requires the words port, speed, and sz to be in lower case letters. It will not operate properly if capital letters are used. The characters "sz" are short for send using zmodem and are followed by the filenames to send which are %3 - %9. The last line in the batch file is used to help WILDCAT! determine if the file transfer was successful or not. In order for the success or failure of the download to be known this line must be included. The sysop should create a text file in the external protocol directory named ALL.OK which may contain anything, just so it exists (a space or C/R will do fine). If the transfer is not successful, most external protocols set the errorlevel to 1 or higher. In the event of an unsuccessful transfer with an errorlevel set to 1 our errorlevel test will copy the dummy file ALL.OK to a file named TRANSFER.BAD. After each external transfer WILDCAT! looks for TRANSFER.BAD in the external protocol directory. If it is found, the transfer is posted as unsuccessful to the ACTIVITY.LOG and the user is not charged with the download. Just prior to beginning each external transfer WILDCAT! erases the previous copy of TRANSFER.BAD, if it was present, to guarantee that it does not exist at the end unless created by our errorlevel test. Note that WILDCAT! looks for TRANSFER.BAD in the protocol subdirectory only. CHECK YOUR PROTOCOL DOCUMENTATION: Each external protocol will have different command line arguments and may use the ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 118 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── parameters in another order, with or without the words port & speed. There is no substitute for reading the protocol documentation. At the end of an external protocol transfer, program control will automatically return to WILDCAT!. There is no need to call CAT.BAT or EXIT, and the path is automatically reset to the WILDCAT! home directory, eliminating the need for a directory change in your batch file. Upload Example Uploads using external protocols are handled in a slightly different manner, and multiple file transfers are not permitted. At the time of the upload the caller is asked for the name of the file to upload followed by the file area where the new upload should be placed. A caller may choose from any file area to which he has upload rights as specified by his security level in MAKEWILD. The previous batch parameters of %1 through %3 are used for the same purposes, but since only one file may be uploaded it is always the %3 parameter. The %4 parameter is assigned to the full drive and path of the file area to receive the new file, and %5 is the full drive, path plus the new filename. As an example of these two new parameters lets assume a caller is uploading a file named NEWFILE.TXT to file area E. Lets further assume that file area E is located in C:\WILDCAT\UPLOADS. The parameters passed as %4 and %5 are as follows: %4 C:\WILDCAT\UPLOADS %5 C:\WILDCAT\UPLOADS\NEWFILE.TXT Now lets look at a sample upload batch file and review it's contents. CD \WILDCAT\EP makes sure that we are in the external protocol directory DSZ port %2 speed %1 rz %3 runs the DSZ program with command line arguments as required COPY %3 %4 copies the new upload (%3) to the file area chosen by the caller (%4). DEL %3 deletes the upload from the temporary external transfer area ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 119 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Again, the translation goes something like this. First we change to the subdirectory where all of our external protocol activity takes pale, just to make sure we are there. We then start the receive with DSZ followed by the command line parameters port %2 speed %1 just as we did for starting downloads. The rz indicates we want to receive using zmodem, and is followed by the filename which will be sent to us. After the file %3 has been received (lets assume the caller sent NEWFILE.TXT), we still have to get it to the right file area on our disk. Although there are several ways to accomplish this, we suggest copying the file to the correct location and then deleting it from the protocol subdirectory. This method allows use of multiple drives for uploads. The last two lines of the batch file complete the move of the file to the proper area as desired. If our fictional upload NEWFILE.TXT was to be placed in area E, which is designated as C:\WILDCAT\UPLOADS, then the batch file parameter %4 would be C:\WILDCAT\UPLOADS, and the %5 parameter would be C:\WILDCAT\UPLOADS\NEWFILE.TXT. The final lines of our batch file then translate to: COPY NEWFILE.TXT C:\WILDCAT\UPLOADS DEL NEWFILE.TXT The main caution necessary using this method is that there must be enough disk space available for 2 copies of the uploaded file for the copy and delete to function. Uploads do not require an errorlevel test to determine if the file transfer was successful since WILDCAT! will look for the newly uploaded file in the area specified by the caller and assume success if it is located and failure if it is not located. The %5 parameter is not used for most operations, but represents the full filename which must exist for the upload to be considered successful. One specific external protocol is handled differently by WILDCAT! when it is selected by a caller. BIMODEM is a protocol capable of upload, download, and chat simultaneously, and is operationally different from others. It is specifically supported ONLY in the registered version of WILDCAT!. As is the case with doors, no external protocols are distributed with WILDCAT! Many are available on the Public Mustang Software WILDCAT! BBS as well as many other systems. CAUTION: TO PROTECT YOUR SYSTEM YOU SHOULD PREVENT CALLERS FROM UPLOADING FILES WITH THE SAME NAMES AS YOUR BATCH FILES USED FOR EXTERNAL TRANSFERS. WITH THIS TEST-DRIVE RELEASE WE SUGGEST YOU SIMPLY PLACE THE BATCH FILENAMES IN YOUR FILE DATABASE WITH PASSWORDS TO PREVENT THE NAMES FROM BEING USED AS AN UPLOAD ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 120 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FILENAME. THIS IS IMPORTANT SINCE AN UPLOAD WITH THE SAME NAME AS YOUR BATCH FILE COULD PROVE TO BE A DESTRUCTIVE BATCH PROCESS, AND WILL BE EXECUTED SINCE DOS DOES NOT KNOW THAT THE FILE HAS REALLY CHANGED SINCE IT STARTED THE BATCH PROCESS. IF YOU HAVE ANY QUESTIONS IN THIS REGARD PLEASE CALL OUR TECHNICAL SUPPORT STAFF FOR CLARIFICATION. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 121 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── VIEWING COMPRESSED FILES The [V] selection on the files menu supports a feature which allows looking into files which have been compressed or combined using utility programs to view files ending in .ARC or .ZIP, etc.. This is accomplished by having WILDCAT! run an appropriate un-compressing program and send the output to a file for display to the caller. It operates in much the same manner as external protocols in that a shell to another copy of the command processor is initiated. Use of this feature must only be considered after completely reading the preceding sections regarding batch file security and the associated warnings. When [V] is selected WILDCAT! will suspend it's operation, shell to another copy of DOS, and initiate a batch file named VIEW_ARC.BAT. This batch file must be located in the WILDCAT! home directory, the one where CAT.BAT operates and where the MAKEWILD configuration is stored. As it calls the file VIEW_ARC.BAT it passes the batch variable %1 to the batch file for its use. This variable contains the complete drive, path and filename of the .ZIP (or whatever) file to be processed as selected by the caller. If you are unfamiliar with the %1 parameter in batch files refer to your DOS manual. The contents of VIEW_ARC.BAT should look similar to this: PKUNZIP V %1 > VIEW_ARC.DAT This example makes use of the DOS command > to redirect the output of the command to a location other than the screen, in this case the file named VIEW_ARC.DAT. No CTTY command is necessary when this method is used. This command results in PKUNZIP performing a view into the filename represented by the %1 parameter, and sending the output to the file VIEW_ARC.DAT, rather than to the computer screen. When control is returned to WILDCAT! immediately after this command, WILDCAT! looks for the file VIEW_ARC.DAT and will display it to the screen if it exists, with screen pauses. Any program may be used to accomplish the peek into the compressed file, as long as it is capable of handling the compression method used on your system. Several shareware programs are available which can un-compress multiple formats, including .ARC, .PAK, .ZIP, and .ZOO. Our example uses PKZIP/UNZIP by PKWARE, Inc. Another popular option for implementing this choice is to use a special program such as AVIEWCOM which extends your options while viewing a compressed file. Many offer reading the text inside a .ZIP, or even downloading a portion of the .ZIP file. AVIEWCOM is available on our Public WILDCAT! BBS system. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 122 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Although this feature was designed to allow use of the compression listing programs, a little imagination will reveal other possible applications. A change to the name of the menu choice will allow a sysop to call it whatever he wants and pass a filename to any program or other batch process. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 123 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── NetMail & EchoMail The REGISTERED version of WILDCAT! is capable of providing full integration to a variety of NetMail and EchoMail systems. This TEST-DRIVE release allows implementation of a remote mailer, but NOT the processes to make mail available to callers. It is a "sysop access" Net & EchoMail implementation in TEST-DRIVE, designed to offer a feel for the wide-area mail concept. The most common and widely know mail system is FidoNet, an international network of personal computers organized and set-up by Tom Jennings a number of years ago. It is an all-volunteer network and literally covers the globe. Although several other message networks have become popular in recent years we will use FidoNet as the example in our NetMail discussion. In order for WILDCAT! to recognize and communicate with an external mail network, the sysop must make use of a Front-End Program. This program is used to answer the phone in place of WILDCAT! to determine if a call is intended for the mail system or is a BBS caller. Calls from other NetMail systems containing messages are processed by Front-End Program, while BBS callers are passed on to WILDCAT!. The newly received messages are processed and placed in a special message format for reading by the sysop with a number of special reading programs. In the REGISTERED USER version this mail is also available to callers. NetMail messages may be public or private, and are addressed to a specific BBS or dedicated mail system. The addressing scheme used for NetMail consists of a Region number, a Net number, and a Node number in the format 1:206/2901 (Mustang Software, Inc.'s address). EchoMail is slightly different from NetMail. It consists of a series of public messages gathered from many other BBS and mail systems across the country who share a common message topic, such as the International WILDCAT! Echo. Each night new messages from every system are sent to a central repository (via several links), and each system receives the new messages from every other participant in the echo. All echo member systems end up with a common message pool which is kept current within a few days. In order for a front-end program to pass control to the BBS when a non-mail call is received, there must be a method of informing WILDCAT! of the caller's baud rate. This is accomplished through the use of a command line argument in the format: WILDCAT /B 1200 The baud rates acceptable are 300, 1200, 2400, 9600 and 19200. If the caller is making use of a reliable connection, one using MNP, ARQ, or other hardware error control, this number should be immediately followed by the letters MNP. If the baud rate is passed on the command line to WILDCAT!, it will connect to the ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 124 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── already existing caller and begin the login process. After the call is completed it is customary to return control to the front-end program through the use of the Call Processing Event (errorlevel 60). In the REGISTERED USER version another command line option is supported in the /B command. It consists of the additional line parameter passing the number of minutes until the next mail event scheduled by the front-end program. WILDCAT! uses this number to adjust the caller's time allowed on the system during his call. The format for passing the time along with the baud rate is an integer which follows the baud rate, delimited by a space: WILDCAT /B 2400MNP 65 The above example indicates that the caller being passed to WILDCAT! is connected is at 2400 baud, is using MNP (or similar) error control, and the front-end mailer needs to begin a mail processing event in 65 minutes. The specifics of NetMail and EchoMail operation are far beyond the scope of this document. Each front-end program operates differently, many requiring complex batch file setup by the sysop. Mustang Software technical support is unable to assist with specifics of any particular interface problems. The choice of front-end programs is left to the individual user and many are suitable for operation with WILDCAT!. These include SEAdog from System Enhancements Associates, BinkleyTerm, Front Door, and The D'Bridge Electronic Mail System by Chris Irwin, an especially robust and easy-to-install mailer. A second supporting feature within the REGISTERED USER version of WILDCAT! for NetMail and EchoMail is the Message menu option to call errorlevel 35. This menu choice is commonly used to begin a batch file process which invokes a NetMail reading program for use by the BBS callers. It is important to realize that the front-end mailer only performs functions to send, receive and organize mail, not reading by the BBS callers. As is the case with front-end programs, several good reading programs are available on the Private WILDCAT! HQ BBS. This test-drive release will easy allow a sysop to establish a fully operational Net or Echo system with all functions available to the system operator. File requests can even be implemented if desired. For the sysop's information we present the following brief discussion of the Message menu [N]etmail choice in the REGISTERED USER release. The set-up of a mail reading program with errorlevel 35 follows the exact same procedures as a door. In fact, the NetMail option is listed in the MAKEWILD door definition screen as the first item. The CAT.BAT file must include a test for errorlevel 35, such as the line: ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 125 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── IF ERRORLEVEL 35 NETREAD.BAT The batch file NETREAD.BAT should change to the subdirectory containing the NetMail reading program and perform any other conversion chores necessary to begin reading mail. At this point in time there are no NetMail reading programs supporting multi-user access. In a multi-node system, when one caller is reading NetMail the remaining nodes must restricted from accessing this feature. This is accomplished by indicating that the NetMail door is NOT multi-user. Callers requesting your message menu [N]etMail choice when another node is already reading NetMail will be told that the door is already in use by another node. Future Directions Mustang Software is currently working with other net and echomail program authors to create a fully automatic Net and EchoMail system utilizing a common message database format. We are in the process of creating the bridge between D'Bridge and WILDCAT! that will offer a transparent netmail connection in a multi-user environment. It will feature internal message entry, reading and control, with fully automated front-end processing. Along with messages, D'Bridge and WILDCAT! can send files as attachments, and can even accept file requests from other systems. See the documentation for D'Bridge for details on its operation. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 126 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── WILDCAT SUPPORT PROGRAMS ADDFILES ADDFILES is a utility to ease the addition of files to your file database. It is designed to help add files to the file database when a system is initially set-up, but may be used for minor maintenance. It operates by reading the files on disk for selected file areas, and add any files which do not already exist in the file database. If a file is already present, you may elect to have the date and size information in the database changed to match the information actually on disk. This process is referred to as freshening the database. As files are add to your WILDCAT! database with ADDFILES, you can enter descriptions, if desired. ADDFILES will process all file areas, or may be limited to specific locations. It is one of the easiest methods of creating a file database for the first time, or may be used for maintenance. In the REGISTERED version of WILDCAT!, the PRO! Series utility F-PRO! offers similar features with batch driven event operation, expanded operational parameters, and various reports. The opening screen allows you to specify which file areas will be affected by the ADDFILES session. Use the cursor to delete letters of file areas which you do not want to process. The next prompt allows you to confirm files prior to adding them to the database. If you are uncertain that your subdirectories contain only files to be made available, you may have ADDFILES prompt you for confirm of the addition of each by responding "Y". ADDFILES will then ask if you want to use the date of the file on the disk as the date entered into the WILDCAT! file database. If you do not, the current date will be used, and this is the most common choice. After you answer, the question changes to: Do you want to freshen the database date and size to match the file date and size on any existing files? [N] Answering "Y" will cause ADDFILES to scan the disk for filenames that already exist in your WILDCAT! file database, and change the database date and size to match what is on the hard disk. This is a convenient way to check your file areas for updated or changed files without any manual intervention. If the file dates and sizes are the same, no modifications to the database are made, and the file is ignored. ADDFILES then asks: Do you want to enter descriptions for ANY new files? [N]? Answering "Y" will allow you to enter a 2 line file description for each new file as it is read from the hard disk and added to ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 127 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── the file database. A "N" answer will simply add the files, but leave the descriptions blank. If you elect to enter the descriptions here, you are then asked: Do you want to be prompted Y/N for each new file description? [Y] If you answer "Y" then as each file is added it will first display the file name and then ask if you want to enter a description. You may then skip the description with a single keystroke, if desired. A "N" answer will force you to both line 1 and line 2 of the description for every file added. Lastly ADDFILES asks how the "UPLOADED BY:" field should be completed for the files being added. The default name is SYSOP , but may be set to anything you wish. After confirmation from the operator, ADDFILES begins processing the specified file areas, prompting for addition and descriptions as requested. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 128 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── CONVERT Convert is a utility to process the text file listings of a other BBSs or a plain directory listing of files into WILDCAT!'s database format. It is designed to be used for the initial database creation process, but may be called on to add files at a later date. In many instances the use of ADDFILES is a better choice to add file unless the descriptions are already type in some other BBS format. CONVERT is primarily needed if the sysop has already compiled a list of files and descriptions in a text format. CONVERT processes a text file and places the file names, sizes, dates and descriptions, if included, into the file database.We will review the procedures after a brief discussion of the text file format that must be used.The standard file list formats of other BBS programs do not usually contain the necessary information for WILDCAT!'s database, and will require alteration. New sysops will probably find it easier to use the ADDFILES program for initial database creation. Preparation for running CONVERT consists of creating a text file in each of your WILDCAT! download subdirectories. This text file may be a modified copy of another BBS text listing of the file information for that particular area, or the DIR command output. For the purpose of this documentation we will assume that the user has used MAKEWILD to establish two download directories, one for Utilities and one for Games. The path for Utilities is C:\WILDCAT\UTIL and the path for Games is C:\WILDCAT\GAMES. If you have another BBS text listing for each of these areas, place the file in the subdirectory and name it FILES.BBS. If you don't have a text listing but want to create one rather than use ADDFILES, you should create one for each subdirectory after placing all the appropriate files in the subdirectory. Move all your games to C:\WILDCAT\GAMES, etc.. The method of creating the text file from the DOS DIR command entails use of re-direction of the DIR output to disk rather than the screen. This is accomplished by using the > character. The proper command line syntax is: DIR > FILES.BBS This command should be run from the games subdirectory and again from utilities. The result is a file in EACH area named FILES.BBS which contains the name, extension, size, date and time on each file. It also has some header information on the drive volume label and footer information about the available space remaining. PRIOR TO PROCESSING WITH CONVERT, THIS HEADER AND FOOTER INFORMATION MUST BE DELETED with an ASCII editor. At the same time you may add a file description by beginning the first description line at character position 34, one space after the ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 129 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── date. WILDCAT! does not make use of the file time. Line 2 of the description begins on character position 74. Regardless of whether you are using another BBS text file listing or the DIR output, you must use an ASCII editor to delete all lines that contain any information other than files. The FILENAME, regardless of length always starts at position one. It may be written in the older DOS manner of FILE.EXT (with all characters together, separated by a period) or the newer format of FILE followed by the EXT starting at position 10. If the EXT begins at position 10 there may not be a "." in any position other than 9 since CONVERT looks for either a period or a space to terminate the FILENAME and begin the extension. The Size starts at position 15 and extends to 21, and may contain commas. It should be right justified and blank positions may exist at the beginning as in our example. The Date starts at position 24 and leading zeros may be omitted for any numbers. The only valid delimiter between month-day-year is the dash (-) character. The first Description line begins at position 34 and may extend out to position 73. Any description from position 74 to 115 will appear on description line 2. File lines may be up to 115 characters long, but only one file listing per line! We now have created a file named FILES.BBS in each of our download directories. Each reflects the names of the files in that particular area and contains nothing but one line after another of file information. To begin the conversion we start at the WILDCAT! file database directory, the location of the database files. For each subdirectory that you want to convert you must run the CONVERT program. Lets use our Games subdirectory as a first example. Copy the FILES.BBS file from the Games subdirectory to the WILDCAT! file database area and run CONVERT. COPY C:\WILDCAT\GAMES\FILES.BBS C:\WILDCAT\DATAFILE CONVERT When you run CONVERT, you are reminded of the correct file format and then asked to identify how the file list should be processed. The first question asks which file area you want the file to be assigned to. Our example answer might be area G for Games (this answer must match your choices in MAKEWILD!). Next CONVERT asks the name of the person who should be listed as uploading the files. In most instances this will be sysop or perhaps left blank since the actual information is not known. The final question is the filename that contains the text information. You would answer FILES.BBS since that is the text file we want to ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 130 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── process. After confirmation of the answers, CONVERT will add each file's information to the WILDCAT! database. The main trick to importing your files into WILDCAT! is to make sure that your import text file is clean and correctly formatted. No blank lines, no header or footer information and no extra lines. Prior to beginning, PLEASE make a back-up of your existing database file if they already exist, and take one section at a time. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 131 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── MAKEQUES Makeques is used to create questionnaire files in WILDCAT! readable format, and is the only way to make these files. WILDCAT! questionnaires have the ability to "branch" to any other question at any time, perhaps to ask sysops or another group of callers another set of questions. The easiest method of creating a questionnaire is to FIRST write down all the questions you want to ask. Put them in groups according to "branches" that are to be answered together, i.e. questions for sysops, questions for general users, questions IF an order is to be taken, questions IF a caller wants to register, etc. Question types available are Alphanumeric, Numeric, Multiple Choice, Phone, Date, Time, Zip, State, MC/VISA, or American Express. All of the above are FORMATTED field answers except Alphanumeric & Numeric, which restrict the answer to numbers/letters/punctuation or just numbers. The questionnaire ends anytime the last question number is reached (by entering a blank [ENTER] keystroke), or when a branch calls question #99. Branching is allowed both forward and backward, and questions are repeated until answered with a proper response. Do not attempt to branch to a non-existent question! Plan things out ahead of time! Here is an example of a planning session written out: (the numbers in parentheses refer to branch-to question numbers) 1. Do you want to purchase a product using a Credit Card? YES - (2) NO - (14) 2. Do you have the card # and exp. date handy? YES - (3) NO - (14) 3. What product do you want to order? A - WILDCAT! (4) B - MORTPLAN (4) C - PRTLABEL (4) 4. Do you want to order another product? YES - (3) NO - (5) 5. What name do you want it shipped to? (6) 6. What street address? (7) 7. What City? (8) ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 132 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── 8. What State? (9) 9. What type of credit card? A - VISA (10) B - M/C (10) 10. What is the card number and exp. date? xxxx-xxxx-xxxx-xxxx mm-yy (11) 11. What is a voice phone during the day to verify your order? xxx-xxx-xxxx (12) 12. Should we PROCESS or CANCEL the above order? A - PROCESS (15) B - CANCEL (13) 13. THIS order request will NOT be processed. Start the order over again? YES - (1) NO - (14) 14. No order taken. Do you want to leave an order comment? YES - (16) NO - (99) 15. Your order will be processed ASAP. Do you want to leave an order comment? YES - (16) NO - (99) 16. Comment (line 1 of 2) (17) 17. Comment (line 2 of 2) (99) After creating your written questionnaire you are ready to begin the MAKEQUES program. The Main Menu offers several choices, one of which is to LOAD a questionaire. A sample questionnaire names QUESTEST.BBS is included for your review. Next lets take a quick look at the MAKEQUES editor. While using MAKEQUES the following standard editing commands may be used. [left],[ctrl S] - Cursor left one character [right],[ctrl D] - Cursor right one character [ctrl left],[ctrl D] - Cursor left one word [ctrl right],[ctrl F] - Cursor right one word [home],[ctrl Q - S] - Cursor to beginning of line [end],[ctrl Q - D] - Cursor to end of line [del],[ctrl G] - Delete character at cursor [bksp],[ctrl H] - Delete character to the left of cursor [ctrl end],[ctrl Q - Y] - Delete to end of line [ctrl Y],[ctrl X] - Delete entire line [ctrl home] - Delete from beginning of line ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 133 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── [ctrl T] - Delete word to right of cursor [ins] - Toggle insert mode, large cursor [ctrl R],[ctrl Q- L] - Restore original contents of line The Main Menu presents the choices EDIT, LIST, EXECUTE, LOAD, SAVE, and an EXIT option. We will review the choices one at a time. the first option normally used is LOAD a questionnaire, unless a new questionnaire is being created, in which case EDIT might be used initially. You may follow this documentation with no questionnaire loaded, or may select LOAD at this time to get the QUESTEST.BBS questionnaire loaded in memory during this discussion. EDIT If editing is selected without previously loading a questionnaire, a blank screen is presented with the cursor on question number one. The lower section of the window indicates what information about the caller will be included at the beginning of the answer file, and these are labeled System Toggles. The bottom line of the display shows the function key assignments available. F1: "Insert line" and F2: "Delete line" are used to add and remove lines from your questionnaire. Removing or adding lines will automatically adjust the branch field question numbers for all relocated questions (more on this later). F3: "System Toggles" allows you to edit which user items are included in the answer file. After pressing F3 use the arrow keys to highlight the choice to change and press the Enter key to toggle the item on or off. F4: "Clear All" is used to clear the entire questionnaire screen and should only be used if you want to erase all questions. F10 is the "Exit" key used to return to the Main Menu. While working in MAKEQUES a copy of the last edited questionnaire remains in memory, and selecting EDIT again will return you to the last questionnaire used. When in edit mode enter the text you want displayed to the caller in the question text field. Note that only the first sixty characters are displayed, but the editor will scroll left and right as needed up to seventy-five characters. You may move about the screen to edit information by using the editing keys defined previously. The next field offers you the choice of which type of question will be asked. Pressing ENTER in the "type" field pops up a window with the available choices, touched on below: Text Alphanumeric text entry by the caller. Date Accepts standard US formatted date input. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 134 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Phone Accepts standard US Phone input with area code. Time Accepts standard time format HH:MM State Accepts 2 letters only, auto-capitalization. ZIP Accepts only numeric input, formatted for standard 9 digits (ZIP + 4). M/C Standard MasterCard format XXXX-XXXX-XXXX-XXXX followed by a request for expiration date. AmExp Standard American Express card format, followed by MM/YY for expiration date. SS# Accepts XXX-XX-XXXX format with numeric input only. Visa1 VISA card format XXXX-XXXX-XXXX-XXXX followed by expiration date prompt. Visa2 VISA card format XXXX-XXX-XXX-XXX followed by expiration date. Note that you should offer a choice of charge card formats, see the example questionnaire QUESTEST.BBS for an example. Note This question type doesn't ask for any input from the caller. It simply displays the question text and branches to the indicated question. It may be used to ask very lengthy questions by placing one or more NOTES prior to the actual question, or just to insert a comment in the questionnaire. END This type indicates the end of the questionnaire. Make sure there are no questions after the END question. Once the question TYPE has been selected the cursor is located in the Br (BRANCH) field. Each question has the ability to change the next question number, based either on the answer in a Multiple Choice or the entire question. You will notice that Multiple Choice questions have a editable branch field marked with a » since they have different branches for each choice. Pressing [ENTER] on a » branch will bring up the previously entered branches for each multiple choice in a window. There may be no blank question numbers between the first and last question. Any question which is used to end the questionnaire (there may be more than one since it may end from any number of branches) should branch to question 99. All question lines after the actual last question in the display should have question type END. Now we will review the balance of the options on the main menu. LIST ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 135 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── This option allows viewing a formatted output of the questionnaire on the screen, printer or a file. You are presented with a pop up window asking for a filename which will be used for the output. If printer output is desired enter the words PRINTER, or simply press ENTER for a screen display, with pauses. EXECUTE This option plays back your questionnaire. The screen is split, and the questionnaire in memory begins execution in the upper window and the answers are shown in the lower window> This allows checking both the branching and answer file responses generated as execution progresses. LOAD All MAKEQUES activity takes place in memory, and an existing questionnaire must first be loaded before it may be edited, executed or listed. SAVE After modifications have been made to a questionnaire in memory, a copy of the revised file must be saved to disk. EXIT This option prompts you to save a questionnaire in memory if you have not done so already. Note that you may leave the EDIT or LIST sections to execute without saving. A copy of the questionnaire is held and executed from memory. Remember, the question files created with MAKEQUES and the answers generated are kept in the home directory. Filenames that are read by WILDCAT! are as follows: QUESTION.BBS Display file sent when [Q]uestionaire is selected from the Main Menu prompt. It should contain a numeric listing of the questionnaires available, and functions just like the bulletins. QUES#.BBS Read at the questionnaire menu prompt, much the same way as bulletins. The # is replaced by the questionnaire number in QUESTION.BBS. QUESNEW.BBS This is the New-user questionnaire which is read by the system IF requested in MAKEWILD. It is presented just after NEWUSER.BBS. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 136 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── QUESCLOS.BBS This is the closed board questionnaire. It is sent by the system if the board is a Closed system as specified in MAKEWILD. It is sent immediately after logon if the user's name is NOT found in the database. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 137 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── WAIT! & WAITFOR! These two programs are handy utilities to program pauses into batch file operations. WAIT! simply pauses for five seconds (by default), and can be instructed to pause for any number of seconds with a command line argument such as WAIT! 30 to pause for 30 seconds. The time counts down on screen and the batch file continues at expiration. WAITFOR! accepts a command line argument for the time of day that the pause should be released. The time must be in 24 hour format such as 15:00 for 3 pm. WAITFOR! displays the time on screen as it awaits the designated time, then it simply stops running, passing control to the next batch file line. These two utilities are useful in event scheduling to keep the system inactive for a period of time, such as during a short event. WAIT! may also be used in a network setting to delay workstation login to the server long enough for the server to completely initialize and get ready for the workstations. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 138 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── FIXUSERS, FIXMSGS, FIXFILES WILDCAT! is distributed with these three utilities, programs designed to be used to for damaged databases and configuration files. These utilities should seldom need to be run except when an inconsistency develops in the database files. The symptoms of such a problem are error log entries describing database errors in files, messages or users, or inconsistent database operation. These programs should not be run on a regular basis as preventative maintenance. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 139 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ DOORS (NOT SUPPORTED IN THE TEST-DRIVE RELEASE) *************************************************************** *************************************************************** The following information is provided to give the operator a feeling for the door implementation in the registered release of WILDCAT!. *************************************************************** *************************************************************** A Door is a feature which allows WILDCAT! to run specific programs from outside the program code. Although Doors are not available in the Test Drive version, they will be discussed here for the sake of the user who knows nothing about doors, but would eventually like to implement them in the registered version. Doors can be written specifically to operate in a door environment or may be designed to operate under the redirection of CTTY, DOORWAY or GATEWAY. Again, CTTY is not recommended for door operation. When Mustang Software originally researched the state of door handling in a BBS system, we discovered that there was no standardized method of setting up for this external program operation. The Capitol PC User Group's program RBBS-PC handles this feature using a specific, defined format which is unique to RBBS-PC. There are many programs written which take advantage of the RBBS-PC format. Other BBS programs use yet other methods of passing parameters to the door programs. In fact, many use a number of different, incompatible methods depending on the version of the BBS that is in use. In an effort to standardize the door environment, WILDCAT! has contacted authors of RBBS and a number of door authors. We have reviewed the needs of this type program and established what we hope will be molded into a standard ASCII record for passing parameters for the door feature. The record criteria for this ASCII file, CALLINFO.BBS, is available from Mustang Software. This file is created and deleted by the system and usually will not be seen on your disk. Although a large number of WILDCAT! specific doors have been developed, Mustang Software, Inc. does not write any door programs. We have made provisions to allow WILDCAT! to run many of the extensive number of doors already available for most other BBS systems. The only door distributed with WILDCAT! is DOORTEST which is a simple test program that will verify your batch file and configuration settings. We will review the setup of DOORTEST to familiarize you with standard door operation. All DOORTEST does is echo back the name of your BBS System and allow the remote caller to type a test message on the screen. If it operates properly your procedural parameters and hardware are working correctly and other programs can be installed. We refrain from distribution of other door programs since most are products of other shareware authors who may have distribution █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 140 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ restrictions. Many of the more popular choices are available on the MUSTANG SOFTWARE WILDCAT! HQ PUBLIC BBS as well as other WILDCAT! BBS systems. DOOR IMPLEMENTATION (NOT SUPPORTED IN THE TEST-DRIVE RELEASE) Doors are started by the caller by selecting the Main Menu command [D]oors. This presents the display file DOORS.BBS (or DOORS.SCR) which should be created to contain the choices available, much like the Bulletin menu BULLET.BBS. In order for this feature to function, WILDCAT! must find DOORS.BBS in your path for doors designated in MAKEWILD. The caller then selects a number choice corresponding to the program they wish to run. This number is the key to which batch file is invoked by WILDCAT! since a batch file named DOOR#.BAT will be executed. Batch files for the doors available must be located in the WILDCAT! startup directory, the same area where MAKEWILD was run and where CAT.BAT was started. The actual behind-the-scenes processing by WILDCAT! from this point is important for a complete understanding of door operation. At the point that a program is selected by a caller, WILDCAT! creates an ASCII file named CALLINFO.BBS that contains complete information about the caller who invoked the door. WILDCAT! then makes a copy of the requested door batch file (perhaps DOOR1.BAT) under the new name DOOR.BAT. This generic name is the actual batch file name executed later. WILDCAT! then sets the errorlevel to 50, terminates and removes itself from memory. You will note that this is the same process used in remote drop to DOS and external events. The balance of a successful door operation rests with the proper batch file configuration. The first requirement is that the CAT.BAT file tests for errorlevel 50 to see if a door has been requested. If so, it must pass control to the batch file DOOR.BAT, our generic name which is now the same as the door requested by the caller. As indicated previously, DOOR.BAT is simply a copy of DOOR#.BAT for the correct # door that has been requested. For each available door the sysop must have created a batch file to run the program, including any conversion routines required. For example, if door #1 is DOORTEST then the batch file that is copied to DOOR.BAT for execution is DOOR1.BAT, and it must contain every command needed to run the door from the instructions give by the door author. Lets take a look at DOORTEST now. In order for proper operation it needs a configuration file, like many other doors you may encounter. It does not require any conversion programs since it was written specifically for WILDCAT!, and knows how to read the CALLINFO.BBS file directly. Later in this section we will review procedures for doors which cannot read our CALLINFO.BBS file, and how to perform a conversion. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 141 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ The configuration file required is named DOORTEST.CFG, and is a plain ASCII text file of three lines. Line one must contain the number of your com port as a numeric character such as 1, 2, 3, 4, etc.. Line two must contain the complete name of your caller information file (CALLINFO.BBS), including the entire path. Remember that CALLINFO.BBS is located in your startup directory, so this line might read C:\WILDCAT\CALLINFO.BBS. The third line in the configuration file should be the name of your BBS system. An example DOORTEST.CFG file would be: 2 Your communication port number C:\WILDCAT\CALLINFO.BBS The complete name of the call information file, including the full drive and path. Mustang Software Private BBS The name of your BBS system Once we have created the configuration file we can continue setting up the batch file to invoke our test door. We will assume that the test will be door number 1 in the door menu file (DOORS.BBS), and will call our file DOOR1.BAT. The command line for starting the DOORTEST program is simply the program name DOORTEST followed by the name of the configuration file DOORTEST.CFG. Our batch file looks like this: DOORTEST DOORTEST.CFG This is the actual program. The command line argument DOORTEST.CFG is a text file containing information needed by DOORTEST to operate properly. It includes three lines with the COM port number, the path to the CALLINFO.BBS file and the BBS name. CAT This invokes your startup batch file after the door has completed. CAT.BAT is then responsible for getting WILDCAT! back on line properly. When the above batch file is executed the door program runs and then the CAT.BAT file is called to re-start WILDCAT!. Every door program operates in a similar manner, and each must call CAT.BAT at the end to restart the BBS. Since our DOOR.BAT has called CAT.BAT it's now up to WILDCAT! to determine if it is returning from a door or it is just a fresh startup of the program. It accomplishes this by first checking for the existence of carrier detect (to see if someone is connected), and then for the CALLINFO.BBS file. If carrier is present, it then checks for the file, and if both exist WILDCAT! assumes that this is a return from a door, and reads CALLINFO for █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 142 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ the callers name. It then deletes CALLINFO.BBS and reconnects the user. During the return from a door a user is asked to verify his identity with his password ONLY if the program is answering the phone using modem auto-answer. If ring detect is being used (auto-answer is disabled), there will be no prompt for password since there is no possibility that the caller is other than the person listed in CALLINFO.BBS. If Carrier Detect is not present but CALLINFO.BBS exists, it is erased after first charging the user for his time in the door, since he obviously was disconnected or hung up inside the door program. If Carrier Detect is found without CALLINFO.BBS, WILDCAT! attempts to lower it and complete initialization normally. Keep in mind that a return to WILDCAT! from a door requires a complete startup of the WILDCAT! program, including everything contained in your CAT.BAT file. In order to minimize this return time we encourage you to place the minimum amount of commands necessary in CAT.BAT. If you need to establish RAM disks or copy files to different locations to establish your operating environment, it is suggested that these other activities be carried out in an AUTOEXEC.BAT file rather than in CAT.BAT. As mentioned earlier, there are many doors written for other BBS program environments. In order to operate these door programs, the sysop needs a conversion utility which creates the required system files for the other BBS program from our CALLINFO.BBS file. The private registered WILDCAT! BBS contains up-to-date conversions for all other BBS door programs. The proper use of these utilities is included in a documentation file with the conversion program. It usually consists of an additional line in the door batch file consisting of the conversion program name, such as WC2RBBS, which creates a configuration file for RBBS-PC from our CALLINFO.BBS file. CAUTIONS, CONCERNS AND CAVEATS ! The above explanation of doors is simplified and assumes that no problems are encountered. The actual operation a number of events may occur that interrupt either the remote user's connection or the batch file operation. Both of these circumstances could cause problems ranging from a locked-up system to a serious security breach if not handled properly. This section deals with methods to protect your system and its users from such problems. Carrier Detect Monitoring The first possible problem to overcome is that of a caller who drops carrier during a door. This could cause the door program █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 143 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ to sit idle indefinitely! Unless the door is watching the carrier detect status, a locked system could result. All reputable door programs monitor CD as part of their operation, and automatically terminate when carrier is lost, returning control to the batch file which will then call WILDCAT!. This is the best protection available. In the event that a door does not handle this chore, you should think twice about running it! Although there are several utility programs which will monitor carrier and reboot if CD is lost, we recommend against their use since a system reboot is not desirable just because someone drops carrier. Users quickly discover that they can drop carrier at the end of a door to keep the time spent in the door from being subtracted from their daily time allotment. Ctrl-Break and Ctrl-C Lockout The second obstacle to be overcome to successfully run doors involves securing your batch files from interruption, either intentionally or otherwise. Most users are familiar with the use of CTRL-BREAK or CTRL-C to prompt for termination of a batch process. Allowing a remote caller to do this during execution of a door could be a catastrophe! Remember that every door makes use of a batch file, one that must be protected from the use of Ctrl-break. Fortunately most doors are specifically written to direct their own input and output to the communications port, and may not be interrupted. We suggest use of a program similar to BRK.COM and BRK.DRV (Control-Break driver) to protect against unwanted actions by disabling the use of Ctrl-C and Ctrl-break. BRK may be placed in any batch file followed by the command line argument ON or OFF to enable or disable trapping for the Ctrl-break, and Ctrl-C keystrokes. We strongly recommend that the command line BRK ON be placed in your CAT.BAT file to prohibit the undesired characters throughout WILDCAT!'s operation. The protection will extend through doors, Remote Drop to DOS, and external protocols. You may also turn the trapping off at the end of CAT.BAT with the command line BRK OFF to allow local use of the Ctrl-keys after a normal exit with the F10 key. An alternative method of using CAT-TRAP would be to place the ON command as the first line of each batch file, and then turn it off as the last command in each. This method requires much more intervention on the part of the sysop to ensure that all batch files are protected, but allows flexibility such as use of Ctrl-C during a local drop to DOS with ALT-D. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 144 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ Regardless of the method of implementation, we strongly recommend that batch file protection against Ctrl-break and Ctrl-C be incorporated as a basic part of your system security. Lets look at an example of the above precautions in action. The expanded CAT.BAT file may look something like the one listed below: BRK ON the program CAT-TRAP turns ON trapping and disables the CRTL- BREAK command. :RELOAD label to restart CD \WILDCAT assures that we are in the right directory for starting WILDCAT! CTTY CON redirects input/output to the keyboard and screen IF it has been changed by DROPDOS.BAT WILDCAT starts WILDCAT! IF ERRORLEVEL 50 DOOR.BAT calls up the door program (checking remains turned ON for Ctrl-C and Ctrl-break). IF ERRORLEVEL 40 DROPDOS.BAT calls up batch file which allows remote drop to DOS. IF ERRORLEVEL 20 BAK.BAT calls up batch file for event J. In this example event J does a backup. IF ERRORLEVEL 1 GOTO RELOAD sends batch processing to the label RELOAD if the errorlevel is set to 1, an abnormal exit due to an error or other problem. BRK OFF the program CAT-TRAP turns OFF trapping for CTRL-BREAK and enables the use of it again now that WILDCAT! is terminated. Remember that the processing never gets to the last line unless the sysop has used F10 to exit WILDCAT! normally. User Verification on Return to WILDCAT! The last item of concern when operating doors has to do with the possibility of a person other than the original caller getting on the system at the close of a door. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 145 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ The problem arises if the sysop has set MAKEWILD and the modem to auto answer, either by dip switches or a software command such as ATS0=1. In that case the original caller could have been disconnected during the door for some reason, and anyone could have called in after the disconnect but before WILDCAT! re- cycled. This is a period of perhaps 10 seconds or more depending on the length of CAT.BAT and modem delays. The modem would answer the phone and then establish carrier for the new caller. Now we have a situation where WILDCAT! comes to life, finds a carrier present and then looks for CALLINFO.BBS and finds it as well. WILDCAT! then assumes that the original caller whose name is in CALLINFO.BBS is returning, but we know better.... To prevent security problems in this regard, WILDCAT! will always ask for the user's password if MAKEWILD is set to answer the phone by auto-answer. If ring detect is being used rather than auto-answer, no password is requested on return from a door since no other caller could have established a connection. To avoid any possible security problems, Mustang Software strongly recommends that sysops who implement doors answer phone by ring detect. Forcing WILDCAT! to answer the phone by ring detect (internal monitoring of pin 22) assures that the modem will not acknowledge any new callers since it won't even look at pin 22 until after checking for a return from a door. If Auto- answer MUST be used, WILDCAT! will request a password on each return to WILDCAT!. Door Technical Support One final note about doors. Due to the differences in setup and configuration of this feature for each door, we must limit our technical support calls to problems with the WILDCAT! interface only. This means that the we are unable to extend advice on specific door operation or hardware system configurations. We will assist in configuration of the DOORTEST program but after proper operation of DOORTEST, the responsibility for installation and operation of specific programs rests with the user. We make NO commitments that any door program will run properly on your system. Each door operates differently and may require a conversion program, special device driver, basic run time module (BRUN40, etc.), or other type of manipulation to operate. Some versions of DOS, in combination with some IBM compatible hardware, do not function properly with the CTTY command or with some doors. THIS IS A DOS/HARDWARE PROBLEM, AND NOT A FLAW IN THE WILDCAT! PROGRAM. Most of these situations can be overcome using DOORWAY. Questions on specific doors should be directed to the program author. We encourage program authors to contact Mustang Software for program configuration advice and possible testing of their product within our beta group. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 146 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ We suggest that sysops making use of this feature call the WILDCAT! HQ BBS and interact with the special message folder and file area devoted exclusively to doors. ******************************************************************* ******************************************************************* END OF DOOR SECTION, NOT INCLUDED IN TEST-DRIVE RELEASE ******************************************************************* ******************************************************************* █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 147 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ MUTLI-LINE OPERATION (Not supported in TEST-DRIVE) **************************************************************** **************************************************************** This discussion of Multi-line and network operation is provided to answer questions regarding the WILDCAT! multi-node operation. **************************************************************** **************************************************************** As indicated in the Software License Agreement, any multi-line version of WILDCAT! may be used "on multiple computers that are connected by direct cable to the same network server". It is not licensed for use at multiple locations. Any questions regarding your rights under the Software License Agreement should be directed to a corporate officer of Mustang Software, Inc. for clarification. OVERVIEW Users installing the multi-line version for the first time, as well as those upgrading from a single-line version should first set up a single line system, then add additional lines according to the information given here. HOW IT WORKS When writing the program code for a multi-line BBS system there are at least two ways of addressing the task of talking to more than one communications port at the same time. The first makes use of "internal program multi-tasking" where a single PC/AT handles the port addressing for all lines, and internally directs the program responses to the ports as needed. This type of setup has the advantage of needing only the one computer, but is limited in that it cannot perform any BBS activities which require outside program or DOS shell support. It is not possible to run doors, external protocols, or any other program as a sub-process. The second uses multiple-program operation, a method in which a separate copy of the BBS program is loaded into memory for each line or node. This type setup allows the flexibility for every individual line to perform whatever activity or BBS maintenance event is desired, while allowing the remaining lines to perform independent activity. The disadvantage is the extra memory required for multitasking software, or additional hardware for network operation. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 148 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ WILDCAT! makes use of this second method of multi-line operation for the advantages it offers. This type of setup is required for doors and external file transfer protocols in a multi-line system. HARDWARE Prior to explaining the procedures for setting up a multi-line BBS we will review the necessary hardware and software conbinations that may be used. In the following discussion the term "multi-line" is synonymous with "multi-node", and the two may be used interchangebly. Likewise, both a "line" and a "node" refer to a single WILDCAT! session connected to a single modem and phone line. We have designed all version of the multi-line WILDCAT! to operate in single line mode on a single PC system, or in multi- line mode in any of three general configurations: 1. LOCAL AREA NETWORKS WILDCAT! includes support for file and record locking under Novell, 3-COM, Banyan Vines, PC-MOS 386, CBIS Net, LANtastic, and any networks that truly support DOS 3.x SHARE. Keep in mind that a number of peer-to-peer networks claim support of SHARE but do not actually have it! If in doubt, try running our Network message program "Brainstorm" on the network in question and saving several messages at the same time. In a LAN environment, each WILDCAT! line operates on a separate computer connected to the other PCs or ATs via network cable. Each line runs its own copy of WILDCAT! which is loaded from a network "server's" hard disk. A "server" in this context is used to define any computer in a LAN setting that allows sharing any of its peripherals such as hard disks, printers or other devices. Some network configurations only allow sharing programs located on a "dedicated server", one that only performs LAN management functions. Others enable sharing of disk devices located in other workstations and are normally referred to as peer-to- peer networks. In a network which allows multiple "servers", the server computers can also be used as a workstations for a WILDCAT! node. Each workstation running WILDCAT! is assigned a separate and unique WILDCAT! Node ID Number in MAKEWILD, in an additional screen. Regardless of the type of network used, only one copy of the WILDCAT! program and support files needs to be kept on the disk . This one copy is available to each workstation running a WILDCAT! node. All workstation nodes may update and access a common message, file, and user databases if desired. Each node requires it's own PC (512K suggested, single floppy is ok), a modem, a telephone line, and a █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 149 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ connection to the network. Local logon sessions on a network do not require a modem or phone lines. 2. SLAVE CARD SYSTEM This setup requires an AT or clone, and a slave card such as Alloy's PC-Slave, which is available in 8088 (NEC V-20) and 80286 versions. A slave card usually contains a CPU (8088/V-20, or 80286), a serial port, a keyboard port and a monitor port. Each slave card is actually a PC on a card which interacts with and shares the other peripherals in the PC, including the hard disk. In brief, a slave card environment is one in which a single machine adds one or more slave cards with a modem and phone line connected to each slave card. WILDCAT! is loaded in the memory of each card just as if it was a separate PC system, and it uses the shared hard disk of the main system for storage. Some slave systems allow viewing access to each slave PC environment via the main system keyboard and screen. The cost factor in this setup can approach or exceed the LAN setup, depending on the network type and PC cost. A spin-off on the slave card environment is the multi-PC card from CUBIX. It installes in a Novell network server, and operates 2 workstations from within the network server. 3. DESQVIEW For those interested in running only 2-3 or possibly 4 nodes, it can done on a single 80286/80386 system under DESQview, a multi-tasking operating environment available from Quarterdeck Office Systems, 150 Pico Blvd., Santa Monica, CA 90405, (213) 392-9701. Although very fast 286/386 combinations may be able to run 3 or 4 nodes, we have found that performance may suffer significantly on slower systems when more than 2 serial port applications are opened. We will only recommend 2 ports under DESQVIEW unless you are prepared to upgrade your serial port UART chips, and are using a 386/20MHz AT or faster. DESQview setup involves purchasing DESQview ver. 2.25 or above from Quarterdeck, and installing it on your 286/386 system. Versions prior to 2.25 will not operate well with multiple serial applications, and are not recommended or supported by Mustang Software. In order to establish 2 DESQview applications you will need at least 512K of Expanded memory (NOT EXTENDED). Make certain that the memory board you purchase is fully compatible with the DESQview memory manager - check with Quarterdeck for details. In general, you need memory which meets the specifications for either AST's EEMS version 3.2 or LIM 4.0. CAUTION: Most attempts at utilizing EXTENDED memory to emulate EXPANDED memory will prove unreliable when performed █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 150 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ in a multi-tasking environment. This is due to the continual switching back and forth between the "real" and "protected" mode of CPU operation which can result in lost interrupts and system lock-ups. We do not recommend extended memory use for any purpose, even extended memory which is "converted" to EMS memory by use of a software driver. This type of multiple line installation is the only one in which the performance of the BBS program may be hindered, due to DESQview's time-slicing. By contrast, both LAN and slave cards offer almost full throughput with no degradation. The number of nodes actually possible under DESQview will depend on a number of variables, including the speed of the microprocessor & clock, the baud rates of the connections supported, and the speed of the hard disk. The memory requirements for WILDCAT! operating under DESQview are approximately 300K - 320K for each copy of WILDCAT!. This means that the total memory required easily exceeds the 640K base memory area. A system with 512K of expanded memory will operate well for 2 lines. Although our recommendation is for no more than 2 nodes in a DESQview environment, there are a number of situations which may allow additional nodes to be added. If an exceptionally fast 286 or 386 CPU is used you may very well find that an additional node or two can be added with only minor impact on performance. Likewise, if the majority of your callers will be operating at 2400 baud, or if your BBS activity excludes downloads where speed is a factor, additional nodes may also be possible. Testing in a proposed installation is the only method of determining the actual limits for a system. The choice of multi-node configuration is left up to the user. A later section of this manual contains more specific hardware installation references and suggestions for maximizing performance in each of the hardware environments. SOFTWARE & STRUCTURE This section reviews the principles, assumptions, and background information needed to successfullly operate WILDCAT! in a multi- node environment. You should not attempt to install a multi-node system until you have successfully installed a single-line. Regardless of the method of hardware installation, the software and directory structure is basically the same. This discussion will assume that all WILDCAT! related files are stored on a single hard disk in a dedicated network server (or a single hard disk in the computer using the slave cards or DESQview). In reality the subdirectories may be located on any hard disk or █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 151 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ subdirectory in any computer accessible by the nodes needing the files. Much of the discussion in this section is intended to help prepare your answers to the MAKEWILD screen "Node Information" (only in the REGISTERED USER version) since a separate configuration file (CONFIGWC.BBS) is needed for each node. The file structure for multi-line is very similar to that for single line operation. We begin creation of our multi-line system with the first single node in C:\WILDCAT. The WILDCAT! program files should already be located in this main area (C:\WILDCAT). These include WILDCAT.EXE, WILDCAT.OVR, MAKEWILD.EXE, CONVERT.EXE, ADDFILES.EXE, WAIT!.EXE, WAITFOR!.EXE, MAKEQUES.EXE, CATEYE#.EXE (if available), and the PRO! Series .EXE files (if available). The files in this area will be made available to the individual nodes through a path statement in the AUTOEXEC.BAT file with wording PATH=C:\WILDCAT, or whatever actual pathname is appropriate. This path statement must be added to your AUTOEXEC file if it is not already present. Next we need to create a new WILDCAT! "startup directory" for each additional node on the system. This is a very important step! Every node in a WILDCAT! multi-line system must have its own startup directory, and its own unique node ID number. This directory is the location where MAKEWILD is run for each node. Remember, the actual MAKEWILD.EXE program does not need to be in this startup directory, it will be located through the path statement. The subdirectory contains the node specific information from MAKEWILD in the CONFIGWC.BBS file, and is the starting place for each node's CAT.BAT file. Our first node can still be started from the main WILDCAT! startup directory and does not need to be altered. In our example (a 2 node BBS) the startup directories may be identified as C:\WILDCAT (for node 1) & C:\WILDCAT\NODE-2 (for our second line). Multi-line configuration also entails creation of separate directories for external protocols, and common areas for messages, files, and users, if shared. Since each node creates its own configuration file (CONFIGWC.BBS) in its own startup directory, each may customize the locations of all other support files. This is done in the MAKEWILD "Node Information" screen. In our presentation here we will assume that all files are shared, although each node could access different menus, bulletins, doors, and other files. If you want different nodes to have different bulletins, questionnaires, menus, doors, or display files you should change these path names in MAKEWILD for each node, and create different subdirectories and files. Lastly, each node must assign a MASTER path to indicate which nodes are included in a "system". This "system" is simply a reference to which nodes may be connected in multi-node chat, which nodes contribute to the total call count for the system, and which nodes can be checked for status, such as up/down/waiting for calls, etc. by the CATEYE TSR program. If █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 152 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ you want both lines to have a combined call count and to be able to enter inter-node chat the MASTER paths must be the same. A node may be part of a "system" by sharing a MASTER path with others, but still access different messages, files & users. In this case the node will contribute to total "system" calls, will be able to participate in inter-node chat (if it is made available to callers), and will be shown as a node in the [W]ho is online command. An example of such a configuration is the Mustang Software Public access BBS which has completely separate databases for users, files, and messages, but shares a MASTER path with the Private WILDCAT! HQ BBS system for registered users. The callers to the public system have the ability to check out the other node access with [W]ho is online, although we have disabled the inter-node chat command for that node. As mentioned previously, the Startup Directory is the location of the MAKEWILD configuration file CONFIGWC.BBS. Since each node creates its own file in its own directory with its own unique node ID number, the sysop may exersise a great deal of variety in the configuration. For example, in a network environment with several nodes actually taking calls from phone lines, you might create almost identical CONFIGWC files. You may even create just one and copy it to the other directories for minor modification of Node ID number and path for external protocols. Other workstations on the network, even without a modem, can also be assigned a node number and startup directory as well, and access the BBS system via a local logon with the COM port set to 0 (zero). The name of the sysop for the non-modem local nodes may even be listed as the name of the local PC user to enable easy sign-on with F1. As an example of the above, all Mustang Software staff have listed our individual names as "sysop" in the MAKEWILD configuration for our local access nodes, allowing each of us to logon with F1 and bypass the initial welcome messages. You may even specify that a local node should perform an errorlevel 60 after each which results in immediate return to DOS after every local sign-on. The important thing to remember is the settings will only affect the one node that starts up from the directory where that particular MAKEWILD configuration is located. Many variations are possible, just be certain that each node is assigned a unique WILDCAT! Node ID in its MAKEWILD configuration, one which is different from all others, whether connected to real telephone lines or other local node sessions. The MAKEWILD screen "Node Information" is the primary location of multi-line configuration. The initial questions deal with the directory paths for various items discussed previously. These first questions apply to both single-line and multi-line installations. The balance of the items deal primarily with multi-node setup, and do not even appear unless your WILDCAT! version is capable of multi-line operation. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 153 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ Node ID: Each node MUST have a different ID number, within the range allowable for the version of WILDCAT! installed. Numbers do not have to be used in sequence, but each node number must be unique. DUPLICATION OF NODE I.D. NUMBERS WILL RESULT IN LOCK/UNLOCK CONFLICTS! Security to access node: This value represents the minimum level needed to connect to a specific node. In situations where lines are reserved, such as our beta test node, access may be limited to prevent lower level users from connecting even if the phone number is obtained. The display file NO-#.BBS is sent to callers denied access, where # is replaced by the node ID number, i.e., the file NO-4.BBS is sent if it exists to a caller to node 4 who has too low a security level for access. Overwrite chat file: The group and private chat feature operates by creating a disk file containing the text entered by the callers engaged in chat. This file is then read by each node in chat whenever it is updated with text from another node in chat. This is the only method of sending information to the proper locations in an orderly manner. More details of chat file operation is included later in this manual. This option allows the sysop to specify whether the disk files are started fresh each time a chat is initiated, or if the text of new chat sessions should be appended to the end of the current file. Appending rather than overwriting allows the sysop to view the contents of chat sessions which took place since the file was created using the VIEWCHAT.EXE utility. On an active system the chat files can rapidly grow quite large, and should be monitored for deletion just like the ACTIVITY.LOG. The response to this question also controls the capture file used when the sysop answers a page or initiates local chat with the F7 key (REGISTERED USER version only). The capture file PAGED.CAP is either appended to or overwritten the same as the inter-node chat files. Network type: Pressing the spacebar cycles through the available choices. Specific networks include Novell, PCMOS 386, and CBIS Net. The choice DOS 3.x SHARE should be selected for any other network which truly supports or emulates the SHARE command. These include Banyan Vines, 3-COM, LANtastic, and many others. The final choice is SINGLE LINE for non-network use. IF YOU ARE OPERATING A WILDCAT! RELEASE WHICH IS CAPABLE OF MULTI-LINE, BUT ARE ONLY RUNNING A SINGLE NODE SYSTEM, YOU SHOULD SET THIS TO SINGLE LINE. If set to DOS 3.x SHARE when only one line is in use, the SHARE program must be loaded. Since no file and record locking is needed with only one node, loading SHARE is a waste of memory and processor resources. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 154 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ At this point we have reviewed the multi-line criteria which apply to all configurations, and will proceed with a short discussion of installation considerations for several specific types of networks and multi-tasking systems. Review the sections dealing with your particular installation. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 155 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ NOVELL Novell, like a number of good networks available, offers a great deal of configurability which is useful in a WILDCAT! environment. We suggest making use of the following specific network options or their equivalent with WILDCAT! multi-node. Novell does not require loading the optional Novell NetBIOS module at the workstation level when loading WILDCAT! from a network disk. Simply load the workstation shell with ANET3 (ver 2.0a) or IPX and NET3 (ver. 2.12 & 2.15). WILDCAT! directly supports Novell without SHARE or the NetBIOS programs. The exception to this is when WILDCAT! is loaded from a non-network disk such as drive C:, even if the PC is attached and active on the network. Use of a non-network drive is supported without SHARE under Novell, as long as WILDCAT! is loaded from a network drive. Novell offers several versions of NetWare including the entry level system ELS Level I, ELS Level II, and Advanced NetWare. ELS I is limited to 4 workstation connections, including a non- dedicated server that can operate as a workstation. ELS II is limited to 8 workstation connections and also makes use of a non-dedicated server that doubles as a workstation. Both of the above are priced significantly lower than Advanced NetWare which will allow connection of up to the maximum 250 WILDCAT! nodes. We have found that Advanced NetWare ver. 2.15 is capable of operating two nodes on a single workstation using the multi- tasking program DESQview. This type of configuration allows operating a six line BBS on only 3 AT's connected as Novell workstations, with each AT running 2 BBS lines. CAUTION: This setup has not been tested at this time on ELS NetWare! Contact Mustang Software Technical support before purchasing a Novell ELS network for this type operation. Configuration Establish a user name such as NODE-1 etc. for each node on the system. Assign the "user" security access for read, write, modify, and create access rights to all files in the STARTUP directory for each node. Remember that Node-1 will use the main WILDCAT! directory as the startup area, while additional nodes nust have separate startup directories. Extend these rights to each EXTERNAL PROTOCOL directory, MENU directory, HELP directory, DISPLAY directory, BULLETIN directory, QUESTIONNAIRE directory, DOOR directory, DATAFILE directories, MASTER directory, and any directories containing downloadable files. Assign read rights to the WILDCAT! program directory (even though this is the same area where node-1 is started) to enable every node to load the program files. The "user" does not need access rights to the rest of the system, except perhaps the the "public" and "logon" directories if you will want to do system maintenance from the node workstation under the node username. You may want to █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 156 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ establish a group name such as BBS and assign these rights by group rather than individually by node names.. If your network supports it (Novell does), you may establish a drive "MAP" to your external protocol directory to enable addressing it as a single drive letter. For example, our actual path to the protocol directory for node 2 is F:\REGISTER\NODE-2\PROTOCOL but it is addressed in MAKEWILD as simply Y: since we include the Node-2 login script command MAP Y:=SYS:/REGISTER/NODE-2/PROTOCOL As you can see, the MAP command functions much like the DOS command SUBST. This allows WILDCAT! to pass a much shorter command line to the shell, such as Y:ZDOWN.BAT filename1 filename2 etc. A Novell system using a fast hard disk in the server with ample disk caching memory can easily handle a very large number of callers. No system degradation is usually noticed with the WILDCAT! database "safety mode" set to FULL. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 157 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ PEER-TO-PEER NETWORKS This section reviews network considerations generic peer-to-peer networks using LANtastic as an example. The operational features discussed apply to most similar LANS except for network specific recommendations. From an operational viewpoint, these networks will function much like any other. The primary difference for a WILDCAT! installation is the use of multiple "servers". If multiple workstations are used as servers for various system resources, these same server/workstations may also be used as a WILDCAT! node. Each node must still be given a unique Node ID, and must reference its own private startup directory and external protocol directory. LANtastic This network operates WILDCAT! well when configured properly. The following network parameters have been found to increase reliability and improve operation: DOS ver. 3.1 or 3.3 are recommended, version 3.2 is not fully compatible with the network communication interfaces. The SHARE command is not necessary since LANtastic emulates SHARE in the LANBIOS. The use of a small disk cache system with LANtastic is recommended for best performance. For additional information, contact Mustang Software, Inc. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 158 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ SLAVE CARDS These follow the same WILDCAT! software setup procedures as a network. The only real difference here is that SHARE must be loaded in EACH SLAVE ENVIRONMENT. Alloy's PC Slave system is established to act much like a network with no cables connecting the individual workstations. Instead, each workstation computer is actually a card installed into the bus on the "server". Alloy's own network software is NTNX. Setup the hardware and software according to the instructions from Alloy. If the slave cards are populated with 1 megabyte of memory we recommend allocating 512K for the slave partition and the remaining 512K as system disk cache within NTNX. The WILDCAT! configurations on the slave cards are established on the server hard disk exactly like any other network setup. Create separate startup directories for each node and create the required node areas for external protocols, if used. This setup may be done from the server console, but each node must actually be started and tested by its own autoexec.bat file as describe in the documentation. The individual slave cards may be accessed by connection directly to the cards via terminals (monitor & keyboard). Alloy cards also operate with the utility program NXSCAN to control slave cards from the server in real time without using additional terminals. The NTNX software includes a utility to monitor each slave from the server, although interaction is not possible. When operating in a slave system, all WILDCAT! sessions MUST make use of answering phone by Auto-Answer since Alloy uses the ring detect line (pin 22) internally to reboot the individual slave systems from remote. Using auto-answer may have an impact on your door operations, and you are cautioned to review the disadvantages of using auto-answer with doors or external protocols. See the door section of Advanced Features for details. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 159 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ DESQview DESQview should to set up with two windows (or more, limited by your PC), and follow the same WILDCAT! software installation procedures as a network. The only real difference here is that SHARE must be loaded prior to starting the DESQview program with DV or XDV. There is no need to load SHARE in each DV window. WILDCAT! is DESQview "aware", and will recognize when it is operating in a DV environment. When the presence of a multi- tasker such as DV, TaskView, or OmniView is detected WILDCAT! automatically performs direct screen writing to an alternate video buffer provided by DESQview. When configured properly WILDCAT! is able to run in any size screen window, in foreground or background mode, with no interference with other programs. We recommend use of DESQview version 2.25 and above only. We also strongly suggest use of the 16550A UART chip as a replacement for the 8250 or 16450 found in most RS-232 boards. The use of this chip becomes even more important when more than two WILDCAT! nodes are configured on a single machine. This chip is inexpensive and is available from a number of sources at a nominal cost, including Arrow Electronics at 1-800-932-7769. The Initial setup of DESQview (SETUP.BAT) allows setting performance parameters which affect the processing time allocated to foreground and background tasks. You will want to experiment with these settings, but should begin with each task receiving equal time if both are operating a WILDCAT! node. Start with 3 ticks for each node. If you are operating a single BBS in the background while using the foreground for other activities such as word processing, you then should allow the background task more time by a factor of about 3. The following screen shows the major setup parameters and the proper settings for a 2 line BBS under DESQview. The important parameters here begin with the second half of the page. Optimize communications must be set to "Y" in order to operate high speed modems reliably. In addition, you should load the WILDCAT! node that uses the highest baud rate first. Doing so prevents the 0-640K area of memory from becoming fragmented since communications programs are never swapped out, and guarantees the best transfer speeds. In addition, if an Enhanced Expanded Memory board (EEMS) is being used DESQview will make use of its "instantaneous" mapping registers for the first program while assigning all other programs to the slower registers with mapping overhead. Remember that the processing power of your PC ultimately limits how many high speed communications programs may be run simultaneously without dropping characters. Swapping of programs may be set to "Y", although WILDCAT! should never be swapped out of memory. This parameter simply allows other programs this option. Printer contention should not be █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 160 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ managed since DV will suspend a program that attempts to print if another is already printing. We recommend setting DV to indicate that WILDCAT! does NOT write directly to the screen (even though it does) since the video buffer is automatically redirected by WILDCAT! internally. Fine tuning DESQview parameters may be helpful in any individual installation. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 161 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ The following are WILDCAT! program areas which are affected by multi-node operation, and may need additional explanation. The WILDCAT! multi-node program code performs both file and record locking, unlike many other BBS packages which only make use of file locking. What this means to you as a sysop is enhanced versatility and operation. For example, when operating several nodes at one time, WILDCAT! is able to perform sweeping changes including deleting messages in the wastebasket, since any messages currently being "used" by a node are simply ignored due to the record lock. Record locking allows the PRO! series to actually perform major database updates to most items without disabling all nodes. File locking systems prohibit this type of access. We provided the newest file structures to developers who wish to upgrade their products. The new databases make use of the B-Tree Filer 5.0 from Turbo Power Software, Scotts Valley, CA. DATABASE SAFETY MODE The "safety" mode of database operation is configurable in WILDCAT! Multi-Line. It can be set for "FULL", "PARTIAL", or "NONE". The default setting of "PARTIAL" will perform additional database activity of flushing the buffers after each access. Although this will virtually guarantee that a power failure will not cause data corruption, it takes extra time to perform the flushing. The "FULL" mode creates an additional database file with the extension .DIA, and will perform integrity checks as data is changed and new data is added. The FULL mode may take as much as 4 times as long to write record changes in the databases. It actually holds information in the .DIA (diagram) file, and checks data integrity during the next transaction. If an error is encountered it is immediately corrected before continuing with the new record. If network operation seems excessively sluggish or you are operating under DESQview and need additional speed, we suggest changing the safety mode to "NONE". The WCREPAIR program will fix any database problems that develop in any mode. DOORS Door operation in a multi-node system is esentially the same as single line. A DOOR.DAT file is created in the DOOR path, and is used by all nodes sharing that path. If you have a DOOR path shared between nodes WILDCAT! will check the DOOR.DAT operational flags to determine a door is "in use" whenever a caller requests access. Access is denied if it is in use and the door has not been specified as multi-user in MAKEWILD. For those few doors with true record locking you may specify that it is multi-user and no checks for access will be performed. The door itself will then be responsible for handling the necessary locks when two or more callers access it at one time. Most doors are not multi- user. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 162 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ INTER-NODE CHAT As mentioned previously, chat makes use of disk files for text entered by callers. Although the port to port access could be accomplished in any one environment (LAN, DV, etc), there is no feasible way other than disk files to support such diverse applications true networks, slave cards, and unknown port parameters under a number of multi-tasking programs. The key to having your callers make successful use of inter-node chat is clear explanation and training. Make use of the PRECHAT.BBS (.SCR), CHAT.HLP, and CHATCMD.HLP files to help your users. Since screen updates are only possible once a line has been sent, emphasize that users should be patient. If the other caller exits chat a notice will be sent to all others in chat. The same is true after paging a caller; simply wait for the notification that he has entered chat rather than issuing a constant stream of /USERS commands. The chat file created by WILDCAT! is in record format, and is not easily readable without the VIEWCHAT utility. VIEWCHAT is invoked by following the command with the filename to view, such as CHAT.002 or CHAT.GRP. VIEWCHAT is not required to view the local chat capture file PAGED.CAP. The output is sent to the screen with no pauses. This allows redirection to a plain ASCII file for archival purposed. PRO! SERIES OPERATION Read the individual documentation file for complete operational details. In multi-node situations the PRO! utilities may be run without taking down active BBS nodes for most functions. All PRO! applications MUST be started from a valid startup directory, and have access to a valid, unused node ID via a CONFIGWC.BBS file. This startup directory may be one of the actual BBS nodes which has been scheduled to run a PRO! utility as an event, or a node which has been manually stopped with F10. It could also be an unused node ID on a separate workstation or in another DESQview window. Just like a local WILDCAT! access from a network computer, it must have a valid Node ID to function. DUPLICATION OF A NODE ID USED BY ANOTHER WILDCAT! BBS NODE OR ANOTHER PRO! SERIES IN OPERATION WILL CAUSE DISASTEROUS RESULTS! As an example, if you are operating 6 actual lines on the 10 node version 2.0N, and have set them up as nodes 1-6, you may still run U-PRO! on another network PC as long as you have created a startup directory for an additional node (perhaps 7), have run MAKEWILD in the node 7 startup directory, and have assigned a node ID of 7. If you have already used Nodes 1-10 for real incoming lines, you MUST take down one line to operate the PRO! utility. █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 163 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ Each PRO! series should be limited to operation on only one workstation at a time if database modification is being completed. For example, unused nodes 7 & 8 may both run M-PRO! at the same time, even while nodes 1-6 are taking calls, as long as they are reporting rather than making changes. If one is deleting messages that are over 60 days old and private, and the other is deleting all mail in folder B that is over 10 days old, there will be just too many record locks thrown at the system at one time. If both are simply listing mail to a file for archiving, the dual processing will probably be handled adequately, but again this is dependent on the network used. If in doubt, run only one utility at one time. EVENTS Multi-node operation must be taken into consideration when running most events. We have discussed the PRO! series which may be run as events (for most functions) even with other nodes active. You can easily schedule node 2 for a wastebasket dump of folder "Y" at 4am while leaving all other nodes available for calls. This is in contrast to the message renumbering portion of both WILDCAT! and M-PRO! which will not operate unless all nodes have been taken down. To perform a renumber the sysop must schedule an event on ALL nodes that access the same message datafiles at the same time, say 4am. One node then uses the WAIT! program to pause for five minutes or so (just in case the clocks are a little off) with the command WAIT! 300 (wait for 300 seconds). The second line of the batch file tells M-PRO! to perform the renumber. At the same time the other nodes in the system execute an event batch file that simply says WAITFOR! 04:30 (wait for 4:30am, then continue). This assumes that the renumber does not take more than 25 minutes. Any third party programs that read the datafiles may also need all other nodes to be suspended since the files or records needed may be locked at any time and access unavailable. The exception are utilities making use of the B-Tree Filer from Turbo Power Software. USER ACCESS Only one username may have access to a system at one time. If user John Magan signs on node 4, no one by that name may access any other node on the system. This feature prevents multiple updates of user records from different nodes to extend time or functionality. BACKUP This aspect of proper computer management is more important than ever in a multi-line environment. The introduction of file and record locking adds an additional dimension to this activity which can cause problems. You may find that your previous backup software is unable to backup files which have locks placed on █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 164 FEATURES DISCUSSED BELOW ARE NOT INCLUDED IN TEST-DRIVE █████████████████████████████████████████████████████████████████ them by software, especially if you have been relying on a batch file copy process. Aside from purchasing "intelligent" backup software designed to sidestep the locks and backup all files on your particular system while the BBS is running, you may have little alternative than to implement a system-wide event which takes all nodes down with a WAITFOR! command while one node performs the necessary backup to disk or other media. PHONE ROTATION This may seem like a trivial topic for discussion, but there are a number the alternatives and differing opinions regarding the best implementation. We will review several possibilities here with no attempt to persuade a sysop that one is better than another, but present them as different alternatives for different installations. As an example we will discuss a 10 line system. The simplest setup is a single published phone number which rotates (or hunts in telephone company parlance) down from line 1 to two, to three, to ten. This rotation ignores the caller's baud rate, and leaves access to faster modems to chance, unless all lines are connected to the same modem types. Another alternative is publishing three numbers, the first rings line one which rotates to two and three. All 3 lines are supported with a 2400 baud modem. The number for line four is then published as a USR 9600 HST number, and rotates through lines 5, 6, 7 and 8. The number for line 9 is also published and is supported by a HayesV-Series 9600 which rotates to another V- Series on line 10. While this setup allows higher speed modems to selectively call the correct lines, it forces the caller to dial several numbers if they have no preference for connect rates. his setup is used on the Mustang Software Private HQ BBS. A variation on the above could have the calls to the HST lines limited to 9600 baud only by making that limitation clear to callers and then setting the modem with &N6 to limit calls below 9600 BAUD █████████████████████████████████████████████████████████████████ THIS SECTION INCLUDED FOR FEATURE INFORMATION ONLY 165 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX A - MODEMS Modems in General A computer and the supporting peripherals that constitute a bulletin board system represent a chain of equipment that rarely gets to rest. Even while idling, the system is working. Most BBS's are on call twenty-four hours a day, seven days a week. If a chain is only as good as its weakest link, what about the various links that constitute a BBS operation? It then begins to have real meaning that the hardware/software must not only work together, but that each component is actually dependent upon the others, and must be durable as a stand-alone device. A BBS system's modem is the most important link to the outside world. We strongly recommend purchasing a name brand modem that has proven itself as a reliable performer under long term use. Mustang Software regularly solicits modems from manufacturers during our program development, with the understanding that WILDCAT! will be tested and guaranteed to run on their equipment. We continue to add modem settings to our list as new manufacturers cooperate with demonstration units for testing. Our thanks to those who have participated in this evaluation program. Hardware Error Checking Many modems support the ability to perform checking of transmission through hardware built into the modem itself. If your modem supports an internal error checking protocol (MNP or ARQ), you may make use of this feature and have WILDCAT! offer an additional internal file transfer protocol that takes advantage of this ability. This protocol is 1K Xmodem-G, and will increase the transfer throughput significantly. Note that WILDCAT! will not make this protocol choice available to a caller unless the connection was made using a result code for reliable connection (see MAKEWILD Modem Information, Part 2). The REGISTERED USER version of WILDCAT! also adds YMODEM-G (batch) to this list. A few of the modems which support MNP/ARQ are Microcom, US Robotics HST and 2400e, Telebit, Ven-Tel, and the Multitech 224EH and EC. Consult your modem manual to determine if you have MNP support. Modem Related Connection Problems Should you have trouble with your modem operating properly after installing and checking the setup parameters, you should follow these steps to determine the problem area. NOTE that all ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 166 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── references to the character 0 are ZERO and not the letter "O". THIS IS VERY IMPORTANT! First, start your favorite communications program such as Qmodem, ProComm, Smartcomm, Telix, etc.. Perform whatever commands are necessary to enter "command state", usually a blank screen where you can enter modem commands. Second, type ATZ and press ENTER. You should see "OK" or its numeric equivalent "0", which indicates you have established a good connection with the communications port. If this test fails, i.e the modem returns "ERROR" or its numeric equivalent "4", then you need check your hardware to make sure the port you have selected exists and is the ONLY port with that designation (COM1 etc.) If you got the "OK" or "0" then proceed with the following step. Third, enter the appropriate startup strings listed in your WILDCAT! set-up one at a time, pressing ENTER after each, to see if the modem is interpreting them correctly. For example, if your modem calls for AT V0 M0 Q0 E0 you would type AT V0 <ENTER> The result should be a "0" (ZERO) which is the numeric result code for "OK". Then type AT M0 <ENTER> and check the response. Continue to test each setup parameter until you are sure that the modem accepts each one. Perform this test for EVERY command in ALL startup strings, as well as the reinitialization string, if being used. Should all of them be accepted by your modem but it still fails to operate properly you should increase the modem delays in MAKEWILD to 2500 each in increments of 500. If any individual setup string item fails, check your manual and make sure the parameter is a valid command for your particular modem. Modem Switch and Register Settings The settings for any individual modem may vary, but most modems make use of some standard switch and S-Register settings. The discussion here deals with the most common dip switch choices (if your modem has them) and the register settings. The switches, if present, may be arranged and numbered in any order, but will usually cover the following functions. If your modem has switches you should set them according to this discussion. Data Terminal Ready (DTR) One of the pins on your cable or connection between the modem and computer is DTR, which is used to assure that the two modems can "talk" to each other. WILDCAT! handles the operation of DTR and uses it to control the connection. One of the main uses for DTR is manipulation to tell the modem that the caller has pressed "G" for Goodbye and wants to hang up. This switch can usually be either FORCED ON or NORMAL. WILDCAT! needs a NORMAL setting in order to be able ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 167 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── to raise and lower DTR to tell the modem when to hang up the phone. Verbal/Numeric result Codes This switch controls the type of responses the modem sends to the computer for connect, carrier detected, etc.. The two choices are Verbal (also called Verbose) or Numeric (also called Terse). WILDCAT! must receive numeric codes, and sets this by use of the AV0 (That's zero, not a letter "o") command in the startup strings. This switch must be set to numeric since some modems (the USR HST in particular) will not allow the V0 command to override the switch setting. Display result Codes This switch indicates if the response from the modem should be sent to the computer. WILDCAT! needs to get the numeric codes therefore this switch should be set to enable result code display. Command Mode Local Echo Local echo refers to the ability to actually display the result code on the screen locally when it is sent. WILDCAT! does not require this echo to operate properly. Auto Answer The preferred method for WILDCAT! to use in answering the phone is by monitoring the Ring-Detect Line, rather than having the modem auto-answer the phone. In this case the auto-answer switch should be set NOT to answer. If instead you elect to answer the phone by auto-answer (in MAKEWILD), this switch must be set to have the modem perform auto- answer. The status of this switch can be over-ridden with AT S0=0 to disable auto-answer or AT S0=1 to enable it. Carrier Detect Override (DCD or CD) This switch is VERY important. WILDCAT! monitors pin 8 to determine whether a carrier exists to know if someone is on-line. If this switch is set incorrectly, WILDCAT! cannot tell when someone hangs up, and may think someone is on-line when they are not! It should NOT be forced true or forced on. It MUST be set to reflect reality or to follow the software. If WILDCAT! is started with CD forced true it will display the message "Session in Progress". Single/multiple phone line Can be set either way depending on your phone line. AT Command Set recognition Since WILDCAT! sends and receives AT commands to and from the modem, this switch must be set to enable AT command set recognition. Escape Code Operation ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 168 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── It is advised that your modem disconnect if it receives a +++ from your caller. Not all modems have this switch. To prevent acting on an escape sequence, we recommend including the command S2=255 in a modem string to change the escape code character from +++. See the discussion of the S2 register below and in your modem manual. Use Factory or NRAM defaults Some modems which allow storing setup parameters in non- volatile RAM (NRAM) also allow selection of whether the power-on default parameters are loaded from NRAM or the hardware factory settings. If your modem allows a choice you must set this switch to load from the NRAM settings, not the factory settings. The USR HST is one modem which has this dip switch. S0 register Sets the ring number to answer the phone. If set to 0 (zero), auto-answer is disabled. S0=1 will enable auto- answer on the first ring. Set this to S0=0 under normal circumstances and use ring detect to allow WILDCAT! to take care of answering the phone. S2 register Holds the ASCII value of the escape sequence character. The factory default is 43, the plus sign (+). The character indicated in S2 needs to be sent three times with appropriate pauses to place the modem in command state. Values above 128 disable the escape sequence. We recommend disabling the escape sequence since it is not needed by WILDCAT!, and will prevent troublesome callers from attempting to disable your modem. S7 register This value determines how long the modem waits for a carrier to be detected after it has answered a call. It should normally be set to the default of 30, and must match the value in MAKEWILD for WILDCAT! to wait before giving up (Modem Information - frame 3). S25 register Not all modems have this register, but it is important if it exists. A change in the DTR (data terminal ready) status from on to off that is shorter than the value specified in the S25 register is ignored. This means that the default value of 5 (five-hundredths of a second) represents the shortest time that DTR must be lowered to have the modem hang up. You may recall that WILDCAT! uses a lowering and raising of DTR to end a call, and we expect the modem to respond. If it doesn't it could be due to this register being set too high. We lower DTR for just over 3 seconds, and therefore the maximum value of S25 should be 30. We suggest leaving the default of 5. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 169 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Modem-Specific Settings Depending on your particular modem, one of the following setup configurations may be of use. Each are described in detail, and are listed below. STANDARD 1 The following setting would usually apply to a modem with a maximum speed of 300 or 1200 baud (may apply to some 2400 baud modems) which has dip switches on the modem for setting DTR (Data Terminal Ready) as well as CD (Carrier Detect), as well as those switches involved with COM port designation. This type of modem DOES NOT have non-volatile memory to store the AT command set on a permanent basis. This type of modem DOES NOT support the EXTENDED Hayes "AT" Commands such as &C, &D, and &W which writes the settings to the Non- Volatile memory. Startup String #1: [BLANK] Startup String #2: [BLANK] Startup String #3: [BLANK] String to re-initialize after every call: AT V0 M0 Q0 E0 S0=0 S7=30 S2=255 X1 ------------------------------ STANDARD 2 The following setting would apply to a modem with a maximum speed of 2400 baud. It DOES NOT have many dip switches on the modem for modem control except for COM port designation. This type of modem DOES NOT have non-volatile memory to store the AT command set on a permanent basis. This type of modem DOES support the EXTENDED Hayes "AT" Commands such as &C and &D. Startup String #1: [BLANK] Startup String #2: [BLANK] Startup String #3: [BLANK] String to re-initialize after every call: AT V0 M0 Q0 E0 S0=0 S7=30 S2=255 &C1 &D2 X1 ------------------------------ STANDARD 3 The following setting would apply to a modem with a maximum speed of 2400 baud. It DOES NOT have many dip switches on the modem for modem control except for COM port designation. This type of modem DOES have non-volatile memory to store ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 170 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── the AT command set on a permanent basis. This type of modem DOES support the EXTENDED Hayes "AT" Commands such as &C, &D and &w to write the settings to the non-volatile RAM. Startup String #1: AT &F Startup String #2: AT &C1 &D2 Startup String #3: AT V0 M0 Q0 E0 S0=0 S7=30 S2=255 X1 &W String to re-initialize after every call: [BLANK] ------------------------------ The US Robotics HST 9600 baud modem makes use of a number of setup strings and codes to maximize throughput at high speeds. This discussion will review a few of the parameters used to increase throughput at high speed. Keep in mind that the fine tuning for maximum speed may have an effect on some doors (in the Registered version of WILDCAT!) and external protocols, which may not operate properly with the faster DTE rates. Startup String #1: AT &F Startup String #2: AT E0 &B1 &R2 &H1 S2=255 Startup String #3: AT V0 M0 Q0 S7=30 X1 &W String to re-initialize after every call: [BLANK] To get maximum speed your USR-HST should be initialized at 19200 with the DTE locked at the initialized baud rate of 19200. In addition you should include &B1 in the setup string to tell your modem that the DTE is locked, and &H1 to enable Hardware Flow Control using the CTS (Clear To Send) line on your modem. Remember that when you lock DTE at 19200 you have actually opened the line from your computer to the modem at the fastest rate possible. This will mean that a user who enters a spacebar to stop a display file may not have it stop since by the time he/she presses the spacebar the entire file may have already been sent to the modem at 19200, but the modem is sending it to him at perhaps 2400 baud. ------------------------------ For the Hayes V-Series V42 9600 baud modem, the following string is advisable: Startup String #1: AT &F Startup String #2: AT E0 S7=9 &C1 &D2 &Q5 S36=3 &K3 W2 Startup String #3: AT V0 M0 Q0 S2=255 S7=30 X1 &W String to re-initialize after every call: [BLANK] ------------------------------ ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 171 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX B - ANSI CODES (color only) and DOS colors ANSI CODE DOS COLOR # --------- ---------------- Erase Display ESC[2J ALL ATTR. OFF ESC[0m BOLD ON ESC[1m add 8 to color # UNDERSCORE ON (IBM Mono ONLY) ESC[4m BLINK ON ESC[5m add 128 to color # REVERSE VIDEO ON ESC[7m CANCEL ON (invisible) ESC[8m FOREGROUND BLACK FG ESC[30m 0 RED FG ESC[31m 4 (bold = 12) GREEN FG ESC[32m 2 (bold = 10) YELLOW FG ESC[33m 6 (bold = 14) BLUE FG ESC[34m 1 (bold = 9) MAGENTA FG ESC[35m 5 (bold = 13) CYAN FG ESC[36m 3 (bold = 11) WHITE FG ESC[37m 7 (bold = 15) BACKGROUND BLACK BG ESC[40m RED BG ESC[41m GREEN BG ESC[42m YELLOW BG ESC[43m BLUE BG ESC[44m MAGENTA BG ESC[45m CYAN BG ESC[46m WHITE BG ESC[47m Additional ANSI codes are available for cursor movement and other functions. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 172 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX C - Distribution for Profit We sincerely desire to make our TEST-DRIVE product available to as many people as possible through the electronic and catalog distribution network. We ask that individuals, groups, vendors or other distribution companies which market diskettes containing programs for profit obtain written permission from Mustang Software, Inc. prior to distribution. This is a simple process. Please forward a copy of this application if you desire to distribute WILDCAT! TEST-DRIVE for profit. The following conditions apply to this type of distribution: 1. Due to its size we ask that WILDCAT! TEST-DRIVE not be included on a diskette with any other software. 2. Please limit the copying fee to $10.00 per diskette and do not accept any additional payments for the program. 3. Distributors are asked to show that they fully support user registration of Shareware and TEST-DRIVE products as evidenced by advertising or promotional material. Along with your application for distribution rights, please include a copy of your promotional material and advertising copy. Forward your request to: Mustang Software, Inc. P.O. Box 2264 Bakersfield, CA 93301 Attn: Rick Heming COMPANY NAME:_________________________________________________ ADDRESS:______________________________________________________ CITY:_________________________ ST:__________ ZIP:____________ VOICE PHONE:__________________________________ Please include sample brochures, literature and advertising, if available. In return we will mail the current version of WILDCAT! TEST-DRIVE, and keep you up-to-date with the latest versions of ALL Mustang Software products as they become available. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 173 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Thank You! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 174 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX D - ERRORS AND TROUBLESHOOTING Setting up a bulletin board program isn't always an easy task. Due to the complex configuration necessary between the modem, computer and program, the end result is often not achieved the first time. If you are having difficulty the following section may be of some help. Most Commonly Asked Questions: Q1 When I start WILDCAT! it seems like it tries to initialize the modem, but displays a message that a "Session is in Progress..". A1 Your modem setting for Carrier Detect (CD) is probably forced "ON". Change the appropriate DIP switch for "NORMAL CD". Some modems without this switch use the &C1 command to perform this function. "Session in Progress.." means that WILDCAT thinks a call is in progress! If your modem does not have this particular switch, or no switches at all, then add &C1 to your modem initialization string. See Appendix A for more information on switch settings. Q2 Things work fine, but when callers try to say [G]oodbye, WILDCAT! just sends the Main Menu to them again and doesn't log them off. A2 Your modem has the DTR (Data Terminal Ready) line forced "ON". Change the appropriate DIP switch to "NORMAL DTR". Some modems without this switch use the &D2 command to perform this function. If your modem does not have this particular switch, or no switches at all, then add &D2 to your modem initialization string. See Appendix A for more information on switch settings. Q3 WILDCAT! answers the phone, but just sits there and the caller gets no response. WILDCAT! displays the message "Determining Baud Rate...". A3 You have apparently set WILDCAT! to determine baud rate by result codes, and it isn't getting codes that it can identify. First, check to be sure that you are sending NUMERIC codes, best set in the initialization string with V0 (zero). If you are sending numeric codes, then check the numbers in MAKEWILD for each baud rate against your modem manual. Lastly, perhaps your modem will only send different numeric codes for each baud rate if EXTENDED codes are requested. Extended codes are usually activated with the AT command Xn, where n is a number from one to about seven. Consult you modem manual. Q4 Why am I considered a New user when I first log on? ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 175 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── A4 See the section in the User Database. Remember, until you have logged on the first time and used the F9 key to upgrade your security to that of Sysop, WILDCAT! has never heard of you! Q5 WILDCAT! seems to run OK, but I get an error 202 or 203 after it gets going. A5 Both these numbers indicate a heap/Stack collision. Most of the time it means that you are attempting to run WILDCAT! without enough memory available. If you have any utilities in memory such as SideKick, remove them one at a time until the program functions properly. Q6 After WILDCAT! gets started it gives me an error 4. A6 Error 4 is a Turbo Pascal indication that too many files are open. The problem is almost always the omission of the statement "FILES=40" from the CONFIG.SYS file. See "System Requirements" for more information. Q7 When I try to use ALT-D to drop to DOS locally, I find I don't have enough memory. A7 Since ALT-D performs a "shell" to invoke another copy of the command processor(DOS), there needs to be enough memory available for the second copy of DOS. If sufficient memory is not found, the request is ignored. Remember, any memory-resident programs will reduce the memory available. DOS requires from 50K to 80K to invoke the second command processor. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 176 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX F - FILE & RECORD FORMATS See the file TEST-DRV.REC included on the SUPPORT diskette or in the WILDCAT2.EXE file for complete record structures for this release. ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 177 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── APPENDIX G - REGISTRATION See or print the file REGISTER.FRM for ordering the REGISTERED USER version of WILDCAT! ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 178 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Index 16550A UART 160 Banyan Vines 149 3-COM 149 Batch .BBS 82 Protocols 61 /M 63 Batch File Operation 88 /NOEMS 63 BBS and .SCR .SCR 71, 82 Differences 82 BEGCHAT.BBS 73 A BIMODEM 120 ACTIVITY.LOG 69, 73, Birth-Date Verification 104 36 ADDFILES 127 BIRTHDAY.BBS 73 AFTERDOS.BBS 71 BUFFERS=40 18 ALT#.BBS (.SCR) 71 BULLET#.BBS 74 ALT-Keys BULLETIN.BBS 73, 74 Defined 66 Bulletin Menu 90 ANSI 45 Bulletins ANSI Color 82 Path for 43 Editors 86 ANSI.SYS 18, 40 C Menu relationship 56 Call Processing Event APPENDIX A 110 MNP 167 CALLINFO.BBS 114, 141 Modem Registers 169 CARBON COPY 114 Modem Strings 167 Carrier Detect 168, 175 MODEMS 166 Carrier Wait APPENDIX B S7 Register 25 ANSI Codes 172 CAT.BAT 88, 109, 112, APPENDIX C 113, 145 Policies 173 Starting with 63 APPENDIX D CBIS Net 149 Trouble-Shooting 175 Chat APPENDIX F Inter-node 163 File and Record Local 66 Formats 177 CLOSED.BBS 74 APPENDIX G Closed Board 31 REGISTRATION 178 Codes AT Commands 26 Embeded 83 ATZ 25 Color 18 Auto Answer 28 ANSI Menus 75 AVIEWCOM 122 Foreground attribute 45 B Monitor type 45 Background 15 COMMENTS.BBS 74 BADLIST.BBS 72 Communications 24 BADNAMES.BBS 73 CONFIG.SYS 82, 176 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 179 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── CONFIGWC.BBS 19, 69 E CONFIGWC.OLD 69 Echomail Control Codes 83 Description 124 CONVERT 129 Future Directions Copyright 13 126 Ctrl-B 84 Implementation 125 Ctrl-C 77, 84 Editing Display Files CTTY 112 83 EDITMSG.HLP 74 D Embedded Codes 83 Daily Time Limit(DTL) EMS 63, 160 56 ENDCHAT.BBS 74 Databases within Ending WILDCAT! WILDCAT! 15 F10 66 File Database 15 Environment Message Database 16 Creating 17 relationship between ERROR.LOG 69 16 Errorlevel User Database 15 #35 126 Desqview 150, 160 #40 102, 112 Direct Screen Writes #50 141 150 #60 110 Display Files 42 #0 & #1 89 Distribution and Sequence 109 Copyright 13 Errorlevel 6 DLIMIT.BBS 74 Call Processing DLKLIMIT.BBS 74 Event 45 Doors Errors Batch Files 141 "Determining Baud Cautions 143 Rate.." 175 Description 140 "Session in Implementation 141 Progress" 175 Technical Support ALT-D 176 146 Error 4 176 DOORS.BBS 141 Error 202/203 176 DOORTEST 141 Logging off 175 DOORWAY 114 Trouble-Shooting 175 DOS-Next 65 Events 102 DOWNLDOK.BBS 74 Call Processing Downloading Event 110 Display Files 77 Creating 107 Help File 75 Schedule "X" 108 Limits Schedule "Y" 108 # 59 Schedule File 70 Max Bytes 59 Timing 111 Menu Choice 99 Expanded Memory 160 Ratios 40, 80 Expanded memory 63 Drop to DOS Expert Level 91 Remote 35, 102, 112 Extended Memory 150 DROPDOS.BAT 74, 112 Extended Result Codes DSZ 118 26 DTR 167, 175 External Protocols Batch Files 117, 120 BIMODEM 120 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 180 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Cautions 120 H Definition 61 Heap/Stack Collision Description 116 176 Implementation 116 HELLOxx.BBS 75 Number of 45 Help Files 42 Path for 42 Help Level 91 Help with Commands 91 F HOME Key 68 F-PRO! 127 File Database 15 I File Menu 52 Imbedded Codes 83 FILEAREA.IDX 70 Installation 19 FILEDATE.IDX 70 Interrupts FILEINFO.DAT 69 Duplication 24 FILENAME.IDX 70 Registered Version Files 24 Area Access 58 Usage 24 Areas 44, 47 IRQ and Port number 24 Color 41 Database Area 102 K Downloading 99 KERMIT.EXE 117 Help 75 Keyboard Switches 77 Information On 99 Kill a Message 94, 97 Listing 100 Path Definitions 60 L Reading Text 100 LANtastic 149, 158 Statistics On 100 LASCALL.BBS 76 Text Search In 100 Limited Warranty 12 Uploading 101 Lock-out 104 Used by WILDCAT! Logoff 90, 99 Data Files 69 LOGON Display 71 First Time 89, 176 Viewing Compressed New User 176 101, 122 Logon FILES=40 18, 176 Local 63, 64, 65 FILES.HLP 75 New User 64 FILES.SCR 75 FILESC.HLP 75 M FILESxx.BBS (.SCR) 75 M-PRO! 164 FIXFILES 139 MAIN.HLP 76 FIXMSGS 106, 139 Main Menu 19, 48, 90 FIXUSERS 81, 139 MAINC.HLP 76 Flow Control 30 MAKEQUES 132 Formfeed 84 MAKEWILD 19 Front End Programs 125 Drop to DOS Function Keys Local 67 Defined 65 Makewild Birth-date G age-limits 32 GATEWAY 114 CONFIGWC.BBS 19 General Information 21 Drop to DOS GOODBYE.BBS 75 Remote 35 External Protocols 61 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 181 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── File Menu Defined 52 Determining Baud 28 File Paths 60 DTE 27 File Section Setup Flow Control 30 47 Registers 169 General Information Result Codes 175 21 Ring Detect 28 Installation 19 Standard Settings Main Menu Defined 48 171 MENUINFO.BBS 19 Modem Message Menu Defined Communication Port 51 24 Modem Information 24 Makewild 24 NewUser Defaults 31 More- 84 Security Information MPE.EXE 83, 85 35 MSGHEADR.DAT 70 Security Levels MSGINFO.DAT 70, 106 Defined 54 MSGNUMBR.IDX 70 Sysop Menu Defined MSGTF.IDX 70 53 Multi-Line System Configuration Chat 163 39 Description 148 Time compensation Doors 162 Ratio 40 Hardware 149 Time Limit Implmentation 151 First Call 33 Phone Rotation 165 Memo Date 105 Memory management 63 N MENUINFO.BBS 19, 69 Netmail MENUINFO.OLD 69 Description 124 Menus Future Directions Types 90 126 Message Database 16 Implementation 125 Message Folders Network 158 New-User 33 Chat 163 MESSAGE.HLP 76 Description 148 Message Menu 51 Doors 162 Messages Hardware 149 Carbon Copy 94 Implementation 151 Deleting 94, 97 Phone Rotation 165 Entering 94 Newsletter 92 Folder Access 56 NEWSLTR.BBS 76, 92 Folders 46 NEWUSER.BBS 76 Menu 94 NewUser Defaults 31 Private 37 NO300.BBS 77 Range 41 NOEMS 63 Reading 97 NON-FATAL ERRORS 69 Return Receipt 94 Norton Editor 83, 85 Scanning 98 Novell 149, 156 Text Search In 98 Novice Level 91 MESSAGEx.SCR 76 MESSASEC.HLP 76 O Modem Off-Hook 29 Auto Answer 28 On-Hook 29 Delays 26, 29 Other Requirements 18 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 182 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── Overlay buffer 63 Required Environment 17 Result Codes 168, 175 P Return Receipt 94 Page Bell 77 Reviews 13 PAGED.BBS 77 Ring Detect 28 Paging the Sysop 21 RS-232 10 Passwords 64 Paths 41 S PC ANYWHERE 114 S2=255 73 PC-MOS 386 149 S7 Register 25 PCKERMIT.EXE 117 Scan 98 Personal Mail 94 SCHED.BBS 70 Phone Number Schedule "X" 108 Verification 35 Schedule "Y" 108 PKZIP/UNZIP 122 SCR and .BBS Port Number and IRQ 24 Differences 82 PREDOWN.BBS 77 Screen Write Toggle 66 PRELOG.BBS 77 SEC#.BBS 80 PREUP.BBS 77 SECERROR.BBS 80 Printing Security Activity Log 65 Levels 37 Toggles 65 Levels Defined 58 Users 104 Online-Upgrade 64, PRO!-Series 66 Implementation 164 Passwords 37 Overview 163 Phone and Birth Date PROTOCOL.BBS 78 36 PROTOCOL.HLP 78, 99 Private Messages 37 Special Display 80 Q Security Information 35 QDONE#.BBS 78 Session in Progress 175 QDONECLO.BBS 78 SHARE 149, 154 QDONENEW.BBS 79 Source Code 13 QSEC#.BBS 78 Spacebar 82 QUES#.ANS 79 Statistics QUES#.BBS 79, 136 On Databases 104 QUESCLOS.ANS 78 Subscription Systems QUESCLOS.BBS 78, 136 105 QUESNEW.BBS 79, 136 SysOp QUESTION.BBS 78, 92, Closed operation 31 136 Sysop 21 Questionnares 132 Comments to 44, 90 Quick Start 17 Help Files 80 QUOTES.BBS 40, 79 Menu 102 Menu Files 80 R Page 92 RATIO.BBS 80 Paging of 21 Ratios SYSOP.HLP 80 Setup 40 SysOp Menu 53 Redirection of I/O 112, SYSOPC.HLP 80 114 SYSOPxx.SCR 80 Registration 6 System Configuration 39 Regular Level 91 System Requirements 10 REMM.SYS 63 System Toggles 65 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 183 WILDCAT! TEST-DRIVE 11/1/89 ───────────────────────────────────────────────────────────────── T UPLOADOK.BBS 81 Technical Support 11 USER#.BBS 81 Compuserve 11 User Database 15 Regional 11 USERINFO.DAT 69 THEDRAW 86 USERNAME.IDX 69 Time Users Inactive 88 Database Area 104 Time Limit Lock-Out 104 First call 33 Printing 104 Increase/Decrease 68 Special Display 81 Maximum Allowable 45 Toggles 65 V TRANSFER.BAD 118 Verifying Users 93 Trouble-Shooting VIEW_ARC.BAT 122 "Determining Baud Viewing Compresses Rate.." 175 Files 122 "Session in Progress" 175 W ALT-D 176 WAIT! and WAITFOR! 138 Error 4 176 Warranty 12 Error 202/203 176 Wastebasket Logging off 175 Dump 106 What is WILDCAT! 6 U Features 8 UART 160 Included with Uploading 101 Registration 6 Display Files 78 Security 10 Help File 75 Ratios 40, 80 Z Time Comp. 40 ZMODEM 117 ───────────────────────────────────────────────────────────────── Mustang Software, Inc. 184