HomeWare 14

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

/ HomeWare 14 / HOMEWARE14.bin / comms / gt1800_5.arj / GT18HOST.DOC < prev next >

Wrap

Text File | 1993-07-22 | 230KB | 4,721 lines

GT POWER - 18.00 Copyright (c) 1985, 1993: by P&M Software Co. All rights are reserved. Host Mode Documentation July 22, 1993 P & M Software Company 3104 E. Camelback Rd. #503 Phoenix, AZ 85016 U. S. A. Voice Phone: (602) 897-9557 Modem Phone: (602) 897-9549 - 1 - Table of Contents ---------------------------------------------------------------- A Brief Summary . . . . . . . . . . . . . . . . . . . . . . . 4 The Installation Of Host Mode . . . . . . . . . . . . . . . . 4 The Modem Init String . . . . . . . . . . . . . . . . . . 4 The Host Mode: Modem Init String . . . . . . . . . . . . 4 The Modem Answer String . . . . . . . . . . . . . . . . . 5 The Modem Result Codes . . . . . . . . . . . . . . . . . 5 Logging Status During Host Mode . . . . . . . . . . . . . 6 Hang-up During Host Mode . . . . . . . . . . . . . . . . 6 The BBS/CBS Path . . . . . . . . . . . . . . . . . . . . 6 The Default Message Base Path . . . . . . . . . . . . . . 7 The Default File Section . . . . . . . . . . . . . . . . 7 File Reception Directory . . . . . . . . . . . . . . . . 8 The Sysop Message Base . . . . . . . . . . . . . . . . . 8 Security Considerations . . . . . . . . . . . . . . . . . . . 8 DSZ.EXE, PCKERMIT.EXE and Other Externals . . . . . . . . 10 Host Mode Text Files . . . . . . . . . . . . . . . . . . . . 13 Forcing a "More?" Prompt . . . . . . . . . . . . . . . . 13 Disable the "More?" Prompt . . . . . . . . . . . . . . . 13 Nest the Display of Bulletins . . . . . . . . . . . . . . 13 Disable the ^K/^C Break . . . . . . . . . . . . . . . . . 13 ANSI Graphics (.BBS vs .CBS) . . . . . . . . . . . . . . 13 The Variable Substitution Line . . . . . . . . . . . . . 13 File Descriptions . . . . . . . . . . . . . . . . . . . . . . 15 GTSYSID.BBS . . . . . . . . . . . . . . . . . . . . . . . 15 GTWELCOM.BBS . . . . . . . . . . . . . . . . . . . . . . 15 GTPASSWD.BBS . . . . . . . . . . . . . . . . . . . . . . 15 Field Descriptions . . . . . . . . . . . . . . . . . 15 Time Bank Setup . . . . . . . . . . . . . . . . . 17 Carbon Copy Messages . . . . . . . . . . . . . . 18 Callback Setup . . . . . . . . . . . . . . . . . 20 GTPASSWD Comment Entries . . . . . . . . . . . . . . 21 Alternate Default Areas . . . . . . . . . . . . . . . 21 GTBULLET.BBS . . . . . . . . . . . . . . . . . . . . . . 21 BULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . . 21 GTMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 22 GTHELP.BBS . . . . . . . . . . . . . . . . . . . . . . . 22 GTBYE.BBS . . . . . . . . . . . . . . . . . . . . . . . . 22 GTBYEx.BBS . . . . . . . . . . . . . . . . . . . . . . . 22 GTUSER.BBS . . . . . . . . . . . . . . . . . . . . . . . 22 GTDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . . 23 Group Header Lines . . . . . . . . . . . . . . . . . 23 Comment Lines . . . . . . . . . . . . . . . . . . . . 23 Directory Lines . . . . . . . . . . . . . . . . . . . 23 CDROM Support . . . . . . . . . . . . . . . . . . 23 Freebie Areas . . . . . . . . . . . . . . . . . . . . 24 GTUDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 25 GTLDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 25 Multi-Language Support . . . . . . . . . . . . . . . 25 GTANSI.BBS . . . . . . . . . . . . . . . . . . . . . 26 GTDDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 26 Door Screens . . . . . . . . . . . . . . . . . . . . 27 GTBMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 27 Personal Bulletins . . . . . . . . . . . . . . . . . 28 GTMDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 29 QWK Message Areas . . . . . . . . . . . . . . . . . . 30 Grouping Areas . . . . . . . . . . . . . . . . . . . 31 - 2 - GTDOORS.BBS . . . . . . . . . . . . . . . . . . . . . . . 31 GTDOORnn.BAT and GTDORnnn.BAT . . . . . . . . . . . . 32 ANSWERn.BBS . . . . . . . . . . . . . . . . . . . . . . . 33 QUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . 33 New Caller Questionnaire . . . . . . . . . . . . . . 34 Programmable Questionnaires . . . . . . . . . . . . . 34 PQUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . 38 GTQMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 38 PROTOCOL.BBS . . . . . . . . . . . . . . . . . . . . . . 39 GT_VSCAN.BAT . . . . . . . . . . . . . . . . . . . . . . 39 Virus Scan Setup . . . . . . . . . . . . . . . . . . 39 GT_PIGGY.BAT . . . . . . . . . . . . . . . . . . . . . . 41 WELCOME.BBS . . . . . . . . . . . . . . . . . . . . . . . 41 MBULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . 42 SYSOP.BBS . . . . . . . . . . . . . . . . . . . . . . . . 42 The Caller Id Token . . . . . . . . . . . . . . . . . 44 The Fax Token . . . . . . . . . . . . . . . . . . . . 45 SCHEDULE.BBS . . . . . . . . . . . . . . . . . . . . . . 46 TRASHCAN.BBS . . . . . . . . . . . . . . . . . . . . . . 47 FILES.BBS . . . . . . . . . . . . . . . . . . . . . . . . 48 UPLOADS.BBS . . . . . . . . . . . . . . . . . . . . . . . 48 RECENT.BBS . . . . . . . . . . . . . . . . . . . . . . . 50 Host Mode Control Files and Directories . . . . . . . . . . . 51 Running Host Mode . . . . . . . . . . . . . . . . . . . . . . 53 SYSOP Commands . . . . . . . . . . . . . . . . . . . . . 53 Command Line Usage . . . . . . . . . . . . . . . . . . . 53 The HOST.BAT File . . . . . . . . . . . . . . . . . . . . 56 The HOST.SCR File . . . . . . . . . . . . . . . . . . . . 56 Full Screen Message Edit . . . . . . . . . . . . . . . . 56 Caller Expiration Dates . . . . . . . . . . . . . . . . . 57 XWARNING.BBS . . . . . . . . . . . . . . . . . . . . 57 EXPIRED.BBS . . . . . . . . . . . . . . . . . . . . . 57 Using a LAN with GT . . . . . . . . . . . . . . . . . . . 57 The CB Simulator . . . . . . . . . . . . . . . . . . 59 The Host Mode LOG . . . . . . . . . . . . . . . . . . . . . . 62 File Tagging . . . . . . . . . . . . . . . . . . . . . . . . 63 TAGWARN.BBS . . . . . . . . . . . . . . . . . . . . . . . 63 Binary Message Upload . . . . . . . . . . . . . . . . . . . . 64 QWK Mail . . . . . . . . . . . . . . . . . . . . . . . . . . 65 The Shell to DOS . . . . . . . . . . . . . . . . . . . . . . 73 COMMAND.COM . . . . . . . . . . . . . . . . . . . . . . . 73 DOS 2.xx . . . . . . . . . . . . . . . . . . . . . . . . 73 Using the Shell to DOS . . . . . . . . . . . . . . . . . . . 74 The Usage of Color . . . . . . . . . . . . . . . . . . . . . 75 The Logon Doors . . . . . . . . . . . . . . . . . . . . . . . 75 GTLOGON.BAT . . . . . . . . . . . . . . . . . . . . . . . 75 GTNLOGON.BAT . . . . . . . . . . . . . . . . . . . . . . 76 BPLOGON.BAT . . . . . . . . . . . . . . . . . . . . . . . 76 The Logoff Doors . . . . . . . . . . . . . . . . . . . . . . 76 GTLOGOFF.BAT . . . . . . . . . . . . . . . . . . . . . . 76 GTNLOGOF.BAT . . . . . . . . . . . . . . . . . . . . . . 76 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Extended ASCII Codes . . . . . . . . . . . . . . . . . . 77 Sample ANSI Sequences . . . . . . . . . . . . . . . . . . 77 Power-Loss Protected Operation . . . . . . . . . . . . . 78 Sample Files For Power-Loss Protected Operation . . . . . 79 GT POWER under DESQview . . . . . . . . . . . . . . . . . 80 - 3 - Brief Summary ------------- The host mode provided within GT POWER allows you to run an unattended session with your system. That is, if you expect to receive calls from other computer systems (say from clients or a set of authorized remote users) then you can tell GT POWER that it should automatically answer the telephone for you, verify the caller's credentials, and if found to be valid, to provide that user with a menu of functions that can be performed. All of that, of course, without further intervention on your part. Security is of paramount importance when running in host mode for obvious reasons. Please read the section entitled 'Security Considerations' before attempting to operate this system. Installation of Host Mode ------------------------- The most important thing about host mode is proper installation of the modem control strings and result codes. These strings and codes must not just control the modem, they MUST WORK TOGETHER. For example, if the modem init strings specify "verbose" result codes, then the result code table better have the "verbose" codes in it. There are 11 specific areas that must be installed; all of these options and strings are accessible via the ALT-I command. Let's discuss each of these items in turn: 1. The "Modem Init String". The default value is: AT V1 Q0 E0 X1 S0=0 S2=43| Assuming that one wants to use the default string, there is really only one thing that one SHOULD DO to this string: change the Xn command. The most powerful Xn command available on your modem is the one to choose. With a USRobotics Courier 2400 modem, use either X5 or X6. With a normal Hayes-compatible 1200 baud modem, use X1. X4 would be normal for most Hayes-compatible 2400 baud modems. For other modems consult the modem manual. Despite the advice given above, many situations call for the modem to use a lower Xn setting. For example dial tone detection logic can sometimes be bothersome, ditto for the voice detection logic... the solution is to set the lowest Xn value that supports busy detection (which is very helpful). NOTE: Many so called "Hayes-compatibles" are compatible in name only. We get many calls for support from individuals with non-Hayes modems. Please read your modem manual carefully because it is very hard to support all the different modems. 2. The "Host Mode: Modem Init String". This string is found under item #30 of the configuration screen. The default value is: AT V1 Q0 E0 M0 X1 S0=0 S2=255| - 4 - There are several things one could do to this string. First, one must modify the X1 command to match the value added to the Modem Init String above. Secondly, if one desires the speaker to be heard during host mode, remove the M0 from the string. Thirdly, the S0=0 may be changed to S0=1, THIS IS THE ONLY OTHER VALID VALUE! If S0=1 is used, the modem will answer automatically, otherwise GT POWER will count the rings and command the modem to answer after the 2nd ring (or if the /Rn command line switch is used, after the Nth ring). This is why S0=0 and S0=1 are the only permissible values! In any case, the S0 setting must be lower than the /Rn setting. Refer to the GT1800.DOC file for a complete discussion of the available command line switches. 3. The "Modem Answer String". This string is located with the Host Modem Init String under item #30 of the configuration screen. The default value is: ATA| GT POWER will issue this string to the modem whenever the ring count reaches 2 (or the number indicated by the /Rn switch). This string should not be changed, unless GT POWER should not be allowed to answer the modem. For example, one could erase this string and set S0=5, so that the modem would answer on the 5th ring, but I don't advise anyone do this. 4. The "Result Codes". Because the modem init strings above contain V1, "verbose" result codes should be programmed. They can be found under item #29 of the configuration screen. There are 19 possible results. If the modem does not support all of these, simply leave the extra strings in their default state. The program comes with the default result codes set for use with a USRobotics Courier HST modem. Please consult the manual for the modem in use and modify this table to match. Remember, use the "verbose" (word codes), not the "terse" codes. It IS POSSIBLE to use the "terse" codes, but they are not as compatible with such services as PC Pursuit. If one of the newer high speed modems is in use, such as a v.32/v.42 type, it is most likely that the modem has more CONNECT type result codes than GT POWER has space in its table. To get around this problem, and avoid the necessity of continually expanding the result code table, GT POWER will automatically recognize CONNECT messages that match the standard form. For example: CONNECT 9600/REL This code is not one of the default codes in the table, but GT POWER will recognize it, since it matches the standard form: (1) The word CONNECT, followed by (2) The DCE baud rate, followed by - 5 - (3) The error correction indicator. GT POWER will automatically recognize this and take the proper action. To enable this smart result code handling, the modem must be setup to return "verbose" codes. 5. It is highly recommended that logging be TRUE during host mode. Otherwise, all records of the host mode activities will be discarded. It is possible to set the logging to DETAILed, in which case many items that are not normally logged, will be logged. 6. How to allow GT POWER to hang-up during host mode. Since the "escape code" must be disabled during host mode, otherwise some caller may crash your system, the normal hang-up string, "~+++~ATH", will not work! Therefore, GT POWER cannot hang-up the modem, unless you set the modem to normal DTR operation. During host mode, GT POWER will drop the DTR signal whenever it wants the modem to hang-up. Most modems come from the factory set so that they ignore the DTR signal - you must reset a switch or, in the case of the Hayes 2400 modem, you must make an entry in the Modem init string to do this. In any case, if the modem ignores DTR, it will not hang up during host mode operations. Some modems which must be setup via the init strings to handle DTR properly use either &D2 or &D3, please consult the manual for the modem in use to determine the correct setting. 7. How does GT POWER determine when a connection is lost? The GT POWER host monitors the carrier detect signal from the modem, when this signal goes low, then GT POWER assumes that the connection has been lost. Most modems come from the manufacturer with the carrier detect signal forced high. "This is like having a telephone with no ringer." Quote by Tom Jennings. Obviously, this must be changed. Some modems have a switch that must be reset to enable a true carrier detect, others require setup via the init string. Many of the modems that require init string setup use '&C1', please consult the manual for the modem in use to determine the correct setting. If it appears that GT POWER drops callers too quickly, item #13 under Alt-I, "Online: lost CD wait", allows the sysop to specify a longer time interval in seconds between the loss of carrier and the disconnect of the caller. Higher values should be used with _care_, but if the modem is flaky or the cabling loose, higher values can be beneficial. If the disconnect are due to line noise, raising the "lost CD wait" will not help, and in fact, will be a nuisance. 8. If this path is set, GT POWER will search that path for BBS/CBS files. GT POWER will also search the GTPATH directory for the files. The GTPATH directory is search first, then the BBS/CBS path. This feature will be of great interest to LAN users, who are advised to become familiar with the DOS "subst" command, which will allow GTMDIR.BBS and GTDIR.BBS to be the same across a - 6 - LAN. Here is a sample of the "subst" command: subst e: c:\ If this command were invoked in the AUTOEXEC.BAT file on your LAN server, then all references to drive E: on the server would be translated to drive C. This would be extremely helpful if the LAN workstations mapped the server's drive C to E also. This would mean that both workstation and server could reference the same physical drive with the same drive letter, i.e. E. It is possible to also use the BBS/CBS path for the door batch files, but it would be wise for LAN operators to make these files Read-Only, otherwise they can cause a SHARE violation, as DOS does not open them in a shared read mode. The following DOS command can be used to make batch files Read-Only: attrib +r *.bat Assuming, of course, that the batch files to be altered are in the current default directory. It is also possible to place the BBS/CBS files outside of either the BBS/CBS directory or the GTPATH directory. This may be accomplished by placing these files with the GT POWER .OVL file. For example, one could place all of these files, including the .OVL into a RAM disk -- providing that the RAM disk was in the DOS PATH and not in the GTPATH directory. In effect the search order for the BBS/CBS files now becomes: (1) the .OVL directory, (2) the GTPATH directory, and (3) the BBS/CBS directory. 9. Another option available under the Alt-I, #26, the pathname setup section, is the "Default Message Base PATH". This option is to be used to indicate to GT POWER where the main or default message base is located. This is the message base that the user will be initially given access to upon calling the system. This should be an open message base since all callers to the system that pass the logon procedure will have access to this area. 10. Another option available under the Alt-I, #26, the pathname setup section, it the "Default File Section". This option indicates to GT POWER where the main or default file section is located. This is the file section that callers will see initially when they access your system. This should be an area with the lowest security access level, so everyone will be able to use it. The default message base and the default file area are also configurable on an access level basis. This override of the default settings is specified in the GTPASSWD.BBS file by adding a line, where necessary, following each CLASS or password entry. Like this: C1 [1:00,1000,2:00] CLASS UP,DN,MS,PR,PW | FILE=c:\gt\c MSG=d:\trade - 7 - In this example, callers with access level 'C' would have the default file area set equal to "c:\gt\c" and the default message base set equal to "d:\trade". The '|' line is indented with blanks (not Tab characters). Either of the overrides may be omitted, and of course, the '|' line is optional. 11. To designate the directory where the host mode receives files, you should specify the DOWNLOAD directory path. This option is specified under Alt-I, #26, the pathname setup section. You may be confused by the terminology here, so let me stress that the DOWNLOAD directory is where GT POWER *RECEIVES* files, whether in host or terminal modes. Further, the UPLOAD directory path only pertains to Terminal Mode, as the host mode file areas are controlled via entries in the GTDIR.BBS file, described below. 12. To specify the directory where the host mode will save messages to the sysop. These messages are entered with the 'M' command from the main menu. This option is specified under Alt-I, #26, the pathname setup section. PLEASE NOTE: The pathnames mentioned above are all found on the pathname setup section, #26 of the Alt-I menu. Security Considerations ----------------------- Many of GT POWER's design considerations were directed towards providing absolute system integrity while in host mode. This section is designed to highlight some of those considerations with the intention of making the System operator of a host mode fully aware of both his protection and his responsibilities in that regard. The fundamental truth about security is that it is essentially YOUR responsibility. GT POWER's first line of defense in your behalf is its password function. Without a pre-assigned password, a remote caller cannot gain access to the functions provided by GT POWER! Thus, it stands to reason that your first responsibility is to assign those passwords and TO GUARD THEM. Because there are several sets of facilities that you will wish to control and to allow various users to be provided selectively, GT POWER provides several 'levels' of authorization that may be assigned to each password. In this way, all users who log on with the same password will have identical (and only those that are assigned) access to GT POWER's facilities. For example, GT POWER provides to users who have a sufficiently high level of authorization, the ability to shell to DOS, and have the ability to execute ANY DOS COMMAND from their remote location! Obviously, you would not casually distribute that password amongst your user community. Most users should NEVER be allowed to shell to DOS! (While in DOS a user could, for example, format your hard disk - that would, of course, result in the end of subsequent functionality of the entire system). To most users you should assign a lower level of - 8 - access. The SYSOP.EXE program can be used to change most items in a caller's user record -- especially the access level may be raised or lowered, as necessary. One of the nicest features of the host mode provided by GT POWER is its message bases. With this feature the users of the system may leave mail for other users and receive mail for themselves. Indeed, there are two kinds of mail: Public and Private. Public mail may be read by any user of the system. Private mail, on the other hand, may be read only by the person sending it or by the recipient. Here, then, is another area of security that you need to be aware of and control. For example, say that you allow your system to be called by clients of your firm and that they are encouraged to leave messages to you in your absence. It is possible that several of your clients are competitors of each other. Thus, it would be improper to allow them to read messages sent by others. This is the reason for Private mail. At this point, I would like to point out that there is no such thing as 'Private' from the Sysop! That is, the Sysop may read any message, whether addressed to the Sysop or not and whether they are marked Private or not. Finally, in case the earlier remarks did not sink in, any user who has access to the DOS via the Shell command (because of his assigned extremely high 'level' of authorization) can easily read any messages while he is in the DOS Shell! As far as sending Private messages to the System operator is concerned, any user may do that! There is an 'M' command on the Main Menu that results in messages that only the Sysop may view. These messages are automatically addressed to the Sysop and marked as private. They are placed in the message base specified for sysop messages, they may be read only by someone with the Sysop authorization level. This message base needs to be accessed at least once by the sysop during setup, to insure that a message is entered to create all control files. Otherwise, the system will not be able to process 'M' messages to the sysop. The hierarchy of access 'levels' based on password enables the Sysop to control which directories on the disk those users have access to for purposes of downloading files. However, each caller to the system will be granted access to the "Default file section", which is a configuration option. So please be sure that this file section contains the least sensitive material on your system. For ease of use, it is recommended that the user construct a batch file to invoke GT POWER, especially host mode users. It should look like this: C: To specify a default drive of C set GTPATH=C:\GT Remember to set GTPATH! GT1800 host.scr To invoke GT POWER If the above batch file were called GT.BAT and placed in your system's PATH then you could easily invoke GT POWER by simply typing: GT. It is important to note, that one of the most frequent errors reported to the GT POWER support staff is the incorrect setting of GTPATH. The - 9 - file 'host.scr', named on the GT1800 command line above, is an ASCII text file that contains a single entry: host The 'host.scr' file can be easily created with a text editor, such as EDLIN, EDIT or QEDIT, and it should be placed in the script directory, which is named under the Pathnames option on the Alt-I screen. As you will see when you read the next section (about the GTDIR.BBS file), you can allow your users to have access to all directories that have a matching authorization level OR LOWER. Further, you can specify that particular directories are only available to specific authorization levels. Where is all this authorization level information kept within the GT POWER system? In a file called GTPASSWD.BBS. That file is the key to the security of your system. One of the subtle security features of GT POWER is that it will not allow that file, even if it is contained in a directory that the user has been authorized to download from, to be transmitted over the telephone! NOTE: That the external protocols can transfer prohibited files and for this reason, extreme care should be taken when using either DSZ.EXE or PCKERMIT.EXE. Similarly, because the log file that is optionally maintained by GT POWER contains the user names and passwords of those who have logged onto the system, it may not be transmitted over the telephone either. When running in host mode the screen on the host system shows all keystrokes entered by the remote user (except while he is in the DOS Shell or using a DOOR). In other words, if the remote user, for example, entered a Private message to another user, or to the Sysop, the text is showing on the host screen as it is typed. If the user were to log off immediately after entering the message then it would be possible that the text of the message remained on the screen. GT POWER erases the screen after the caller hangs up to prevent such a lapse in security. If you are running a host mode system in an environment where others might be able to observe the screen then it is recommended that you turn your monitor off while you are not in attendance. If others may be in the area as you are communicating (chatting) with users and you wish to control the information on the screen you would do well to remember that the Alt-W keystroke will erase your screen instantly. A user may be bannned from accessing the system. Note, however, that doing so merely encourages an undesirable to log on with another user name. With the advent of personalized passwords, this provision has become more effective, since one could setup the system password to have a low access level, which would be raised only after validation. - 10 - Computer time is a resource that you can also control in host mode. Each password may have a designated time limit beyond which the caller will be automatically logged off. The number of calls per day made to your system by an individual caller is also subject to control. One of the more subtle security measures needed in a host mode ennvironment is called a 'Watchdog'. In the GT POWER system, this function is provided by a program called DOORMAN. DOORMAN is a TSR program that should be loaded in your AUTOEXEC.BAT file, it has no command line options, and is loaded simply by its name, DOORMAN. Should an authorized user be in the DOS Shell or in a DOOR, and if for any reason he were to drop his carrier (hang-up), the system would then be vulnerable to the next caller as that caller could find the system at the DOS prompt and he would then have uncontrolled access to do as he pleased to your system. In the situation mentioned, loss of carrier, DOORMAN will force your system to reboot and if you setup the AUTOEXEC.BAT file properly, when the system completes rebooting it will invoke GT POWER and put it back in host mode! The same thing would happen if a power failure occurs during host mode operation. When power is restored the system will automatically return to the host mode of GT POWER. Note, however, that for those systems that do not have a built in clock, the time and date of the system would no longer be correct. As a Sysop of a GT POWER system you must be aware that there are some legal considerations that you may face. For example, should you allow users to place copyrighted programs onto your system and to then allow other users to download those same programs, then you are participating in an illegal activity! Naturally there is no way to prevent a user from sending you copyrighted material, provided he has upload capability. There are many things that you can do, however, to stop others from having access to that material. For example, GT POWER allows you to cause all files that are uploaded to your system to be placed into a special receiving directory, rather than into the directory the user is currently using. It makes good sense to make a receiving directory PRIVATE, in the sense that it is NOT listed as available in the GTDIR.BBS to your remote users. In this way, you may review the files received at your convenience and move them over to the public directories if you are satisfied that they are either public domain or shareware programs and files. Another reason that you will want to do the above is that there are a few people out in the world that like to send what are called Trojan Horse programs to BBS's. A Trojan Horse is a program that causes some form of damage when it is run. It would not be at all fair to your users to expose them to such programs. So, when it is safe for you to do so, run the programs you receive before making it publicly available (using BOMBSQAD or a similar program to prevent a problem for you). When you are satisfied that the programs received are safe then you can move them to public areas. NOTE: Running programs uploaded to a BBS is extremely dangerous. And can result is the crash of your system, i.e. someone may break- - 11 - in, because you have run what seems to be a harmless upload. Please be carefull!! And in the event that a user does send you a Trojan Horse or copyrighted code, it is in your best interest to know who did so. GT POWER provides an optional log file function. If that is enabled, which is highly recommended, then the log contains the name of the person who logged on and sent you the file. GT POWER also puts the name of the uploader with the file description given at the time of upload. This section of the document is substantially larger than you may have expected it to be. The reason should now be obvious. YOU are the person responsible for security. It is necessary that you know the previous information and take appropriate actions. - 12 - Host Mode Text Files -------------------- The following text files must be created and/or maintained with an editor that can produce plain ASCII files. Any of the display type BBS files may have a DC2, Ctrl-R, character inserted into column 1 of line 1 to disable the "More?" prompt during display of the file, and a DC4, Ctrl-T, character inserted into column 1 of line 1 to disable the Ctrl-K and/or Ctrl-C user break, or a ENQ, Ctrl-E, character inserted into column 1 of any line to force a "More?" pause at that line. A NAK, Ctrl-U, can be inserted in column 1 of any line to introduce a variable substitution line. The ACK, Ctrl-F, can be used in column 1 of a bulletin file to nest the display of other text files. +--------------------------------------------------------------------+ | | | Ctrl-E ... ENQ ... Insert a "More?" at current location. | | Ctrl-F ... ACK ... Nest the display of bulletin files. | | Ctrl-R ... DC2 ... Disable "More?" during file display. | | Ctrl-T ... DC4 ... Disable ^K/^C break during file display. | | Ctrl-U ... NAK ... Introduce variable substitution line. | | | +--------------------------------------------------------------------+ Please note that once the Ctrl-E command has been used the automatic insertion of "More?" prompts are terminated for the duration of the current display. Using the Ctrl-R to disable the "More?" prompt is useful when the file contains such graphic or annimation techniques that would be spoiled by such interruption. Except for the GT?DIR.BBS files and the SYSOP.BBS file, every .BBS file can have two versions: (a) a color graphics version or (b) a plain text version. This is coordinated with the ANSI graphics question asked of callers before they logon the system. The .BBS extension is the default used if only one version of the file can be found by GT, the .CBS extension is used to indicate to GT POWER that a graphics version is available. If both versions are available, the .CBS version will be shown to callers who elect graphics, if graphics are not elected by the caller, the .BBS version will be displayed. The variable substitution line is interpreted by GT POWER, and certain substitutions can be made. The following are supported: A ... The DTE baud rate. B ... The DCE baud rate. C ... The caller's number (i.e. the 100th caller). D ... The current calendar date. DL .. Daily download limit, in thousands. DT .. Amount downloaded today, in thousands. F ... The caller's first name. G ... The caller's screen length setting. H ... The caller's home - city and state. L ... Time left for current session in minutes. M ... The current message base description. - 13 - N ... The caller's full name. R ... The caller's upload amount in kilobytes. RF .. The caller's upload amount in number of files. S ... The current file section description. T ... The current time of day. TB .. Current Time Bank total. TD .. Time Bank daily deposit limit. TW .. Time Bank daily withdrawal limit. Wn .. Set width of the parameter that follows to 'n' columns. X ... The caller's download amount in kilobytes. XF .. The caller's download amount in number of files. XD .. Expiration date for caller's account. XP .. Number of days past expiration date. XU .. Number of days until expiration date. XL .. Number of days warning that expiration will be given. Z ... The caller's default file transfer protocol. n ... 'n' number of blank columns. In addition to these items, plain text may also appear on the variable substitution line, it must be quoted however, like this: "plain text between quotation marks" For example: ^U" Name: "N ^U" First: "F ^U" Home: "H ^U" Time remaining: "L ^U" Current time: "T ^U" Default protocol: "Z ^U" Blank Columns: "30"30 of them." ^U" Fixed width: "W30N"30 characters in width" Please note: ^U is just a symbol used in this document to represent the Ctrl-U character. The Ctrl-U feature can be used with messages, as well as with bulletins and other screens. For example, you can now address a message to: ^UF Which, as you guessed, make all callers think that the message was personally addressed to them! A fancy way to implement "junk mail" on a bulletin board! <GRIN> The text of messages can also contain Ctrl-U lines, to further allow customization of messages. Everyone should restrain their usage of the Ctrl-U feature in echomail conferences. In fact, it may be banned from echomail conferences, if abused. The nesting of bulletin files with the Ctrl-F character is extremely useful, but also hazzardous, if the nesting is done to a great level. For best results, the nesting should be kept to a single level. An example of usage is: - 14 - ^Fc:\gt\foo.bar Please note that there is no space between the Ctrl-F and the filename and that the full pathname must be given for the file. File Descriptions ----------------- GTSYSID.BBS This file is displayed as soon as the GT POWER host detects a connection has been established with an incoming call. After displaying this file, GT POWER will ask the user if the terminal program he is using supports ANSI graphics. If a language menu, GTLDIR.BBS, is being used, it will be displayed before the ANSI graphics question. GTWELCOM.BBS This file is displayed to a caller just before he is asked for his name by the GT POWER host. It should identify the system to callers. GTPASSWD.BBS This file contains the list of passwords that people must know to access the system. Comments may be placed in this file by placing a ';' in the first column of any line. The entries in this file are composed of one line per password, and each line contains the following information, beginning in column 1: Lx ([xx:xx(,m/n,hh:mm,path)]) Pwd Auth (1st-Name Last-Name Phone-Number) These items can have a variable number of blanks between them, but the 'L' must begin in column 1. EACH PASSWORD, "Pwd", MUST BE UNIQUE and from 1-20 characters in length. The () which have been shown around the call time limit, the daily call limit, the daily download limit, the daily time limit, the name, and phone number fields, indicate that these items are optional and need not be included in the file. Field descriptions: ------------------- Lx ......... The Access Level assigned to this entry. May be any character from the following sets: 0-9, A-Z, or a-z. NOTE: "0" is the highest level and "z" is the lowest. The 'x' following 'L' is the bullet number that this caller will be shown. Valid bullet numbers are 0-9, A-Z. Read additional instructions bellow under BULLETx.BBS. - 15 - xx:xx ...... The Call Time Limit. This field is optional and is enclosed within [...]. If omitted, it defaults to approximately 24 hours. m/n ........ The Daily Call Limit/the Daily Download Limit. This field is a sub-field within the [...] of the Call Time Limit field. It cannot be specified without the Call Time Limit being specified also. Example: [1:30,2] would grant two calls per day of 1:30 duration each and unlimited downloads. Another example, [1:30,2/500], shows a 500k daily download limit in effect. hh:mm ...... The Daily Time Limit. This field is a sub-field within the [...] of the Call Time Limit field. It cannot be specified without the Call Time Limit and the Daily Call Limit being specified also. Example: [1:00,5,2:00] would grant five calls per day, each of up to 1 hour each, but a maximum of 2 hours per day total usage. path ....... The upload pathname. This specifies where files uploaded by a particular class of user are to be stored. pwd ........ The Password. As said above, the password may be from 1-20 characters in length and must be unique. If this line is a class entry the "pwd" field should contain the word CLASS in capital letters. auth ....... The Authorizations given to this entry. They come from the following list: UP : Upload authorized. DN : Download authorized. PR : Private mail authorized. KL : Allow the killing of messages, the same as the Sysop. MS : Allows message reading. MV : Allows message moving between message bases. NB : Bulletin menu not allowed. QK : Allows access to the QWK mail commands. Callers must have the "UP" authorization to upload REPs, that is reply packets. The "DN" authorization is needed to download QWK mail packets. CC : Allows usage of the carbon copy feature for messages. RA : Callers with this permission can do nothing except leave a message to the sysop. RC : Require netmail credit for all netmail messages - normally local messages don't require credit. BP : Bypass logon. This allows callers to bypass all the steps between logon and the main menu. BO : With the BP option, causes only bulletins to be - 16 - bypassed during the logon procedure. SY : Sysop priveledges authorized. CH : Manual directory change is authorized (in absence of the GTDIR.BBS file). CB : CB Simulator authorized. SH : Shell to DOS is authorized. DR : Use of DOORS is authorized. FA : Allows file attach when using the netmail programs. FR : Allows file request when using the netmail programs. NL : Disable the (L)ist directory command at the main menu. NN : No name uploads. Callers with this authorization will not have their name recorded in the FILES.BBS, when they upload a file. NE : Disable the (E)nter message command. NP : Disable the sysop (P)age command. NX : No expert mode. Callers with this authorization will not have access to the e(X)pert mode. PW : The caller is authorized to change his password. But before he can change any personal information, the caller must match his phone number to verify his identity. TB : The Time Bank is authorized. These authorizations are listed seperated by commas, following the "pwd" field. See examples below. The CH authorization is a "do nothing" authorization in most cases, because most systems use a GTDIR.BBS file. On these systems the CH option may be used as a way to grant no authorization, because a total lack of authorization yields the default authorization set: DN,UP,PR,MS. Time Bank Setup --------------- The Time Bank, TB, authorization has a rather complex format, for example: ; TB field labels uk uf dk df me mr mk qk rp dl wl E1 [1:00,5/30,2:00,C:\UP] CLASS UP,DN,MS,TB=01/02/03/04/03/00/05/01/01:060/060 Note the TB= entry at the end of the authorization list. Each field is of fixed length, 0's required, as shown. No field may be omitted from the list, however they may be zeroed out, if not wanted. The field definitions are: uk = Upload time bank credit per 100k uploaded. If possible, the credited amount is rounded and pro- rata for lesser uploads. For example, if uk = 2, then a 50k upload would earn a credit of 1. uf = Upload time bank credit per file uploaded. dk = Download time bank deduction per 100k downloaded. As is done with the 'uk' field, this deduction is - 17 - pro-rata for lesser downloads. df = Download time bank deduction per file downloaded. me = Message Entry time bank credit per message entered. mr = Time bank credit per message read. mk = Time bank deduction per message deleted. qk = QWK mail credit per 100 messages downloaded. rp = QWK mail credit per 100 messages uploaded. dl = Daily limit on time bank deposits. wl = Daily limit on time bank withdrawals. Time may be withdrawn from the Time Bank via the main menu command [TB]. Time may also be converted to netmail credits, if desired. Carbon Copy Messages -------------------- The carbon copy feature allows us to send the same message to a group of people. The list of names may appear in the message itself, or be contained in a separate file. This feature is controlled via dot commands. Like other dot commands, a '.' is put into column 1 of any line of the message, followed immediately by the appropriate command. The most familiar commands are: .CS, .GL, .GM and .RR (which should be familiar to all netmail users). Now here are some new ones to control the carbon copy feature: .CC ..... Carbon Copy. For example: .cc John Doe,64/2 .cc Frank White The first .CC would send a carbon copy of the current message to John Doe on net/node 064/002 (via the netmail system, of course). The 2nd example would simply create a carbon copy for Frank White on the current BBS where you entered the message. .BC ..... Blank Carbon. This command works like the carbon copy command, except that this carbon is not included in the distribution list (normally shown at the bottom of the message). This is neat, if you want to send a carbon to someone, but not alert the - 18 - others on the distribution list. Pre-canned distribution lists are available for use by folks that have a repeating distribution. The '@' syntax is used with the .CC command to call up a pre-written distribution... as follows: .cc @c:\gt\foo.bar The full pathname should be specified for this entry, however, GT POWER will look in the GTPATH directory, if no pathname is given. The contents of the distribution file uses the same syntax as given above, the .CC and .BC lines written as if they had been put in the regular message. For example, the file C:\GT\FOO.BAR might contain: .cc John Fisher,22/1 .cc Rob Roesch,64/3 .cc Reb Gambrell,33/16 .cc Stephen Ricciardelli,32/400 Also, it is possible, in a pre-canned distribution list, to blank out the names and replace them with a comment (when they appear in the message). This is done by making the 1st line of a pre-canned distribution the .LA command, as follows: .la Beta Distributors .cc John Fisher,22/1 .cc Rob Roesch,64/3 .cc Reb Gambrell,33/16 .cc Stephen Ricciardelli,32/400 Notice, the .LA command on the first line. The .LA command can only appear in pre-canned distributions, and if it appears, it must be the 1st entry in the file. LA is short for LABEL, which can be spelled out, if desired. If an .LA entry is at the beginning of a pre-canned distribution file, then no names are shown on the carbon copy list in the message, rather it would simply show: Carbon Copy: Whatever the LA command says goes here Using the example above: Carbon Copy: Beta Distributors Note, it is possible to mix netmail responses with local conference responses. For example, this is okay: .cc Stephen Ricciardelli,32/400 .cc John Dokes .cc Perry Alexander,32/1 - 19 - The 1st and 3rd carbons would be delivered via netmail, while the 2nd would be placed into the currently selected conference. 1st-Name Last-Name Phone-Number These three fields are present when it is desired to allow the caller "callback" priveledges. In effect, if the caller's name matches the name listed here and he gives the correct password, the system will offer to call him at the listed number. This allows the host to assume the cost of the phone charges for the session. The caller must be prepared to accept the call, that is his modem must be in "auto-answer" mode. Send "ATS0=1|" to most Hayes type modems to set auto-answer mode. The "|" represents a "carriage return". If the conditions are met GT POWER will return the call within 15 seconds, and will retry 3 times before giving-up hope of establishing the connection. NOTE: the password assigned here for the callback, must *not* be the same as the caller's personal password, i.e. the callback password *MUST* be unique. NOTE: It is possible to append a single character to the level indicator. Thus "A1" would be a valid level. This extra character is used to identify a custom bulletin file for this caller. This extra character is optional, but if present MUST BE a character that is legal within a file name. Read about BULLET files below. Examples: A [2:00,100/1000,5:00,c:\goodies] MASTER SY B1 [1:00] FRIEND DN,PR B1 [1:00,4/500,2:00,c:\up] CLASS DN,UP,PR C [1:30] JOGGER DN,UP,PR,DR MARY ADAMS 1-213-555-1234 A [2:00,10,4:00] CLASS SY C2 [2:00,3/250,3:00] CLASS DN,UP,PR,DR In version 12.10 of GT POWER, personalized passwords were introduced. When a caller gets his personal password it is stored in the USER.CTL file, with the other user information. The access level assigned to the password used by the caller on the first call (before a personal password was assigned) will be the access level assigned to the caller until changed via the SYSOP program. To provide a time limit, daily call limit, and bullet#, a cross reference of the access level stored in the users record in USER.CTL file and the GTPASSWD.BBS file is required. This is accomplished by placing CLASS cards for each access level your system uses into the GTPASSWD.BBS file. The format of the CLASS card is the same as a normal password entry, except the word CLASS must appear in uppercase letters. In addition, the CLASS entries cannot be used to provide callbacks, normal password entries must be provided for that purpose. Here are some example CLASS entries: - 20 - Examples: A1 [2:00,5/500,3:00] CLASS DN,UP,PR,DR,SH,MS B3 [1:30,2/250,2:00] CLASS DN,PR,MS K2 [:45,1/100,:45] CLASS DN,UP,PR,DR,MS The first CLASS entry establishes a class for callers with an 'A' access level, grants them 2 hours of session time, a daily call limit of 5 calls, a daily download limit of 500k, 3 hours of time per day, and gives them the authorizations: Download, Upload, Private mail, use DOORS, Shell to DOS, and read messages. The other entries grant lesser time amounts to the 'B' and 'K' classes. The 'B' class is given Download, Private mail, and Read message authorizations. The 'K' class is given Download, Upload, Private mail, use DOORS, and message read authorizations. Note: if you neglect to setup CLASS entries then once your callers have been assigned their own personal passwords, and this is automatically done by GT POWER, then they will have unlimited time access to your system, the default authorizations, and they will not be given a bullet#. It is possible to add comment lines to the GTPASSWD.BBS file. Any line with a ';' in the 1st column is a comment entry, and will be ignored by GT POWER. Optionally, the default message and file areas can be configured on an access level basis. This is done by putting an extra line following the CLASS and/or password definition, for example: C1 [1:00,100,2:00,c:\uploads] CLASS UP,DN,MS,PR,PW | FILE=c:\gt\c MSG=d:\trade The line beginning with '|' must follow immediately after the appropriate CLASS entry and the '|' character is indented with blanks -- not Tab characters. Either of the override specifications may be omitted -- so both areas don't need to be specified. +----------------------------------------------------------+ | | | Remember to give callers the MS authorization | | so they can "read messages". And setup a CLASS | | entry for every different access level in use. | | | +----------------------------------------------------------+ GTBULLET.BBS This file is displayed for the caller after he/she completes logon. It is useful to leave notes here for expected callers. BULLETx.BBS The "x" may be any character that can be a legal part - 21 - of a filename. This character must match the character which is found after the level indicator in the password file, to enable custom bulletin files to be displayed for callers. For example: if a caller's level was "BZ", then the program would search for a file named BULLETZ.BBS to display whenever the caller logged onto the program. NOTE: Custom bulletin files are OPTIONAL. If you do not wish to use them, simply use single letters for access level indicators. GTMENU.BBS This file is displayed for callers as the main menu. It may be suppressed by a caller by selecting e(X)pert mode. GTHELP.BBS This file is displayed when the caller requests help from the main menu. GTBYE.BBS This file is displayed for the caller when he logs off, i.e. selects the (G)oodbye command from the main menu. GTBYEx.BBS This is a custom bye file. The 'x' may be any character that can be a legal part of a filename. It comes from the GTPASSWD.BBS file, as the letter following the level indicator. Most commonly a number. See custom BULLETx.BBS files above. GTUSER.BBS This file is created whenever a call comes into the system. It will contain the access level and name of the current caller, or if no call is in progress, the previous caller to the system. The file contains just this 1 line of text. The exact format is: L 1st-Name Last-Name auth baud ANSI-opt last-on limit event time The line is free format with spaces delimiting fields. The 'L' field is the access level of the caller. The "Last-Name" field will consist of a single character, a ';', if the caller has only 1 name. The ';' will act as a placeholder in that case, so that DOOR programs will have an easier time unpacking this data on the line. The 'auth' field will contain the authorizations given this caller from the GTPASSWD.BBS file when he logged onto the system. The 'baud' field will two baud rates seperated by a ':', for example 19200:2400. The first baud rate is the DTE rate, the second baud rate is the DCE rate. The split rate is necessary for those using high speed modems. If the current session is a local sysop logon, then the 'baud' field will contain the word LOCAL, if the sysop is logged-on. The 'ANSI-opt' field will contain 'NOANSI' if the caller doesn't want ANSI graphics, or - 22 - 'ANSI' if he does want the graphics. The 'last-on' field contains the date the user last called the system. The 'limit' field contains the remaining time the caller has left for the current call. The 'event' field contains the time remaining until the next event is scheduled. The 'time' field contains the current time in 'xx:xx' format. The time remaining fields are integer showing time left in minutes. The 'event' time is always measured _from_ the 'time' field base - - not from the DOS clock. The purpose of this information is to supply needed control information to external programs that run either in the Shell to DOS or DOOR environment. GTDIR.BBS This file contains a list of directories that may be accessed by callers. There are three types of lines in this file: the actual directory lines, comment lines and group header lines. The comment lines are displayed to the caller when he asks to see the list of directories. The list displayed will contain only those directories the caller is authorized to access. The formats: Group Header Lines: Begin with a '.' in the 1st column. The detailed format is explained under GTMDIR.BBS. GTDIR.BBS and GTMDIR.BBS have very similar formats, so rather than explain it twice... Groups are optional, both in the GTDIR.BBS and the GTMDIR.BBS. Comment Lines: Contain a blank in the 1st column, the remainder of the line is displayed for the caller. Directory Lines: Column 1 - access Level. The minimum level required to access the directory. If this column contains an '=' then the actual line is shifted to the right 1 column and the '=' acts to reserve the directory for the indicated access level - which would now be in column 2. (See example.) One or more blank columns follows the level, then the complete DOS pathname of the directory, including all drive and PATH information. One or more blank columns follows the directory name, then a description of the directory is given. When a caller selects the (C)hange directory command, the list of choices will display the descriptions you provide here, so try to be helpful. - 23 - CDROM support is specified on the directory lines. The first step is to specify a full pathname for the FILES.BBS, as one can't put a FILES.BBS onto the CDROM itself. Here is an example: Z F:\DIR6,,C:\GT\FILES\D6.BBS,CD Some description E G:\DIR22,,C:\GT\FILES\D22.BBS Another description Compared to normal entries in the GTDIR.BBS you will note that the pathname for the directory is followed by two commas and the pathname for a BBS file, which is optionally followed by ',CD'. The two commas are required... don't ask why just yet, I plan to stick a new field in there later on. Following the two commas is the full pathname of the FILES.BBS (must be on a writable disk drive). The ',CD' is optional, and causes GT POWER to skip this directory when the caller asks for new file (I)nquiry (kinda senseless to search a CDROM for new files, heh?). The FILES.BBS for an upload directory is always found in the directory with the uploaded files. The CDROM support cannot be used to redirect the upload descriptions to a different location. Note: To newcomers, a FILES.BBS is a file that contains the descriptions of the files available for download. It's construction is described elsewhere in this document. Examples: .Z GENERAL General File Board This is a comment. (Since column 1 is blank) A G:\DIR9,,C:\F\DIR9.BBS,CD The description goes here. =B C:\LOTUS\DATA This is for 'B' level callers only. C A:\ The description again goes here. The first line in the example above, shows a group header line. This example shows three directories, one with an 'A' access level (on a CDROM drive), one with a 'C' access level. These are the minimum levels that callers must have to "see" these directories. The '=B' directory may be accessed only by callers with the 'B' access level. Freebie download areas can be created by placing a "paragraph character", ASCII 20, before the pathname in the GTDIR.BBS file. I would give an example, but the "paragraph character" does not show-up well in wordprocessing documents. A "freebie area" is one where all the downloads are free, i.e. not accounted for -- so callers can feel free to take - 24 - all they want. GTUDIR.BBS This file provides caller selectable multiple upload areas. Of course, this is an optional feature, just omit this file if you wish all uploads to go into the normal upload directories (specified in the GTPASSWD.BBS file, on a CLASS basis). The format of GTUDIR.BBS is similar to the GTDIR.BBS, here is an example: Upload Directories ------------------ z C:\GTBBS\UP Misc Upload Directory z C:\GTBBS\PROG Programmer's Uploads =E D:\SPECIAL Alpha Tester's Uploads A C:\PRIVATE Private Uploads The 3rd upload area, with the '=E' designation, would only be available to callers with access level 'E'. The first two areas would be available to all callers, with 'z' as the required minimum access level. The 4th directory would be private (assuming that most callers have access lower than 'A' <GRIN>), access given only to those with 'A' access level or above. If the GTUDIR.BBS is present, GT POWER will ask the caller where to place the upload, just before the upload begins. The areas that the caller has access to will be listed for the caller, so that the caller can make a choice. The selected upload directory will override the upload path from the CLASS entry in the GTPASSWD.BBS file (in fact, if you use the GTUDIR.BBS file, the upload path in the GTPASSWD.BBS file is redundant). GTLDIR.BBS This file allows the Sysop to construct a menu that will be presented to callers immediately after the GTSYSID.BBS screen and prior to the ANSI graphics question. This menu can be used to swap around different language files. The GTLDIR.BBS has the following format: Starting in column 1, the name of the batch file to be executed if the related menu option is selected. Followed by at least 1 blank, then the text to appear on the menu. Any line that begins with a blank is displayed "as is" for the caller... explanatory text. Comments may be included by placing a ';' in column 1 of the comment line (comments aren't displayed for the caller). For example: ; This is a comment - 25 - Language Selection Menu ; Language 1, the most likely choice GTLANG_1 Language Number 1 GTLANG_2 Language Number 2 GTLANG_3 Language Number 3 ; The End This would appear on-screen for the caller like this: Language Selection Menu 1. Language Number 1 2. Language Number 2 3. Language Number 3 Enter Language Selection: The batch files, GTLANG_1.BAT, GTLANG_2.BAT, GTLANG_3.BAT should contain simple copy commands. Copy commands that move into place BBS/CBS screens matching the selected language entry. Nothing heavy duty should be done in these batch runs, as there may be limited memory available. The example showed 3 choices, but there can be more, however the menu should not be more than 1 screen full, otherwise the crashmail runs won't be able to work properly. After the language batch file has run, GT POWER will display a new screen, GTANSI.BBS, for the caller. This screen will only be displayed if the GTLDIR.BBS is installed and operational. It should contain some lead-in explanation for the ANSI graphics question (that formerly would have been in the GTSYSID.BBS screen). GTDDIR.BBS This file controls access to the GT DOOR system. Its function is much like GTDIR.BBS is for file directories. It serves as a way to add security to doors, document them and pass parameters to them. Each door must have an entry in this file, there are no comment lines in this file. Each line in this file follows the this syntax: L [comment_here_with_no_spaces] (Prompt message here:) The () indicate which fields are optional and need not be included in the file. As with the GTDIR.BBS file, the 'L' controls the minimum access level required to open the door. The [comment] is not optional, and must be enclosed within [...] and no blanks are allowed. If a parameter must be passed to the DOOR, then the optional prompt field - 26 - must be added. The answer given to this prompt by the caller will be passed to the DOOR as command line argument %3. Examples: B [this-is-door-1] Z [this-is-door-2] Enter filename: S [this-is-door-3] In the example above, the 2nd door has a prompt listed that indicates that this door requires a filename be passed. This could be for example to implement an ZIP view door, where the name of the ZIP file to be processed might need to be supplied. The caller's response will be passed as command line argument %3 to the GTDOOR2.BAT file in this case. +----------------------------------------------------------+ | | | Please note, the order of the lines in this file | | must be 1st door on 1st line, 2nd door on 2nd line, | | etc. The lines must be in 1, 2, 3... order. | | | +----------------------------------------------------------+ Doors may have screen files optionally associated with them. For example, GTDOOR1.BAT could have GTDOOR1.BBS (or .CBS). These screens are displayed to the caller just prior to the invokation of the door. GTBMENU.BBS This file is the bulletin menu file. It should list the numbered bulletin files. The numbered bulletin files can be located in the "Default File Section", or the GTPATH, or the BBS/CBS directory (but they should all be in the same directory). Their file names should simply be 1, 2, etc. This menu file will be displayed as users logon your system and besides the numeric bulletins, two alpha options should be listed: (L)ist logon bullets and (Q)uit bulletin menu. An example of a GTBMENU.BBS file: 1. Bullet #1 description here. 2. Bullet #2 description here. . . etc. . L)ist logon bullets Q)uit bulletin menu. It is possible that these bulletin files can contain ANSI graphics. If so, they should be named with a CBS extension. For example: 1 Bullet #1, no extension, no graphics. - 27 - 1.CBS Bullet #1, with .CBS extension, contains graphics. 2 Bullet #2, no extension, no graphics. 2.CBS Bullet #2, with .CBS extension, contains graphics. Remember: CBS versions of bulletins cannot occur without the standard "no graphics" version. Starting with GT 16.00, these bulletin files may be nested. When nesting bulletins, we will talk about bulletin numbers with a decimal point embedded within, i.e. 1.0.0 or 2.1.0. Each successive level of nesting requires another decimal be added to the bullet number, to a maximum of 5 levels deep. When equating the bulletin numbers to file names, the periods are first eliminated, for example 1.0.0 would equal filename 100, and 2.1.0 would equal filename 210. If we consider this situation for a bit, we see that there must be a sub-menu structure applied to these bulletins, in order to get them properly nested. For example, we might have the following in the top level file, GTBMENU.BBS: 1.0 General Bulletins 2.0 Game Bulletins The 1.0 would refer to the file 10 and the 2.0 would refer to the file 20. Each of these files, 10 and 20, would be sub-menus, which then actually referred to the actual bulletins. For example, file 10 might look like this: ;BMENU 1.1 Rules of the board 1.2 How to get more time 1.3 How to get higher access The line beginning with ';BMENU' must be the very first line of file 10, this signals GT POWER that this file is not actually a bottom level bulletin, but instead is another bullet menu. Files 11, 12 and 13 are the actual bulletin files (and therefore, would not contain the ';BMENU' entry). Because these bullet menus can be nested up to 5 levels deep, some new letter commands are available for usage in navigation. As follows: M Return to main bulletin menu (GTBMENU.BBS). P Pop back to the previous bullet menu. Beginning with GT POWER 18, personal bulletins are now - 28 - possible. These bulletins, if created, are named according to the caller's "Caller Number" in the caller's user record. To aid in determining the proper caller number, this number is now recorded in the log. If necessary, the SYSOP.EXE program can be used to lookup the caller's record. Here is an example of a personal bulletin filename: 4872.BBS If this file was located in the GTPATH or the BBS/CBS directory, then it would be displayed for caller number 4872 whenever he calls the system. Do not include leading zeros in the filename. It is possible to have .CBS versions of these files, but it gets confusing. If you wish to have .CBS versions of these bulletins, you _must_ place the regular bulletins, described above, into the default file area, and place the personal bulletins in the GTPATH directory. Otherwise, the filename conflict will get embarrassing. A real good idea would be to just not have .CBS versions of the personal bulletins! That would avoid all the problems. GTMDIR.BBS This file controls the multiple message bases that GT POWER can support. The format of this file is very similar to the format for the GTDIR.BBS file, except that you have 1 additional option for column 1, you may place a '*' in column 1 of an line in this file and then that message area will become a 'by application only' message base. The caller applies for entrance by trying to select the message area via the (A)rea change command. GT POWER will inform the caller that application has been accepted and the Sysop must approve. The users name will be placed into the USER_MSG.CTL file associated with the message base, but the BAN bit will be set, the Sysop must use SYSOP.EXE to reset the BAN bit so that the caller can be admitted. When setting up, the Sysop should insure that all sub- directories listed in GTMDIR.BBS exist, but GT POWER will automatically provide all the control files and message directories, as needed. All message areas must have an entry in this file, including the Sysop Message Base. The main default message area must be open to all callers and must use the same pathname as the message base pathname in GT POWER's configuration file. The GTMDIR.BBS file must be located with the other BBS files, either in the GTPATH directory or the BBS/CBS directory. - 29 - +--------------------------------------------------------------+ | | | The pathname portion of the lines in the GTMDIR.BBS | | file may be prefixed with either '^', '~', '<', '$' | | or '#'. | | | | ^ ... Designates a message area that can support | | public messages only. | | ~ ... Designates a message area that is used as a | | netmail area (see netmail docs). | | < ... Designates a message area that is Read-Only. | | Only the Sysop can enter messages. | | $ ... Designates a message area that can support | | private messages only. | | # ... The netmail reply mechanism is denied on a | | message base level. | | | +--------------------------------------------------------------+ Examples: Z ^C:\GTBBS\OPEN Public Message Base E C:\GTBBS\GENERAL General Message Base F C:\GTBBS\SPECIAL Special Message Base Q #^C:\GTBBS\ECHO An Echomail Conference Z ~C:\GTBBS\PUBLIC Public Netmail Area Please notice the entry for the Echomail Conference, it demonstrates that echoes should have only public messages, the '^' modifier assures this, and the '#' modifier disables the netmail return feature (netmail returns are only available to callers that have netmail credits -- use SYSOP.EXE to issue netmail credits). Personally, I like the netmail return feature, but some Sysops don't, so a means has been provided to disable it on a selective basis. If your BBS is going to handle QWK mail, then some things need to be added to the definition for each conference participating in the QWK mail (not all conferences need be available for QWK mail). If a conference is to be included in the QWK mail setup, then the "conference number" and "conference id" must be given in the GTMDIR.BBS. Here are some samples: Q c:\gtbbs\gospa,20/Our_Lady The Messages of Mary Z d:\trade,30/Trade_Echo The Trading Post The conference number follows the pathname, with a comma in between, then a '/' followed by the conference id. The conference numbers can be in the range 0 to 65534, excluding 8192 thru 8447. The conference id may be up to 10 characters, no blanks. Blanks may be included by using the '_', underscore, - 30 - character -- which GT will convert to a blank. Message bases and file areas, GTMDIR.BBS and GTDIR.BBS, can be split into logically grouped areas. Groups are totally optional... you don't have to introduce groups into either the GTMDIR.BBS or GTDIR.BBS. The beginning of a group is denoted by the Group Header, like this: .Z GENERAL General Board Z #^C:\GT General Message Base Z ~C:\MAIL Netmail Area .=D NETWORK GT Network Sysop Board Z ^C:\SYS GT Network Sysops Echo Z ^D:\NODE_ECO The Nodelist Echo In the example above, there are two groups. A group header begins with a '.' in column 1. The 2nd character is usually an access level (the minimum required to access the group). But note the 2nd group header begins '.=D', this denotes a group that is available to the 'D' access level only. After the access level, there is at least one blank, then the group name, 'GENERAL' and 'NETWORK' in this example. After the group name is the menu description for the group. The lines following each group header are the usual entries for the message bases or file areas (in the case of GTDIR.BBS). The group name must be unique in the first 8 characters, but may be up to 30 characters in total length. GTDOORS.BBS This file is displayed for the caller when he selects the (O)pen DOORS option from the main menu. It is a pure text file, which should contain your DOOR menu. Each DOOR is assigned a number, 1-999, and should be listed on this menu by the number needed to select the door. It is possible to have sub-menus, which work off of the GTDOORS.BBS menu. If the GTDOORS.BBS file looked like this: Main Door Menu -------------- A. Game Doors B. Database Doors C. Utility Doors Then, if the caller selects 'A', the sub-menu GTDOOR÷A.BBS would shown. Or if 'B' were selected then GTDOOR÷B.BBS would be shown. Then whenever a - 31 - numeric entry is made, the caller would be put into the selected door. A simple carriage return would take the caller back to the main door menu, GTDOORS.BBS. GTDOORnn.BAT These are the DOOR files themselves. These are batch GTDORnnn.BAT files, much like the Shell to DOS batch file, but instead of executing another copy of COMMAND.COM, it executes your DOOR program. The mechanism of the DOOR uses the CTTY commands at the start and end of the file. The CTTY redirects the console to the COM port at the start of the DOOR file, and back to the console at the end. Sample DOOR files are included with the package. Here is a short example: %1 com%2 edlin %3 %1 con The %1 will become "ctty" or "rem", and the %2 will become the port number, through substitution by DOS. The "REM" substitution is used when the DOOR is being run locally by the Sysop to check it out. A DOOR that works in the local mode may not work for a remote caller, because the DOOR program may not use the DOS functions to perform I/O through the console. Remember that the 3rd command line argument is passed from the GT POWER host to the DOOR containing the response from the caller to a prompt you have placed into the GTDDIR.BBS file. In this case, it would have asked the caller which file he wanted to edit. If the door doesn't require a 3rd parameter, GT POWER will pass the DCE baud rate as the 3rd parameter. If the door does require a 3rd parameter, then it will override and replace the baud rate. This should be handy for doors that do file transfers via external protocol drivers. Please note the two forms of the door names. GTDOORnn.BAT is used for door numbers 1 through 99. For doors numbered from 100 through 999, use GTDORnnn.BAT. For example: Door #5 ..... GTDOOR5.BAT Door #45 .... GTDOOR45.BAT Door #125 ... GTDOR125.BAT Door #999 ... GTDOR999.BAT Doors may have screens associated with them. These screens are stored in files with the same name as the door .BAT, but with the BBS or CBS extension. For example: GTDOOR5.BBS would be the screen for GTDOOR5.BAT. The screen is displayed for the caller - 32 - just before GT invokes the door .BAT file. ANSWERn.BBS This file contains the answers supplied by the callers to the 'n' questionaire, that you have stored in the QUESTn.BBS file. The format of this file is as follows: each answer given by a user is written on a separate line to this file, the answers are grouped by placing the users name, from logon, onto the first line of the group, enclosed within << ... >>, following this each answer appears on a separate line and each group is terminated with a line containing a single period. Here is an example: << Paul Meiners >> 3104 E. Camelback Rd. #503 Phoenix, Az 85016 602-897-9557 . << Susie Meiners >> 1245 Sunnyside Dr. Houston, TX 77081 713-894-3465 . The example shown above contains two groups of answers. As GT POWER accumulates answers it will continue to append them to the end of this file. If this file does not exist, GT POWER will create it. The Sysop should avoid editing this file, because any attempt to do so may render GT POWER incapable of adding answers to it (if the editor adds a Ctrl-Z character to the end of the file -- the STRIPZ.EXE program may be used to remove Ctrl-Z characters). QUESTn.BBS This file contains the questionaire for callers to fill out. This feature is optional. The file is in template format, using the [------] construct to indicate where GT should gather answers to questions. For example: [------------] Enter Phone Number: Would direct GT to collect the phone number, showing GT where to collect the answer and the maximum width answer to accept. Each answer can be up to 80 characters long and there may be up to 50 questions per questionaire. After having filled out the questionaire, the caller will be asked if he wishes his answers to be recorded. If he indicates NO, the GT POWER will discard the answers. - 33 - The questionaire is optional, and if the user tries to fill out a questionaire that cannot be found, GT POWER will indicate to the caller that there is no questionaire currently available. There can be up to 99 different questionnaires for the caller. The GTQMENU.BBS file is displayed with a list of all available questionnaires. Before a new caller reaches the main menu, GT POWER will automatically present the New Caller Questionnaire. It is questionnaire 0, QUEST0.BBS. No pre-questionnaire will be displayed, the caller will just be forced to answer the questionnaire. If the caller tries to drop carrier or otherwise avoid the new caller questionnaire, then GT POWER will force them to answer it on their next call. Of course, the new caller questionnaire is optional (simply omit QUEST0.BBS and there is no harm). Questionnaires are programmable. Commands must start in column 1 of any line that contains a command. Line labels can be added to the questionnaire, so that branch commands have some way to locate where to goto. A line label begins with a ':' in column 1, followed by an 8 character name, for example: :label The following commands are supported: [%DT] ............... Date/time stamp. Records the current date/time in the answer file. [%ABORT] ............ Abort the questionnaire. Stop the questions and return the caller to the main menu. [%JN,pathname] ...... Join caller to message base. Join the caller to the message base pointed to by 'pathname'. [%TB,label] ......... Test for blanks in answer. Test the answer to the previous question for blanks, if the answer is blank, then branch to the specified line label. [%TA,label] ......... Test for ASCII in answer. Test the answer to the previous question for all - 34 - ASCII data. If all characters are normal ASCII (32-125 decimal), then branch to the specified line label. [%SV] ............... Force questionnaire to be saved. This command should be placed near the beginning of the questionnaire, to insure it is "in effect" before the caller decides to drop carrier <GRIN>. Once it has taken effect, the questionnaire WILL BE saved, unless the computer crashes. [%MO] ............... Execute a "More?" prompt. This command causes a "More?" prompt to be given to the caller. [%TL,A-E=label] ..... Test access level. [%TL,L=label] If a caller has the indicated access level, then branch to the specified line label. As shown above, the test can be for a range of levels, or for a particular access level. [%IF,X,xxx=label] ... Test answer for value. [%IF,X,x=label] [%IF,X,A-C=label] [%IF,N,10=label] [%IF,N,20-30=label] This command allows the Sysop to test the answer to the previous question. The entry can be tested as a number or a string of characters. The 'X' param indicates a string test should be performed. The 'N' param indicates a numeric test. The test can be for individual numbers or characters, or it can be a range. For example: [%IF,X,Y=okay] Test 1st character of answer for a 'Y'. [%IF,N,10-15=right] Test if the number was between 10 and 15 inclusive. [%IF,X,MAGIC=got_it] Test if the word was the word 'MAGIC'. If the test evaluates to be true, then branch to the specified line label. [%GO,label] ......... Goto label. Unconditionally branch to the specified line - 35 - label. [%XX,reason] ........ Disconnect caller, log reason. Disconnect the caller from the BBS immediately and write the 'reason' to the GT.LOG file. [%XD,nnn] ........... Adjust the caller's expiration date. Where 'nnn' is the number of days from today to set the expiration date. For example, 365 would set the expiration date to a year from today. [%LV,x] ............. Adjust caller's access level. Change the caller's access level to the value of 'x', where 'x' can be any legal access level. [%LP,n,label] ....... Loop back to label. This command allows the previous question to be repeated. This is very handy for cases where the caller's response appears incorrect or unacceptable. The 'n' specifies how many times the question is to be asked --- the [%LP command will fall through after asking the question 'n' times. A good time to [%XX the caller <GRIN>. [%LG,text] .......... Log command. The "text" is written to the GT.LOG file. The "text" can be plain text or one of these special variables: %nn ...... Log the answer to question 'nn', where 'nn' is a number from 1-50. [%LG,%23] Log the answer to question 23. %PR ...... Log the answer to the previous question. [%LG,%PR] [%LG,Anything you want here!] Writes the string "Anything you want here!" to the GT.LOG file. [%JB,xxx] .......... Join message board. - 36 - This command allows the sysop to join a caller to a message board. Where "xxx" is th board name taken from the group header line, '.' in column 1, in the GTMDIR.BBS file. Answer labels ------------- Prior to version 17.06, one of the biggest problems that I've had with questionnaires is that there has been no easy way to identify the answers, without some way to cross-reference with the questionnaire. Answer labels can be added to the questionnaire by making an addition to the prompt line. For example: [---] Are you are sysop? This question has no answer label. The answer is recorded in the ANSWERn.BBS file as entered by the caller. But now, let's add an answer label: [---] Are you are sysop? [%SYSOP] Now, the caller's answer will be recorded with the label "SYSOP". The answer file might look something like this: AGE : 12 SYSOP : no BBS_PHON: 602-897-9549 VOICE_PH: 602-897-9557 The "answer label" is recorded in the first 8 columns, the caller's answers are recorded in column 11 and afterwards. The "answer label" should not be confused with the "line label" discussed above. The line label is not recorded in the answer file, but is used to control the branching within a questionnaire program. Sample Questionnaire -------------------- [%DT] NEW USER QUESTIONNAIRE :ASK_AGE [---] How old are you? [%AGE] [%IF,N,1-18=MINOR] [%IF,N,19-70=ADULT] - 37 - Really! That is too old!! [%LP,3,ASK_AGE] [%GO,DUMP] :ADULT You are an adult. [%GO,ASK_SYS] :MINOR You are a minor. :ASK_SYS [---] Are you a sysop? [%SYSOP] [%IF,X,Y=SYSOP] [%IF,X,N=REGULAR] [%LP,3,ASK_SYS] :DUMP Sorry! You gotta go... [%XX,DUMB BELL SYNDROME] [%GO,FINAL] :REGULAR You aren't a sysop. [%GO,FINAL] :SYSOP You are a sysop! [%LV,A] :FINAL --------------------------- End of Sample Questionnaire PQUESTn.BBS This file is displayed for the caller immediately after he selects the questionaire he wishes to complete from the questionnaire menu. It should explain to the caller the basic purpose of the questionaire and allow him to consider if he wishes to continue to fill out the questionaire. Immediately after this file is displayed, the caller will receive a prompt, asking if he wishes to continue and fill out the questionaire. The PQUESTn.BBS file is optional. - 38 - GTQMENU.BBS This file is listed for the caller when he selects the (Q)uestionnaire option from the main menu. It is a menu file that should contain a list (in text format) for the user to choose which questionnaire he wishes to complete. For example: 1. Order form for GT POWER. 2. Order form for Turbo CALC. 3. User poll. This shows only three options, as many as 99 questionnaires may be supported by the system. PROTOCOL.BBS This file contains the protocol menu that will be displayed for the caller if he initiates a file transfer. It is provided so that the Sysop can customize this menu to his own taste. It is pure text format, except for the first line, which contains the list of protocols the Sysop wishes to activate for his system. The format of this activation line is as follows: ;XYZB1TWKMSGA Where the ";" appears in column 1 of the line. Each letter activates a specific protocol. For example: X ... Xmodem Y ... Ymodem Z ... Zmodem B ... Ymodem Batch 1 ... 1k Telink T ... Telink W ... WXmodem K ... Kermit A ... MegaLink M ... Super MegaLink S ... SEAlink G ... Ymodem-G By omitting the activation letter from this line, the Sysop may disable the corresponding protocol. For example: ;XYZT Would activate and allow on the Xmodem, Ymodem, Zmodem and Telink protocols. The other protocols would not be allowed. The PROTOCOL.BBS file is optional, if omitted GT POWER will display a canned protocol menu. GT_VSCAN.BAT This is a batch file that should be setup for the - 39 - virus scan of uploads. The GT_VSCAN.BAT will be executed, like a door, if it exists in the GTPATH, after a caller completes an upload. The names of the uploaded files will be passed to the batch file in a log file called GT_RECV.LOG. The format of this log file is very simple: (a) full pathnames are used, (b) a single filename per line, (c) entries begin in column 1, and (d) no other information is present in the GT_RECV.LOG. GT POWER will not automatically erase or create the GT_RECV.LOG, so that it may be used in a cumulative manner (so the virus scan can be run later -- after logoff or whenever the Sysop wishes). To get things started, the Sysop must create an empty GT_RECV.LOG, the following DOS command works nicely: rem >C:\GTLOGS\GT_RECV.LOG This creates a 0 byte file to get things started. Once the log is created, GT POWER will append the uploaded filenames to the file after each upload. After GT_VSCAN.BAT runs, GT POWER does not automatically erase the GT_RECV.LOG, so the Sysop must add the commands to GT_VSCAN.BAT to clear the file after the scan has been done. Again, the DOS 'rem' command works well: rem >C:\GTLOGS\GT_RECV.LOG NOTE: the GT_RECV.LOG must be located in the GT POWER LOG PATH (which may or may not be the same as the GTPATH). The LOG PATH is set by the Sysop under the Alt-I, Pathnames selection. If the Sysop wishes to scan the files later, sometime after the caller has logged off, the GT_VSCAN.BAT file should not be created, instead the virus scanning logic should be placed in the GTLOGOFF.BAT (or wherever the Sysop desires), but remember to clear the GT_RECV.LOG after the virus scan has been done, otherwise the GT_RECV.LOG will continue to accumulate. For example, the virus scan could be done during daily or weekly maintenance runs, because full pathnames are recorded in the GT_RECV.LOG file (as long as you don't move the files someplace else, before the scan has a chance to run <GRIN>). IMPORTANT: GT POWER does not automatically create the GT_RECV.LOG. The Sysop must create it to begin with, using the DOS 'rem' command, as shown above. If the Sysop forgets to do this, GT POWER will not record anything in the GT_RECV.LOG! - 40 - GT_PIGGY.BAT This batch file is executed after every download, and upload -- if GT_VSCAN.BAT is not invoked. If you are using the GT_VSCAN.BAT, then the "piggy" logic should be included in the GT_VSCAN.BAT. GT POWER will create a file to be processed by the "piggy" batch file, it is called GT_XMIT.LST and will be placed in the GTPATH directory. The format of this file is: 0000000352 G Sam Spade 0000000117 0 0 0 C:\BBS\AREA1\CBGREET.BBS The 2nd line will be repeated for each file transfered. The column layout of the first line is: Col. 1-10 Seek address of the caller's record in the USER.CTL file. 11,13 These columns are blank. 12 The caller's access level. 14-43 The caller's name. The rest of the lines in the file define the transfer session that just finished: Col. 1-10 The file size in bytes. 11,13,15,17 These columns are blank. 12 The rx/tx flag: 0=download 1=upload 2=aborted 3=QWK mail 4=DIZ upload 14 CDROM flag: 0=regular disk 1=CDROM disk 16 Freebie flag: 0=regular 1=freebie 18 Complete pathname of the file. The "piggy" bat is designed to be a hook used by 3rd party authors to use to implement a up/down ratio system. WELCOME.BBS Each message base may have a welcome screen. If present, it resides in the directory with the message - 41 - CTL files and is displayed for the caller as he enters the message base. It is in the nature of a conference welcome screen. The WELCOME.BBS file is optional. MBULLETx.BBS Each message base may have bulletins associated with it. These bulletin files will reside in the directory with the message .CTL files and will be displayed for the caller after the WELCOME.BBS file has been displayed. The bulletin numbers are coordinated with the regular bulletin numbers in the main GT POWER directory, which come from the bulletin numbers on the entries in the GTPASSWD.BBS file. The MBULLETx.BBS files are optional. SYSOP.BBS The SYSOP.BBS file contains almost all of the prompts and short menus used by the host mode. They may be customized to suit the sysop's taste. But there is a danger in changing the file too greatly, the overall length of each entry should not be greatly changed, and each entry is limited to 1 line. In addition, when new GT POWER releases are made, it may be difficult to transfer the custom changes to the new file. There are some special lines in the SYSOP.BBS file. The 1st line of the file is the welcome to chat mode, it can be customized to let the caller know who they are chatting with. The 3rd line of the file can have the name of the sysop replace the word 'Sysop'. This will allow GT POWER to personalize messages left to the sysop. On line 158, the minimum length of passwords required by the host mode is configurable. The minimum length may be set anywhere from 0 through 9 characters. This is accomplished by changing line 158 in SYSOP.BBS to reflect the desired width. For example: "Password is too short[!] Must be [6] - [20] characters." GT POWER scans this line looking for the very first number. In this case, GT POWER would find the number 6, and that would become the minimum length for passwords. On line 214 of the SYSOP.BBS file are more special lines. First, the <Alt -_> and <Alt =+> time increment can be customized. If a caller is online, the sysop can increment his time limit by a small amount, use <Alt -_> to decrease the available time or <Alt =+> to increase the available time. The amount of the increment is shown on a line near the end of the SYSOP.BBS file that begins like this: - 42 - "\n\n3 minute change. The number following the "\n\n" is the amount of the change. It can be any number from 1 to 9 minutes. A little farther down, on line 216 in the SYSOP.BBS file, is a line that looks like this: ".ZIP .LZH .ARC .ARJ .GIF .EXE" This line contains the default extensions that are used to satisfy download requests. Each extension must be separated from the one before by a single space, and each extension must begin with a '.' character. This line can be changed or added to, if need be, but there should probably be no more than 8 defaults listed, otherwise system performance may degrade. Father down, on lines 219 and 220, are two lines that look like this: "MENU=" "MMENU=" These lines may be modified to add items to the menus used in the GT POWER host mode. The MENU= line is used to add items to the main menu and MMENU= is used to add items to the message menu. Each item that is added must have a two character invokation sequence. For example: "MENU=[XX]batname;Q;Enter filename:" 'XX' is the command selection character (i.e. what the caller will need to type to execute this command). 'batname' is the name of the batch file that will be executed. The 'Q' is the minimum access level required before a caller can select this menu option, and the 'Enter filename:' is a prompt for data that will be passed to the batch file. For example: "MENU=[XX]batname;Q;Enter filename:;[MR]modread;Z" The access level and prompt for data are optional, but they may not be skipped over. That is, if you have specified a prompt for data, you must also have an access level specified. Several commands can be added in the manner shown above to each of these two lines in SYSOP.BBS, MENU= and MMENU=, but one must be carefull not to extend the lines past 255 characters in length. - 43 - The interface to the batch files invoked by these items is similar to the command interface for door batch file. As follows: Param Description ----- ----------- 1 The CTTY or REM indicator. 2 The COM port number. 3 The prompted for data. The last param, #3, is optional, of course. And, for items on the MMENU= list, GT automatically adds the following four parameters: 4 -Ppathname, where 'pathname' is the path to the currently active message base. 5 The message number previously read by the caller. 6 Access control switch block, where a 0=false and 1=true: a. Netmail message area. b. Public message area. c. Private message area. d. Read-only message area. 7 Netmail credits available to this caller. For example: medit CTTY 1 foobar -PC:\GT\MSGB1 103 0100 200 Where: medit ......... The name of the batch file from the MMENU= line in SYSOP.BBS CTTY .......... The caller is coming in remote 1 ............. on COM port #1. foobar ........ Data given by caller in response to the prompt (optional). -PC:\GT\MSGB1 . The currently active message base. 103 ........... The previous message read by caller. 0100 .......... Access control switch block: 0: Not netmail area. 1: Public messages only. 0: Not for private messages only. 0: Not a read-only message base. 200 ........... This caller has 200 netmail credits. On line 354 of the SYSOP.BBS file is the Caller Id Token. This line needs to be changed to a value appropriate for your modem. The default " = " works with Rockwell chipset modems, such as the SupraFAXmodem. I believe that the value ": " will work for the ZyXEL modems. - 44 - To make the Caller Id option work, the BBS must be using a modem that supports Caller Id reporting. The modem must be setup to report the Caller Id information in plain ASCII text -- not the hex format. And, of course, your phone company must have the Caller Id feature enabled on your phone line. The following command is proper for use with a SupraFAXmodem that has the Caller Id feature: AT#CID=1 GT POWER looks for the Caller Id information to be reported between the first and second RING, so /R2 should be used on the GT POWER command line, to force GT POWER to answer on the second ring. The Caller Id Token is used to distinguish the other result codes from the Caller Id information. The token must be on each line of the Caller Id report. The Supra modem puts " = " on each line, like this: RING DATE = 0419 TIME = 1726 NMBR = 6028979549 NAME = MEINERS RING This is captured text from testing I did with my Supra modem. The Caller Id information is recorded in two places: a. The GT.LOG file. b. A file named CALLER.ID -- stored in the GTPATH directory. The information is recorded exactly as reported by the modem. On line 355 of the SYSOP.BBS file is the Fax Token. It should be changed to a value appropriate for your modem, if you want GT POWER to passoff to a backend Fax program. If GT POWER is waiting for a call in host mode and detects a modem result code containing the Fax Token, then GT POWER will execute the batch file GT_FAX.BAT. I've been told that the ZyXEL modems can be set to CLASS=6 and then handle this sort of passoff from a frontend BBS program. I've also been told that modems based on the Rockwell chipset can also be used for this purpose when used with a 3rd - 45 - party fax program called BGFAX -- available from the larger GT POWER file boards. SCHEDULE.BBS The "scheduler" is code within the GT POWER host mode which allows the sysop to schedule events. The format of the SCHEDULE.BBS file is very simple. The file is composed of lines that begin with a time or range of times, then the command to be executed at the specified time. The entries in this file for the schedule must be in strict ascending numerical order. Notice the entry below for '24:50', in GT POWER's terminology this is 50 minutes past midnight. Under GT POWER you must choose whether you wish to use 24 or 0 as the hour after midnight. The hour between midnight and 1 a.m. is either the 24th hour or the 0th hour, in any case - remember, the schedule must appear in strict ascending numerical sequence, and one should never mix references to hour 24 and hour 0 in the same schedule. Examples: 03:00 copy file1 file2 03:30 QUIT 5 04:00-05:00 QUIT 6 06:00 maint 24:50 QUIT 8 Based on the above example, at 3 a.m. the GT POWER host will copy file1 to file2 (any DOS command can be executed like this). Then at 3:30 a.m. the GT POWER host will quit execution and set an ERRORLEVEL of 5, the runstream that is controlling GT POWER must be prepared to deal with this ERRORLEVEL, else nothing will be done. Also the user must insure that the GT POWER host is restarted. At any time between 4 a.m. and 5 a.m. the GT host will quit execution and an ERRORLEVEL of 6 -- this one is meant to illustrate a quit to the netmail function, which should always be started with a range of times, so that in case it cannot start exactly on the button of 4 a.m. the GT POWER host will start it, even if it is late starting. Again the runstream that is controlling GT POWER must be prepared to deal with the indicated ERRORLEVEL, 6 in this case, and must restart the GT POWER host *after* 5 a.m. Then at 6 a.m. the GT POWER host will execute the 'maint' batch file. Please note, it is possible that an event may be run more than once, if it finishes the first run prior to the end time of the range. For example, the 3rd event above is shown running 03:00-04:00, if the first time through finishes before 5 a.m., then it will start again (over and over again, until 5 a.m. is finally - 46 - reached). So the sysop must select the range of times with care. Wider ranges better insure that events aren't missed, narrower ranges make it easier to avoid multiple runs of the same event. A sysop may also add a special line to the SCHEDULE.BBS file which will allow control of the (P)age function from the main menu. The OFFICE command allows the sysop to specify when a (P)age will be acceptable. If a (P)age is attempted outside of the specified time range, then the caller will be notified about the sysop's OFFICE HOURS. Here is the format: OFFICE=08:00-21:00 The hours may be given in 24:00 or 00:00 notation, but again, DO NOT mix the two styles, i.e. 00:00-24:00 would be INCORRECT. But 00:00-23:59 would be the right way - or 01:00-24:59 would also be correct. Please notice that leading zeros must be supplied. 08:00 is correct, 8:00 is wrong! No embedded spaces are allowed in this format. It must be as shown above. +----------------------------------------------------------+ | | | NOTE | | | | Five minutes prior to a external event, GT POWER | | will cease accepting calls and wait for the event | | start time. Callers who call in the vicinity of | | an event will have their time on the system cutback | | so that the caller will be off the system before | | the event is to start. | | | | | +----------------------------------------------------------+ TRASHCAN.BBS This file will test your creativity <GRIN>. All the dirty words go in here, and then anyone, who uses one of them in their name, will not be allowed to enter your system. The words in the TRASHCAN.BBS must be in _lowercase_, otherwise they won't be recognized. A special wildcard character can be used in TRASHCAN words, the '?' character can be used to match *any* character other than a blank. The blank is treated as a delimiter between first and last names, and each name is checked against the trashcan individually. The check is only performed on new callers to your system, so it doesn't slow the regular logon. And use of the trashcan is optional. Just leave it out, if you don't want to use it. An example TRASHCAN.BBS file: - 47 - d?mn h?ll scr?w f?ck sh?t FILES.BBS When you create a directory to contain files, either for upload or download, you should include within the directory a file named FILES.BBS. It should contain the descriptions of the files contained within the directory. When the caller selects the "F" option from the main menu, the content of this file will be displayed. The FILES.BBS that is located in the appropriate upload directory will be updated automatically with information supplied by the uploader as follows: Position Description -------- ----------- 1-12 Filename 13 Blank 14-21 File size in bytes 22-23 Blank 24-31 File upload date 32-33 Blank 34-41 File creation date 42 Offline indicator: '*' means offline 43 Blank 44-78 The name of the caller who uploaded the file. Following this header line will come up to 10 lines of description. Each line of description will begin with a '|' as the first non-blank character (i.e. not equal to hex 20). The format of the description may be changed by the sysop from the default used by GT POWER, the only rule is that the first non-blank (i.e. not equal to hex 20) must be the '|', otherwise GT POWER will treat the line as a header or a comment. A header is a line that begins with a non-blank character, i.e. not equal to hex 20 (except for description lines, detailed above). A comment line is any other line that begins with a blank, hex 20. NOTE: a hex 20 is a blank, a character whose decimal ASCII value is 32. UPLOADS.BBS As uploads are received GT POWER will record their descriptions in an additional place (in addition to the normal FILES.BBS). That new place is a special file, created in the GTPATH or in the LAN Path (if running on a LAN system), named UPLOADS.BBS. This file will contain a LIFO list that records the uploads - 48 - in the reverse order in which they were uploaded. NOTE: the UPLOADS.BBS file must initially be created by the sysop. GT POWER will only update this file once created by the sysop. When you first look at this file, it appears much like a normal FILES.BBS, but it _IS NOT_. The first difference is seen on the very first line of the file. The first line contains a semi-colon followed by a number, like this: ;200 The semi-colon should appear in column 1 of the line. The number tells GT POWER how many files you wish to keep listed in the UPLOADS.BBS. When the file has more than the desired number, GT POWER will drop off the oldest files. The 2nd difference between the UPLOADS.BBS and a regular FILES.BBS is the presence of a security specifier for _EACH_ file entry. That specifier appears before the filename... for example: A FOO.BAR 1024 01-20-93 01-15-93 | This is the description | for FOO.BAR. It is a tasty file. =J CREAM.PUF 10240 01-19-93 01-15-93 | This is the description of CREAM.PUF | It will be seen only by 'J' level callers. The 'A' and the '=' should be in the first position of the line. Because of the security placed on each file in UPLOADS.BBS, regular comments in this file should be placed only as a header at the top of the file... because comment lines do not have security associated with them (everyone will see the comments, but the associated files may not be visible). The description lines are associated with their files, and have the same security assigned to them (unlike comments). It is anticipated that the sysop might want to manually add files to the UPLOADS.BBS... but normally, automatic maintenance of the file will be performed by GT POWER. A new main menu command has been implemented to list these uploads for the caller... the LU command, Latest Uploads. The LU command checks the security level for each file individually, before listing it for the caller, insuring that only files downloadable by the caller are shown. - 49 - As new uploads are received, GT POWER must create a temporary file in the GTPATH (even on LAN systems), so that the UPLOADS.BBS file may be updated. If the system crashes during an update cycle, the temporary file may remain leftover in the GTPATH. It may be erased---be sure you have a good UPLOADS.BBS file before erasing the temporary file, as it may be your only backup. The filename is GT$TMP00 (where the '00' is the pid number for the node where the file is located. GT POWER attempts to handle conflicts created by simultaneous uploads on multiple nodes at the same time, but it is possible that things will get rather slow, if very many nodes process upload descriptions at the very same moment. RECENT.BBS This file will contain a list of recent callers to the BBS. The list is kept in reverse order, i.e. the latest callers are at the top of the list and oldest callers are at the end of the list. The first line of RECENT.BBS must specify the number of callers you want kept on the list. It defaults to the most recent 50 callers. Here is what the first line should look like: ;50 The ';' must appear in column 1 of the line, the number following is the desired length of the list... in this case 50 callers. On LAN systems, the RECENT.BBS is kept in the LAN Path, but the work file RC$TMP00, is placed in the GTPATH directory. The '00' is the pid number of the updating node. The work file will normally be removed automatically, but in case of a system crash it may remain cataloged. It may be erased, if desired. If you wish to make the RECENT.BBS visible to callers, you will need to make it available via a bulletin or other screen. The ^F, file include feature, is useful for this purpose. - 50 - Host Mode Control Files and Directories --------------------------------------- During the operation of the GT POWER host mode, several files and directories will be created automatically. The SYSOP.EXE and DELREN.EXE program must be used to maintain these files, when the need arises. Here is an overview of the purpose of these files: MESSAGE.CTL This file contains the header information for all messages maintained by the GT POWER host. Such information as sender name, addressee name, date of entry and whether or not the message has been received, are kept here. Each message base has one of these files associated with it. USER_MSG.CTL This file contains information about the messages which have been read by each caller who has joined a message base. Each message base has one of these files associated with it. USER_MSG.IDX The index file for the USER_MSG.CTL file. Speeds access to individual caller records. Each message base has one of these files associated with it. USER.CTL This file contains information about the callers to your GT POWER host. Such as their name, where they are calling from and their personal passwords and access level. This file is stored in the GTPATH direcotry (or the LAN Path, if you are using the LAN setup). USER.IDX The index file for the USER.CTL file. Speeds access to individual caller records. FILES.CTL This file contains information about all the files on the system that are available for download. It is built by the FILES_DB.EXE program (the FILES_DB program must be run to build a new FILES.CTL whenever you move files around on the system. The presence of this file enables the universal download feature and helps to eliminate duplicate uploads (that is, GT POWER will lookup filenames in this database prior to allowing an upload from a caller - if you already have the file, the upload will not be allowed to continue). FILES.IDX The index file for the FILES.CTL file. Speeds access to individual file records. Even on very large BBS systems, access to the files database is accomplished in less than a second or two. GTMSGS This is a sub-directory where the text of the messages is stored. The GTMSGS sub-directory is built automatically by GT POWER. Each message is stored without header information, which is stored in the - 51 - MESSAGE.CTL file. The messages are stored in files with an extension of .MES. Each .MES file contains 10 messages within it. As follows: 00001.MES Contains messages #1 through #10 00002.MES Contains messages #11 through #20 ...etc... The messages are stored in plain ASCII text format. Each message begins with a 'start of message' indicator with the following format: Col 1 = Ctrl-X 2-4 = 'SOM' 5 = '0' through '9', depending of the relative position of the message within the file. Within 00001.MES, message #2 would have a header of ^XSOM1, where ^X is the symbol for Ctrl-X. In 00002.MES, messages #12 would have a header of ^XSOM1 --- the same as message #2 in 00001.MES. This scheme allows for the possibility of a "rapid" renumbering. That is, the internal numbers in the header lines are relative, not absolute. Changing the name of the MES file, i.e. from 00002.MES to 00001.MES, automatically would renumber the messages contained within. Except for the files database (FILES.CTL and .IDX) these files will be created as necessary by the GT POWER host. The SYSOP.EXE and DELREN.EXE programs will perform needed maintenance of these files: for example renumbering the messages, deleting obsolete users, providing reports and listings. HOWEVER, do not run SYSOP.EXE prior to establishing these files. For batch usage, DELREN.EXE is provided to delete and renumber messages - the command syntax for DELREN can be obtained by executing the program with any parameters. - 52 - Running Host Mode ----------------- Once installed, the host mode is fairly self-explanatory, but here is a quick once over. Host mode is started by pressing "ALT -". GT POWER will automatically enter "Half duplex" mode. This is so that anything typed on the host console will echo so that it can be seen. Then GT POWER will send the Host Mode Modem Init String to the modem and wait for a call. While GT POWER is waiting for a call, there are 4 commands available: [Esc], which will terminate host mode, carriage return, which allows the Sysop to logon to GT POWER's host mode from the local console, [Ctrl÷L], which turns on the system printer for logging, and [Ctrl-S] to load a fresh copy of the schedule from disk (useful for folks who edit the schedule from a 2nd window under DESQview or Windows). Note that you should have logging enabled in the GT POWER configuration, via Alt-I, the [Ctrl-L] command merely enables the printer, so that whatever is logged will also appear on the system printer. There also is a command line option to turn on the log printer. If you place "/p" on the GT command line, the printing of the log will automatically be turned on from the very start of the program. Once GT has answered an incoming call, there are several commands available to the operator, as follows: +--------------------------------------------------------------------+ | | | SYSOP COMMANDS | | | | Alt-H List available sysop commands. | | | | Ctrl-D List current schedule on the screen. | | Ctrl-L Toggle log printer on/off. | | Ctrl-N Raise caller's access level while on-line. | | Ctrl-P Sysop initiated chat mode. | | Ctrl-R Reset time limit, gives caller more time. | | Ctrl-S Load new schedule from disk. | | Ctrl-T Terminate after current caller disconnects. | | Ctrl-X Abort the caller. | | Ctrl-Z Terminate chat mode. | | Alt -_ Decrement the time available to caller. | | Alt =+ Increment the time available to caller. | | | +--------------------------------------------------------------------+ Command Line Usage ------------------ When you start GT POWER, there are several command line switches that are available to you: name You may indicate a script file to be executed upon start-up of GT POWER. - 53 - /AI Causes GT POWER to issue the ATA command to the modem immediately and answer the call ringing in when GT POWER was started. This is useful if you have a frontend Fax program that can tell the difference between distinctive ring patterns (indicating DATA vs FAX call), and pass off data calls to a backend BBS program. /BV Force the BIOS Video setting to be equal TRUE. This overrides any BIOS Video setting in the GT POWER configuration file, and is intended to help users with speech synthesizers. /D You may indicate whether or not you wish to have GT POWER drop the DTR signal to the modem when GT POWER exits back to DOS. /C You may indicate whether you are connected via cable to the host computer. /F This gives GT POWER a "frontend" type interface. If you run a "frontend" program like Binkley, you can use this command line option with GT. The /F takes two sub-params, like this: /F:nnnnn:m Where: nnnnn ...... The DCE baud rate. m .......... The COM port number. For example: /F:2400:1 2400 baud on COM port 1. When the caller logs off the system (or drops carrier), GT will execute an exit to DOS with an ERRORLEVEL 254 or 255. You should insure that the batch file traps these ERRORLEVELs and returns control to the "frontend" program. See documentation that comes with the "frontend" program for further details. /K You may initiate the capture mode from the very start of the program. It is normally not wise to use the /K option, or capture mode, during host mode operations. Capture mode should never be left enabled when the sysop is not present. /M Suppress the "Check for personal mail?" function. /MN This would allow the "Check for personal mail?" function to continue, *but* would change the default prompt from [Y/n] - 54 - to [y/N]. /P You may enable logging to the system printer. /PE You may specify the pre-event wait interval, and whether you want the phone to go offhook during the wait. By default, GT POWER uses a 5 minute pre-event wait and leaves the phone onhook. An example of this parameter is: /PE03:OFF Which would set the pre-event wait to 3 minutes, and take the phone offhook during that interval. /PE07 This sets the pre-event wait to 7 minutes, but leaves the phone onhook, the default state. NOTE: the events mentioned above are those scheduled via the SCHEDULE.BBS file. Please see the explanation of the schedule elsewhere in this document. /S This option will allow the Sysop Page to be heard during quiet mode. Normally, nothing would be heard during quiet mode. /Tn This option will override the normal keyboard timeout value of 10 minutes. When this timeout occurs, GT will disconnect the caller. For example: /T5 Lower the timeout to 5 minutes. /T45 Raise the timeout to 45 minutes (my favorite). /1 You may configure the port addresses in use by your serial port. The actual port number to be configured, 1-8, is placed after the slash. The new base address of the indicated port is placed after the slash number with an intervening blank. The address must be given with a leading $ sign and be in hex notation, for example $3F1 would be a valid address. Refer to your hardware documentation for the correct address to use. GT uses standard addresses if you do not override with this option. GT POWER allows you to also configure the IRQ used. To specify the IRQ, simply follow the port address with a ':n', where the 'n' is the new IRQ to be used. The IRQ must be in the range '0' to '15'. Be sure that the IRQ is not being used by any other device! IRQs above 7 are only available on AT class machines (and above). /Rn This option applies to the GT POWER host mode. It specifies the ring number upon which GT POWER will answer incoming calls. For example /R3 would cause GT POWER to answer on - 55 - the 3rd ring. NOTE: that the host mode modem init string must contain S0=0 to allow this to work properly. /RBmm:nn This option applies to the GT POWER host mode. It specifies that GT should answer the modem after a "ring back". To enable this to work properly, the host mode modem init string must contain S0=0. Once installed properly this option makes the GT POWER host mode answer the phone on the 2nd or 3rd ring after a gap of between 'mm' and 'nn' seconds. If the gap between rings is less than 'mm' seconds or greater than 'nn' seconds, GT POWER will not answer the phone. This allows the use of an answering machine on the same phone line as the computer. The answering machine should be programmed to answer on a later ring, the 4th for example. The 'mm:nn' is optional, and will default to a 9 to 32 second gap. /W On LAN systems, this option will force GT POWER to perform "whereis" style lookup to find files for download. Normally on LANs, this rather time consuming search is not done. HOST.BAT File ------------- c: cd \gt set GTPATH=c:\gt GT1800 host.scr HOST.SCR File ------------- host +------------------------------------------------------------------+ | | | This listing of command line switches came from the main GT | | documentation file. Please refer to that document for sample | | usage of these switches. | | | +------------------------------------------------------------------+ Message Entry Editor -------------------- While entering a message, full screen editing is possible. The (E)dit command is available from the message entry sub-menu for those who prefer line editing. But starting with version 17.00, the caller can simply arrow to a mistake and correct it. The arrow keys are active for this purpose anytime during the message entry process, even when sitting at a "More?" or at the message entry sub-menu. The [Ins], [Del], [Home] and [End] keys are programmed to help navigate within a line, once positioned to the line via arrow keys: [Ins] .... Toggles between overwrite and push right modes. [Del] .... Deletes the character under the cursor. [Home] ... Moves cursor to the start of the line. - 56 - [End] .... Moves cursor to the end of the line. Some terminal packages may not be able to take advantage of this feature, as their special keys don't send the necessary escape sequences. The codes that GT sends for these keys are listed in an appendix to the GT1800.DOC file, under "ANSI Emulation - Transmitted Characters". NOTE: when navigating with the up and down arrows, GT POWER will skip over some lines. This is normal. GT POWER will not position the cursor to any line whose on screen image differs from the memory image that GT has of it. Such things as [Tab] characters and/or escape sequences embedded in the text can cause this problem. Setting Expiration Dates For Callers ------------------------------------ Concerning expiration dates (introduced with version 17.00), the Sysop can specify a warning interval. This is under Alt-I, the Miscellaneous Options, at the very bottom, #19. When a caller is within the warning interval of the expiration date, the caller will receive a warning that the expiration date is near and the file XWARNING.BBS will be displayed for them. When a caller's account has expired, GT POWER will notify him of that fact and will display the file EXPIRED.BBS. Also GT POWER will automatically lower the caller's access level to 'z' (lowercase z) -- actually the expired access level is configurable under Alt-I, the Miscellaneous Options, #20. It would be extremely wise if the Sysop has a CLASS entry for the expired access level in the GTPASSWD.BBS file. In the event that no CLASS entry is located, GT POWER will give the caller default access (which is almost never desirable). Also, the default message base and file area must have low enough access, otherwise the expired callers will see pathnames instead of descriptions atop your main menu. Expiration dates can be set via the SYSOP.EXE program. Using a LAN with GT ------------------- Running a multi-node BBS with GT POWER is easy. GT POWER will allow up to 32 nodes on a network to share common message bases and file areas. The first thing you must do is decide on a structure for your network BBS. One of the systems must be identified as the 'server' and will be referred to as "PID Zero" in the following description (however, you can easily have multiple servers). The LAN Path must point to a location on the server where all the caller records are stored, and where the "PID_FILE.BBS" is maintained automatically by GT POWER. Once you have decided on the structure of the network, you must install GT POWER on each node --- part of the installation process for GT POWER on a LAN node is setting the LAN parameters under the Alt-I configuration. Three pieces of information must be provided for each node: - 57 - PID Number ... Must be a unique number between 0 and 31. PID Name ..... The name by which this node is known to the network software, each node should have a unique PID Name. LAN Path ..... This must be the home directory for GT POWER on the network server. The LAN Path will contain the USER.CTL, USER.IDX and PID_FILE.BBS (at the least). These are created automatically. It is assumed that these files will be shared among the other systems on the LAN. The LAN Path must be specified to get file and message sharing fully enabled. Without a LAN Path, GT POWER will assume that a non-sharing environment is established (like a regular single node BBS). File sharing is implemented using the record locking facilities of DOS 3.1+ SHARE.EXE. It is recommended that you give this program adequate facilities to do its job. This command line seems to work well, but more resources may need to be allocated on busy systems: SHARE /F:7168 /L:70 It should also be noted, that some LANs require your CONFIG.SYS parameters to be changed. For example FCBS may need to be specified on LAN servers, for example: FCBS=24,12 And STACKS are very important under a LAN enviroment. If you are using DOS 3.2, I would recommend switching to DOS 3.3. With DOS 3.3, I would recommend: STACKS=62,512 DOS 3.2 has some bugs that do not make it a good choice for the DOS on the LAN server. It has also been observed that BUFFERS are critical on a LAN. Setting BUFFERS above 40 is a sure formula for a crash. I recommend: BUFFERS=35 If this response of the server becomes to slow, due to the low setting of BUFFERS, rather than raising the BUFFERS, I would suggest that you obtain a LAN compatible disk cache program. Ask your LAN manufacturer to recommend one to you. Finally, resist the temptation to overload the directory indicated as the LAN Path. For example, do not have the workstations use that directory for the log files. This would result in chaos. Each workstation must have its own GTPATH and LOG Path. Often times it is extremely handy to have a common pathname to reach - 58 - directories on the network. For this reason, the DOS SUBST command is very useful. With it, you can assign a common pathname to shared disk space on servers. For example: SUBST e: c:\ Would allow the server to use drive E: to make reference to 'c:\', as the workstations probably do. Thus E: becomes a common path to drive C: across the whole network. The CB Simulator is an online conferencing feature that is intended for use on multi-node LAN based BBS systems (a NetBIOS emulator is required). The CB Simulator checks for the presence of NetBIOS before allowing callers to get stuck in the CB mode. Locally, when the host mode enters the CB Simulator, split screen mode is automatically invoked. You should advise callers to manually invoke split screen mode on their terminals -- otherwise they will not see what they type (remember, split screen is half-duplex, the host mode will not echo the caller's keystrokes during CB Simulator operations). When using the CB Simulator, please make sure that you have allocated adequate NCBs. I have setup the following command for my NetBIOS startup: lanbios irq=5 address=2 ncbs=35 sessions=15 I am not sure if 35 NCBs are enough, but it seems to work fairly well on a 3 node LAN. On the server, if it is not dedicated, you should insure that the server can manage sufficient simultaneous tasks - my server was set for 2 simultaneous tasks, but I now have it setup for 5. This does consume memory, to be sure, each extra task requires considerable buffer space, but it is required for the CB Simulator to work alongside the other network tasks. The following files must be created by the sysop, if the CB Simulator, command (Z) from the main menu, is going to be used: CBWELCOM.BBS ...... Welcomes callers to the CB Simulator. CBHELP.BBS ........ Displayed in response to '@help' by the caller. CBPAGE.BBS ........ Displayed to a caller who receives an '@page' from another caller. CBGREET.BBS ....... Displayed for the caller after entering his handle. The file should be short and to the point, i.e. introduce the automatic '@who" list and tell the caller how to get help. The following commands are available to callers in the CB Simulator: @help ........ Display the CBHELP.BBS file. @ignore ...... Ignore further pages from other callers. - 59 - @page ........ Invite another caller, by handle, into CB mode. Ex: @page foxy Where 'foxy' is the handle of the caller you are paging. The handle is obtained from the '@who' list. @quit ........ Quit from CB Simulator to the main BBS menu. @tune ........ Tune the CB Simulator to channels 1 through 98. Ex: @tune 5 @who ......... Find out who else in on the system and which channel, if any, they are tuned to. @sys ......... For sysops only. Allows broadcast messages or messages directed to specific pids. Ex: @sys 5 Hello Mike! Ex: @sys The system is going down in 5 minutes! The first example sends a message to pid 5, where Mike is logged on. The second example sends a broadcast message, to all pids, telling them that the system is about to go down. Please note, that these pids do not have to be in the CB Simulator to get the message. These messages will interrupt most things, except file transfers. NOTE: A pid corresponds to a "position" or "workstation" on the LAN. The CB Simulator uses the NetBIOS Datagram feature to pass the messages between pids on the LAN. The Datagrams are sent to the group name 'GT_POWER_CB_SIM" (the 16th byte is 0x00). GT registers this group name whenever the host mode is started under NetBIOS in a LAN environment. The Datagrams used by GT are of a fixed format, as follows (for those of you that want to try their hand at NetBIOS programming): Byte Offset Description ----------- ----------- 0 'S' for special messages, such as '@sys'. 'C' for normal CB Simulator messages. 1-2 The channel number the message is addressed to. Channels 1-98 are the normal CB channels. Channel 99 is used for broadcast messages. 3-4 The originating pid number. This is used to keep a pid from processing messages that he originates. Datagrams are received by *all* LAN stations having registered the group name 'GT_POWER_CB_SIM'. 5-6 Transaction code: '00' - Normal message. All 'C' type datagrams. '01' - Who inquiry. 'S' type datagram. '02' - Who reply. " " " '03' - Page inquiry. " " " The transaction codes '01' and '02' are now obsolete, since the @who command uses the PID_FILE to get its information. Transaction code numbers up to '50' are reserved for future expansion. It is anticipated that '04' will be used for remote submission of DOS commands, and '05' will be used - 60 - to remotely shutdown all pids. 7 Unused. Reserved. 8 ','. Constant. 9-16 The sender's handle. If no handle, then the first name of the sender. 17 ','. Constant. 18-127 Text. In a page transaction, this is the handle of the caller being paged. In other transactions, this may be blank or contain a regular message. It is variable length, only the amount of data required is transmitted, up to the maximum of 128 bytes. - 61 - Host Mode LOG ------------- A few sections above, I suggested that logging be TRUE, while GT POWER is running in Host Mode. Here is why: during Host Mode operations, GT POWER will log all of the calls received, who called and the password used. A record will also be kept of who tranfered each file, how long it took and the efficiency of the transfer. I consider the gathering of this information to be critical to the operation of a GT POWER Host. If you have ample hard disk space, I would recommend that the logging option be set to the DETAIL setting. This will allow many things not previously logged to be tracked. It does take a lot of disk space very rapidly though. - 62 - File Tagging ------------ Files may be tagged, whenever the caller lists files, using the (F)ile describe, (W)hereis, (I)nquire or (L)ist commands. The option to tag a file for later download is offerred via two methods: (a) the arrow keys and the carriage return (or spacebar) can be used to navigate the screen and mark the desired files, or (b) if the caller's terminal program is unable to handle the full screen movement, a (F)ilename option is offerred to add files to the Tag List. The edit tag list command, [ET] from the main menu, can be used to add or subtract files from the tag list. The caller is shown the estimated download time for each file, as well as for the complete list. Naturally, if more than 1 file is tagged, the caller must use a protocol capable of batch transfers (otherwise, only the first file in the tag list will be transferred). When the caller starts the download, if he has too many files tagged, the [ET] command will automatically start, so that the caller has the opportunity to prune the list. If the caller begins to logoff the board while files remain untransferred on the tag list, a warning will be displayed and the caller will be asked if he wishes to continue to logoff. As explained above, if the caller logs off, while untransferred files remain on the tag list, a warning will be displayed. The warning message is stored in the TAGWARN.BBS file. - 63 - Binary Message Upload --------------------- It is possible for a caller to prepare a message offline and then to upload the message to a GT POWER message base, after he logs onto your board. The binary message upload facility has been implemented using the internal protocols. To use the feature, the caller begins entering a message, in the normal manner, but hits [Enter] on the first empty line, where the upload is to begin, then selects (U)pload from the message entry submenu. Non-batch protocols, such as Xmodem and Ymodem are recommended for this purpose. The host will not ask for a filename, since the message is stored in a temporary file until the upload is finished. After the upload has completed, the uploaded message is tested for text and/or graphics and rejected if found to be improper for inclusion in a message base. If the message is okay, it is appended to any text that was entered prior to the upload. The uploaded message can contain any sort of ANSI graphics and may contain line lengths up to 255 characters (including the CR/LF pair at the end of each line). This procedure is a great improvement over the standard ASCII transmit that has been used to upload messages, because the binary protocols include effective error correction procedures. ASCII transmit suffers from slowness and noisy lines. - 64 - QWK Mail -------- The QWK Mail format is in wide use by offline mail readers and for networking. GT POWER implements the QWK format as described in the document, "QWK Mail Packet File Layout" by Patrick Y. Lee, version 1.3, July 6, 1992. Some things have not been implemented (yet), while some features implemented are unique to GT POWER -- for example the way GT POWER implements its tagline via the GTQUOTES.BBS file. To setup the QWK Mail feature, several things must be done. a. A file named QWKSKEL.BBS must be created and placed into the GTPATH or LAN PATH directories. A sample is shown below: The P&M Test System Phoenix, AZ (602) 897-9557 <owner name>, Sysop <serial number>,GTHOME <packet date>,<packet time> <caller name> 0 <message count> <conference count> <conference list> GTWELCOM.BBS GTBULLET.BBS GTBYE.BBS This is a skeleton of the QWK CONTROL.DAT file. The items within <...> should be left _as is_, GT POWER will fill in the required information. The <...> are there as placeholders. Line 1 has the name of the BBS. Line 2 has the city-state of the BBS. Line 3 has the phone number of the BBS. All these things should be filled in, as appropriate. On line 5, there appears the BBSID after the ','. This should be 8 characters that identify your board -- the characters should be suitable for usage as a filename, so avoid unnecessary control or special characters. On the last 3 lines of this file, you will find the names of the "HELLO" file, the "NEWS" file and the "LOGOFF" file. The sysop may vary the names that appear here, as appropriate for his setup. QWK Mail cannot be processed, if this file is incorrectly setup or not setup at all. Here is a sample QWKSKEL file in use on my system here: The P&M Test System Phoenix, AZ (602) 897-9557 - 65 - <owner name>, Sysop <serial number>,GTTSTSYS <packet date>,<packet time> <caller name> 0 <message count> <conference count> <conference list> GTWELCOM.BBS GTBULLET.BBS GTBYE.BBS b. A file named GTQUOTES.BBS should be available in the GTPATH or the LAN PATH. GT POWER will use this file to pull up quotes for inclusion on the tagline in the reply messages. Here is an example: 0000000000~ The gods play games with men as balls. -Titus Maccius Platus He was a wise man who invented God. -Plato Plato is a bore. -Nietzsche The information on the first line should not normally be changed, it provides GT POWER with information on the previously used quotation so that new ones can be used in their turn. If you make a lot of changes to this file, you should probably zero out the line, as showed above. But since this line acts like a "placeholder", the format requires 10 zeros followed by a '~' character. There should be at least a couple of quotations in this file. Each quotation is limited to 64 characters, if you wish it to appear normally in the message. There may be any number of quotations in the file -- as you have disk available. GT POWER will use them sequentially, and return to the top of the file, after all have been used. c. The SYSOP.BBS has numerous new lines pertaining to the handling of QWK Mail. They are near the end of the file. For example, at line number 314 you will find the following line: "M=200,C=50/100,TM=2000,K=1000" This line specifies, in order: M= the maximum number of messages per conference to be put into the QWK packet. C= the maximum number of conferences with messages/total to be put into the QWK packet. The example above shows 50/100, which means up to 50 conferences with messages, up to a maximum of 100 conferences scanned. - 66 - TM= the maximum number of messages to put into the QWK packet. K= the maximum size of the MESSAGES.DAT file in kilobytes. This is prior to compression! In the example above, 1000k is allowed, which would probably compress down to a packet of around 500k... roughly speaking. The K, M and TM values on this line are not used directly, but are changed proportionately according to the caller's DCE baud rate. If the caller is at 9600 baud, then the values will be used as is. If the caller is below 9600 baud, the values will be lowered proportionately. For example, if the caller is at 2400 baud, the values will be divided by 4, at 1200 baud they will be divided by 8, etc. If the caller is above 9600 baud, these values will be raised proportionately. For example, if the caller is at 19200, the values will be doubled. At 14,400 the values will be multiplied by 1.5. Another important entry in SYSOP.BBS for QWK Mail is line number 310. This line contains the command used to compress the QWK packet. It comes setup for use with PKZIP, as that is the most common compression program used. But you may change this... depending on the capabilities of your callers. Be sure, if you change it, to use the "move" option... note the "÷m" used with PKZIP. d. QWK Mail processing requires authorization, a caller must either be the sysop or have the 'QK' permission listed for the access level in use. In addition, any caller that uploads a REP packet must have 'UL' or the upload permission. e. QWK transactions now have their own Time Bank values. The TB= permission has been expanded to allow for two more values, as follows: uk uf dk df me mr mk qk rp dl wl TB=01/02/03/04/03/01/50/01/01:060/600 The new values are shown above under the 'qk' and 'rp' headings. They represent the number of credits to be deposited per 100 messages processed. The 'qk' value is for D/L'ed messages, and the 'rp' value is for U/L'ed messages. f. The 'QK' main menu command brings up a sub-menu for the caller. From the sub-menu, the caller can choose to download a QWK or upload a REP. Network commands may also be executed from the QK menu. If a QWK download is selected, all joined areas are scanned and processed, up to the limits described above. Following the packing, the download is started immediately... using the protocol of the callers choice. If the caller refuses to select a protocol, Zmodem is selected by default. - 67 - The a QWK sub-menu is called GTQWK.BBS (which may also have a .CBS version). It is like any other screen file. g. The sysop has a command to himself, 'RP', which unpacks a 'REP' packet that has been placed in the QWK directory. This is a sysop only command. The QWK directory is named GT$QWK00, the '00' is the pid number, so there may be up to 32 such directories. They are placed under the GTPATH directory. GT POWER places QWK packets here after they have been created. And rep packets are placed here for GT POWER to unpack. The QWK directory may be made available to callers via the GTDIR.BBS or GTUDIR.BBS, but that is optional and up to the local sysop. The QWK work directory can now be specified via an environment variable as follows: set GT$QWKnn=f:\foobar\qwktemp The environment variable is customized for each pid, i.e. 'nn' represents the pid number, or '00' for single node systems. The pathname given must be completely specified, and normally should be different on each pid, to avoid share violations. This should allow sysops to place the work directory onto a RAM disk, on the LAN server, or on the workstations... wherever the sysop finds most efficient. h. REP packets are uploaded by callers in the normal manner. Instead of asking for a description, GT POWER will automatically recognize the REP packet, move it to the QWK directory and unpack it, while the caller is watching. ZIP, ARJ and ARC are supported achivers for REP packets. i. The GT POWER QWK feature supports these three control commands: ADD, DROP and RESET. As far as I can tell, these commands operate virtually in a transparent mode with the offline readers I've tried. The commands are put as the topic of a message, addressed to "GTQWK", in the particular conference affected. ADD and DROP are pretty self-explanatory, RESET means to reset the "last read" pointer to zero. The RESET command can take a non-zero argument, i.e. RESET 200, in which case, GT POWER QWK would reset the message pointer to message #200. j. The GTMDIR.BBS must be updated to include the following information for any conference you wish to make available via QWK Mail. Not all conferences need be available! The new information: - 68 - a. Conference number. 0 to 65534, excluding conference numbers 8192 - 8447, which are unusable. b. Conference id. Up to 10 characters, no blanks. Blanks may be included by using the '_', underscore, character, which GT POWER will convert to a blank. For example: .z GENERAL General Board z ~C:\MAIL,10/Netmail Netmail area z ^C:\GOSPA,20/Our_Lady The Messages Of Our Lady z ^D:\IDEAS,30/Beta_Ideas Save Ideas From Beta Testers Notice that the conference number and id code follow the pathname with a comma between. And a '/' separates the number and the id. Any conference without a conference number will be omitted from the QWK packet processing. And naturally, the normal security is enforced, so conferences will be skipped automatically, if they wouldn't normally be seen during normal message processing. k. Packing QWK Mail takes a bunch of memory. So make sure that you have _at least_ 200k available when GT POWER is loaded. If not, then adjust the GTVBUF to make more available. REP processing uses even more memory than packing QWK packets --- so you risk loss of REP packets if insufficient memory is available. The more conferences you have, the more memory you need. GT POWER has no specific limitations on the number of conferences that can be processed, but it takes about 80 bytes of overhead for each conference you have in the QWK Mail setup. If you had 1,000 conferences in the setup, then that would require an extra 80k of memory! Over and above your normal memory require-ments. Which could be as high as 70k for REP processing! l. To send netmail messages from a QWK packet, simply put the following as the first line of the messages: ;nm:1/33 Naturally, the ';' would appear in column 1, and the appropriate net/node number should be used. 1/33 is my net/node number, used for demonstration purposes. m. The Net Status, NS, permission has been added. This permission works with a new BBS file, QWKTRASH.BBS. When GT POWER receives an REP packet or an imported QWK packet, the message sender's name will be matched against the names found in the QWKTRASH.BBS file. If a match is made, the message will be discarded. If the QWKTRASH.BBS file contains a line that reads: =STRICT - 69 - with the '=' beginning in the first position of the line, then all messages must be from the caller himself, unless the caller has Net Status permission. All names in the QWKTRASH.BBS file must begin in the first position of each line. To recap, any message, which has a sender's name match an entry in the QWKTRASH.BBS file, will be discarded. If the QWKTRASH.BBS file has a '=STRICT' entry, then only messages from the caller himself will be accepted, unless the caller has the Net Status permission. Finally, only 64 lines may be put into the QWKTRASH.BBS file, extra lines are simply ignored. n. QWK networking is also being introduced. Consider the case of a caller who downloads a QWK packet from your board, normally it is fed into an offline reader and only that single individual can read and reply to messages. But what if the caller runs a BBS... if the caller uses GT POWER, then the QWK bag can be imported into the message bases on that BBS, via the main menu (IM) command or the (I) command on the QWK menu. To use these commands, import or export, requires the IM or EX permission in the GTPASSWD.BBS file (the sysop gets these implicitly). To accomplish an import or export operation, requires that the appropriate .IMP file be available in the GTPATH directory. Here if the format: Filename: GTHOME.IMP -------------------- Import Local Conf# Conf# ------ ----- 0052 -> 1052 ;Trading Post 0057 -> 1200 ;Shareware The information starts in column 1, it is indented here for readability only. Only lines that begin with a number are processed, all others are considered commentary. The first column of numbers (may be 5 digits, if required) represents the incoming conference numbers, the column of numbers following the arrow, "->", are your local conference numbers. The incoming QWK packet may have many many conferences, but only the ones listed in the .IMP file will be imported (or exported). The filename you choose for the .IMP file is very important, because the main part of the name, before the '.', must match the BBSID of the incoming QWK packet. The incoming packet has the BBSID stored internally in the CONTROL.DAT file. When the replies are exported, GT POWER will ask for the BBSID - 70 - to use with the export operation, it must match-up with an .IMP filename, as GT POWER will only export the files listed in an .IMP file. Here is a graphic representation of what is going on: +--------------+ | Host BBS | BBSID = GTHOME +--------------+ / \ +-------------+ +-------------+ | D/L QWK PKT | | U/L REP PKT | +-------------+ +-------------+ | | | /|\ \|/ | =============|==========================|============ | | | | | | +-----------------+ +-----------------+ | Import QWK PKT | | Export REP PKT | +-----------------+ +-----------------+ \ / +--------------+ | Client BBS | +--------------+ GTHOME.IMP file required on the client system. Filename must match BBSID of QWK host. GTHOME, in this example. When importing or exporting qwk/rep packets, GT POWER will scan the related .IMP file and pickup any line beginning with 'TAG=' as the tagline to be added to the messages, instead of getting entries from the quotes file. The information following the '=' will be used, as is, on the tagline (of course, GT POWER will still prepend its signature)... which will include 'GTnet', instead of the plain 'GT' put on regular QWK messages. The information after the TAG= will be truncated to fit, if necessary. I think there is room for 63 characters... Please note, for those having trouble with .IMP file formatting, the conference numbers _must_ begin in column 1 of each line where they appear. Do not indent them with white space. I have seen several examples of folks using IMP files with the conference numbers indented up to 10 or 15 spaces... and this is incorrect format. o. The old message pointers for each QWK downloader are stored in a subdirectory called QWKSAVE under the GTPATH, or LAN Path on LAN systems. The QWKSAVE subdirectory will now save PTR files for each - 71 - caller, so that the message pointers can be quickly and easily recovered, should something happen to the previously downloaded QWK packet. This is done via the (E) command from the QWK menu. The pointer files are deleted automatically as soon as the caller uploads a REP packet, or whenever the next QWK packet is downloaded. p. Redirection of the PKZIP output, when creating a QWK packet, is optional via a GT POWER command line argument: /QR. Without the /QR, GT POWER will inhibit the redirection... with the /QR, the output of PKZIP will be redirected to the remote caller. Thus some systems that can't handle DOS redirection to the COM port are now allowed for. - 72 - The Shell to DOS ---------------- The DOS Shell allows remote callers to operate your computer remotely. When the "Shell to DOS" option of the main menu is selected, GT POWER will shell to the file GTDOOR.BAT. This file will set up for the remote shell by executing the proper CTTY command, then execute a secondary DOS shell and let the user into the system. He will have the console, so be cautious! The caller will be instructed to issue the "EXIT" command to return to GT. While the DOS Shell is active and the caller is out in the system, GT POWER will not be idle. GT POWER will act as a watchdog. If the caller should hang up while the DOS shell is active, GT POWER will force the system to reboot and will drop the DTR signal to the modem. If commands to start GT POWER are placed in the AUTOEXEC.BAT file and a script is used to start Host Mode, then GT POWER will automatically recycle. The script command to start Host Mode is simply HOST. In order to get the DOS Shell to work, the GT1800.EXE and GT1800.OVL file must be available in the GTPATH directory (and the GTPATH directory should probably be in the DOS PATH statement in the AUTOEXEC.BAT file). NOTE: For this process to work correctly, the COMMAND.COM file must reside in a directory pointed to by the PATH environment variable. In order for this to work on a normal drive C: hard disk, "C:\" should be added to the PATH variable. For example: PATH=c:\dos;c:\lotus;c:\gt;c:\ This will ensure that the proper COMMAND.COM file can be located for execution by the GTDOOR.BAT runstream. A problem with the DOS Shell has been reported when using DOS 2.xx. This is caused by the fact that DOS 2.xx does not support full pathnames when requesting the execution of a program. To work around this problem, if you have DOS 2.xx, you should place the GTDOOR.BAT file in some other directory besides the GT POWER home directory. If GT POWER finds GTDOOR.BAT in his home directory, then GT POWER will issue an EXEC function with full pathname, otherwise GT POWER will not specify any pathname and will rely on the DOS PATH command. The directory where GTDOOR.BAT is stored must be pointed to by the DOS PATH command in this case. - 73 - Using the Shell to DOS ---------------------- What can be done, once one is running DOS remote via a CTTY command? Well, one can't use any of the Fn keys or the other special keys on the IBM keyboard! One can't run any program that does direct hardware control of the screen or keyboard. All screen and keyboard input must be done through DOS. Well, then what can one do? One can run any DOS command; for example COPY, ERASE, DIR and others, including EDLIN, all work properly. In fact, any program that uses the standard DOS handles for input and output to the console will work. But one still won't have F1 - F10 or the other special keys. Well, that's not quite so...if the Host Mode computer is setup so that the ANSI.SYS device driver is loaded via the CONFIG.SYS file. Just put a line like this one into the CONFIG.SYS file: DEVICE=ANSI.SYS Naturally, ANSI.SYS must be located in the root directory of the boot disk. After that has been done, reboot the computer. ANSI.SYS will then be loaded. One can now remap the keyboard so that the special keys are mapped to Ctrl keys instead. This will enable programs to be run that use these keys; for example EDLIN uses the arrow keys as well as several function keys. How does one remap keys with ANSI.SYS? The following sequence must be issued for each key that needs to be re-mapped: ESC [ ##;##;##;...p The (...) indicate that the sequence may be repeated as needed, but each sequence only remaps one key. Once a file containing these mapping commands has been created, they can be sent to ANSI.SYS by TYPEing the file. The "##" in the sequence above indicate the ASCII codes for the keys to be mapped. For example, let's map F3 to the Ctrl-D key. The ASCII codes for F3 are 0,61 and the ASCII code for Ctrl-D is 4. (Note: the special keys have two codes - the first is always 0. These codes are really called extended ASCII codes.) Therefore, the proper ANSI.SYS command to remap F3 to Ctrl-D would be: ESC [ 4;0;61p Note: Blanks are included for readability only, the "p" must be lowercase, and the symbol ESC stands for the escape character, ASCII 27. - 74 - Usage of Color -------------- The GT POWER Host mode now includes color built-in to the various prompts and menus. These colors can be configured. The colors used are of two different sets. The first set is composed of the colors for the "Window foreground and background", and the "Phone directory high lite foreground and background". These colors should be subdued, since they are used for normal informational type displays. For important command line and menu displays, the program will use the colors designated for "Option high lite" and "Option low lite". The user can customize the sysop prompt with these colors, by including the color codes in the SYSOP.BBS file. Here is the code scheme: % ...... Used to kill the meaning of the next character. %% ...... Used to display the % character. $ ...... Shift the pallette to the "Window foreground / background" set. & ...... Shift the pallette to the "Option high/low lite" set (the default). [] ...... High lites whatever is between the [ and ]. ~ ...... Kills the color. Goes back to standard B&W image. For example: $ [SYSOP] John~ here. This would shift pallette to the "Window foreground/background" set, high lite the word "SYSOP" and kill the color after the name "John". Actually, this scheme was only intended to add color to the SYSOP.BBS file and other built-in menus and prompts, but some have already discovered that these colors can be added to the GTMDIR.BBS and GTDIR.BBS files, to add color and emphasis. Logon DOOR ---------- In the GT POWER home directory, it is possible to create a DOOR file, with a special name, that will be executed whenever a user logs onto your system. The file is named 'GTLOGON.BAT' and it is constructed in the same manner as a normal DOOR batch file (shown above). For example: GTLOGON.BAT ----------- %1 com%2 . . { Logon door executes here } %1 con The sequence of events goes like this after a user calls your system: 1. The GTWELCOM.BBS is displayed. - 75 - 2. Then any BULLETx.BBS is displayed. 3. Then the GTBMENU.BBS is displayed. 4. Then the GTLOGON.BAT is executed, if available. It is possible to have a special logon door for new callers. It is named 'GTNLOGON.BAT'. It will execute in place of the regular logon door. If you want both to execute, then you must chain from the new caller logon door to the regular logon door. GTNLOGON.BAT ------------ %1 com%2 . . { New user logon door executes here } . %1 con GTLOGON { Chain to regular logon } The 'BPLOGON.BAT' file will be executed as a logon door for callers that have the BP authorization, if the caller answers 'y' to the bypass prompt. Please note, if the BO authorization is given, the BPLOGON.BAT will not execute. In other words, the 'BPLOGON.BAT' replaces the 'GTLOGON.BAT', when it is skipped. Logoff Batch File ----------------- It is, also, possible to have a logoff batch file, 'GTLOGOFF.BAT', in the GT POWER home directory. This is not a DOOR, but simply a batch file that GT POWER will run, if it is available, whenever a user has disconnected from your system. It may contain any normal DOS command or other processing as required. It can be useful for sysops that want to backup their files if they are using a RAM disk for things like the log file. Please note, this is not a DOOR, CTTY is not redirected, and that the 'watchdog' is not enabled during the execution of this batch file. In addition, when you have a new caller to your system, GT POWER will run, if available, a batch file called 'GTNLOGOF.BAT'. Again, if you wish to run both GTNLOGOF.BAT and GTLOGOF.BAT, then you must chain to the reguler logoff door (if you have one). For example: GTNLOGOF.BAT ------------ . { No DOS redirection in logoff doors } . . { New user logoff door executes here } . GTLOGOFF { Chain to regular logoff, if overlaying } - 76 - APPENDIX -------- Here is a handy list of extended ASCII codes: Key Codes Key Codes --- ----- --- ----- F1 0,59 Right Arrow 0,77 F2 0,60 Left Arrow 0,75 F3 0,61 Up Arrow 0,72 F4 0,62 Down Arrow 0,80 F5 0,63 Home 0,71 F6 0,64 End 0,79 F7 0,65 PgUp 0,73 F8 0,66 PgDn 0,81 F9 0,67 Ins 0,82 F10 0,68 Del 0,83 Here are some sample ANSI sequences! Escape Codes Meaning to ANSI.SYS ------------ ------------------- ^[[4;0;61p F3 -> Ctrl-D ^[[5;0;62p F4 -> Ctrl-E ^[[19;0;77p Right Arrow -> Ctrl-S ^[[1;0;75p Left Arrow -> Ctrl-A With these kinds of mappings, almost any program should be able to run, if it uses the DOS handles for standard input and output. This should make the "Shell to DOS" quite useful. - 77 - Setup for Power-Loss Protected Operation ---------------------------------------- It is quite easy to prepare a set of files that will allow you to bring GT POWER up into what I should like to call a Power-Loss Protected Host Mode of operation. First, however, a few concepts: Whenever power is first applied to your system, (or reapplied following a blackout), the system will boot your DOS into memory and that, in turn, will look for two files; CONFIG.SYS and AUTOEXEC.BAT. Finding the CONFIG.SYS, the DOS will tailor your environment according to its contents (such as setting a new maximum number of files and file buffers). Finding the AUTOEXEC.BAT file will cause the system to immediately execute the set of DOS instructions found therein. GT POWER may be caused to run in an unattended Host mode either through GT POWER commands entered at the keyboard (Alt-dash) or via script. The GT POWER command to do so in a GT POWER script is simply: HOST. The user should have a TSR called DOORMAN loaded if the 'watchdog' function is required during a remote shell to DOS or a remote door activation. DOORMAN will reboot the computer in the event that a caller drops carrier while is the shell or door. Given the above, to set up the system for Power-Loss_Protected Host mode operation of GT POWER you must construct the following files: Your normal AUTOEXEC.BAT A copy of the normal AUTOEXEC.BAT called AUTOEXEC.ORG A new file called AUTOEXEC.GT A new file called HOST.BAT A GT script file called HOST.SCR The first four of these files belong in your root directory while the script file should be placed in the same directory as GT POWER resides (or in the Script path, if one is configured). When you want to enter the Power-Loss-Protected Host mode of GT POWER you need only type the single word HOST from any directory. The result will be the invoking of the HOST.BAT file which, in turn, copies the AUTOEXEC.GT file on top of your normal AUTOEXEC.BAT (so that if a reboot occurs it will get control), it then sets a default directory so that your private directories are not accessible to callers into the system, and then it invokes GT POWER specifying the name and location of the HOST.SCR script file you created. Thus, GT POWER will be given control and placed into Host mode. Upon normal termination, GT POWER exits to DOS which returns to the unexecuted portion of the HOST.BAT file and continues by doing a copy of AUTOEXEC.ORG (a copy of your original AUTOEXEC.BAT) on top of the current one and ending. In the event of a power failure while in Host mode, or loss of carrier while in the DOS Shell, the AUTOEXEC.BAT file that is in place will reset to the default (safe) drive and reinvoke the Host mode of GT POWER POWER. - 78 - Sample Files for Power-Loss Protected Operation ----------------------------------------------- AUTOEXEC.ORG: PATH=C:\DOS;C:\;C:\GT set GTPATH=C:\GT AUTOEXEC.GT: PATH=C:\DOS;C:\;C:\GT set GTPATH=C:\GT host HOST.BAT: c: cd \ copy autoexec.gt autoexec.bat cd \gt gt1800 host.scr cd \ copy autoexec.org autoexec.bat HOST.SCR: host - 79 - GT POWER under DESQview(tm) --------------------------- GT POWER runs quite well as a task under the DESQview(tm) multi- tasking system. There are a few things that should be kept in mind when doing so, however. GT POWER will auto-detect DESQview, and if you have told BIOS Video = FALSE, then GT POWER writes directly to the DESQview screen buffer (greatly speeding the screen update process). This may adversely affect DESQview aware programs run in a shell of GT POWER, since they may not properly tell DESQview which portions of the screen to update. If you run into this problem, tell GT POWER that BIOS Video = TRUE. This will cause screen updates to be slower, but the shell programs will work better. GT POWER will automatically give up unused time to DESQview, so that programs running in other windows are not severely impacted while GT POWER is idle. Also, you will need to provide enough memory for GT POWER to run while under DESQview(tm). If you do not have to consider KERMIT or ZMODEM then you can run GT POWER in a partition of as small as 360K of RAM. Experimentation has shown that in order to support ZMODEM and the other protocols mentioned above you will need to set the partition size to 460K. GT POWER, as it requires rapid access to the serial port you are using for communications must be the first task loaded in DESQview(tm). And, a performance option of DESQview(tm) (set by invoking the SETUP program) must be set showing the existence of High Speed Communications. Other options that need to be set include the fact that GT POWER is NOT SWAPPABLE to disk and time slices somewhere between 3 and 6 ticks in length per partition. Also, it would be best to tell DESQview not to virtualize the screen output while GT POWER is active. This will help in making screen output as rapid as possible. (tm) DESQview is the trademark of QuarterDeck Office Systems. - THE END - - 80 -