ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / GC101_3.ZIP / GC-DOCS.TXT next >

Wrap

Text File | 1990-08-09 | 157.3 KB | 2,887 lines

THE ****** ***** * * * ***** * * * * * ** * * * * *** ***** ***** * * * * * * * * * * * * ** * * ***** * * * * * * ***** ****** ******* * * ******* ***** * * * * ** * * * * * * * * ***** * * * * ***** ***** * * * * ** * * * * * * ****** ******* * * * * * * * ******* - MESSAGE SYSTEM - 1 00000 1 11 0 0 11 1 0 0 1 1 0 0 1 11111 * 00000 11111 A High-Performance Message and Mail System for RBBS Bulletin Boards INSTALLATION AND REFERENCE MANUAL August 10, 1990 By Scott Barnes BarneSoft Business Office: Address All Correspondence to: ------------------------------ ------------------------------------- R.D. 3, Box 316 Box 275003 PA Route 10 North Rochester, NY 14627-5003 Cochranville, PA 19330 Voice: (215) 593-2392 This manual and the related software are Copyright 1989, 1990 BarneSoft All Rights Reserved The Grand Central Reference Manual, Version 1.01 Page 2 ____________________________________________________________________________ -- I M P O R T A N T -- The Grand Central Message System (hereafter referred to as Grand Central or "GC" for clarity) is distributed as a SHAREWARE product. It is neither public domain nor freeware, and is fully copyrighted. You are free to install GC and evaluate it to determine if it meets your needs. However, if you install GC as a working part of a public or private bulletin board system (BBS), I request that you register your copy of GC by sending a check or money order for $35 U.S. funds to BarneSoft at the Rochester address listed on the front page. A registration form is included at the end of this document. If you use or distribute GC, you acknowledge that you will abide by the following restrictions: 1) You are permitted to distribute the GC system as long as: a) No fee is charged for the distribution other than a disk copying fee of $20 or less. All users are still responsible for registering their copy of GC. b) The distributed product remains in its original, unmodified form. 2) You may not modify the GC executable or documentation files. You are also expressly prohibited from reverse-engineering the executable files or creating derivative products in this manner. 3) GC is not intended to be used on local area networks. You must make arrangements with the author to use GC on such a network. Now, with the disclaimers out of the way, here are a few words on the specific benefits I will provide when you register your copy of GC: 1) One 360K 5-1/4" or 720K 3-1/2" disk mailed to you containing GC version 1.1 when it is released. 2) Support services via telephone or E-mail. Full details on support are given in Chapter 9. 3) Mail notification of the next major release of GC. 4) If you wish, your BBS can be included on a widely- distributed list of BBSes that run Grand Central. 5) Opportunity to get on an E-mail distribution list which might be used to distribute: bug notices, revision notifications, technical bulletins, and the GC BBS list. The Grand Central Reference Manual, Version 1.01 Page 3 ____________________________________________________________________________ T A B L E O F C O N T E N T S --------------------------------- SECTION TOPIC PAGE --------------------------------------------------------------------------- 1 Introducing the Grand Central Message System! ....... 5 1.1 Requirements to Run GC .............................. 6 1.2 About GC Version 1.01 ............................... 7 2 Setting Up GC for a First Look ...................... 9 2.1 Steps for Installing the GC Test System ............. 9 2.2 Exploring the GC Test System ........................ 9 3 Overview of Incorporating GC into Your RBBS ......... 11 3.1 Planning GC Conferences ............................. 11 3.2 Other GC Configuration Parameters ................... 12 3.3 .GCS Screens ........................................ 12 3.4 RBBS Considerations ................................. 12 4 Configuring Using G-CONFIG .......................... 14 4.1 GC System Configuration ............................. 14 4.2 GC Conference Configuration ......................... 16 4.3 Post Office Configuration ........................... 19 5 .GCS Screens - The Key to Customizing GC ............ 21 5.1 The Purpose of .GCS ................................. 21 5.2 The .GCS Format ..................................... 21 5.3 Catalog of All .GCS Screens ......................... 22 5.4 Summary of .GCS Concepts ............................ 25 6 Connecting GC to RBBS ............................... 27 6.1 FOSSIL Installation ................................. 27 6.2 Configuring RBBS 15.1C and 16.1A .................... 27 6.3 Configuring RBBS 17.1A and Later Versions ........... 29 6.4 The RBBS.BAT File ................................... 32 6.5 Desirable RBBS Cosmetic Changes ..................... 33 6.6 Testing RBBS and GC ................................. 33 7 The Finer Points of GC .............................. 35 7.1 Novice/Expert Command Entry ......................... 35 7.2 The Conference Selection Menu ....................... 37 7.3 The Unread Message Feature .......................... 37 7.4 The Conference Index Feature ........................ 38 8 Maintaining a GC System ............................. 39 8.1 Maintaining Message Bases ........................... 39 8.2 RBBS User File Changes .............................. 39 8.3 How RBBS Sysop Comments Work ........................ 39 8.4 GC's Chat Feature ................................... 40 8.5 The "LOG" File and GC Error Handling ................ 40 8.6 GC.EXE Command Line Options ......................... 40 8.7 G-CONFIG Remote Use ................................. 41 8.8 Sysop Security Privileges ........................... 41 8.9 Moderator Security Privileges ....................... 42 8.10 The OPTIMIZE Program ................................ 43 8.11 The MAILCHEK Program ................................ 44 9 Support and Feedback Information .................... 47 The Grand Central Reference Manual, Version 1.01 Page 4 ____________________________________________________________________________ SECTION TOPIC PAGE --------------------------------------------------------------------------- 10 For the Future... ................................... 48 APPENDICES: A Upgrading from Previous GC Versions.................. 49 B List of .GCS Screens Which Have Special Restrictions. 50 C Limitations of GC ................................... 52 D About the Author .................................... 53 E GC Registration Form ................................ 54 The Grand Central Reference Manual, Version 1.01 Page 5 ____________________________________________________________________________ CHAPTER 1 - INTRODUCING THE GRAND CENTRAL MESSAGE SYSTEM! --------------------------------------------------------- Have you ever wondered what the future holds for BBS programs? Some people believe the future lies in linking BBSes into large interconnected networks. Others believe that the future means upgrading the fundamentals of each BBS, or, in other words, improving the end-user interface. I tend to gravitate toward the latter vision, although I am by no means anti- network. Wide-area networks are becoming increasingly useful in the global village in which we live. However, the mightiest network becomes little more than a toy if it is not useful and meaningful to ordinary people. The point is that every BBS, whether network-connected or not, needs to have a user interface that is coherent and consistent, and one which reduces the amount of visual clutter transmitted to the user. How does a BBS program attain these goals for its user interface? I believe the way to accomplish the goals is to re-examine some of the assumptions that underlie today's BBS programs. One such assumption I have discovered is that messages within conferences must be time-ordered. This assumption causes some problems, because it makes it difficult for occasional users to follow the course of conversations and keep up with conferences in general. It also limits the number of topics that can be discussed at a time to only one or two, since users only see and remember the most recent conversations. Another assumption is that the mail system must be integrated with the message system. This assumption does allow BBS programs to maintain a compact user interface, but it disregards fundamental differences between the nature of mail and public messages. People like to have one mailbox where they can look for mail, instead of looking (or having the BBS look) in several different conferences for the same. Imagine if you were forced to travel to five different post offices every day to see if you had any mail! The last major assumption I discovered is that every user calls in on a 40 character-wide dumb terminal. This assumption was certainly warranted even several years ago when there were large numbers of terminals and computers that were fluent only in the ASCII character set. However, with the widespread use of IBM PC's, Macintoshes, and terminals which have 80 by 24 screens and are ANSI X3.64-compatible, it is time to assume more about the remote caller's equipment than the least common denominator. The Grand Central Message System is my bid to advance the state-of-the- art in computer bulletin boards, by challenging the validity of the three assumptions presented above. Grand Central is currently implemented as a message/mail door to the RBBS program which replaces RBBS' native conference and mail functions. GC's major features are as follows: 1) FULL-SCREEN DISPLAY FORMAT - GC assumes an 80-by-24 character screen on the remote end and uses the ANSI/VT100 terminal standard to create an orderly full-screen environment. This environment includes such amenities as emphasized text for important items, and bidirectional scrolling. A minimal level of support is provided for terminals or computer software packages which are incompatible with the ANSI standard. 2) FULL-FEATURED CONFERENCING SYSTEM - GC offers the Sysop a great deal of flexibility in setting up conferences. The extensive security system allows one to set up conferences that are totally public, totally private, or some combination of the two. The Sysop can specify The Grand Central Reference Manual, Version 1.01 Page 6 ____________________________________________________________________________ moderators for each conference, who are given Sysop-like privileges in their conferences but nowhere else. 3) TOPIC-BASED MESSAGE SYSTEM - GC organizes each conference's message base by topic rather than chronologically. Hence it is much easier to look at all messages pertinent to a topic, since there are no complex "threading" commands. An unread message feature is also provided to allow the user to see the messages they have not yet read. 4) SEPARATE MAIL SYSTEM - GC has a mail system similar to that of larger computers, where each user is given his or her own mailbox. The mailbox concept eliminates confusion between mail and messages and also does away with time-consuming mail searches. Other features include distributed (multiple recipient) mail, as well as a mail trace which allows letter writers to determine if their letters have been read by the recipient. 5) HIGH-PERFORMANCE, FRIENDLY EDITOR - The GC editor is patterned after the RBBS editor, but at the same time contains powerful new features that make editing easier for everyone. On top of the basic line-editor concept, the GC editor offers automatic paragraph reformatting, multiple-line editing, multiple-line deleting, tab support, and more! 6) FULL SUPPORT FOR SESSION LIMITS, SLEEP TIMEOUTS, CARRIER MONITORING, AND CHATTING - The Sysop can tell GC to "adopt" each user's RBBS session limit. In addition, the user's remaining time is frequently updated in the upper-right corner of the screen. GC handles sleep timeouts, including hanging up the telephone line. Carrier monitoring is performed continuously. Finally, GC allows chatting, with the text from each side of the conversation printed in a different text style. 7) FULL SUPPORT FOR REMOTE OPERATIONS - GC, as well as its companion configuration program G-CONFIG, fully supports remote Sysop sessions. The Sysop thus has the freedom to reconfigure and maintain the GC system from wherever he or she happens to be located! Moderators, too, are given extensive remote capabilities. Within their conferences, moderators can delete topics and messages, and change user security levels, without bothering the Sysop. 8) MISERLY ON SYSTEM RESOURCES - GC is designed to use as little disk space as possible. Space taken by deleted messages and letters is recycled as much as possible. In addition, an automatic optimization program streamlines all message base and mail system files once per week, unattended. So, as you can see, Grand Central really does advance the state of the art in the BBS world. Read on to find out how easy it is to set up a GC system you can try! 1.1 - Requirements to Run GC ---------------------------- The requirements to run GC are much the same as those needed to run RBBS. The main exceptions are that GC does not yet support multiple simultaneous nodes on the same machine nor does it support networks. Aside from that, I believe to the best of my knowledge that almost any computer that will run RBBS will run GC. However, that is not a guarantee. Here are the specific minimum requirements: The Grand Central Reference Manual, Version 1.01 Page 7 ____________________________________________________________________________ 1) IBM PC or clone which runs PC-DOS or MS-DOS versions 2.0 or higher 2) Hard disk recommended 3) Monochrome Graphics Adapter 4) One asynchronous communications port which is driven by an Intel 8250 chip, or compatible - communications port can be connected to a modem, digital PBX, or any other communication device which obeys similar primitives (host system echoes what caller types, DTR signal controls call status, DCD signal indicates call status) 5) 300K *available* memory (i.e., after loading DOS and TSR's) 6) RBBS Version 15.1C or greater - must be installed prior to installing GC 7) Some sort of full-screen file editor (many word processors can pinch-hit in this area) 1.2 - About GC Version 1.01 --------------------------- This version is a minor update of Version 1.0. It fixes several bugs encountered by users (see the BUGLIST.TXT file). No feature changes have been made since the previous release, and the remainder of this section refers to enhancements made in Version 1.0. ==> IF YOU ARE UPGRADING FROM GC VERSIONS 0.95 OR 0.90, PLEASE READ <== ==> THE SIMPLE UPGRADE INSTRUCTIONS IN APPENDIX A. <== A bidirectional-scroll conference index feature is now available. This means that users can view the titles of all of a conference's messages simultaneously, and pick one of them to view. This utility is heavily dependent on ANSI/VT-100 features, and thus is NOT available on dumb terminals. You will be seeing a lot more of this bidirectional scroll list in future GC versions. The mail system is now capable of distributing a single mail item to multiple recipients. The Sysop is given complete control over who can use this feature, so as to avoid "junk mail" problems. All accesses to the mail system (except the "M" conference menu command) now prompt the user "Any Other Recipients (Y/[N]) ?" If the user responds "Y", the system begins prompting for the names of additional letter recipients. Another mail system enhancement is a user search feature. This is activated by typing "?" in response to any letter recipient prompt. The conference menu prompt has been changed so that one can switch to a conference by typing the first few characters of its name. This feature, like the "[N]ext Conference" command, uses an alphabetical list of conferences. Therefore, if there were "ZIPPITY-DO-DAH" and "ZIPPER" conferences, repeated use of the search command "ZIP" would move the user alternately between these two conferences. The editor's "C)ontinue" command is now much more useful than it was previously. The user is now allowed to continue any line in the message. Thus, paragraphs in messages and letters can be extended with relative ease. Finally, a new communication flow control option is offered. This option is simultaneous XON/XOFF and RTS/CTS flow control. Users of high- speed modems can now use software (XON/XOFF) flow control with the remote user, as well as hardware (RTS/CTS) flow control with the local modem. The Grand Central Reference Manual, Version 1.01 Page 8 ____________________________________________________________________________ If you find something you suspect to be a GC bug, please leave a message on the GC support answering machine. Remember, you're talking directly to the programmer (ever try that at another software company?). Also, your opinions are welcome and encouraged. Please see Chapters 9 and 10 for more details on product support and feedback. The Grand Central Reference Manual, Version 1.01 Page 9 ____________________________________________________________________________ CHAPTER 2 - SETTING UP GC FOR A FIRST LOOK ------------------------------------------ Despite the fact GC is intended for remote operation, you can set it up on your computer and have a test system running in under 10 minutes, WITHOUT touching a modem or running RBBS. You need only meet the fundamental GC requirements as listed in the last chapter, with the exception of the communication port. 2.1 - Steps for Installing the GC Test System --------------------------------------------- 1) Set up a GC directory on your hard disk. GC will take up about 800K of disk space initially. Do NOT put the program in the same directory as other software, or you are bound to have problems. It does not have to be on the same disk drive as RBBS. 2) Extract all of the files out of the GC101-1, GC101-2, and GC101-3 compressed files into the GC directory. 3) Edit your system's CONFIG.SYS file and make sure you have a "FILES=" line that is set to at least 15. Setting this parameter does *not* tie up large amounts of memory; it merely tells DOS that up to 15 files can be opened at one time. 4) Now, go to your GC directory and run the G-CONFIG program. 5) G-CONFIG will ask for the drive and directory where RBBS is located (i.e., C:\RBBS). Once this information has been properly entered, G-CONFIG will set up the foundation of your GC system. 6) In several seconds, the G-CONFIG Main Menu will appear. Select the "G" option. 7) You will now be looking at the configuration information for your GC system. You need to tell GC your (the Sysop's) name. Go to item number 1, press <CTRL>-<A>, type your name as it appears in the RBBS system, and finish by pressing <ENTER>. All of the other parameters are set to predetermined values, so it is not necessary to set these parameters to run the test system. 8) Press <ESC> <ESC> to return to the Main Menu. Type <Y> to accept the changes and then <Q> to return to DOS. 9) Now, you can start GC by typing a command like "TRYIT your name", where "your name" is the same name you gave G-CONFIG in step 7 (capitalization does not matter but spaces do). 10) If everything is running properly, you will see GC's opening screen. Instructions for running GC are given in the next section. 2.2 - Exploring the GC Test System ---------------------------------- You should now be looking at the GC opening screen. Note that some of the screens you will see in the test system are customized for my Pinnacle BBS. The system is set up this way so you can observe what a typical GC installation might look like. Note the mail indicators at the bottom of the screen. Since you are the Sysop, you have a business and a personal mailbox. The business mailbox is shared by all other Sysop-level users, The Grand Central Reference Manual, Version 1.01 Page 10 ____________________________________________________________________________ which makes it easier to run a multi-Sysop BBS. After you press <ENTER>, you will be taken into the GC Tutorial. The first screen of the tutorial is an introduction, while the second allows the user to select the proper terminal type. As a local user, you should select terminal type two. GC does not currently make any distinctions between terminal types two through five. Terminal type one, however, forces GC to revert to a dumb terminal mode, where no advanced screen handling is supported. Immediately following the Terminal Setup Screen, you will be taken into the main body of the tutorial. You should carefully read the tutorial, since it explains many aspects of the GC user interface. As you will be able to see at the bottom of the tutorial screens, the <ENTER>-<TAB> convention is one such aspect. This is the convention that permits bidirectional screen scrolling. There are many places in GC where more than one screenful of information is available at one time. By pressing <ENTER>, one can scroll forward through the information by screenfuls. Conversely, <TAB> scrolls backward. After the tutorial is over, you will go to GC's Main Menu. All of the selections will work except [N]ext Conference, which will just redisplay the Main Menu since no other conferences have been set up in GC. One selection you should try is the [R]ead/enter Messages command. GC will alert you to the fact that there are no topics in the main message base, but you can respond by starting a topic. This action will bring up the GC editor, where you can enter a test message. Upon exiting the editor, you will go into the message reading mode and the message you entered will be displayed as it would be displayed to any GC user. This is your chance to try some message reading commands. You will probably want to look at the help screens, which you can do by typing "help" and pressing <ENTER>. After you are finished looking around, use the "exit" command to return to the Main Menu. Another part of GC you will want to look at is the Post Office. When you first enter the Post Office, you will be working with your personal mailbox, which is listed under your name. As alluded to earlier, you can also access a Sysop mailbox. You can exploit this feature to try sending a letter. When you are at the Post Office menu, select the [M]ail Letter command. Type "SYSOP" as the recipient of the letter. You will again have a chance to experiment with the GC editor. After entering the letter, you will return to the Post Office menu. Now, select the [S]ysop Mailbox Toggle. This command will give you the same Post Office menu, but you will now be working with the Sysop mailbox, the same mailbox to which you just sent a letter! If you use the [R]ead Your Mail command, you will see the letter you just created. When you are in the letter reading mode you can get help, as before, by using the "help" command. When you are finished experimenting with GC, simply go back to the Main Menu and use the "[Q]uit to PINNACLE" command. Normally, this command would return you to RBBS, but in this case you just go back to DOS. The Grand Central Reference Manual, Version 1.01 Page 11 ____________________________________________________________________________ CHAPTER 3 - OVERVIEW OF INCORPORATING GC INTO YOUR RBBS ------------------------------------------------------- The key to getting the most out of GC is in the planning you do before installing it. To make a successful installation, one must not only get GC running, but one must make it convenient for people to access it from RBBS. For example, it is often advantageous to simply shut down RBBS' message system so there is no confusion over which program people should use for mail and messages. This chapter will outline the various steps necessary to create a reliable and appealing GC system. 3.1 - Planning GC Conferences ----------------------------- Obviously, it is necessary to choose which conferences will be included in the GC system. GC will support up to 254 conferences. In the process of making these decisions, one should consider the various types of conferences that are available. GC supports four types of conferences, as follows: 1) PUBLIC, FULL ACCESS - This is the type of conference most often associated with BBSes. Everyone is allowed to become a full participating member of the conference (i.e., permission to read and write messages) immediately upon selecting the conference from the Conference Availability Menu. The only restriction you can place on this type of conference is a security level restriction, so users below a certain security level cannot join or participate in the conference at all. 2) PUBLIC, SPECTATOR ACCESS - This type of conference is very similar to the preceding one, except that people become spectators (i.e., permission to read messages only) upon joining the conference. Users can be given full access later by the conference moderator, if desired. 3) APPLICATION REQUIRED - This conference type is similar in concept to a private club. People who are interested in joining the conference convey this interest to the conference moderator through GC. The moderator then acts favorably or unfavorably on this application. Note that there are no electronic forms that must be filled out; the applicant need only indicate interest in joining the conference. If additional information is needed by the conference moderator then the moderator must request this information from the applicant by using E- mail. 4) HIDDEN - This conference type could be described as very private. The conference name will never appear on anyone's Conference Availability Menu, so the only way for people to join is to be made a member directly by the moderator. This type is useful for conferences which will have a small, fixed, and private membership. Another major consideration with conferences is the welcoming screen that will be used with the conference. GC allows a 79 character by 12 line greeting screen for each conference. As explained in Chapter 5, only plain ASCII characters are currently supported for such screens; ANSI graphic/color sequences are not. There are several other parameters that must be addressed when setting up a conference. For example, conference moderator(s) needs to be appointed. On a small BBS, the Sysop may be in charge of all conferences. But, on a larger or more diversified board, other users often handle the The Grand Central Reference Manual, Version 1.01 Page 12 ____________________________________________________________________________ administrative details in conferences. Keep in mind that the moderator(s) controls access to the conference as well as how and when old messages are deleted. Other conference parameters include: the maximum number of topics, maximum number of replies per topic, and maximum number of lines per message. 3.2 - Other GC Configuration Parameters --------------------------------------- Besides conference configuration, there are other decisions that must be made in setting up GC. In the category of overall system configuration, considerations include: who will be allowed on GC (minimum logon security level), how long they will allowed to be on, when sleep timeouts will occur, and who will be considered a Sysop. There are also more mundane considerations that deal with local screen colors and how GC should disconnect users. There are also several Post Office parameters that need to be specified: who will be allowed into the Post Office, who will be allowed to send letters, the maximum number of lines per letter, the biggest allowed mailbox size, the length of time a mail trace will work, and how GC will erase letters. 3.3 - .GCS Screens ------------------ Setting up any BBS system involves a certain degree of creativity in crafting the system's outward appearance. GC is no exception. The GC screen files (known as .GCS files) that are distributed with GC are generic, so they contain no BBS-specific information. As described in Section 3.1, custom welcoming screens should be created for each GC conference. Many other GC screens are also suitable for customization. Chapter 5 contains a thorough explanation of the process of creating and modifying .GCS screens. 3.4 - RBBS Considerations ------------------------- As mentioned above, there are some modifications that must be made to your RBBS setup in order for GC to work properly. There are also several RBBS modifications that are desirable, but not required to run GC. The most obvious change is that GC must be installed as an RBBS door. If RBBS is not currently set up to run a door, there are several areas that must be addressed, including: the batch file that runs RBBS, door security levels, the door batch file, and the door menu. If RBBS is already set up to run a door, the installation is easier since some of the aforementioned items may be set up properly already. Another important consideration is the existing RBBS message system. In most cases, this system can be completely shut down since its functions are replaced by GC. However, if you use RBBS to interface with FIDOnet, or have some other specialized configuration that GC does not support, you will probably want to keep the special conferences in RBBS while transferring the remaining ones to GC. Shutting down the RBBS message system involves modifying existing RBBS menus and changing several security levels in the RBBS security system. The Grand Central Reference Manual, Version 1.01 Page 13 ____________________________________________________________________________ Finally, there are several aesthetic changes that are not required, but which will make it easier for users of the RBBS to understand how to access GC. These changes involve modifying RBBS help files so they no longer refer to the RBBS message functions and refer instead to instructions for accessing GC. The Grand Central Reference Manual, Version 1.01 Page 14 ____________________________________________________________________________ CHAPTER 4 - CONFIGURING USING G-CONFIG -------------------------------------- If you have not already done so, work through the basic GC installation directions given in Chapter 2. All of GC's various parameters - with the exception of the display screens - can be modified by using the G-CONFIG program. G-CONFIG has other functions, but these are discussed in Chapter 8. This chapter consists of complete descriptions of all of GC's parameters. In order to successfully install GC, you should carefully work through G-CONFIG while reading this documentation. It is assumed that you have completed the basic planning (especially conference planning) described in the previous chapter. 4.1 - GC System Configuration ----------------------------- The GC System Configuration parameters can be modified by choosing the "G" option at the G-CONFIG menu. There are 15 parameters to set. Press <ESC> <ESC> then type <Y> to store the configuration changes. The GC system parameters are as follows: 1) SYSOP'S FULL NAME - GC normally knows the name of the RBBS Sysop when it can access RBBS' DORINFO file. However, when GC is started directly from DOS with the /USER= option, GC does not know the name of the Sysop and must look up the name here. In all cases, this name should be exactly the same as the one used in RBBS. Note that this is the Sysop's real name, *not* RBBS' Sysop remote logon password. 2) DRIVE AND PATH TO RBBS FILES - This parameter will rarely need to be set, because G-CONFIG will always check its validity at the start of the G-CONFIG program. If, at that time, RBBS' USERS file cannot be found, you will be prompted for a new drive and path. However, the path can also be changed here. The correct drive and path to RBBS is essential to proper operation of the GC system. 3) MINIMUM RBBS SECURITY LEVEL TO LOG ON - There are two ways a Sysop can restrict access to the GC program. One way is to lower the security level for doors within RBBS. However, that method has a disadvantage in that it changes the minimum security for all RBBS doors, and different security levels for each door may be desirable. GC provides the second method of restricting access by checking each user's security level against this parameter. If the user's level is less than this parameter, the user is informed of this fact and returned to RBBS. If you do not wish to restrict GC access in this manner, set this parameter lower than the lowest security level used on your RBBS. 4) MINIMUM RBBS SECURITY TO BE A SYSOP - Each time a user logs on GC, GC compares the user's security to this parameter to determine who will allowed to have Sysop privileges on GC. Except in special circumstances, this parameter should have the same level as used for RBBS Sysops. 5) RESPECT RBBS SESSION LIMITS? - There are two methods for limiting the time each user can access GC. One method is setting a fixed session limit, so that all users have the exact same session limit regardless of what their RBBS session limit might be. The second method is to allow GC to inherit each user's session limit from RBBS. The Grand Central Reference Manual, Version 1.01 Page 15 ____________________________________________________________________________ The second method is generally preferable, since the existing session limits on RBBS do not have to be changed to account for GC. To use the first method, answer "NO" on this parameter and set parameter six. To use the second method, answer "YES" on this parameter. A special note is in order for the second method. In this method, GC determines each user's remaining session time by subtracting five minutes from the user's remaining time on RBBS. Therefore, if a user exhausts their time on GC, they will still have five minutes left upon return to RBBS. Also note that session limits do not apply to Sysops who log on GC locally. Local users are given a session limit of one whole day, so there should not be any problems with expired session limits in that regard. 6) GRAND CENTRAL SESSION LIMIT - This parameter is applicable only if parameter five is set to "NO." In this case, it is simply the desired fixed session limit for GC in minutes. If parameter five is set to "YES," a "NOT APPLICABLE" message will be displayed. 7) SLEEP TIMEOUT - GC, like RBBS, stops a session when a remote user has been inactive for a certain time period, as specified by this parameter (in seconds). Parameter eight specifies whether the user is to be disconnected or returned to RBBS. Sleep timeouts do not apply to local users. 8) HANG UP LINE AFTER A SLEEP TIMEOUT? - This parameter specifies what GC does in the event of a sleep timeout (see previous parameter). If this parameter is set to "YES," GC will disconnect the remote user. If it is "NO," GC will preserve the connection and return the user to RBBS. There is a bug present in RBBS version 16-1A (fixed in 17-2A, but may be in other versions) that may influence how this parameter is set. In this RBBS version, when GC returns a user to RBBS after a sleep timeout, RBBS prints the familiar "Enter Password (dots echo)?" prompt. However, when RBBS' sleep timeout occurs, the user is not disconnected. Instead, another "Enter Password..." prompt is printed. This cycle can happen up to five times, tying up the BBS for five times your RBBS' sleep timeout period (would be 15 minutes for a typical 3 minute sleep timeout). Therefore, someone who decides to walk away from their computer while talking to the BBS can needlessly tie up the system for much more than the intended three minutes! Due to this problem, I *strongly* recommend that everyone set this parameter to "YES" so GC will handle the details of the sleep timeout. 9) DTR MANIPULATION USED TO HANG UP - There are several instances in which GC may disconnect a user. One such instance is when the user requests to hang up instead of returning to the BBS. Another is when a sleep timeout occurs and parameter eight is set to "YES." GC assumes that some manipulation of the Data Terminal Ready (DTR) communication signal will disconnect the user. One possible manipulation is KILL, where the DTR signal is dropped and never brought back up. Another manipulation is PULSE, where DTR is dropped for a short time and then raised again (drop time is specified by parameter 10). If you are using a modem, PULSE is usually the best choice, since GC must subsequently send a "go offhook" command to the modem. However, if GC is connected to a digital PBX or other non-modem device, KILL may be required, since DTR may give the communicating device permission to answer incoming calls. The Grand Central Reference Manual, Version 1.01 Page 16 ____________________________________________________________________________ 10) LENGTH OF TIME TO PULSE DTR - If parameter 9 is set to PULSE, this parameter specifies the number of seconds that the DTR communication signal is held low after a user is disconnected. For modems, a value of three is often sufficient. 11) COMMUNICATION FLOW CONTROL - GC supports three types of flow control: XON/XOFF (software flow control), RTS/CTS (sometimes called EIA or hardware flow control), or none. Modem-based BBSes generally operate with XON/XOFF flow control. 12) MODEM COMMAND TO GO OFF-HOOK - When a user disconnect occurs and after the DTR hangup manipulation is performed (see previous two parameters), GC can send a command to the communicating device to tell it to make the communication line busy. This command, which can be up to 30 characters long, should be the same "off-hook" command that is used with RBBS. If the command is blank, no off-hook command is sent after a user disconnect. 13) LOCAL SCREEN FOREGROUND COLOR - This color is used for normal text on the local screen. Users with monochrome video systems should choose WHITE. GC does not yet support color for the remote caller. 14) LOCAL SCREEN PRIORITY COLOR - This color is used for important messages on the local screen. Users with monochrome video systems should choose BRIGHT WHITE. 15) LOCAL SCREEN BACKGROUND COLOR - This color is used for the background of the local screen. Users with monochrome video systems should choose BLACK. 4.2 - GC Conference Configuration --------------------------------- The GC Conference Configuration Menu can be accessed by choosing the "C" option at the G-CONFIG Main Menu. The Conference Configuration Menu allows one to either: 1) Add a new conference, 2) Modify an existing conference, or 3) Remove an existing conference. If there is more than one screenful of existing conferences to choose from, <ENTER> and <TAB> can be used to scroll among the selections. The numbers that are displayed alongside each existing conference refer to each conference's GC reference number. The numbers' significance for the Sysop is limited to the welcoming screen names used in the GC screen files ("CONF1" screen for conference#1, etc.). The conference numbers are never shown to users. To add a conference, choose the "A" option. You will be prompted for the long and prompt (short) names of the conference. The long conference name, which can be up to 40 characters long, is used by GC whenever an identifying "banner" for a conference is needed (e.g., above the conference's menu). The prompt conference name, which can be up to 20 characters long, is used as a command prompt in the conference's menu and when the conference's messages are being read. Neither prompt should contain the word "CONFERENCE" because that word is added by GC when necessary. After the conference's names are entered, you are given a chance to modify all of the conference's 12 parameters, which are described in detail below. When you are finished setting parameters in G-CONFIG, you will also need to create a conference welcoming screen in the WELCOME screen file (see Chapter 5). The Grand Central Reference Manual, Version 1.01 Page 17 ____________________________________________________________________________ To modify a conference, you can either type in part of the conference's name or use its number as displayed on the screen. For regular conferences, you can then modify any of the conference's 12 parameters as described below. However, if you are modifying the parameters of the Main Message Base, only parameters 8, 9, and 10 may be changed. This is due to the fact that the Main Message Base always retains that name, is always maintained by the Sysop, and is open to all users regardless of security level. To remove a conference, use the "REMOVE" command. As with modification, you can either use part of the conference's name or its number. G-CONFIG will then request that you type "CONFIRM" to make sure that you really want to remove the conference. Removing a conference deletes all conference membership information, and thus removes the conference from everybody's conference menus. It does not delete conference messages from the disk, however. Note that removing a conference does not cause the numbers of other conferences to be changed. In fact, the slot where the deleted conference used to be will be marked "-UNUSED-" in the Conference Configuration Menu. The GC Conference parameters are as follows: 1) NAME OF CONFERENCE - This is the conference name that is displayed on all menus, including the menus where users select among different conferences. The name may be up to 40 characters long, and should not contain the word "CONFERENCE." If this parameter is changed, the next parameter (conference prompt name) should be modified to reflect the change. 2) PROMPT (SHORT) NAME OF CONFERENCE - This conference name is used for command prompts when a user is present in the conference. For example, if the conference prompt name was "IBM" then the prompt in the conference menu would read "IBM MENU>" and the prompt when reading messages would be simply "IBM>". This name may be up to 20 characters long, and should not include the words "CONFERENCE" or "CONF." 3) CONFERENCE TYPE - The conference type determines the method by which users join the conference. There are four conference types supported by GC, as follows: a) PUBLIC, FULL ACCESS b) PUBLIC, SPECTATOR ACCESS c) APPLICATION REQUIRED d) HIDDEN These types are fully described in Section 3.1. 4) MODERATOR #1 - This is the name of the conference's first (or only, if there is just one) moderator. GC requires that there be at least one person responsible for operation of the conference. This person can be any valid RBBS user or "SYSOP." In GC, moderators are responsible for: a) Handling mail queries about the conference b) Keeping the message base cleaned out by deleting old messages, where necessary c) Handling applicants, if the conference is an "APPLICATION REQUIRED"-type d) Maintaining the conference security system and changing user access levels and locking out users, where necessary Upon exit from conference configuration, the user who is listed here is automatically and immediately given moderator-level access to the conference. Therefore, be careful whom you specify as a moderator. The Grand Central Reference Manual, Version 1.01 Page 18 ____________________________________________________________________________ If you change conference moderators, *you* are responsible for manually reducing the access level of the old moderator (through the GC program Sysop Menu) if you do not want the old moderator to have moderator access any longer. Sysop-level users can always gain moderator access to a conference no matter what their security level is in that conference. This is done by using the [A]ssert Sysop Security Privileges command in GC's Sysop Menu. Note that it is possible for users not listed here to be manually given moderator-level access. The three moderators that are specified in the conference configuration are used mainly for letting other users know who is in charge of the day-to-day operation of the conference, as well as providing a facility for users to address comments, suggestions, and queries to the proper person. 5) MODERATOR #2 - This is the name of the conference's second moderator. If this item is left blank, there will be no second conference moderator. See the preceding listing for more information on conference moderators. 6) MODERATOR #3 - This is the name of the conference's third moderator. If this item is left blank, there will be no third conference moderator. See the listing for parameter four for more information on conference moderators. 7) WHICH MODERATOR RECEIVES MODERATOR MAIL - Each conference menu contains an option which reads "[M]ail letter to moderator." GC determines which moderator will receive the letter using this parameter. If, for some reason, the moderator's mailbox cannot be reached, GC will forward the letter to the Sysop mailbox. 8) MAXIMUM NUMBER OF TOPICS - This parameter puts an upper limit on the number of topics that may be entered in the conference. GC also has an internal purpose for this parameter; it allocates a certain portion of the message control file (the CTRL.xxx files) for topic storage. For those concerned about disk space, each topic you specify by this parameter will take 114 bytes of disk storage. 9) MAXIMUM NUMBER OF REPLIES PER TOPIC - This parameter puts an upper limit on the number of replies that can be made to any one topic in the conference. 10) MAXIMUM NUMBER OF LINES PER MESSAGE - This parameter specifies the maximum number of lines that can be placed in any one message. Note that a higher number here requires more memory, since all editing and message display is performed in memory. 11) MINIMUM RBBS SECURITY FOR NEW USERS/APPLICANTS - This parameter has different meanings depending on the type of conference: a) PUBLIC, FULL ACCESS or PUBLIC, SPECTATOR ACCESS - Users are not allowed to initially join the conference unless their RBBS security is at least equal to this parameter. b) APPLICATION REQUIRED - Users cannot apply for the conference unless their RBBS security is at least equal to this parameter. c) HIDDEN - This parameter is not applicable, since users are not allowed to directly join this type of conference. If you do not wish to restrict conference access in this manner, simply set this parameter lower than your RBBS' lowest security The Grand Central Reference Manual, Version 1.01 Page 19 ____________________________________________________________________________ level. 12) MINIMUM RBBS SECURITY FOR CURRENT USERS - This parameter, which applies to all types of conferences, restricts current conference users' access by their RBBS security level. In most cases, this level should be the same as parameter 11's level. This is due to the fact that a new member of a conference must pass the "parameter 11" test to be allowed to join the conference, but then must pass this test to actually enter the conference. If you are working with an apply-for-membership conference, however, there are valid reasons for having two different security levels in parameters 11 and 12. For example, consider the case where a private club is created whose "clubhouse" is an apply-for-membership conference. In addition, each user accepted into the club is given a higher RBBS security level. Here, a higher current user security restriction would be logical, since persons whose RBBS security is below the club limit would not belong the club, and hence should be denied access to the club conference. 4.3 - Post Office Configuration ------------------------------- The Post Office configuration parameters can be modified by choosing the "P" option at the G-CONFIG Main Menu. There are 9 parameters to set, and they are as follows: 1) MINIMUM RBBS SECURITY TO USE THE POST OFFICE - This setting is used to restrict access to the Post Office. It does *not* prevent users from sending replies to authors of messages nor does it restrict use of the conference menu [M]ail Letter to Moderator command. In essence, it allows the Sysop to prevent certain people from receiving letters. If you do not wish to restrict Post Office use in this manner, set this parameter lower than your RBBS' lowest security level. 2) MINIMUM RBBS SECURITY TO SEND LETTERS AT THE POST OFFICE - This parameter is much like the last one in that it prevents certain people from sending letters at the Post Office, but does not prevent users from sending replies to authors of messages nor does it restrict use of the conference menu [M]ail Letter to Moderator command. If you do not wish to restrict Post Office letter sending in this manner, set this parameter lower than your RBBS' lowest security level. 3) MAXIMUM NUMBER OF LINES PER LETTER - This parameter is similar to conference configuration parameter number 10 (see preceding section). It puts an upper limit on the length of letters. Also, keep in mind that the bigger this parameter is, the more memory that will be required. 4) WIPE AWAY LETTER CONTENT WHEN DELETING LETTERS? - If you are familiar with a DOS "UnErase" utility, you may be familiar with the problem that the DOS DEL command erases the files as people see them, but does not actually erase the *content* of the files from the disk. There is a similar situation with the GC Post Office, except that GC gives you a choice of whether or not you want the content of a letter to be deleted when the letter's recipient deletes the "visible" letter. If you want to preserve the utmost in privacy for your users, select "YES." Otherwise, the Sysop will be able to read the content of all letters (located in the CONT.PST file) even after the letters have The Grand Central Reference Manual, Version 1.01 Page 20 ____________________________________________________________________________ been deleted. Note that the GC optimization program erases deleted letters' content automatically every week. 5) NUMBER OF LETTERS IN MAILBOX BEFORE CLEANOUT REQUIRED - Since the Post Office files can take up a good deal of disk space, this parameter allows the Sysop to restrict users from having too many letters stored in their mailboxes. If a user has more than this parameter's number of letters is their mailbox, GC will prevent that user from sending letters through the Post Office until the user reduces the number of letters in their mailbox to below this limit. Again, as with the Post Office security limits mentioned above, this limit does not prevent the user from sending letters elsewhere in GC. 6) TRACE LIMIT - Since GC's mail system is designed such that a letter sender does not actually see their letter after it is sent, GC provides a feature called mail trace that allows letter senders to determine if their letters have been received. However, to conserve disk space, GC cannot allow the letter control information to remain available indefinitely. This parameter specifies the minimum number of days a trace is possible for after the letter was first read by the recipient. Note that if the recipient chooses not to delete the letter during the trace period, a trace on that letter will still be possible as long as the recipient does not delete the letter. An example will help illustrate this concept. Suppose a letter is mailed on the first of the month and received on the third of the month. If the trace limit were 14 days, the letter sender could determine the status of the letter until at least the 17th of the month, and possibly longer. 7) ALLOW DISTRIBUTED MAIL? - GC allows users to send a single letter to more than one recipient. This service is available anywhere the user is allowed to send a letter, except in the conference menu "[M]ail" command. If this parameter is set to NO, however, distributed mail is disabled everywhere. 8) MINIMUM RBBS SECURITY TO USE DISTRIBUTED MAIL - This parameter allows the Sysop to set a minimum security requirement to use distributed mail. 9) MAXIMUM NUMBER OF DISTRIBUTED LETTERS - This parameter allows the Sysop to set an upper limit on the number of recipients for any one letter. This number may be between 2 and 30. The Grand Central Reference Manual, Version 1.01 Page 21 ____________________________________________________________________________ CHAPTER 5 - .GCS SCREENS - THE KEY TO CUSTOMIZING GC ---------------------------------------------------- .GCS files are the "bread-and-butter" of the Grand Central's user interface (GCS stands, appropriately, for Grand Central Screen). You need to be concerned about these files because they are the place where you will apply your creative touch to your GC installation. 5.1 - The Purpose of .GCS ------------------------- It is probably best to introduce the GCS concept by contrasting it to the system used by RBBS to organize its screens. Your RBBS directory is probably cluttered with dozens of help files and menu displays, with each file containing one display. There are several problems with organizing the screens in this manner. First, having a large number of small files on a disk is not very space-efficient, due to the way DOS allocates disk space. Second, time is wasted in searching the disk each time a particular screen is needed. Finally, it is difficult for you, the Sysop, to identify screens from a directory listing because of the eight-character DOS filename limitation. The GCS concept is an attempt to remedy all three of these disadvantages. GCS files essentially bundle all of the numerous screens used by the GC program into a few easily manageable files. GC currently uses three GCS files: STARTUP.GCS, WELCOME.GCS, and HELP.GCS. You will also notice that there are three related files that came with GC: STARTUP, WELCOME, and HELP. These latter files, which are simply different versions of their respective .GCS files, are the only files you will directly work with. As described later on, the .GCS files are generated by running the included conversion program CONVSCRN.EXE. The GC program only looks at the .GCS versions of the three files. 5.2 - The .GCS Format --------------------- Since you will be working with the STARTUP, WELCOME, and HELP files in your editor or word processor, it is important to understand their basic format. Here is a simplified version of the file STARTUP that was included with your GC package (comments have been added - compare this to the real article by using your file editor): Declarations { !STARTUP,10 { !BADSECLOGON-H1,5 Comment line---> +++++ STARTUP SCREEN +++++ /{ Advanced Conferencing and Mail System / { for RBBS Bulletin Boards / { ---------------------------------------------------------- Content { WELCOME TO THE GRAND CENTRAL MESSAGE SYSTEM! of { STARTUP { If you have any questions or suggestions about GRAND screen { CENTRAL, please send a note to the SysOp using the main \ { menu "M" command. Enjoy! \ { \{ ---------------------------------------------------------- Comment line---> +++++ RBBS SECURITY LEVEL TOO LOW TO LOGON MESSAGE +++++ { ---------------------------------------------------------- Content { *** ATTENTION *** of { Your RBBS security level is too low to use Grand BADSECLOGON-H1{ Central. Please contact the Sysop if you have questions. screen { ---------------------------------------------------------- The Grand Central Reference Manual, Version 1.01 Page 22 ____________________________________________________________________________ The first two lines in the file are known as screen declarations, which tell GC the names of the screens that are contained in the file, the length of each screen in lines, as well as the order in which the screens appear in the file. The names of the screens are predetermined by me, but their order within the file is not. For example, if you decided to rename the STARTUP screen as STARTING, the GC program would become confused since it could not find the STARTUP screen it was expecting. On the other hand, if you decided to swap the positions of the STARTUP and BADSECLOGON-H1 screens within the file (which would mean switching the positions of the screen declaration lines as well as the screen content lines), the GC program would not have a problem with that. Note that the number listed after each screen name represents the length of the screen, not including the comment line that precedes each. Looking beyond the first two lines of the above file, the rest of the file consists of the actual content of each screen. Note that the first line of each screen definition is not a part of the displayed screen, but is instead simply a comment line to aid you in determining where one screen stops and another begins. There is no predetermined format for the comment lines, so you can change them if you so choose. There is a predetermined format, however, for the screen content. Since GC assumes an 80 x 24 screen display, 79 characters are allowed on each GCS screen line (this limitation is necessary since computers and terminals do not always handle line wrapping uniformly). Also, there are length limitations for individual screens; these will be detailed shortly. For the moment, GC does not support ANSI screens (i.e., colors and animation) in the .GCS files. This limitation will be addressed in a future release of the GC. Now it is time to explain how you, the Sysop, can customize your GC system using .GCS files. It is important to realize that there are some GCS screens you MUST customize! If you examine the STARTUP, WELCOME, and HELP files that came with GC, you will doubtless see places where the name of your BBS and other custom touches are required. In some cases, you can utilize the same screens you presently use with RBBS. All that's necessary to transfer RBBS screens is an editor that can cut text out of the RBBS file(s) and transfer it into the proper place in the STARTUP, WELCOME or HELP files. As a sidenote, the shareware word processing program PC-WRITE 3.0 makes GC screen file editing especially easy. Simply make each comment line a PC- WRITE page break (<ALT>-<T>) and, presto, PC-WRITE removes the tedium of determining the lengths of screens (it displays this information on its status line as the page length). This operation in no way affects the way the screens look, since GC does not care what is placed on the comment lines. One rule applies here, however: do not do a page reformat, as this will slightly scramble the file's comment lines. 5.3 - Catalog of All .GCS Screens --------------------------------- What follows is a table of all the screens GC uses, an indication of whether you will need to customize it or not, and the maximum length of each screen. Note that there are special restrictions on some screens, which are listed in Appendix B. The Grand Central Reference Manual, Version 1.01 Page 23 ____________________________________________________________________________ FILE SCREEN NAME DESCRIPTION --------------------------------------------------------------------------- STARTUP STARTUP This screen is used as GC's opening screen. This is a screen you MUST customize, since it will contain your BBS' name and an opening greeting. Maximum length=11. STARTUP BADSECLOGON-H1 This is displayed when a user does not have an RBBS security level high enough to use GC. No need to customize. Max len=23. WELCOME CONFx In this case, the "x" in CONFx refers to an GC internal conference number which was described in Section 4.2. These screens are the welcoming screens for each conference, so they obviously must be set up for your particular BBS. Max len=12. WELCOME POSTAL This contains the logo for the Post Office menu screen and should be customized. Max len=12. WELCOME MENU0 This is the main menu displayed to users. You may wish to customize the listing for the "[Q]uit" command so it reads "[Q]uit to BBSname". See Appendix B for special restrictions on this screen. Max len=8. WELCOME MENUXX This is the general menu displayed when a user enters each conference. No need to customize. Max len=8. WELCOME MENUPOST This is the Post Office menu. No need to customize. Max len=8. WELCOME UNREADALL This screen is displayed when a user wants to read messages in a conference, but he or she has already read all of them. No need to customize. Max len=23. WELCOME CONFSELECT This forms the first several lines in the Conference Select Menu. Just as in the MENU0 screen, you must customize the "[Q]uit" command with the name of your BBS. See Appendix B for special restrictions. Max len=4. WELCOME NEWUSER0 This is a special, longer version of STARTUP that is displayed to new users. It should be customized with your BBS name. Max len=17. WELCOME TERMSELECT This screen is displayed to new users and others who wish to change their GC terminal configuration. Customizing this screen is NOT recommended, since one cannot change the meaning of the numeric selections by changing the appearance of the screen. Max len=24, although the last line is used for a prompt. WELCOME EPILOG This screen is displayed to users who choose to hang up directly from GC. It is a good place to insert the BBS name. Max len=20. WELCOME CHATMODE This is displayed when the sysop initiates a chat with a caller. The SysOp's name can be placed on this screen. Max len=13. WELCOME CONFAPPLY When a user wishes to join a conference which is configured as an application-only conference, this screen is displayed for the purpose of confirming whether the user really wishes to apply for membership in the conference. No need to customize. Max len=24. WELCOME CONFAPPLIED This is displayed immediately after CONFAPPLY, The Grand Central Reference Manual, Version 1.01 Page 24 ____________________________________________________________________________ if the user decides to apply. Max len=24, but see Appendix B for restrictions. WELCOME CONFBADNEWSEC This is shown to people who try to join a conference, but who do not have an RBBS security level high enough to join. No need to customize. Max len=24. WELCOME CONFAPPUPDATE This is displayed to users who check back to see if they have been accepted in an apply-for- membership conference, but for whom no action has been taken. No need to customize. Max len=24. WELCOME CONFDENY This screen is the equivalent of a rejection letter in apply-for-membership conferences. No need to customize. Max len=24. WELCOME CONFACCEPT This screen, the opposite of CONFDENY, is an acceptance screen in apply-for-membership conferences. No need to customize. Max len=24. WELCOME CONFBADOLDSEC This is shown to people who are already a member of a conference, but who no longer have an RBBS security level high enough to use the conference. No need to customize. Max len=24. WELCOME TOPICSFULL When a user tries to enter a new topic into a conference which has reached its topic limit, this screen is displayed. No need to customize. Max len=24. WELCOME REPLIESFULL When a user tries to enter a reply into a topic which has reached the conference limit on replies, this screen is displayed. No need to customize. Max len=24. WELCOME SPECTATOR Users who try to write messages in a conference where they have only spectator access are shown this screen. No need to customize. Max len=24. WELCOME SYSOPMENU This is the menu shown to Sysop(s) when the "[S]ysop functions" command is activated from the main menu. Max len=24, although the last screen line is used for a prompt. WELCOME MODERATMENU This is the menu shown to conference moderators who use the "[S]pecial moderator functions" command from their conference's menu. Max len=24, although the last screen line is used for a prompt. WELCOME APPLICMENU This is the menu shown to conference moderators when they use the "[A]pplicant handling" feature on the Moderator Menu. Max len=5. WELCOME AUTOSPECTATOR When a user first joins a PUBLIC, SPECTATOR ACCESS conference, then the user is shown this screen which indicates that the user has been given spectator-level access. No need to customize. Max len=24. WELCOME POSTBADSEC This screen is displayed to users to attempt to access the Post Office, but who do not have an RBBS security level high enough to access it. No need to customize. Max len=24. WELCOME MAILBADSEC When a user attempts to mail a letter in the Post Office and does not have a sufficient RBBS security level, this screen is shown to the user. No need to customize. Max len=24. The Grand Central Reference Manual, Version 1.01 Page 25 ____________________________________________________________________________ WELCOME MAILCLEANOUT As a Sysop, you can establish a number of letters whereby if a user has more than that number of letters in his or her mailbox, then that user will not be allowed to mail outgoing letters until their mailbox has been cleaned out. This screen is displayed when a user is tries to mail a letter but is in violation of this "clean limit." No need to customize. Max len=24. HELP CSELECT-H1 This is the help screen for the Conference Selection Menu and the related Conference Availability Menu. No need to customize. Max len=23. HELP EDITMSG-H These two screens provide help for the GC EDITLTR-H editor. The difference between the two is that EDITMSG-H provides help when the editor is operating on messages, and EDITLTR-H provides help when the editor is operating on letters. No need to customize. Max len=24. HELP NOVMSG-H1 These screens are the help screens for novice- NOVMSG-H2 level users in the message reading mode. No need to customize. Max len=23. HELP EXPMSG-H1 This screen is the help screen for expert-level users in the message reading mode. No need to customize. Max len=23. HELP NOVLTR-H1 These screens are the help screens for novice- NOVLTR-H2 level users in the letter reading mode. No need to customize. Max len=23. HELP EXPLTR-H1 This screen is the help screen for expert-level users in the letter reading mode. No need to customize. Max len=23. HELP NEWUSERx This is a set of screens that comprise the GC Tutorial. The Tutorial is shown to all new users automatically, as well as to any other user that requests it using the "[T]utorial" command at the main menu. No need to customize. Max len=23. 5.4 - Summary of .GCS Concepts ------------------------------ There are three important considerations during the process of customizing screens for your BBS, namely: 1) The length of the screen: a) Make sure that the length of a screen does not exceed the maximum length for that screen, as listed in this manual. b) Double check to ensure that each screen's defined length (at the top of the file) is the same as its actual length. If they are not the same, GC will not be able to determine correctly where screens begin within the .GCS file. Note that the comment line at the top of each screen is NOT considered part of the screen's length. c) Be aware of special restrictions on some screens. For example, GC overlays the contents of some screens with the names of conferences and conference moderators. These restrictions are spelled out completely in Appendix B. The Grand Central Reference Manual, Version 1.01 Page 26 ____________________________________________________________________________ 2) The screens' contents must be in the same order as their declarations at the top of the file - if they are not, GC may display screens that are completely different from what you intended! 3) All of your modifications take place in the STARTUP, WELCOME, and HELP files - after you are done modifying these files, be sure to run the CONVSCRN.EXE program to convert each of these files into .GCS files. The Grand Central Reference Manual, Version 1.01 Page 27 ____________________________________________________________________________ CHAPTER 6 - CONNECTING GC TO RBBS --------------------------------- As mentioned in Section 3.4, the difficulty of installing GC as a door depends on whether RBBS is already set up for doors. If it is not, there are several additional steps that must be performed. If you are experienced with the ins and outs of RBBS, please forgive me if my descriptions are a bit long-winded. RBBS is intimidating to beginners because almost everything is reconfigurable, and it's very easy to get lost in the jungle of dozens of files and more than two hundred configuration parameters. This chapter is written with the assumption that you are completely shutting down RBBS' message system. If you have a special situation that requires some conferences to remain in RBBS, you will want to skip the passages that describe shutting down the message system. The first step in this process is installing the FOSSIL driver. This process is explained in Section 6.1. The next step is running RBBS' CONFIG program. If you are using RBBS 15.1C or 16.1A, continue with Section 6.2. Otherwise, go to Section 6.3. 6.1 - FOSSIL Installation ------------------------- If you do not already have a FOSSIL communication driver installed in your system, you will need to follow the steps in this section. These installation directions are for the "X00" driver, which is a popular FOSSIL implementation. If you have another FOSSIL driver (such as BNU or FOSSCOMM), GC will most likely work with it, but please consult that driver's instructions for installation guidance. Here is the "X00" installation process: 1) Extract and copy the files X00.SYS and X00.DOC to your disk's root directory. 2) Edit your system's CONFIG.SYS file and add the following line: DEVICE = \X00.SYS E 3) If you are using RBBS version 17.1A or later, you can instruct RBBS to use the FOSSIL driver. Choose the CONFIG parameter named "Communications port to be used by RBBS-PC" (parameter# 221 in RBBS 17.2A), and RBBS will ask you if you want to use FOSSIL. Some RBBS doors such as TradeWars will automatically recognize and use FOSSIL. This installation process will work for the majority of systems. However, if you encounter communication-related problems, you should read the X00.DOC file for further information. 6.2 - Configuring RBBS 15.1C and 16.1A -------------------------------------- As you are going through RBBS' CONFIG program, you may encounter a case where you have named a file differently than the RBBS convention. If this is the case, simply make a note of it, since this document will refer to the standard RBBS names. Note that the RBBS parameter numbers listed here are from RBBS 16.1A. RBBS 15.1C will probably have different numbers. Here are the parameters you need to change, and why: The Grand Central Reference Manual, Version 1.01 Page 28 ____________________________________________________________________________ #89 (Record comments as private messages) - Answer "NO." Since RBBS' message system is being shut down, comments to the Sysop should be recorded in the COMMENTS file, not in the message base. #101 (Is the 'door' subsystem available) - Answer "YES" for obvious reasons. #102 (The 'door' subsystem menu is named) - This should be "MENU5". #103 (File built dynamically to open a door) - This should be "RCTTY.BAT". #104 (When a door closes, re-invoke RBBS-PC via) - This should be "RBBS.BAT". #105 (Drive/path to look for COMMAND.COM on) - Assuming that you are booting from a C: drive, this should be "C:\". #127 (Minimum security level to use RBBS-PC 'doors') - If doors are a restricted privilege on your BBS, you may wish to change this parameter so all regular users can access GC. #130 (Security level for main menu functions) - Change the levels as follows: E)nter message } K)ill messages } - Set 32767 for all of R)ead messages } these since the S)can messages header } message system is T)opic msg scan } being disabled V)iew a conference } J)oin a conference } - Don't change these P)ersonal mail } D)oor subsystem } - Set this to the same level as parameter 127 After you have entered all of the above changes, exit CONFIG and go into your file editor. The next step is to modify your RBBS' main menu and door menu to account for the presence of the GC door. The MENU2 file is the main menu. I suggest doing some extensive editing on that menu so there are as few choices as possible, hence less user confusion. Here is the MENU2 file I use on my Pinnacle BBS: PINNACLE M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ****************************************** > [D]oors, featuring: < > The Grand Central Message System < > -and- < > Trade Wars Multi-Player Game < ****************************************** [F]ile System [C]omment to Sysop [X]pert on/off [B]ulletins [O]perator page [G]oodbye [U]tilities [H]elp ---> Type "D GC" to quickly access Grand Central. ---> Type "D TWARS" to quickly access Trade Wars. The Grand Central Reference Manual, Version 1.01 Page 29 ____________________________________________________________________________ Note that the "[D]" is required since that command letter is used to invoke doors. If you use MENU2C or MENU2G files, you will need to either modify them to look similar to MENU2, or delete them. This step, particularly with MENU2C, requires an ANSI screen editor such as TDRAW. The MENU5 file is the door menu. This file is fairly simple, and can be styled in any manner you desire. The only requirement is that the capitalized word "GC" must appear somewhere on the screen, because it will be the name of the batch file used to invoke GC. Note that users will see the door menu only if they type "D" at the RBBS main menu. However, if the user types "D GC", the door menu is bypassed and GC is invoked immediately, since the separate commands "D" and "GC" are being executed in sequence. Here is Pinnacle's MENU5 file: \ / - * - *** >>> PINNACLE'S DOOR MENU <<< **** ******* Doors with keys available: ************ ************* GC - The Grand Central Message System **************** TWARS - Trade Wars Multi-Player Game ****************** As before, be aware of the MENU5C and MENU5G files. If you can't adequately modify them, delete them. Now, you will need to create a file in the RBBS directory called GC.BAT. This will be the file RBBS calls in order to invoke GC. Since Pinnacle's GC system is located in the C:\GC directory, its GC.BAT file appears as follows: ECHO OFF C: CD \GC GC %1 C: CD \RBBS There are no special modifications needed here, unless your GC or RBBS is on a different drive or directory than listed. For the technically inclined, note that RBBS.BAT is not reinvoked at the end of the file, since this batch file is invoked directly under a COMMAND.COM shell (i.e., primitive batch file call). If you have other RBBS doors, you may need to modify the batch files that invoke them. If any of those doors require that the WATCHDG carrier monitor be enabled, place the WATCHDG1 ON or WATCHDG2 ON statement at the beginning of the batch file that invokes the door(s), instead of in the RBBS.BAT file. This step is necessary because GC does not require WATCHDG to be enabled (see Section 6.4 for details). 6.3 - Configuring RBBS 17.1A and Later Versions ----------------------------------------------- Thanks to some recent advancements in RBBS, the quality and appearance of GC installations can be significantly improved. Please understand that The Grand Central Reference Manual, Version 1.01 Page 30 ____________________________________________________________________________ the items mentioned in this section have been tested only with RBBS 17.2A. These features will probably work with RBBS 17.1, but I'm not making any guarantees. As far as doors are concerned, RBBS 17.3A offers few new features, so you should have no problems with that version. The parameter numbers listed are from the RBBS 17.2A CONFIG program. Arguably the most important new RBBS feature for GC users is the macro facility. This allows the Sysop to make GC accessible through a single- letter command on RBBS' Main Menu. The complete sequence of steps required to set up such a GC system is as follows: 1) The RBBS parameters that must be modified are as follows: #17 (Control character for SMART TEXT) - This should be "123". #79 (Drive/path where macro files are stored) - Set this to the same drive and path where your RBBS is located. #80 (Extension of macro files) - This should be "MCR". #89 (Record comments as private messages) - Answer "NO." Since RBBS' message system is being shut down, comments to the Sysop should be recorded in the COMMENTS file, not in the message base. #101 (Is the 'door' subsystem available) - Answer "YES" for obvious reasons. #102 (The 'door' subsystem menu is named) - This should be "MENU5". #103 (File built dynamically to open a door) - This should be "RCTTY.BAT". #104 (When a door closes, re-invoke RBBS-PC via) - This should be "RBBS.BAT". #105 (Drive/path to look for COMMAND.COM on) - Assuming that you are booting from a C: drive, this should be "C:\". #130 (Security level for main menu functions) - Change the levels as follows: E)nter message } K)ill messages } - Set 32767 for all of R)ead messages } these since the S)can messages header } message system is T)opic msg scan } being disabled V)iew a conference } J)oin a conference } - Don't change these P)ersonal mail } D)oor subsystem } - Set this to the same level as your RBBS' new user security level 2) Now, you will need to modify your RBBS' MENU2 file (Main Menu) to look something like the following: PINNACLE M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ******************************* > [M]essage/Mail System < ******************************* [F]ile System [C]omment to Sysop [X]pert on/off [B]ulletins [O]perator page [G]oodbye [U]tilities [H]elp The Grand Central Reference Manual, Version 1.01 Page 31 ____________________________________________________________________________ 3) Next, modify your RBBS' MENU5 file (Door menu) to account for the presence of the GC door, which will be called "MESSAGE". You can style the menu any way you like, but the capitalized word "MESSAGE" must appear somewhere on the screen. Here is an example: \ / - * - *** >>> PINNACLE'S DOOR MENU <<< **** ******* ************ Door with keys available: ************* **************** MESSAGE - The Grand Central ****************** Message System 4) A file called MESSAGE.BAT must now be created in your RBBS directory. The file assumes GC is located in the C:\GC directory and RBBS is located in the C:\RBBS directory: ECHO OFF C: CD \GC GC %1 C: CD \RBBS 5) Finally, you must create a file named M.MCR. This is the actual "macro", which is simply a sequence of commands that is executed when the user selects "M" at RBBS' Main Menu. Note that the first line of the file is a number which represents the minimum security level needed to execute the file. You should set this number to the same level as your RBBS' new user security level. Here is the M.MCR file I use on my BBS, which has a new user security level of 3: 3 {*1 {*1Please standby... {EN D MESSAGE Another useful feature introduced in RBBS 17.1A was one which allows Sysops to disable the RBBS personal mail check at logon. This prevents the display of the message "Sorry, USER, no mail for you." This message tends to confuse users, since the GC mail system has no influence whatsoever on the display of that message. To deactivate the personal mail check, set RBBS parameter 19 to "Skip". A feature appeared in RBBS 17.1A which allows Sysops to set a "time lock" whereby users cannot access doors or download files for a certain period of time after they log on. This feature is undesirable for systems running GC since it prevents users from accessing mail and messages when they want to. Therefore, it is recommended that you set this "time lock" (parameter 155) to zero. If you are using RBBS 17.2A, you will probably want to use RBBS' new door control file feature. Its main advantage for GC installations is that it can eliminate the password prompt that appears when users go from GC back to RBBS. First, check that parameter 109 is set to "DOORS.DEF". Then, The Grand Central Reference Manual, Version 1.01 Page 32 ____________________________________________________________________________ create a DOORS.DEF file in your RBBS directory containing the following text: MESSAGE,,,D,"MESSAGE.BAT [NODE]",N,, You can look in the RBBS manual for a detailed explanation, but it is sufficient to say here that this action disables the password prompt when users return from GC to RBBS, but otherwise does not affect the operation of GC. 6.4 - The RBBS.BAT File ----------------------- This section describes the process of creating or modifying the RBBS.BAT file. If you already invoke RBBS via the RBBS.BAT file, make sure your version performs the same operations as the sample version below. If you do not currently invoke RBBS with a batch file, you will need to begin doing so. Listed below is the RBBS.BAT file I use on my BBS. For most people, this version should be sufficient. However, if you do exotic things with RBBS.BAT such as network mail handling, you will have to combine this version with your version. Here is my version of RBBS.BAT: Batch file Comments (not in batch file) ------------------------------------------------------------------------ :BEGINNING ECHO OFF <-- DOS command echoing off C: CD \RBBS <-- Go to C:\RBBS directory WATCHDG1 OFF <-- Always disable carrier monitor IF EXIST DORINFO1.DEF DEL DORINFO1.DEF <-- Erase door info file IF EXIST RBBS1F1.DEF DEL RBBS1F1.DEF <-- Erase RBBS exit indicator IF EXIST RBBS1TM.DEF DEL RBBS1TM.DEF <-- RBBS 17.1A or later only! IF EXIST RCTTY.BAT DEL RCTTY.BAT <-- Erase door batch file RBBS-PC 1 RBBS-PC.DEF <-- Invoke RBBS node 1 IF EXIST RBBS1F1.DEF GOTO EXIT <-- Handle RBBS shutdown IF EXIST DORINFO1.DEF GOTO DOORACCESS <-- Jump if invoking a door IF EXIST RBBS1TM.DEF RBBS1TM.BAT <-- RBBS 17.1A or later only! IF EXIST RCTTY.BAT WATCHDG1 ON <-- Skip carrier monitoring for :DOORACCESS doors but not others IF EXIST RCTTY.BAT RCTTY.BAT <-- Invoke door or drop-to-DOS GOTO BEGINNING <-- Loop to re-invoke RBBS :EXIT A few comments about this file are in order. In case you are not familiar with the WATCHDG program, it is a utility that continuously checks for remote user hangups (a process commonly referred to as "carrier monitoring"). If a user does hang up without warning, WATCHDG reboots the BBS computer. It is used mainly with programs which were not originally intended for remote use. GC *does not* require the presence of WATCHDG, since carrier monitoring is performed automatically. If you run GC with WATCHDG enabled, you run the risk of GC malfunctions, since WATCHDG performs immediate reboots which do not allow GC to shut down normally. This file does assume you are using the directory C:\RBBS for your copy of RBBS, and is also written specifically for RBBS node 1. You do not need to be concerned about the RCTTY.BAT, RBBS1F1.DEF, RBBS1TM.DEF, or DORINFO1.DEF files. They are created by RBBS automatically when needed. The Grand Central Reference Manual, Version 1.01 Page 33 ____________________________________________________________________________ Because there is a potential for system reboots due to remote user hangups or power failures, you should set up your system's AUTOEXEC.BAT file to automatically invoke RBBS.BAT if it is not already set up to do so. 6.5 - Desirable RBBS Cosmetic Changes ------------------------------------- In order to keep user confusion to a minimum, it is recommended that you modify several RBBS help files. The first and most important file is MAIN.HLP. You should remove all references to the RBBS message, mail, and conference functions, and add a reference to GC. If you are running RBBS 15.1C or 16.1A, that reference would fall under the "D)oors" entry. If you are running a later RBBS version, you should remove the "D)oors" entry and replace it with a "Grand Central M)essage System" entry. The other important help file is the MD.HLP, which is a help file specifically for the doors function. Whether GC is invoked by an "M" or "D" command, this file should go into detail about what GC does and how to access the system quickly. Here is the MD.HLP file I use on my BBS (which is running RBBS 17.2A): Grand Central M)essage System: The Grand Central Message System is PINNACLE's all-new conference and E-mail system. In Grand Central, you can read and post messages in various discussion groups (called conferences), plus send and receive electronic mail to/from other PINNACLE users. To access Grand Central, you need only type the command "M" at RBBS' main menu. Then, after approximately 20 seconds, you will see Grand Central's opening screen. If you have never used Grand Central before, you will be given a short tutorial on the program's many useful features. After you are done with Grand Central each time, you can either hang up or return to RBBS. 6.6 - Testing RBBS and GC ------------------------- Please do not test GC using the general door testing procedure outlined in the RBBS manual. That method does not work with sophisticated doors such as GC. Instead, there are two methods for testing GC's connections to RBBS. The first and preferable method is to put up your BBS and call it remotely. Try invoking GC both using the RBBS door menu and using the shortcut RBBS command ("D GC" or "M" as described previously in this chapter). While in GC, the two important functions that need to be tested are: 1) the mail system, and 2) the security system. For both of these tests, it is helpful to set up a dummy user "ORDINARY USER" in RBBS, who has the same security level as one of your BBS' typical users. In the mail test, you should try sending mail to Ordinary User, then log in under Ordinary's account and see if the letter was received. If it was not, try using the "[U]ser file" utility in the G-CONFIG program. In the security test, make sure that you can access all of the proper Sysop and moderator menus and that Ordinary User cannot. Make sure that Ordinary User can access the Post Office, send mail, and join the proper conferences, as you deem appropriate. Check the "time remaining" reminder in the upper-right The Grand Central Reference Manual, Version 1.01 Page 34 ____________________________________________________________________________ corner of the screen against the time limits you have established for users (remember that they are set up to be either inherited RBBS limits or fixed limits). Finally, ensure that hangups and sleep timeouts work as they should. If you have RBBS 17.1A or later, you can also test GC through the local Sysop logon procedure. Once you have logged into RBBS, you should be able to access GC in the same manner as remote users. You should test all of the items detailed above. However, note that hangups, session limits, and sleep timeouts are not applicable for local users. The Grand Central Reference Manual, Version 1.01 Page 35 ____________________________________________________________________________ CHAPTER 7 - THE FINER POINTS OF GC ---------------------------------- This chapter will explain three major features of GC in detail. They are all explained to some extent by the on-line tutorial and help screens, but Sysops often like to have a nuts-and-bolts knowledge of what's happening. These explanations will also help you if your users ask questions about these features. 7.1 - Novice/Expert Command Entry --------------------------------- Since GC is a message and mail system, users will probably spend most of their time reading messages and letters. Hence, it is important to concentrate on making the user interface in the message and letter reading modes as smooth and simple as possible. In place of menus or on-the-fly prompting, GC uses plain English word commands in these areas. Here are the words and short phrases that combine to form GC commands: Adjectives: Nouns: Verbs: Prepositional phrases: NEXT MESSAGE SEND [REPLY] TO EVERYONE PREVIOUS LETTER CREATE TO AUTHOR UNREAD TOPIC INDEX HELP EXIT Obviously, not all combinations of these words are valid commands. Here is a complete list of commands which GC recognizes: UNREAD or NEXT UNREAD MESSAGE (Message reading mode) INDEX (Message reading mode) NEXT MESSAGE (Message reading mode) PREVIOUS MESSAGE (Message reading mode) NEXT TOPIC (Message reading mode) PREVIOUS TOPIC (Message reading mode) NEXT LETTER (Letter reading mode) PREVIOUS LETTER (Letter reading mode) SEND REPLY TO EVERYONE (Message reading mode) or MESSAGE TO EVERYONE (Message reading mode) SEND REPLY TO AUTHOR (Message and letter reading modes) or LETTER TO AUTHOR (Letter reading mode) CREATE TOPIC (Message reading mode) CREATE LETTER (Letter reading mode) DELETE LETTER (Letter reading mode) HELP (Message and letter reading modes) EXIT (Message and letter reading modes) There are three methods provided to enter these commands, depending on which mode (novice or expert) is in effect: 1) by entering the commands directly (novices only), 2) by entering single letters which represent words in the command (novices and experts), and 3) by pressing a "hot key" which represents the entire command (experts only). The first method is provided for those people who just can't exist without the classic command line interface. To use this direct entry, one must be in novice mode *and* type the commands in lowercase letters. The commands must be typed out in full, although several abbreviations are permitted, as follows: The Grand Central Reference Manual, Version 1.01 Page 36 ____________________________________________________________________________ Command Accepted Abbreviation(s) ----------------- ------------------------ next nxt previous prev topic top, tpc message msg letter ltr unread unrd index ind send reply send, snd, reply to author author, auth to everyone everyone, all create make For example, one could type "next letter", "nxt letter", "next ltr", or "nxt ltr" to go to the next letter in the letter reading mode. This method is available to novice-level users only. The second method of command entry is a unique hybrid of the command line interface and the hot key interface. To use this method, one types single uppercase letters, each of which represents a word or phrase of a GC command. For example, the letter "N" has been designated to represent the word "NEXT", while the letter "M" represents "MESSAGE." If, while in the message reading mode, one presses uppercase <N> followed by uppercase <M> and <ENTER>, GC will execute the "NEXT MESSAGE" command. Moreover, the actual words "NEXT MESSAGE" will appear on the screen, instead of the letters "NM" used to form the command. Here is a complete list of the keys that are valid for forming commands using this method: <N>=NEXT <T>=TOPIC <S>=SEND REPLY <I>=INDEX <P>=PREVIOUS <M>=MESSAGE <E>=TO EVERYONE <H>=HELP <C>=CREATE <U>=UNREAD <A>=TO AUTHOR <X>,<Q>=EXIT The third method of command entry, commonly known as a "hot key" interface, is available to expert-level users only. In the previous two methods, the user must type a command and press <ENTER>. In contrast, this method allows an experienced user to execute a command by pressing one key, which takes effect immediately. There are actually two sets of commands involved here. If the user is calling from an ANSI/VT100-compatible terminal or computer, or if the Sysop is using GC directly on the computer, the first set of commands applies. However, if the user is calling in from a plain ASCII terminal or computer, the second set applies. This distinction is necessary because plain ASCII terminals might not contain arrow keys. Here are the two sets of key-commands: Command ANSI, VT100, VT102, etc. Regular ASCII terminal ------------------- ------------------------ ----------------------- NEXT UNREAD MESSAGE <SPACE> <SPACE> INDEX <keypad 0> (Not available) PREVIOUS TOPIC <left arrow> <f> NEXT TOPIC <right arrow> <h> PREVIOUS MESSAGE <up arrow> <t> NEXT MESSAGE <down arrow> <g> (previous screen) <keypad 5> <TAB> (next screen) <keypad 2> <ENTER> SEND REPLY TO EVERYONE <!> <!> SEND REPLY TO AUTHOR <@> <@> CREATE TOPIC <*> <*> The Grand Central Reference Manual, Version 1.01 Page 37 ____________________________________________________________________________ HELP <?> <?> EXIT <ESC> <ESC> <ESC> <ESC> It is helpful to get a mental image of several concepts in order to easily memorize the keys. First, you may think of the organization of GC's messages like a spreadsheet, as follows: Topics ----1----2----3----4----5----6----7----8----9----10-----> Replies to each topic | 1 1 1 1 1 1 1 1 1 1 | 2 2 2 2 2 2 2 2 2 2 | 3 3 3 3 3 3 3 3 3 3 | . . . . . . . . . . | . . . . . . . . . . The idea here is that topics are ordered horizontally from left to right while the replies to each topic are ordered vertically from top to bottom. This aid will help you remember the arrow keys. Here are several other aids: For the "!" command, remember that you are "exclaiming" your views to other people. For the "@" command, you are sending a message to the author "at" their mailbox. Note that there are several hot keys which are available to all users. These keys are valid ONLY when the command line is blank: <ENTER>=(next screen of information) <TAB> =(previous screen of information) <SPACE>=NEXT UNREAD MESSAGE 7.2 - The Conference Selection Menu ----------------------------------- The principles behind the Conference Selection Menu are very simple. The main principle is that only conferences of which one is a member are displayed in alphabetic order in the menu. Conferences which deserve attention (i.e., where new messages are available) are highlighted for easy reference. In addition, removing an entry from the menu effectively revokes one's membership in that conference. Conferences may be selected by typing their menu number or part of their name. One concept of this menu that may be confusing is that users join conferences through a separate Conference Availability Menu. This second menu, which is very similar to the Selection Menu, lists conferences which one is allowed to join. Joining a conference in this menu both makes one a member of the conference and adds the conference to the Selection Menu. The Availability Menu is accessed by typing "AVBL" at the Selection Menu's prompt. 7.3 - The Unread Message Feature -------------------------------- The principles behind unread messages are pretty much transparent to the user. GC determines which (if any) messages a user has yet to read by comparing the date and time of the last message in the conference versus the date and time of the last message the user read in the conference. If there are new messages in a conference, this fact is noted prominently on the user's Conference Selection Menu. When reading messages in a conference, the user need only press <SPACE> to go to the next unread message. The Grand Central Reference Manual, Version 1.01 Page 38 ____________________________________________________________________________ This feature works very well as long as two simple rules are followed. First and foremost, if one begins going through the sequence of unread messages in a conference, one should read all the unread messages in the conference during that session. This will avoid having old messages later mistakenly displayed as unread ones. Secondly, the only way to mark unread message as having been read is to proceed through the unread messages sequence (i.e., pressing <SPACE> or using the "NEXT UNREAD MESSAGE" command). Merely moving through the conference with "NEXT MESSAGE" and "NEXT TOPIC" commands will not mark messages as having been read. 7.4 - The Conference Index Feature ---------------------------------- GC is now able to generate an index of message titles within a conference, and allows the user to view a message after selecting it from that index. This feature is accessed by using the "INDEX" command, or, in expert mode, by pressing the keypad "0" key. It is available only on ANSI- and VT100-type terminals. This command is unique because it uses a special bidirectional-scroll viewer in order to display the index. Individual items may be highlighted using the up- and down-arrow keys. A special type of cursor is used for this highlighting operation. While scrolling is being performed, the cursor is kept small in order to reduce transmission time. However, after scrolling is stopped for a short time, the cursor expands to highlight the entire line in which it is located. Page scrolling is accomplished either by repeated individual line scrolling, or by the familiar <ENTER> and <TAB> keys. The spacebar is used to select and view the highlighted message. The Grand Central Reference Manual, Version 1.01 Page 39 ____________________________________________________________________________ CHAPTER 8 - MAINTAINING A GC SYSTEM ----------------------------------- There are several important aspects of GC that have not been covered already. These are the tools that assist the Sysop in day-to-day operations of GC. GC is designed to run unattended most of the time. However, like any continuously-operating system, it requires periodic "care and feeding" to stay in running condition. 8.1 - Maintaining Message Bases ------------------------------- Since GC limits the number of topics allowed in each conference, Sysops and moderators may encounter situations where conference message bases fill up. And, if they do not encounter such situations, it will eventually become necessary to weed out the existing topics so as to keep conferences focused and fresh. GC, unlike RBBS, does not allow regular users to delete messages at will. This power is vested in the conference moderators and Sysops through the moderator and Sysop menus' "[D]elete" command. By using this command, entire topics or individual messages may be deleted. Note that the first message in each topic *cannot* be deleted individually; only replies can be deleted in this manner. 8.2 - RBBS User File Changes ---------------------------- GC is designed to automatically handle the inclusion of new users in its user system. However, since GC does not keep track of users' names, it must depend on RBBS for this information. When the Sysop makes a change that alters the position of users within the RBBS user file, GC must be notified so it can appropriately update its user records. There are three situations where the Sysop must "realign" the GC user system: 1) When RBBS user packing (also referred to as user file repair) is performed 2) When the maximum size of the RBBS user file is changed 3) When individual users are deleted (Sysop must perform RBBS user packing after the users have been deleted) This file realignment is very simple, automatic, and requires minimal interaction from the Sysop. First of all, when user packing or user file size changing is performed, the Sysop *must* be sure to request RBBS to make a backup user file, USERS.OLD. If this step is overlooked, a recent backup of the USERS file (renamed to USERS.OLD) is sufficient. However, if neither a backup nor USERS.OLD is available, GC's user system must be reset, destroying all security data and user preferences. After the RBBS manipulations have been performed, the Sysop need only invoke G-CONFIG and choose the "[U]ser file realignment" option from the Main Menu. Note that if one will be performing both user packing and user file size changing at one time, it is necessary to run G-CONFIG after performing each individual operation, to give GC a chance to adjust to each change. 8.3 - How RBBS Sysop Comments Work ---------------------------------- Prior to installing GC, your RBBS may have been set up to record RBBS comments as private messages. Since, in most GC installations, the RBBS message system will be shut down, it was recommended in Chapter 6 that the RBBS "[C]omment to Sysop" command be configured to send the user comments to a COMMENTS file instead of the RBBS message system. In order to The Grand Central Reference Manual, Version 1.01 Page 40 ____________________________________________________________________________ read the comments users leave, you must use RBBS' "1" command. There is no outward indication comments have arrived; you must remember to check them periodically. Also, the comments accumulate, so you must also erase the entire file occasionally by using RBBS' "4" command. 8.4 - GC'S Chat Feature ----------------------- In order to provide maximum flexibility for Sysops, GC has been equipped with a chat feature very similar to that contained in RBBS. It is invoked in the same way as well - by pressing the <F10> key on the local keyboard. This feature will only work while the user is in a conference menu or the Conference Selection Menu. The chat mode is terminated by pressing the <ESC> key on the local keyboard, whereupon the remote user's screen and operating condition are restored exactly to their respective states prior to the chat. There are several differences between the RBBS and GC chat features, though. For one, GC allows the Sysop to make a customized screen that will be displayed to both parties when the chat begins. Also, GC prints the Sysop's side of the conversation in emphasized print, in order to help one distinguish the two sides of the conversation. Finally, the remote user's session limit is suspended during the conversation. If the user's session limit is exceeded, he or she will be given five extra minutes upon conclusion of the chat, although RBBS will immediately hang up if the user tries to return there. 8.5 - The "LOG" File and GC Error Handling ------------------------------------------ GC maintains a very important file in its directory called LOG. This file is a running record of unusual occurrences that GC has encountered. Most of these occurrences are system errors, although premature remote user hangups (known as carrier drops) are also recorded. GC does *not* record the name of each GC user nor does it record specific information about what actions users perform during their time in GC. Here are two typical LOG file entries: JUN-05-1989 4:09:39 pm .GCS screen not found @ VSM 3810 -- SCOTT BARNES -- Screen name= CHATMODE JUN-09-1989 8:40:52 pm Remote user dropped carrier @ VSM 600 -- ORDINARY USER -- The first entry above (first two lines) was recorded when GC was unable to find a screen it was expecting in the .GCS file. "@ VSM 3810" refers to the location in the program where the error occurred. "SCOTT BARNES" is the name of the user who was logged on at the time. And the final piece of information indicates that CHATMODE was the specific screen that could not be found. The last two lines above comprise the second entry, which was a case where ORDINARY USER hung up (or was disconnected) prematurely. This discussion about the LOG file merits a few words about GC error handling. In order to preserve the integrity and continued operation of the BBSes under which it is run, GC views almost all errors as fatal. Users are gracefully escorted back to RBBS in case of such errors. This philosophy depends upon the assumption that there will be very few fatal errors, which is obviously my goal. If you do experience or discover errors which appear to be the fault of GC, please contact me with the relevant entries from your LOG file along with any additional information you can provide. The Grand Central Reference Manual, Version 1.01 Page 41 ____________________________________________________________________________ 8.6 - GC.EXE Command Line Options --------------------------------- There are two different ways you can start the GC program, as well as an optional parameter (sometimes called a "switch") that you can use in special situations. Method 1 is used when invoking GC under RBBS: GC nodeid [/GCPATH=drive:path] In this case, "nodeid" is the node GC is being run on (single digit or letter), as defined by RBBS. Since GC is currently a single-user program, this number will be 1 in almost all cases. The optional /GCPATH parameter is used to tell GC where to find its files, if you are not invoking GC from its own directory. GC determines the name and security level of the user from information contained in the DORINFOx.DEF file, located in the RBBS directory. Method 2 is used when invoking GC from DOS on the host PC: GC [/GCPATH=drive:path] /USER=username This type of command is used when you are starting GC independently of RBBS on the host machine, and want to log into someone's GC account. Do not use this feature when dialing in remotely, since you will hang the host PC. This feature is primarily intended for those who run versions of RBBS prior to 17.1A, since at least some of those versions do not allow local users to access doors. Note that, no matter what the security level of the user being accessed, regular Sysop privileges are available when using this feature. There is potential for abuse here, since Sysops can scan through their users' private mail at will. In either case, do not run GC under an RBBS shell since there will not be sufficient memory to do so. 8.7 - G-CONFIG Remote Use ------------------------- Unlike RBBS, GC allows Sysops to fully configure and maintain the program regardless of whether the Sysop is sitting at the local computer or calling in from somewhere else. This capability is available since the G-CONFIG program can be run remotely from any ANSI- or VT100-compatible computer or terminal. Using this feature is very simple. Remote Sysops need only go to DOS using the RBBS "7" command, then change to the GC directory and type a "G-CONFIG COMx" command, where "x" represents the number of the communication port being used (1 through 8). G-CONFIG automatically infers the baud rate and other parameters from the serial port, and then starts up. After the configuration session is complete, it is very important that the Sysop return to the RBBS directory. Then, the Sysop can either perform other DOS operations, or exit to RBBS using the "EXIT" command. After using G-CONFIG, you may wonder why the program is so fussy about asking for a <CONTROL-P> keystroke from the user within twenty seconds. This feature is intended to prevent a remote Sysop from accidentally losing control of the system in case he or she didn't remember to tell G-CONFIG to use the communication port. With the <CONTROL-P> feature in place, the worst that can happen in this case is a twenty-second delay before the DOS prompt reappears. The Grand Central Reference Manual, Version 1.01 Page 42 ____________________________________________________________________________ 8.8 - Sysop Security Privileges ------------------------------- In addition to the local logon feature mentioned in Section 8.6, GC offers Sysops several other tools to maintain GC's security system. The most important of these is the "[S]ecurity system" feature in the Sysop Menu. This feature allows the Sysop to observe and modify the access levels of all users in a specific conference. Sysops are also given the sole power to designate conference moderators. The other major security feature is the "[A]ssert Sysop Security Privileges" command in the Sysop Menu. This command effectively gives Sysops unrestricted access to all conferences, regardless of whether those conferences are public or private. This privilege remains in effect until the Sysop exits GC. When active, it prevents Sysops from accessing their own personal Conference Selection Menus, since the Conference Selection Menu will contain all of the GC conferences. All Sysops are automatically moderators of the Main Message Base. This is a fundamental assumption of GC, so there is no way to either delete moderators or add new ones there. 8.9 - Moderator Security Privileges ----------------------------------- Moderators are given tools to allow them to determine who is allowed access to their conference. The "[S]ecurity System" feature described in Section 8.8 is made available to conference moderators, but in this case the moderators' power extends only to their respective conference(s), and does not allow them to designate or change moderators. From within the Security System, the moderator can change the conference access privileges of any GC user to one of four states: Nonmember, Spectator, Member, or Persona Non Grata. The "Spectator" state simply means a user can only read existing messages, but not create new ones. The "Persona Non Grata" state prohibits a user from accessing the conference in any manner. Moderators are given additional powers when they moderate an "Application Required"-type conference (see Section 3.1 for conference types). In this type of conference, users must apply to the moderator before joining. Thus, the moderator must act upon each application favorably or unfavorably. Here is the application process as it appears to the moderator: The moderator is alerted to the presence of new applicants by a "*NEW APPLICANTS*" message on the conference menu screen. Then, the moderator would access the "[S]pecial Moderator Functions" and choose the "[A]pplicant handling" item. At that point, GC will display the name of each applicant for the moderator's consideration. The moderator acts upon the application in one of four ways by pressing a key, as follows: [M]ember acceptance [S]pectator acceptance [R]ejection [D]efer decision When an applicant is deferred, that person will remain a new applicant until the moderator explicitly accepts or denies the application. The Grand Central Reference Manual, Version 1.01 Page 43 ____________________________________________________________________________ 8.10 - The OPTIMIZE Program --------------------------- Since the GC system stores messages and letters in a database, it is desirable to occasionally perform a cleanup in order to attain maximum speed and minimum storage space. The OPTIMIZE program is provided to meet that need. OPTIMIZE can be run manually from the DOS prompt whenever the urge strikes, but RBBS provides an automatic way to accomplish this task. The RBBS facility used to run OPTIMIZE is known as a daily "drop-to- DOS" batch file. It is simply a standard DOS batch file which is always run at a certain time every day by RBBS. If a caller happens to be online at that time, RBBS runs the batch file immediately after the caller hangs up. If you run the popular TradeWars game, you probably have a daily batch file set up already to perform game maintenance. If you do, just add two additional statements to your existing daily batch file: 1) a command to change to the GC directory, and 2) the command "OPTIMIZE". If you don't already have a daily batch file, creating one is not difficult. You have already done 90 percent of the work in Chapter 6. Here are the remaining steps: 1) Run RBBS' CONFIG program. Near the end of the parameter list, there is an item named "Time of day to drop to DOS". Change this parameter to the time of day when you want the daily batch file to be run. Most Sysops prefer a time in the wee hours of the morning, when the process will not inconvenience callers. To finish, exit the CONFIG program. 2) Go to your favorite file editor and create a file in the RBBS directory named "RBBSxTM.BAT", where "x" is the number or letter of the RBBS node you are working on. The file should look like this: CD \GC OPTIMIZE CD \RBBS RBBS This file assumes that "\GC" is the Grand Central directory and that "\RBBS" is the RBBS directory. Finish by saving the file. The setup process is complete. OPTIMIZE has several command-line options that allow you to modify the time at which optimization is actually performed. Normally, OPTIMIZE performs optimization once per week, and does nothing on other days. Here are the options: /NOW causes optimization to be performed immediately, regardless of the optimization schedule /EVERY=nn changes the default optimization interval to "nn" days -- to take effect, this switch must be used every time OPTIMIZE is invoked Finally, here is a note about OPTIMIZE's effect on the GC directory: every time OPTIMIZE performs optimization, it first backs up every GC message and letter data file by creating a backup file with the extension ".OLD". This is simply a fail-safe mechanism in case of optimization The Grand Central Reference Manual, Version 1.01 Page 44 ____________________________________________________________________________ problems. If you regularly perform backups, you may safely delete the .OLD files. 8.11 - The MAILCHEK Program --------------------------- The MAILCHEK program was created as a replacement for the familiar RBBS logon mail check. Due to RBBS limitations, it cannot be run for each user at logon time. However, it can be set up as a "fast door" to be accessed from the RBBS main menu (RBBS versions 17.2A or later), or it can be run as part of another door (before the user plays a game, for instance). The "fast door" is probably the best method for utilizing MAILCHEK, but unfortunately it can be used only for RBBS versions 17.2A and later. Earlier versions of RBBS either start doors by shelling (i.e., running the door under RBBS, which is relatively fast) or by exiting to DOS. In those versions, it is not possible to have one door invoked by shelling and another by exiting. However, the door control file feature in 17.2A makes this possible. Assuming you have set up RBBS according to Section 6.3, here is the procedure for installing MAILCHEK as a fast door: 1) Add the following line to RBBS' DOORS.DEF file: MAILCHEK,,,S,"MAILCHEK.BAT [NODE]",N,, 2) Create a MAILCHEK.BAT file in RBBS' directory with the following text: ECHO OFF CD \GC MAILCHEK %1 CD \RBBS Once again, this assumes "\GC" is the Grand Central directory and "\RBBS" is the RBBS directory. 3) Modify RBBS' MENU2 file to include the presence of the MAILCHEK feature: PINNACLE M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ******************************* > [M]essage/Mail System < > [R]apid Mail Check < ******************************* [F]ile System [C]omment to Sysop [X]pert on/off [B]ulletins [O]perator page [G]oodbye [U]tilities [H]elp If you are adventurous, you can make the command several characters long, such as "FMC" for Fast Mail Check. For the case of "R", however, the existing RBBS command "R" must be disabled, as explained in the next step. 4) Go into RBBS' CONFIG program and select the parameter named "Symbols to use for MAIN menu commands". Select the "R)ead Messages" option, and change its command letter to a seldom-used character such The Grand Central Reference Manual, Version 1.01 Page 45 ____________________________________________________________________________ as "#". Since this RBBS command was disabled back in Chapter 6, changing the letter which activates it has no visible effect on RBBS. 5) Add a capitalized reference to MAILCHEK in RBBS' MENU5 file (the door menu), in the same way you added the word "GC" or "MESSAGE" to the file back in Chapter 6. 6) Finally, create a file in the RBBS directory named R.MCR. This is the "macro" which will be executed when the user selects the "R" command. The file should appear as follows: 3 {EN D MAILCHEK This assumes your RBBS has a new user security level of 3. The MAILCHEK program can also be executed after a user has opened another RBBS door. To use MAILCHEK in this manner, simply insert two lines into the other door's batch file: CD \GC MAILCHEK node where "node" is the RBBS node number/letter MAILCHEK has several useful command-line options, as follows: /NOWAIT MAILCHEK normally waits for the user to press the <ENTER> key before it finishes. This option will remove the wait under most circumstances (see /DETOUR option, below). /NOMSGS MAILCHEK normally checks for new messages in the conferences of which the user is a member. This option disables all conference message checking. /DETOUR This is a powerful feature which allows the user to immediately detour (through a DOS shell) to the main Grand Central program to read new mail or conference messages. This option overrides /NOWAIT when there are new letters or messages. You may use this option only when MAILCHEK is being executed outside RBBS. The /DETOUR feature is valuable for attracting user attention to GC, and merits several explanatory statements. This feature should be activated only when MAILCHEK has enough available memory to run the main GC program (approx. 280-300K). Thus, /DETOUR should not be used in a "fast door" situation. Also, keep in mind that MAILCHEK rewrites RBBS' DORINFOx.DEF file, taking into account the amount of time the user has spent detouring to GC. For example, if a user is allowed 35 minutes in a TradeWars door, but first detours to GC and spends 10 minutes there, then the TradeWars program will see a time limit of 25 minutes. Finally, note that the user is not allowed to detour in all situations - only when new mail or conference messages are encountered. The Grand Central Reference Manual, Version 1.01 Page 46 ____________________________________________________________________________ MAILCHEK in the fast-door configuration has crashed my BBS on several occasions. This turned out to be a inexplicable conflict between my "Watchdog" carrier monitor and MAILCHECK. I reached this conclusion since the problem occurred only after the watchdog had been installed in memory (note that MAILCHEK does NOT require a watchdog!). If you experience such problems, a first solution would be to try your FOSSIL driver's carrier monitor feature (both X00 and BNU have such features). A final remedy is removing the fast MAILCHEK door. Please let me know if you experience such problems, and perhaps I can do some more investigating work. The Grand Central Reference Manual, Version 1.01 Page 47 ____________________________________________________________________________ CHAPTER 9 - SUPPORT AND FEEDBACK INFORMATION -------------------------------------------- It is important to remember that full support is provided ONLY to registered users. As for unregistered users: I will help them get started and answer questions about vague points in the documentation, but no more. I am not offering, and cannot offer, direct call-in telephone support. I am a full-time college student, so I am not generally available during business hours. Also, my college telephone is not suitable for business transactions. Therefore, I maintain a GC support telephone line and answering machine in BarneSoft's Pennsylvania office, which I check quite frequently. The number is (215) 593-2392. Phone support for registered users works like this: after I receive your message, I will return your call, most likely the next day. BarneSoft will pick up the phone tab for most calls, but if a problem requires extensive phone contact (i.e., calls of more than 15 minutes), I must ask you to accept collect calls in order to avoid stratospheric phone bills on my end. Please include both daytime and evening phone numbers in your message. In addition to phone support, I am making a special effort to make myself available via E-mail channels. E-mail addresses don't change that often, they eliminate telephone/answering machine tag, and they give me the flexibility to reply to queries in detail after fully investigating problems. My GEnie and CompuServe addresses are available year 'round: GEnie : S.BARNES2 CompuServe: 72510,1553 Also, thanks to the good folks at the University of Rochester Computer Center, I am available through several academic/military/business networks from September through May: Internet : SBA8_LTD@UHURA.CC.ROCHESTER.EDU BITnet : SBA8_LTD@UORDBV UUCP : ...!rochester!uhura!sba8_ltd Please include voice phone numbers with your inquiry. In addition to providing support services to GC users, I am also interested in hearing constructive criticism of GC. You can use any of the above channels as a suggestion box. Remember, all feedback goes directly to the programmer! I have established several national GC distribution sites, which will always be provided with the latest major and minor releases of GC. The sites are as follows: GEnie BBS Forum CompuServe IBMBBS Forum Ken Goosens' Your Place RBBS (703) 978-6360 [3 lines] (other sites will be added in Fall '90) The Grand Central Reference Manual, Version 1.01 Page 48 ____________________________________________________________________________ CHAPTER 10 - FOR THE FUTURE... ------------------------------ NEWS FLASH: A national GC support board is a distinct possibility in the near future! I am presently rigging the support telephone number to allow BOTH incoming voice and incoming modem calls. When this is complete, I am seriously considering placing my old faithful PS/2-30 to work on running a support BBS. Stay tuned! The message on the support line answering machine will have complete instructions on how to access the BBS when and if it goes up. The next release of GC - barring any major problems with this version - will be 1.10. The main feature I am presently working on is a significant upgrade of the unread message system. Of course, there are other things in the works, but they are too uncertain to mention here. And, besides my improvement ideas, YOU can have a voice in how GC evolves. I am very interested in how GC can be improved to meet your needs and make your life easier. Please be generous with your comments on the back of the Appendix E registration form, and feel free to contact me about these issues. GC has a bright and promising future, and your contributions can make it even better! The Grand Central Reference Manual, Version 1.01 Page 49 ____________________________________________________________________________ ****** * * *** * * VERSION 1.01 ***** ****** * APPENDICES * * ****** ---------------------------------------------------------------------------- APPENDIX A - UPGRADING FROM PREVIOUS GC VERSIONS ------------------------------------------------ This section contains upgrade instructions for users of GC 0.95 and 0.90. Users of 0.95 need only perform steps 1, 2, and 6; users of 0.90 must perform all the steps. The steps are as follows: 1) Be sure to keep a backup copy of your old GC files for posterity. 2) Copy all GC 1.01 files with extensions .EXE, .DAT, and .TXT into your main GC directory. You will also need to copy the SAMPLEx and SAMPLEx.GCS files, which contain sample screens. DO NOT copy the WELCOME, HELP, or STARTUP files, since you would overwrite your present screen files. 3) (GC 0.90 ONLY) Bring the WELCOME and SAMPLE2 files into your favorite file editor. Look in SAMPLE2 for the screen that begins with: +++++ SYSOP MENU FOR ACCEPTING/DENYING APPLICANTS +++++ Copy this screen from SAMPLE2 and paste it after the last screen in WELCOME. Add the following line as your *last* screen declaration in WELCOME (see Section 5.2 if you don't understand what a screen declaration is): !APPLICMENU,5 To make the screen update complete, type the following DOS command: CONVSCRN WELCOME 4) (GC 0.90 ONLY) The eight new user tutorial screens in the HELP file have been rewritten. If you did not do extensive modifications on the GC 0.90 HELP file, simply extract the HELP and HELP.GCS files from the GC101-3 compressed file and copy them over the old HELP and HELP.GCS files in your GC directory. 5) (GC 0.90 ONLY) If you do not already use a FOSSIL communication driver with RBBS, follow the instructions in Section 6.1 to install one. 6) Run the G-CONFIG program and go to the main menu. If you do not intend to use XON/XOFF communication flow control, go to the "[G]rand Central system configuration" and change item 11. If you intend to use the distributed (multiple recipient) mail feature, go to the "[P]ost Office Configuration" and modify items 7 through 9. That's it! Your upgrade process is complete. The Grand Central Reference Manual, Version 1.01 Page 50 ____________________________________________________________________________ APPENDIX B - LIST OF .GCS SCREENS WHICH HAVE SPECIAL RESTRICTIONS ----------------------------------------------------------------- What follows is a list of all the .GCS screens in which GC places special information at specific locations on the user's screen. This affects what one can place in the .GCS screen, because .GCS screen data that is placed in these special locations will be overwritten, very likely creating a confusing jumble on the user's display. For example, several screens display the user's security level to inform them why they can't perform a certain operation. Such a display obviously requires an explanatory message such as "Your security level is:". Since the security number is written *over* the .GCS screen, it is important that the explanatory message be properly placed and of the proper length. The purpose of this list is to warn you about which areas of which screens should be left as they currently stand. A few explanatory comments about the list are in order here. Almost without exception, the end of the first line on the user's screen is occupied by the session limit notice (i.e., "(101 min)"). Also, it is important to understand the difference between a "screen" and a "user screen," as used in this list. "Screen" is used here to mean the entity that exists within the .GCS file, which is Sysop-modifiable. "User screen" refers to the actual screen that the user sees, which may be a combination of a .GCS screen and other information. The "other information" is added by the GC program, and cannot be modified by the Sysop. STARTUP - This screen is only part of the screen actually displayed to the user. The portion of the screen you define will appear between lines 8 and 18 of the user screen, starting just below the copyright notice until just above the "new mail" announcements. Another restriction is that the first three lines of this screen are displayed starting at column 18; the first 17 columns are reserved for a portion of the GC logo. Max len=11. MENU0 - If the user is a Sysop, the message "[S]ysop functions" will be shown centered on line 21 of the user screen (the sixth line of this screen). Thus, it is recommended that only the first five lines of this screen be used for the menu. Max len=8. MENUXX - If the user is a conference moderator, the message "[S]pecial moderator functions" will be shown centered on line 21 of the user screen (the sixth line of this screen). Thus, it is recommended that only the first five lines of this screen be used for the menu. Max len=8. MENUPOST - If the user is a Sysop, the message "[S]ysop mailbox toggle" will be shown centered on line 21 of the user screen (the sixth line of this screen). Thus, it is recommended that only the first five lines of this screen be used for the menu. Max len=8. CONFSELECT- If the user has new messages in the Main Message Base, the message "*NEW MESSAGES*" will appear on this screen at line 1 at column 54. If the user has new mail, the message "*NEW MAIL*" will appear on line 2 at column 54. Max len=4. The Grand Central Reference Manual, Version 1.01 Page 51 ____________________________________________________________________________ NEWUSER0 - This screen has one restriction in common with the STARTUP screen: the first three lines of the screen are displayed from the 18th column on; the first 17 columns are reserved for part of the GC logo. Also, the user's first name is displayed on line 5 of this screen starting at column 14. Max len=17. TERMSELECT- The last line is reserved for user input. Max len=24. CONFAPPLY- The conference name is shown centered on the second line. The names of the conference moderators are shown on lines 4, 5, and 6. The last line is reserved for prompts and user input. Max len=24. CONFAPPLIED- Same restrictions as CONFAPPLY CONFBADNEWSEC- Same basic restrictions as CONFAPPLY. Security level numbers are printed at line 8, column 40 and line 9, column 22. CONFAPPUPDATE- Same restrictions as CONFAPPLY CONFDENY - Same restrictions as CONFAPPLY CONFACCEPT- Same restrictions as CONFAPPLY CONFBADNEWSEC- Same basic restrictions as CONFAPPLY. Security level numbers are printed at line 8, column 44 and line 9, column 22. SYSOPMENU- Last line is reserved for user input. Max len=24. MODERATMENU- Last line is reserved for user input. Max len=24. AUTOSPECTATOR- Same restrictions as CONFAPPLY. MAILCLEANOUT- Line 8 is reserved for a message describing the mailbox cleanout restriction. Max len=24. The Grand Central Reference Manual, Version 1.01 Page 52 ____________________________________________________________________________ APPENDIX C - LIMITATIONS OF GC ------------------------------ Maximum number of users -------------------------- 32,767 Maximum number of conferences -------------------- 254 Maximum number of topics per conference ---------- 999 Maximum number of replies per topic -------------- 999 Maximum number of lines per message -------------- 999 Range of valid security levels ------------------- -32,768 to 32,767 Range of valid sleep timeouts -------------------- 31 to 86,399 seconds Maximum length of conference names --------------- 40 characters Maximum number of letters in a mailbox ----------- 254 Maximum number of recipients for any one letter--- 30 Range of valid mail trace limits ----------------- 1 to 30 days The Grand Central Reference Manual, Version 1.01 Page 53 ____________________________________________________________________________ APPENDIX D - ABOUT THE AUTHOR ----------------------------- Scott Barnes is currently pursuing a B.S. in Electrical Engineering at the University of Rochester in Rochester, New York. An avid programmer, Scott has been involved with personal computers since the introduction of the Commodore PET in 1977. In the past several years, his interests have turned to applications in communications over both wires and radio waves. Grand Central, first conceived in mid-1988, was written from the ground up in QuickBasic 4. The program was developed and tested on an IBM PS/2 Model 30 hitched up to Rochester's Rolm Digital PBX as well as to other PC's. For those of you who are not familiar with the name Grand Central, it is derived from the famous Grand Central Terminal, a train station located in New York City. Built in the early years of this century by the New York Central Railroad, the terminal was and remains a marvel of service and efficiency. The author wishes to offer his gratitude to John Ferri and Larry Bilker for their valuable assistance during the earlier phases of this project. The Grand Central Reference Manual, Version 1.01 Page 54 ____________________________________________________________________________ APPENDIX E - REGISTRATION FORM ------------------------------ GC registration costs only $35 and provides you with these benefits: o A 5-1/4" or 3-1/2" disk mailed to you with GC 1.1, when it is released o Support services via telephone or E-mail o Mail notification of the next major release of GC o Opportunity to get technical bulletins, revision notifications, etc. via E-mail o Your BBS can be included on a widely-distributed list of BBSes that run GC To register GC 1.01, please remit $35 (U.S. funds) and this form to: Scott Barnes Box 275003 Rochester, NY 14627-5003 Name: _________________________________________________________________ Mailing: _________________________________________________________________ address: _________________________________________________________________ _________________________________________________________________ Voice phone number (optional): (______) _____ - _______________ Send GC 1.1 on: o 5-1/4" 360K disks } CHECK ONE ONLY! o 3-1/2" 720K disks } Where did you obtain GC? __________________________________________________ (Please include phone number if it is a public BBS) E-mail addresses (optional): CompuServe / GEnie: _____________________________________________________ Internet/BITnet/UUCP: ___________________________________________________ Place me on the E-mail distribution list: o Yes o No Please rate the following potential GC improvements in terms of THEIR IMPORTANCE TO YOU (1=Not important, 5=Very important): ____ Multitasking support (i.e., DesqView, Windows/386) ____ BBS network support (i.e., Fidonet) ____ LAN support ____ Improved editor ____ ANSI / Color support for user-defined screens ____ Improved unread messages system ____ Full-service BBS system (i.e., logon support, file system, etc.) ____ Support for other BBS programs YOUR COMMENTS ARE WELCOME!! (Please use the reverse side of this form) BBS INFORMATION MAY BE PROVIDED ON THE NEXT PAGE ---- V The Grand Central Reference Manual, Version 1.01 Page 55 ____________________________________________________________________________ BBS information (optional): BBS Name: _______________________________________________________________ Sysop: _______________________________________________________________ City/State: _______________________________________________________________ Baud rates supported: _____________________________________________________ Specialties: ______________________________________________________________ Access information: _______________________________________________________ _______________________________________________________ Place this BBS on the GC BBS List: o Yes o No