Maximus System Operations Manual Version 3.0 Lanius Corporation Lanius Corporation, Kingston, Ontario, Canada Copyright (c) 1989, 1995 by Lanius Corporation. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system without the prior written permission of Lanius Corporation. Maximus and Squish are trademarks of Lanius Corporation. MS-DOS, Windows, Windows 95 and Windows NT are trademarks of Microsoft Corporation. IBM, PC-DOS and OS/2 are trademarks of International Business Machines Corporation. Hayes is a trademark of Hayes Microcomputer Products, Inc. V.FC is a trademark of Rockwell International. MD5 is a trademark of RSA Data Security, Inc. BNU is a trademark of Unique Computing Pty Ltd. X00 and SIO are trademarks of Raymond L. Gwinn. All other trade names are trademarks of their respective holders. Contents 1. Introduction ............................................1 1.1. About Maximus.......................................1 1.2. System Requirements.................................2 1.3. Typographical Conventions...........................3 1.4. Ordering a Printed Version of this Manual...........4 1.5. Ordering Maximus for Commercial Use.................4 2. Maximus Overview ........................................5 2.1. Waiting for Callers.................................5 2.2. Logging On..........................................5 2.3. Command Stacking....................................6 2.4. Guest Accounts......................................7 2.5. The Main Menu.......................................7 2.6. The Message Section.................................9 2.7. The File Menu......................................21 2.8. The Change Setup Menu..............................25 2.9. The SysOp Menu.....................................28 2.10. The Chat Menu.....................................28 2.11. The Off-Line Reader Menu..........................29 3. Installation ...........................................31 3.1. Step 1: Unpacking the Distribution Files...........31 3.2. Step 2: Running the Installation Program...........32 3.3. Step 3: Configuring your Modem.....................33 3.4. Step 4: Installing Communications Drivers..........34 3.5. Step 5: Editing Configuration Files................37 3.6. Step 6: About Control Files........................39 3.7. Step 7: Compiling the Control Files................40 3.8. Step 8: Starting Maximus...........................40 3.9. Step 9: Support for Remote Callers.................42 3.10. Step 10: Miscellaneous Information................51 4. Customization ..........................................53 4.1. Events and Yelling.................................53 4.2. Access Control: Classes, Privilege Levels and Locks55 4.3. Display Files: *.mec and *.bbs.....................62 4.4. Message Areas and File Areas.......................64 4.5. Maintaining File Areas.............................70 4.6. Barricades and Extended Barricade Files............77 4.7. Menus..............................................79 4.8. QWK Mail Packing...................................81 4.9. Multilingual Support...............................82 5. Maximus Subsystems .....................................85 5.1. Waiting for Callers Subsystem......................85 5.2. Local File Attaches................................86 5.3. QWK Mail Packer....................................88 Contents iv 5.4. RIPscrip Support...................................92 5.5. User Expiration and Subscriptions..................94 5.6. Message Tracking System............................95 6. External Programs .....................................105 6.1. Execution Methods.................................105 6.2. Swapping..........................................106 6.3. Errorlevel Batch Files............................106 6.4. Restarting After Errorlevel Exit..................107 6.5. External Program Translation Characters...........109 6.6. Running Doors.....................................112 6.7. On-Line User Record Modification..................114 6.8. Doors and OS/2....................................115 7. Multinode Operations ..................................117 7.1. Installation......................................118 7.2. Multinode Chat Operation..........................121 7.3. Master Control Program............................123 8. Utility Documentation .................................125 8.1. ACCEM: MECCA Decompiler...........................125 8.2. ANS2BBS/MEC: ANSI to MEC conversion...............126 8.3. CVTUSR: User File Conversions.....................127 8.4. EDITCAL: Call Modification Utility................128 8.5. FB: File Database Compiler........................129 8.6. MAID: Language File Compiler......................132 8.7. MAXPIPE: OS/2 Redirection Utility.................134 8.8. MECCA: Display File Compiler......................135 8.9. MR: Maximus Renumbering Program...................136 8.10. ORACLE: Display File Viewer......................137 8.11. SCANBLD: *.MSG Database Builder..................138 8.12. SILT: Control File Compiler......................141 8.13. SM: Session Monitor..............................142 9. REXX User File Interface ..............................145 9.1. Introduction......................................145 9.2. Function Descriptions.............................146 9.3. Accessing "usr." Variables........................153 10. Introduction to MEX Programming ......................161 10.1. About MEX........................................161 10.2. MEX Road Map.....................................161 10.3. Creating a Sample MEX Program....................162 10.4. Compiling MEX Programs...........................165 10.5. Running MEX Programs.............................166 11. MEX Language Tutorial ................................169 11.1. Program Development Cycle........................169 11.2. Elements of a MEX Program........................171 11.3. Variable Declarations............................174 11.4. Variable Scope...................................178 11.5. Preprocessor.....................................179 11.6. Calculations and Arithmetic......................180 Contents v 11.7. Displaying Output................................185 11.8. Flow Control.....................................187 11.9. Function Calls...................................194 11.10. Arrays..........................................206 11.11. Structures......................................214 11.12. Casts...........................................223 11.13. Further Explorations in MEX.....................225 12. MEX for C and Pascal Programmers .....................227 12.1. Comments.........................................227 12.2. Include Files....................................227 12.3. Blocks...........................................227 12.4. Function Definitions.............................227 12.5. Types............................................229 12.6. Variable Declarations............................229 12.7. Function Prototypes..............................229 12.8. Function Return Values...........................229 12.9. Strings..........................................229 12.10. Compound Statements.............................230 12.11. Arithmetic, Relational and Logical Operators....230 12.12. The for Statement...............................231 12.13. Arrays..........................................231 12.14. Pointers........................................231 12.15. Pass-By-Reference Arguments.....................232 12.16. Variable-Length Arrays..........................232 12.17. Structures......................................232 12.18. Run-Time Library Support........................233 13. Interfacing MEX with Maximus .........................235 13.1. User Information.................................235 13.2. Message Area Information.........................236 13.3. File Area Information............................237 13.4. Changing Message and File Areas..................237 13.5. Displaying Output................................237 13.6. Retrieving Input.................................238 13.7. File I/O.........................................239 13.8. Menu Commands, Displaying Files and External Programs .......................................................239 13.9. Download Queue...................................239 13.10. Other Functions.................................240 14. MEX Compiler Reference ...............................241 14.1. Command Line Format..............................241 14.2. Environment Variables............................242 14.3. Error Messages and Warnings......................242 15. MEX Library Reference ................................251 15.1. Global Variables and Data Structures.............251 15.2. Functions by Category............................262 15.3. Function Descriptions............................272 16. MEX Language Reference ...............................351 16.1. Operator Precedence..............................351 Contents vi 16.2. Language Grammar.................................351 17. MECCA Language Reference .............................355 17.1. Usage Guide......................................355 17.2. Color Token Listing..............................357 17.3. Cursor Control and Video Tokens..................360 17.4. Informational Tokens.............................362 17.5. Questionnaire Token Listing......................366 17.6. Privilege Level Controls.........................368 17.7. Lock and Key Control.............................369 17.8. Conditional and Flow Control Tokens..............370 17.9. Multinode Tokens.................................378 17.10. RIPscrip Graphics...............................379 17.11. Miscellaneous Token Listing.....................381 18. Control File Reference ...............................387 18.1. SILT Directives..................................387 18.2. System Control File..............................387 18.3. Language Control File............................420 18.4. Off-Line Reader Control File.....................421 18.5. Colors Control File..............................422 18.6. Message Area Control File........................424 18.7. File Area Control File...........................430 18.8. Menu Control File................................433 18.9. Access Control File..............................450 18.10. Protocol Control File...........................454 18.11. Event File......................................459 18.12. Language Translation File Reference.............461 Appendices ...............................................463 Appendix A: Common Problems............................463 Appendix B: Error Messages.............................465 Appendix C : Command Line Switches.....................468 Appendix D: Local Keystrokes...........................471 Appendix E: User Editor Keystrokes.....................473 Appendix F: AVATAR Colors..............................474 Appendix G: Sample BAT/CMD Files.......................475 Appendix H: Support Files..............................481 Index ....................................................485 1. Introduction 1.1. About Maximus Maximus is a flexible bulletin board package for the DOS and OS/2 operating systems. Maximus allows remote users to con- nect to the system by modem, read and write messages, par- ticipate in public conference areas, send and receive files, and much more. In addition to the standard message and file features found in most BBS programs, Maximus also includes: * MEX, an extension language that combines the best elements of the C, Pascal and BASIC languages. MEX includes support for advanced language features such as structures, arrays, dynamic strings, and pass-by-reference function arguments. MEX can be used to customize and extend Maximus in an infi- nite number of ways. * MECCA, an easy-to-use scripting language that can be used to colorize screens and add simple menus and prompts to display files. * Support for RIPscrip graphics. Maximus can detect RIPscrip capabilities, automatically size menu output based on the terminal window size, display most internal prompts using RIPscrip graphics, and much more. * Support for SM, a Presentation Manager LAN monitoring tool for OS/2. SM can be used to manipulate and examine multiple Maximus sessions running on remote workstations. * Full support for CD-ROMs and other slow filesystems. Maxi- mus will copy files to a staging area before a transfer and it will only access the drive when absolutely necessary. Areas can also be specifically excluded from new files searches. * A message tracking system for use in technical support en- vironments. Maximus can keep an audit trail of all messages in certain areas, assign "ownership" of messages to indi- viduals, and produce detailed reports regarding the status of various messages. * Support for an unlimited number of message and file areas. Maximus also supports "divisions" for constructing multi- level message and file area hierarchies. 1. Introduction 2 * Support for a REXX user file interface. This interface can be used to read from and write to the Maximus user database from any OS/2-based REXX program. * A powerful message "browse" feature that allows selection of messages based on user-defined search criteria. * A built-in QWK mail subsystem that allows users to read and compose messages while off-line. * Support for the Squish message format, a compact database for storing messages. * Optional support for user password encryption. This feature uses the RSA Data Security, Inc. Message-Digest 5 algorithm as a one-way hash for storing passwords in the user file. * Full multilingual support. The Maximus language file can be customized to support almost any language. Maximus also in- cludes special support for the Swedish 7-bit and the Chi- nese BIG5 character sets. * An internal multinode chat facility, including virtual CB channels and private chatting between two nodes. * An internal full-screen editor for composing messages. * Internal file transfer protocols, including Zmodem, Ymodem- G and other popular protocols. 1.2. System Requirements This chapter describes the minimum hardware requirements for a standard Maximus installation. 1.2.1. MS-DOS or PC-DOS Requirements The minimum system requirements for the DOS version of Maxi- mus are: * an IBM (or 100% compatible) personal computer with at least 450K of available conventional RAM, * MS-DOS or PC-DOS version 3.3 or greater, and * A FOSSIL communications driver (revision level 5 or higher). (Common FOSSIL drivers are X00, BNU and OpusComm.) 1. Introduction 3 1.2.2. OS/2 Requirements The minimum system requirements for the OS/2 version of Maxi- mus are: * an IBM (or 100% compatible) personal computer with at least four megabytes of installed memory, and * one of the following products: * IBM OS/2, Version 2.0, 2.1 or 2.11 * IBM OS/2 Warp, Version 3 or above * IBM OS/2 Warp Connect, Version 3 or above 1.2.3. Common Requirements Regardless of the operating system type, the following hard- ware is also required to run Maximus: * A Hayes-compatible modem, 1200 bps or faster. * A hard disk with at least 15 megabytes of free space. Addi- tional space is required to store the contents of file and message areas. 1.3. Typographical Conventions This document is provided in ASCII form for the convenience of noncommercial users. However, the master version of this document was designed and laid out for the bound version of the Maximus documentation. The content is identical in these two versions of the manual. However, a number of features and styles cannot be correctly translated into the ASCII version of the document. In spe- cific: * The ASCII version of this document includes no lines, bor- ders, boldface, italics, shading, or sidebars. * Indentation, table formatting, and hyphenation may not ap- pear correctly in the ASCII version. * Typographical quotes are replaced with the ASCII equiva- lents. * The ASCII version of the MEX and REXX documentation does not show the sideheads that appear in the printed version of the manual, including the "Prototype," "Arguments," "Return Value," "Description" and "Example" headings. 1. Introduction 4 Please see the printed version of the manual for the official layout and formatting. 1.4. Ordering a Printed Version of this Manual The commercial version of Maximus optionally comes with a printed and bound version of this manual. However, even noncommercial users can order a copy of the manual without purchasing the software itself. The printed manual is 466 pages long, perfect-bound (glued back binding), dimensions 7" by 9", with a black and red cover printed on glossy white card. To order a copy of the manual, please see the "MAXDOC" prod- uct in the ORDER.FRM file (included in the distribution pack- age). 1.5. Ordering Maximus for Commercial Use Maximus is completely free for noncommercial users. Most non- commercial and private users can use Maximus without paying a cent. To determine whether or not you are a commercial user, please see the program license (contained in LICENSE.DOC). However, to use Maximus in a commercial environment, you must obtain a commercial license from Lanius Corporation. For in- formation on ordering a copy of Maximus, please see the order form included in the Maximus distribution archive (called OR- DER.FRM in MAX300C.ZIP). You can also contact Lanius at: FAX: +1-613-634-3058 Post: Lanius Corporation email: sales@lanius.com 777 Downing St. Kingston, Ont. CANADA K7M 5N3 2. Maximus Overview This chapter provides a brief list of the commands and fea- tures supported by Maximus 3.0. This list is by no means com- plete, but it serves as a useful introduction to those System Operators (SysOps) who are unfamiliar with Maximus. 2.1. Waiting for Callers When Maximus is set up to handle remote callers, it enters "Waiting for Caller" (WFC) mode as soon as the system is started. In this mode, Maximus initializes the modem and in- structs it to wait for incoming calls. When a ring is detected, the modem answers the phone. If a connection is successfully established, Maximus waits until the user presses twice, or until five seconds have elapsed, whichever occurs sooner. 2.2. Logging On After a connection is established, Maximus displays the sys- tem name and version, followed by any information that the SysOp has placed in the log-on display file, \max\misc\logo.mec. This screen must not include any graphics commands or high-bit characters, since Maximus has not yet determined the graphics capabilities of the caller. Maximus then prompts the user for a name. Unlike other BBS programs, Maximus allows more than two words in a username, so names such as "John Q. Public" are perfectly acceptable. However, Maximus rejects callers with one-word names unless the Single Word Names feature is enabled. If the user does not exist in the user file, Maximus displays the \max\misc\notfound.mec file. This file normally informs the user that no existing user record with the specified name could be found, and it normally indicates that a new account will be created if the user continues with the log-on proc- ess. Next, Maximus displays a prompt to ensure that the user's name was entered correctly. Given input of "John Doe", Maxi- mus will respond with: John Doe [Y,n]? 2. Maximus Overview 6 If the username was spelled incorrectly, the user can enter "n" and begin the log-on process again. 2.2.1. Log-on Process for Existing Users If the name of an existing user is entered, Maximus prompts the user to enter the password for that user account. The user has up to five tries to enter the correct password. If none of the five attempts are successful, Maximus displays the \max\misc\bad_pwd.mec file. By default, this file allows the user to leave a message to the SysOp before the system hangs up. Once Maximus validates the password entered by the user, it displays the \max\misc\welcome.mec file. This file can con- tain ANSI or RIPscrip graphics to be shown to the user. 2.2.2. Log-On Process for New Users If the user enters the correct password, Maximus validates the user and displays the \max\misc\welcome.mec file. If a non-existent username is entered, Maximus enters the "new user" state. In this state, Maximus first displays the \max\misc\applic.mec file, which normally gives the caller some information about the system. This file can also present an application form to be filled out by the user. Maximus will then prompt for the user's city and state/province, alias, phone number, and a number of other user settings. Lastly, Maximus will display \max\misc\newuser2.mec. This file typically describes the system in more detail. 2.3. Command Stacking Maximus allows the user to stack command responses by enter- ing multiple words at an input prompt. This feature is nor- mally used to expedite the log-on process, but command stack- ing can also be used for most other Maximus commands. Without command stacking, a typical log-on sequence looks like this: What is your name: John Doe John Doe [Y,n]? y Password: ...... 2. Maximus Overview 7 Instead of entering each of these responses separately, all of the responses can be placed on the same line, as shown be- low: What is your name: John Doe;y;password Maximus also supports command line editing at most system prompts. After the user has logged on, and as long as ANSI or AVATAR graphics are enabled, the user can use the cursor keys to edit any of the text on the command line. Editing can be performed using the , , , , , and keys. To use the command line editing feature from remote, the user's terminal program must support either "Doorway mode" or VT-100 keyboard codes. 2.4. Guest Accounts If the SysOp uses the user editor to create an account that has no password, Maximus treats it as a guest account. If a user logs on using a guest account, Maximus automatically skips the password prompt. In addition, Maximus prompts the guest user for a new set of configuration options at the be- ginning of every log-on, including editor preference, graph- ics support, and more. This feature allows the SysOp to specifically create a single account for new users, even if the Logon Level Preregistered feature is enabled. This feature is useful when the SysOp wants potential users to fill out an application form (using the guest account) before granting access to the system. 2.5. The Main Menu After displaying the log-on screens, Maximus also displays the text in the \max\misc\bulletin.mec file. This file typi- cally contains system bulletins or other messages of interest to all users. Following the system bulletins, the user is placed at the main menu. Although Maximus's menus are completely customiza- ble, this section describes the commands that are found on the main menu in the default configuration. Message Section This command takes the user to the message section. The message section is used to participate in public conference 2. Maximus Overview 8 areas and to enter messages to other users. Please see sec- tion 2.6 for more information. File Section This command takes the user to the file section. The file section contains libraries of files that can be downloaded (retrieved). The user can also upload (send) files, search for files of a specific name, and display a file list. Please see section 2.7 for more information. Change Setup This takes the user to the change setup section. This menu allows users to adjust settings in their user profiles. The user can change the screen width and length, select a de- fault file transfer protocol, change telephone numbers, and more. Please see section 2.8 for more information. Goodbye This option logs the user off and hangs up the phone. Even if the user does not log off using this command, Maximus will still update the user's user record. However, this command gives the user the opportunity to leave a comment to the SysOp. Comments to the SysOp are placed in the message area speci- fied by the Comment Area keyword in the system control file. The subject used for the log-off comment can be set in the comment_fr string in the Maximus language file. This string can include external program translation characters. Please see section 6 for more information. Statistics This command displays the user's statistics, including the time of day, the length of the current call, the user's to- tal time for the day, number of kilobytes uploaded and downloaded, and so on. Yell This command allows the user to request a conversation with the SysOp. By default, this command plays a simple tune on the system speaker. (This tune can be configured in the \max\tunes.bbs file.) The local speaker can also be toggled on and off by pressing "!" at the local console while a user is logged on. 2. Maximus Overview 9 OS/2 Maximus can also play yell tunes on a SoundBlaster or only! SoundBlaster-compatible device. Please see section 18.11 for more information. Userlist This command displays the list of all records in the user file. Users can exclude themselves from this list using the "InUserList" command on the Change Setup menu. In addition, the SysOp can modify the access control file to restrict the user list display to a certain set of privilege levels. Version This command displays the Maximus version number and copy- right information. SysOp Menu This command takes the user to the SysOp menu. Normally, only the system operator or a trusted user will have access to this command. Please see section 2.9 for more informa- tion. Chat Menu This command takes the user to the multinode chat menu. This menu allows the user to access all of Maximus's multi- node features, including paging, toggling chat availabil- ity, and private/public chatting. (This command is used ex- clusively to allow users to communicate among themselves. The Yell command is used to chat with the SysOp.) Who is On? This command displays a list of callers who are currently logged onto the system. The Who is On? display includes each user's name, status, and chat availability. At the SysOp's discretion, other options and submenus can be added to the main menu. Please see section 18.8 for more in- formation on adding menu options. 2.6. The Message Section Maximus supports four distinct message area types: local ar- eas, NetMail areas, EchoMail areas, and conference areas. Local areas are used for messages that are local to your BBS. These messages can be public or private, but local messages do not get transmitted to other bulletin boards. 2. Maximus Overview 10 NetMail areas are used for private, point-to-point communica- tion between users on two FidoNet-compatible systems. When entering a message in a NetMail area, Maximus prompts the user for additional addressing information, including the destination address of the message and (optionally) a number of message handling attributes. Maximus also maintains a "NetMail credit" account for each user that can be used when billing users for NetMail usage. Conference areas and EchoMail areas (also known as echoes) are used for public conferences that are distributed among many systems. A message entered in an EchoMail area is broad- cast to all of the systems which carry that conference. To a Maximus user, an EchoMail area appears identical to a local message area, except that messages entered in EchoMail areas have network control information added to the end of the mes- sage. In addition, after a user enters a message in an EchoMail area, Maximus adds the name of that area to the Log EchoMail file. This file can be used later by a scanning pro- gram, such as Squish, to export that message to the rest of the network. In addition to defining the message area type, a number of message area attributes can be assigned to each message area. A complete listing of these attributes can be found in sec- tion 18.6, but some of the more common attributes are given below: Pvt All messages entered in this area will be marked private. Private messages can only be read by the message sender and the addressee. (Users in a privilege level class that has the ShowPvt flag can also read private messages addressed to any user. Typically, these permissions are only granted to the SysOp.) Pub All messages entered in these areas are marked as public. Regardless of the addressee of the message, any user can read a public message. If both the Pvt and Pub attributes are specified, the user can enter either public or private messages. ReadOnly The SysOp can place messages in a read-only area, but nor- mal users are unable to post messages in areas of this type. (Users in a privilege level class that has the WriteRdOnly flag can also post messages in this area.) 2. Maximus Overview 11 Anon When a user enters a message in an area with the Anon at- tribute set, Maximus prompts the user to enter the From: field of the message. (In all other areas, Maximus auto- matically fills in the From: field with the user's real name.) However, Maximus can optionally embed the user's real name within the message such that the SysOp can read it if nec- essary. This option is enabled by default. See the Style NoNameKludge flag in section 18.6 for more information. Attach Message areas with this attribute allow users to attach files to messages created in the area. Please see the de- scription of the Enter Message command in section 2.6 for more information. Also see section 5.2 for information on local file attaches. The SysOp can also assign passwords to message and file ar- eas, enable message tracking, add support for high-bit char- acters, and more. Access to individual message areas can also be granted based on a user's privilege level or name. Please see section 18.6 for more information. 2.6.1. The Message Menu This section describes the commands that are found on the standard message menu: Area Change This command allows the user to select another message area. The user can select an area by name, but the "[" and "]" keys can be used to select the message areas which pre- cede or follow the current area, respectively. The "?" character displays a list of areas. For navigating within a hierarchical area structure, the "/" key moves to the top-level menu, and the ".." sequence ascends one level in the menu tree. Next This command displays the next message in the current area. After displaying a message with the Next command, pressing at the message area prompt automatically displays the next message. 2. Maximus Overview 12 Previous This command displays the prior message in the current area. After displaying a message with the Prior command, pressing at the message area prompt will automati- cally display the prior message. Enter a Message This command allows a user to enter (post) a message in the current message area. Maximus first prompts the user to fill out the message header, including the To field, the Subject field, and the message attributes. For users who have ANSI, AVATAR or RIPscrip graphics en- abled, Maximus displays a message header with fields that can be filled out by the user. The and keys can be used to move between fields, as can the and keys. If the message area definition permits both public and pri- vate messages, Maximus allows the user to select either type of message. For users who have graphics enabled, the private flag can be toggled by pressing when the cursor is on the attributes field (above the message date) The P key also has the same effect. In areas which support file attachments, a file can be at- tached to a message by pressing the A key while the cursor is on the attributes field. (Maximus will prompt the user to upload the file after the message has been created.) In Local areas, the user can obtain the system user list by pressing ? at the To prompt. Maximus normally generates this list automatically from the system user file, but if a \max\misc\userlist.mec file exists, Maximus will display it instead of the real user list. In NetMail areas, the attributes field can also be used to select other mail handling options. Entering a ? at the at- tribute prompt gives a complete list of keys. In addition, NetMail areas also allow the user to select the destination address for the message. After entering the message header information, Maximus will run the system editor and allow the user to enter the body of the message. 2. Maximus Overview 13 Change a Message This command allows the user to modify an existing message. Although the SysOp can modify any message on the system, a normal user can only modify messages which: * have not been read by the recipient, * have not been sent (in the case of NetMail or EchoMail), and * have the user's name in the From field. Both the message header and the message body can be modi- fied. When graphics are enabled, the user can also modify the message attributes. Reply to Message This command allows the user to enter a response to the currently-selected message. The Reply command is similar to the Enter command; however, Maximus will automatically fill out the fields in the message header when doing a Reply. In addition, Maximus will also adjust the message reply chain so that the new message is marked as a reply to the origi- nal message. Within the message editor, the user can also quote (copy) text from the original message into the newly-created re- ply. Read Non-Stop This command displays a number of messages all at once, with no pauses or prompts between messages. If the user last selected the Next command, Maximus displays all mes- sages from the current message to the last message in the area. Otherwise, if the user last selected the Prior com- mand, Maximus displays all messages from the current mes- sage to the first message in the area (in reverse order). Read Original This command examines the current message and finds the original message in the reply thread. (If the current mes- sage was a reply to another message, this command displays that other message.) Messages that are replies to other messages have a "*** This is a reply to #msg" line at the bottom of the message or a "- msg" field in the message header. 2. Maximus Overview 14 Read Reply This command displays the message which is a reply to the current message, if any. Messages which have replies have a "*** See also #msg" line at the bottom of the message or a "+ msg" field in the message header. Read Current This command redisplays the current message. Browse This command scans any or all of the message areas on the system and retrieves selected messages. Browse acts as a powerful database engine for the message bases. Users can select a set of messages and operations to perform, and then have Maximus automatically identify and display the messages that were requested. The first browse menu prompts the user to select a set of message areas. The user can select any of: * the current area, * all message areas, * all tagged message areas, * a wildcard specification (such as "comp.lang.*"), or * the current group (all areas which are on the same level in the message area hierarchy) The second browse menu prompts the user to select a type of message. The user can specify: * all messages, * new messages (those which are above the user's lastread pointer), * your messages (unread messages which are addressed to the user and which are above the user's lastread pointer), and * from a certain message number (such as from message 500 to the end of the area). Maximus also allows the user to perform a search based on keywords in the To, From and Subject fields, in addition to searching the message body. Complex searches can be defined by combining the logical or and and operators. The third and final browse menu prompts the user to specify an operation to perform on the selected messages. Messages can be: * listed (one to a line, with to/from/subject only), 2. Maximus Overview 15 * read (displayed in full, with the option to reply or kill each message), or * packed (compressed into a QWK packet for download and off-line mail reading). Tag This command allows users to select a subset of the message areas on the system. Each user can select his or her own set of personal message areas. This area selection is used to control the areas scanned by the Browse command and the off-line message reader. Edit User This command reads in the current message, checks the From field, invokes the system user editor, and automatically positions the user editor on that user's user record. This option is useful for validating users, since a user's user record can be displayed at the press of a key. (This com- mand is normally only available to SysOps.) To invoke the user editor without seeking to a specific user, instead use the User Edit command from the SysOp menu. Goodbye This option logs the user off and hangs up the phone. Even if the user does not log off using this command, Maximus will still update the user's user record. However, this command gives the user the opportunity to leave a comment to the SysOp. Comments to the SysOp are placed in the message area speci- fied by the Comment Area keyword in the system control file. The subject used for the log-off comment can be set in the comment_fr string in the Maximus language file. This string can include external program translation characters. Please see section 6 for more information. Main Menu This command returns the user to the main menu. Kill a Message This command allows the user to delete a message from the current area. A normal user can only delete messages which contain that user's name in either the To or the From field 2. Maximus Overview 16 of the message to be deleted. However, the SysOp can delete any message on the system. Upload a Message This command allows the user to directly upload a text file as a message. This command is identical to the Enter com- mand, except that Maximus prompts the user to start a file transfer protocol instead of invoking one of the system editors. Forward This command allows the user to copy a message in the cur- rent area and send it to someone else. Maximus prompts the user to enter the message number to be forwarded and the name of the addressee. The user can also forward the message directly into another area by typing the area number when prompted. The Forward command also supports two special modifiers: * Entering FK from the message area menu instructs Maximus to delete the original message after it has been for- warded. * Entering FB from the message area menu instructs Maximus to send a "bombing run." Maximus prompts the user to specify a local filename that contains a list of message addressees. (In order to use this command, the user's privilege level must be equal to the level required to create a message from a file, as defined by the Message Edit Ask FromFile keyword in the system control file.) The format of each line of the bombing run file is as follows: [-x] The and [-x] fields are only used for NetMail messages and should be omitted for local bombing runs. -x can be one of the switches shown below in Table 2.1: Table 2.1 Bombing Run Options Switch Description -h The message should be marked as "hold for pickup." -c The message should be marked as "crash." 2. Maximus Overview 17 -n The message should sent normally (default) In the username field, spaces in a user's name must be represented by underscores. For example: SysOp 1:225/337 Scott_Dudley 1:249/106 -c Bob_Davis 1:106/114 -h Vince_Perriello 1:141/191 -n Note! If you are performing a NetMail bombing run, it is cour- teous to send all messages directly to the destination (without routing your mail through other systems). Hurl This command moves messages from one area to another. The Hurl command asks the user for the destination area and the number of the message to be moved. Xport This command exports a message to a specific path and file- name on the local system. (The Xport command is normally only available to SysOps.) The exported message includes a copy of the message header. The message body is formatted for an 80-column screen. To print a message on the printer, specify an Xport file- name of "prn". In addition, other menu options can be placed on the message menu, including commands to call auxiliary menus, display text files, and run external programs. Please see section 18.8 for more information. 2.6.2. Message Editors Maximus has two internal message editors: MaxEd, the full screen editor, and BORED, the line-oriented editor. Maximus also supports a single, SysOp-defined external message edi- tor. 2.6.2.1. MaxEd MaxEd is the Maximus full screen editor. To use MaxEd, the user must have ANSI, AVATAR or RIPscrip graphics enabled, 2. Maximus Overview 18 have a screen width of 80 columns, and have a screen length of at least 23 rows. The full screen editor has a number of advantages over the line editor, with the most obvious being that it is much easier to use. MaxEd is more like a word processor than a conventional BBS line editor; the cursor keys can be used to page through a message and insert or de- lete text at various points in the message. For editing messages, MaxEd uses a mixture of WordStar and generic VT-100 keystrokes. A full list of the keys used by MaxEd can be obtained by pressing from within the editor. When composing a reply to another message, text from the original message can also be quoted (copied) into the reply. The R sequence (or on the local keyboard) toggles the quote window display. To scroll the quote window down by four lines, press either or . To scroll the quote window up by four lines, press either or . To copy text from the quote window into the message, press either C or . Maximus will copy the text and automatically scroll the quote window down by four lines. MaxEd also has its own menu that allows the user to modify the fields in the message header. This menu can be accessed by pressing either H or . The options available on the MaxEd menu include: Continue This command returns the user to the MaxEd's message- editing screen. To This command allows the user to change the addressee of the message. Subject This command allows the user to change the subject of the message. From This command allows the user to change the From field of the message. The privilege level of this command should be 2. Maximus Overview 19 set high enough so that only the SysOp can access this com- mand. Handling This command allows the user to modify the message's at- tributes. Attributes such as the Private flag can be changed, in addition to NetMail attributes (such as Crash, Hold and File Attach). This option is normally only avail- able to the SysOp. Read File This command allows the user to read in a file from the lo- cal hard drive and include it as part of the message. This option is normally only available to the SysOp. 2.6.2.2. BORED BORED is the Maximus line editor. Unlike MaxEd, BORED does not require ANSI or AVATAR graphics, so it can be used by any user. (However, most users who have graphics capabilities will likely prefer to use MaxEd.) BORED allows the user to enter a message one line at a time. If the user presses on a blank line, BORED displays the editor menu. The following editor commands are available: Save This command saves the message and returns to the message menu. Abort This command aborts (discards) the message and returns to the message menu. List This command lists the message. Each line in the message is indicated by number. Edit This command is used to replace text in a message. First, Maximus prompts the user to enter the line number which contains the text to be replaced. Next, the user enters the search text (the text which is to be replaced). Finally, the user enters the replacement text. 2. Maximus Overview 20 To insert text at the beginning of a line, simply press at the Text to replace: prompt. Insert This command inserts a blank line in the message. The user can specify a line number to indicate where the blank line is to be placed. Delete This command deletes a specified line in the message. Continue This command allows the user to continue writing by append- ing new lines to the end of the message. Quote For messages which are replies, this command allows the user to quote text from the original message. Maximus prompts the user to enter the starting and ending line num- bers (in the original message) for the text to be quoted. To This command allows the user to change the addressee of the message. Subject This command allows the user to change the subject of the message. From This command allows the user to change the From field of the message. The privilege level of this command should be set high enough so that only the SysOp can access this com- mand. Handling This command allows the user to modify the message's at- tributes. Attributes such as the Private flag can be changed, in addition to NetMail attributes (such as Crash, Hold and File Attach). This option is normally only avail- able to the SysOp. 2. Maximus Overview 21 Read File From Disk This command allows the user to read in a file from the lo- cal hard drive and include it as part of the message. This option is normally only available to the SysOp. 2.7. The File Menu This section describes the commands that are found on the standard file menu: Area Change This command allows the user to select another file area. The user can select an area by name, but the "[" and "]" keys can be used to select the areas which precede or fol- low the current area, respectively. The "?" character displays a list of file areas. For navi- gating within a hierarchical area structure, the "/" key can be used to go to the top-level menu, and the ".." se- quence can be used to ascend one level in the menu tree. Locate This command allows the user to search all file areas on the system for a specific file. Maximus first prompts the user to enter a text string. Next, it will go through all of the file areas on the sys- tem, and if it finds a match for that string (in either a filename or file description), it will display the name of the area and the corresponding file information. The L* command instructs Maximus to search all file areas for new files. This command will display a list of files that have been added to the system since the last L* com- mand was executed. File Titles This command displays a list of files in the current area. New files are identified by a flashing asterisk (*) next to the file date. If the user specifies an argument when invoking this com- mand, the File Titles command displays only those files which contain that string in the filename or description fields. (However, the File Titles command only searches the current file area, whereas the Locate command searches all file areas.) 2. Maximus Overview 22 In addition, when the More [Y,n,t,=]? prompt is displayed during a file list, the "t" option (if present) allows the user to tag files for download. This option is only dis- played if the user has an access level high enough to allow file downloading. View This command displays the contents of an ASCII file in the current area. Before displaying the file to the user, Maxi- mus first checks the file to ensure that it contains only ASCII text. Goodbye This option logs the user off and hangs up the phone. Even if the user does not log off using this command, Maximus will still update the user's user record. However, this command gives the user the opportunity to leave a comment to the SysOp. Comments to the SysOp are placed in the message area speci- fied by the Comment Area keyword in the system control file. The subject used for the log-off comment can be set in the comment_fr string in the Maximus language file. This string can include external program translation characters. Please see section 6 for more information. Main Menu This command returns the user to the main menu. Download This command allows the user to download one or more files from the system. Maximus first prompts the user to select a file transfer protocol. (However, if the user has selected a default file transfer protocol from the Change Setup menu, Maximus will automatically skip to the next step.) Maximus includes internal support for Xmodem, Xmodem-1k, Ymodem, Ymodem-G, SEAlink, and Zmodem. Other transfer pro- tocols can be added as external protocols. After selecting a protocol, users are prompted to enter the names of the files to be downloaded, one file to a line. Files that were previously tagged using the Tag command are automatically included in the list. 2. Maximus Overview 23 When processing filenames entered by the user, Maximus automatically expands wildcards, including the "*" and "?" characters. In addition, if the FB utility is used to maintain a system file database, the filenames entered by the user can reside in any file area. (Otherwise, the user must change to the correct file area before selecting the Download command.) In addition to entering filenames, the user can also: * press to start the download, * enter /q to abort the transfer without sending any files, * enter /e to enter edit mode. This mode allows the user to list and delete files in the download queue, or * enter /g to start the download and automatically hang up when the transfer is complete. Tag This command allows the user to queue one or more files for later download. The Tag command is also accessible through the t command when performing a File Titles or Locate com- mand. To download files which have been tagged using this com- mand, simply select the Download command and press at the File(s) to download: prompt. Upload This command allows the user to upload (send) files to the system. If no default file transfer protocol is defined, Maximus prompts the user for the protocol to be used for the upload. If the user selects Xmodem or Xmodem-1K, Maxi- mus also prompts the user for the name of the file to be uploaded. (With all of the other file transfer protocols, the filename is automatically transmitted by the sending terminal program.) Maximus will then start the upload. After the transfer is complete, Maximus will prompt the user to enter a descrip- tion for each file that is uploaded. Maximus can use the upload filename to automatically screen out certain types of uploads. The \max\badfiles.bbs file contains a list of files to be ignored. This list of files can include wildcards. A sample badfiles.bbs could look like this: MAKE$$$.TXT MAKECASH.* 2. Maximus Overview 24 *.RBS *.GBS *.BBS *.GIF *.JPG *.TIF Statistics This command displays the user's statistics, including the amount of time that the user has been online for the cur- rent call, the time online for the day, number of kilobytes uploaded, number of kilobytes downloaded, and so on. Contents This command displays the internal file catalog of a com- pressed file. The Contents command can display the direc- tory of any .zip, .arc, .pak, .arj or .lzh file Raw Directory This command displays a listing of all files in the current area, including files which are not listed in the files.bbs catalog for that area. This command is normally only avail- able to the SysOp. Override Path This command allows the user to override the download path for the current file area. For example, the download path can be overridden to c:\max to allow a privileged user to download files from the Maximus system directory. This com- mand is normally only available to the SysOp. Hurl This command moves a file from one area to another. Maximus prompts the user for the name of the destination area and the name of the file to be moved. This command is normally only available to the SysOp. Kill File This command deletes a file from the current file area. Maximus will prompt the user for the name of the file to be deleted. Maximus will ask the user to confirm the name of the file to be deleted; if the user answers "n" to this prompt, Maximus will give the user the option of leaving the physical file alone and removing the entry from the file listing. This command is normally only available to the SysOp. 2. Maximus Overview 25 2.8. The Change Setup Menu This menu allows the user to modify settings in the user pro- file. The following commands are available on the standard Change Setup menu: City This command modifies the user's "City" setting. Phone Number This command modifies the user's "Phone Number" setting. Alias This command is designed for use on systems that support aliases. This command allows a user to change his/her alias. Password This command changes the user's password. The user is first prompted to enter the old password. The user is given five chances to correctly enter the old password before Maximus hangs up. Next, the user is prompted to enter the new password. The user must enter the new password twice to prevent acciden- tal typing errors. Help Level This command selects the system help level. Maximus sup- ports the help levels shown below in Table 2.2: Table 2.2 System Help Levels Type Description NOVICE Full menus REGULAR Abbreviated menus EXPERT No menus Nulls This command selects the number of NUL characters which are transmitted after every line of text. Most users will not need to use this command. 2. Maximus Overview 26 Width This command changes the assumed screen width. This value is used by Maximus when displaying system menus and when drawing the full-screen editor display. However, for local users, Maximus will automatically detect the local screen size and adjust the "current width" value accordingly. The local screen size value overrides (but does not update) the value in the user file. Length This command changes the assumed screen length. Tabs This command toggles the translation of tab characters. Maximus normally sends tab characters directly to the user's terminal. However, if the user's terminal program does not support tab characters, this option can be dis- abled. More This command toggles the "More [Y,n,=]?" prompts on and off. Video Mode This command selects the user's video mode. Maximus sup- ports the following video modes: * TTY * ANSI * AVATAR RIPscrip graphics mode can be toggled by a separate menu option. Full-Screen Editor This command toggles the use of the MaxEd full-screen edi- tor. If MaxEd is turned off, BORED is used for message ed- iting. IBM Graphics This command toggles the use of IBM "extended ASCII" char- acters. DOS and OS/2 based computers support an "extended" 8-bit character set, including characters for box-drawing and block graphics. Most non-IBM systems do not support these extended ASCII characters, so Maximus can be config- 2. Maximus Overview 27 ured to map extended ASCII characters into normal ASCII characters. Hotkeys This command toggles the hotkeys setting. Turning on hot- keys instructs Maximus to process keystrokes as soon as they are received (without requiring an after most commands). Language This command selects an alternate system language. Maximus supports up to eight different language files, and the user can switch between installed language files at any time. Protocol This command selects a default file transfer protocol. When a default protocol is selected, the Download command imme- diately displays the File(s) to download: prompt instead of asking the user to select a protocol. Archiver This command selects a default archiving program. This al- lows the user to select a commonly-used archiver for com- pressing QWK mail packets. Show in Userlist This command toggle's the displaying of the user's name in the system user list. Users are displayed in the user list by default, but this command can be used to hide the dis- play of the user's name and last-call information. Full-Screen Reader This command toggles the use of the full-screen reader (FSR). When the FSR is enabled, Maximus will display a stylized blue box at the top of the screen when reading messages. This header includes information from the To, From and Subject fields, information on the message reply links, and net/node information. RIP This command toggles the use of RIPscrip graphics. When this command is selected, Maximus will test the remote user's terminal program to ensure that it supports RIPscrip. If RIPscrip graphics support is not detected, Maximus will not enable RIPscrip graphics. 2. Maximus Overview 28 Quit This command returns to the main menu. 2.9. The SysOp Menu This menu contains commands that are normally only accessible to the SysOp. User Editor This invokes the Maximus internal user editor. This command is normally only available to the SysOp. Please see Appendix E for more information. OS Shell This command invokes either a local or a remote shell to the operating system. Note that can always be used from the local console to shell to the operating system. OS/2 When running external programs that are not specifically only! designed to run as doors, OS/2 users should use the Max- Pipe program to invoke the command, rather than redirect- ing input with the "<" and ">" characters. DOS Under DOS, if you are using an alternate command processor only! (such as 4DOS or NDOS), the entry for this command (in the menus control file) must be changed to reflect the name of your command processor. 2.10. The Chat Menu Maximus supports an internal multinode chat facility. Users on different nodes can hold private discussions with one an- other, and users can even engage in large group discussions on a "virtual CB channels." CB Chat The CB Chat function allows two or more users to partici- pate in a real-time multinode chat. Messages can be sent back and forth to all users who are participating on a spe- cific CB channel. Messages are sent to other users one line at a time. Maximus supports up to 255 virtual CB channels. Page User The Page User command allows a user to initiate a private chat with another node. Selecting Page instructs Maximus to send a "chat request" message to the specified node number. 2. Maximus Overview 29 Maximus will then place the paging user in chat mode and wait for the other user to respond to the page. Answer Page The Answer Page command is used in conjunction with the Page User command. After a user receives a page request from another node, the paged user can select Answer Page to engage in a private chat with the first user. Toggle Status The Toggle Status command allows a user to toggle the chat availability flag. Users who are unavailable for chat can- not be paged using the Page User command. 2.11. The Off-Line Reader Menu The Off-Line Reader menu is the key to Maximus's internal QWK mail packer. Commands on this menu can be used to select a default protocol and archiving program, select a set of mes- sage areas, download messages from that set of areas, and up- load reply packets. Tag Area The Tag Area command (equivalent to the command of the same name on the message menu) allows the user to select a set of message areas to be processed by the Browse and Download commands. Download New Messages The Download command packs all new messages in the user's set of tagged areas. The messages are then compressed into an archive and sent to the user. Upload Replies The Upload Replies command allows the user to upload a .rep reply packet. Max automatically determines the program used to compress the .rep file, decompresses the reply packet, and places the uploaded messages into the appropriate ar- eas. Protocol Default The Protocol Default command allows the user to select a default file transfer protocol. 2. Maximus Overview 30 Archiver Default The Archiver Default command allows the user to select a default archiving program. 3. Installation This section of describes how to install a new copy of Maxi- mus 3.0. (To upgrade from Maximus 2.0, simply run the install program and follow the directions.) 3.1. Step 1: Unpacking the Distribution Files If you purchased a copy of Maximus, all of the required files are on the distribution disk and nothing more needs to be done. Skip to step 2 for information on running the install program. Otherwise, if you obtained Maximus electronically, the system consists of three separate archives, as shown below in Table 3.1: Table 3.1 Maximus Distribution Files File Description max300r.zip DOS (real-mode) executables. max300p.zip OS/2 (protected-mode) executables. max300c.zip Common executables and files for both DOS and OS/2. To install Maximus, you need max300c.zip, plus either or both of max300r.zip or max300p.zip, depending on the operating systems that you wish to use. The install program will examine the files that are avail- able, and if both the DOS and OS/2 versions of the executa- bles are present, it will allow you to select either or both versions for installation. Of course, you can also install Maximus for only one of the supported operating systems. The first step in the installation is to unarchive all of the required .zip files into a temporary subdirectory. (The in- stall program will move the files from the temporary direc- tory to a permanent directory of your choice, so this tempo- rary directory can be located anywhere on your system.) To decompress the .zip files, you need either the commercial "PKUNZIP" program from PKWare or the freeware "unzip" program from InfoZip. The following files are contained inside the .zip archives: 3. Installation 32 * an ASCII version of the system documentation, * the install program, * the program license agreement, and * a number of files with a .fiz extension. Most of the pro- grams in the distribution kit are packed using the proprie- tary FIZ compression algorithm, and the only way to extract these files is to run the install program. 3.2. Step 2: Running the Installation Program To execute the install program, run install.exe from the in- stall disk (or from the temporary directory, for the elec- tronic distribution version). After displaying some copyright information, the install pro- gram will prompt you for the type of install to perform. Se- lect the New Install button here, since these installation instructions only describe new installations. In the next dialog box, the install program will prompt you for a number of system paths. Aside from changing the drive letter or root name of the \max directory hierarchy, inexpe- rienced users should leave these paths alone. Next, the install program will prompt you for some basic in- formation about your system, including the BBS name, the name of the SysOp, and information about your communications hard- ware. In the dialog box, simply type text in the appropriate boxes, and use (or click with the mouse) to move between fields. To select a particular option from a radio button group, use the and keys to cursor over to the appropriate location and press to select that option. Press or click on the OK button when you have speci- fied the correct values. OS/2 Most of the executables in the OS/2 version of Maximus end only! with the letter "p." This "p" signifies that the executable runs in protected mode and is a native OS/2 application. Add- ing an extra "p" to the filename allows both Maximus-DOS and Maximus-OS/2 to be installed into the same directory. However, to keep this manual concise, only the base name of an executable is mentioned, without the trailing "p." When working through the installation, keep in mind that when the documentation refers to an executable filename, a "p" should be added for OS/2 users. For example, while the DOS version of the "ANS2BBS" utility is called ans2bbs.exe, the OS/2 version is called ans2bbsp.exe. 3. Installation 33 3.3. Step 3: Configuring your Modem This section describes how to configure your modem to work with Maximus and other related software packages. The modem is your BBS's gateway to the rest of the world, but it can also be one of the most difficult components to con- figure correctly. Due to the wide variety of modem manufac- turers and products, this manual cannot possibly cover all aspects of installing and configuring modems. However, this documentation describes a common set of modem commands that are supported by most popular modems. To run smoothly, Maximus requires a Hayes-compatible modem. Although it may be possible to use Maximus with a non Hayes- compatible modem, only Hayes-compatible modems are officially supported. When setting up your modem, the first step is to determine how your modem handles the Data Carrier Detect (DCD) signal. DCD is a signal sent by the modem to your computer to indi- cate when a connection has been established. When your modem is idle, DCD is normally in the low state. However, as soon as a user connects to your modem, DCD be- comes high. Maximus uses the DCD signal to determine when a user connects with the system, and it also uses DCD to deter- mine when a caller hangs up. Unfortunately, the default settings of many lower-speed mo- dems instruct the modem to always set the DCD signal high, regardless of whether or not the connection is active. To ensure that your modem is reporting the DCD signal prop- erly, you must check the configuration of your modem. Depend- ing on your modem type, this can be done in a number of ways: 1200 bps modems. If your modem is 1200 bps or slower, chances are that your modem's DCD handling is controlled by DIP switches. DIP switches are the small plastic toggles on the front, rear or bottom of your modem. (One or more panels may need to be removed to access these switches.) On most 1200 bps modems, DIP switch #6 controls the DCD sig- nal. For proper operation, this switch should be in the up position so that the modem reports the true DCD value. (However, some modems are different, so please consult your modem documentation before changing any DIP switches.) In addition, you may also need to change one of the other DIP switches so that your modem sends back verbal result codes (as opposed to numbers). The DIP switch to control these re- sult codes is manufacturer-dependent, so you will again need 3. Installation 34 to consult your modem's manual to determine which switch to check. 2400 bps, 9600 bps, 14.4 kbps, 19.2 kbps, or 28.8 kbps. If your modem is 2400 bps or faster, the configuration process can usually be performed using a standard terminal program (including Procomm Plus, Telix, Crosstalk, and others). After loading your terminal program and configuring it for the correct communications port, type in the command "AT" and press . If everything is well, your modem should re- turn an "OK" response. After you have established that your modem is working cor- rectly, enter the command "AT&C1&S1&D2&W" and press . (If this command does not work, try omitting either or both of the "&C1" or the "&S1" strings, since some modems do not support these settings.) This command configures your modem so that DCD always reflects the modem's actual state, and it also configures your modem's DTR handling so that Maximus can use the DTR signal to end a session and hang up on a user. External modems. If you have an external modem, one other po- tential problem is the modem cable. If your cable does not have the correct signals wired through, your modem may still behave as if DCD is set incorrectly, regardless of DIP switch settings. The best way to determine whether or not your modem cable is working correctly is simply to borrow a cable from another SysOp with a working BBS and try it on your system. If you determine that your cable is at fault, most computer stores or service centers can order or manufacture a modem cable. The wiring specifications for modem cables are: DB25 connectors (25 pins). This is the most common type of modem cable. As a minimum, pins 2 through 8 and pin 20 must be wired straight through. DB9 connectors (9 pins). All nine pins must be wired straight through. 3.4. Step 4: Installing Communications Drivers 3.4.1. OS/2 Communications Drivers OS/2 The following paragraphs are for OS/2 users only. DOS users only! can skip to section 3.4.2. 3. Installation 35 Unlike DOS, OS/2 does not require a FOSSIL driver. OS/2 in- cludes its own device driver to handle serial I/O. Unfortu- nately, the device driver included with OS/2 does not work correctly in all situations. (Under OS/2 2.x, the supplied COM.SYS driver sometimes uninstalls itself after certain com- munication errors occur.) Fortunately, a number of third-party device drivers are available: The 16-bit COM16550.SYS device driver can be used instead of the standard IBM driver. An evaluation version of COM16550 is bundled with Maximus, but COM16550 is a third-party product that is not sold or supported by Lanius. Please see the docu- mentation in the \max\com16550.zip file for more information. In addition, a third-party, 32-bit device driver called SIO.SYS has many more features than COM16550 and can operate at much higher speeds. SIO.SYS is not provided with Maximus, but it can be obtained from the Hobbes OS/2 archive at ftp.cdrom.com. SIO can also be found on most bulletin board systems that offer OS/2 support. Please note that COM16550 has a maximum speed of 19.2 kbps, whereas SIO.SYS has a maximum speed of 57.6 kbps. For this reason, if you are running a V.34 or V.FC modem, SIO.SYS is preferable to COM16550. In addition, Maximus runs with any serial device driver that supports the standard OS/2 "ASYNC IOCtl" interface. This means that Maximus-OS/2 can be used with intelligent serial cards such as the DigiBoard or the ARCTIC card. 3.4.2. DOS FOSSIL Drivers Under DOS, Maximus requires an external serial port driver called a FOSSIL. FOSSIL is an acronym which stands for "Fido/Opus/SEAdog Standard Interface Layer." The FOSSIL han- dles all of Maximus's low-level serial communication needs, including sending and receiving characters. Using a FOSSIL allows Maximus to be used on a wide range of serial port hardware without modifying the Maximus core. (For example, third-party vendors have developed FOSSIL drivers that support the DigiBoard intelligent serial card.) Maximus ships with a copy of Unique Computing Pty's BNU FOS- SIL driver. BNU supports most non-intelligent serial ports. If BNU is not suitable or will not run on your system, other FOSSIL drivers are available. Some of the most common FOSSILs are X00 and OpusComm. 3. Installation 36 There are two separate types of FOSSIL drivers. Some FOSSIL drivers, such as OpusComm and BNU, are loaded as Terminate and Stay Resident (TSR) programs in the c:\autoexec.bat file. Other drivers, including X00, are loaded in the c:\config.sys file. Although different FOSSIL drivers have different set-up instructions, it is fairly easy to install a FOSSIL for a ba- sic configuration. OpusComm installation. To install OpusComm on COM1, simply insert the following commands at the beginning of your AUTO- EXEC.BAT: opuscomm ocom_cfg L1=19200 (see note below!) Ensure that opuscomm.com and ocom_cfg.exe are on your current PATH, or else these commands will not work. The second "ocom_cfg" line locks port 1 at a speed of 19200 bps. This line is required for 9600+ bps modems. (Note that OpusComm does not support speeds faster than 19.2kbps.) This line is only required if you are using a 9600+ bps mo- dem. Users with 2400 bps or slower modems must not include the call to ocom_cfg. BNU installation. To install BNUcom on COM1, simply insert the following command at the beginning of your AUTOEXEC.BAT: bnu -l0=38400 Ensure that bnu.com is on your current PATH, or else this command will not work. The "-l0=38400" command instructs BNU to lock port 0 (COM1) at a speed of 38.4 kbps. This parameter is required for 9600+ bps modems. Users with 2400 bps modems must omit the "-l0=38400" parameter. Warni BNU uses 0-based COM port numbers. To lock the speed of COM1, ng! use "-l0=speed"; to lock the speed of COM2, use "-l1=speed"; and so on. X00 installation. To install the X00 driver on COM1, simply insert the following command at the beginning of your CON- FIG.SYS: DEVICE=X00.SYS B,0,19200 Ensure that X00.SYS is in your c:\ directory, or else this command will not work. 3. Installation 37 The "B,0,19200" parameter instructs X00 to lock COM1 at a speed of 19200 bps. This parameter is required for 9600+ bps modems. Users with 2400 bps modems must omit the "B,0,19200" parameter. Warni X00 uses 0-based COM port numbers. To lock the speed of COM1, ng! use "B,0,speed"; to lock the speed of COM2, use "B,1,speed"; and so on. 3.4.3. Checklist for high-speed modems When using a high speed modem (9600 bps or above, including any modems which support V.32, V.32bis, V.32ter, V.FC, or V.34), the modem normally communicates with the host BBS at a fixed speed, regardless of the speed of the user's modem. For this reason, if you are running a high-speed modem, you must instruct Maximus to talk to the modem at a fixed speed. To use a fixed port speed, you must: * ensure that the "&B1" parameter is included in your modem initialization string, * ensure that CTS flow control is enabled (using the "Mask Handshaking CTS" option in the system control files), and * use the -sspeed command line parameter when starting Maxi- mus. (This parameter is only required when running Maximus in a mode that handles remote callers. This parameter is not required when starting Maximus in local mode.) For example, to instruct Maximus to wait for a caller and use a locked port rate of 38.4 kbps: max -s38400 -w The "-s38400" parameter instructs Maximus to talk to the serial port at 38.4 kbps only. The modem itself will handle all rate negotiation with the remote system. 3.5. Step 5: Editing Configuration Files In order to run Maximus on your system, you need to make sev- eral changes to your system configuration files, including config.sys and autoexec.bat. For example, Maximus and related utilities always need to know how to find the main Maximus system directory. To accom- plish this, these utilities examine the system environment for the MAXIMUS environment variable. This variable must al- ways point to the master system configuration file. 3. Installation 38 OS/2 DOS users should skip the next few paragraphs. only! To set up the Maximus environment variable under OS/2, you must add the following line to the end of the config.sys file on your OS/2 boot drive: SET MAXIMUS=C:\MAX\MAX.PRM This example assumes that Maximus was installed in the c:\max directory. If you installed Maximus somewhere else, substi- tute the appropriate path for "c:\max". After making this change to config.sys, you must reboot the computer for the change to take effect. DOS OS/2 users should skip to the next section. only! To configure Maximus to run under DOS, you must add a number of lines to your c:\config.sys file. An ASCII editor, such as the standard DOS edit.com, can be used to edit this file. The first line to be added to config.sys is the "buffers=" statement. If there is no BUFFERS line in your config.sys file, simply add the following line to the end of the file: BUFFERS=30 However, if a BUFFERS line already exists, ensure that it specifies a value of at least 30. Next, the "files=" statement must be added. If there is no FILES line in your config.sys file, simply add the following line to the end of the file: FILES=40 However, if a FILES line already exists, ensure that it specifies a value of at least 40. Finally, if you plan to use Maximus in a multinode environ- ment, Maximus also requires the share.exe program. (Even in single-node environments, share.exe is still strongly recom- mended.) To install share.exe, simply add the following line to the end of c:\autoexec.bat: share Note for Novell users. Installing share.exe is not completely necessary. As long as you load int2f.com after running the Netware shell, you do not need to load share.exe. 3. Installation 39 Note for Windows for Workgroups and Windows 95 users. Windows comes with a SHARE-compatible VxD, and as long as you run Maximus exclusively within the Windows for Workgroups or Win- dows 95 environments, you do not need to install share.exe. Finally, to set up the system environment variable under DOS, you must add the following line to the end of the c:\autoexec.bat file: SET MAXIMUS=C:\MAX\MAX.PRM This example assumes that Maximus was installed in the c:\max directory. If you installed Maximus somewhere else, substi- tute the appropriate path for "c:\max". Once you have made all of these changes and saved the con- figuration files, you should press to reboot the computer. Unless you reboot now, changes made to con- fig.sys and autoexec.bat will not take effect. 3.6. Step 6: About Control Files This is the most complicated step in setting up a Maximus system. Four text-based configuration files control most of the operations of your system: max.ctl, msgarea.ctl, filearea.ctl and menus.ctl. max.ctl controls almost everything about your system, from the name of the log-on display file to the "time reward" given to users who upload files. msgarea.ctl controls all of the message areas that are acces- sible to users. filearea.ctl controls all of the file areas that are accessi- ble to users. menus.ctl controls all of the menus and options that can be selected by users. All of these text files are stored in an ASCII format, so the DOS edit.com or the OS/2 e.exe can be used to modify these files. These files contain a number of fairly complicated commands, but these control files give you control over even the most minute aspects of your BBS. However, the power to tailor your BBS to a very specific set of needs also makes it relatively easy to configure your system incorrectly. Consequently, new SysOps are advised to refrain from making too many modifica- tions to the control files until the basic BBS is up and run- ning. 3. Installation 40 The installation program will have already customized most of the system control files, so no specific modifications are required at this point. 3.7. Step 7: Compiling the Control Files Every time you modify max.ctl or any of the other control files, you must run SILT, the Maximus control file compiler. If you make changes to your control files and forget to run SILT, Maximus will not recognize the changes that you have made. Note! The system installation program will have already compiled your control file for the first time. However, it is a good idea to compile it again here, just so that you can learn how to run SILT.. Compiling your control files with SILT is easy; just enter the following from the command prompt: silt ctlname where ctlname is the name of your main system control file. In the default installation, the main control file is always called max, so most users only need to type "silt max". When SILT runs, it automatically compiles all of the control files, including menus.ctl, filearea.ctl, msgarea.ctl, and a number of other control files. These secondary control files cannot be compiled alone; you must always run SILT on the main control file, regardless of which secondary control file was changed. When SILT runs, it will scan through all of the control files and write a compiled version of the system information to max.prm, marea.dat, farea.dat, and a number of other system data files. If you made mistakes in the control files, such as misspell- ing a keyword or omitting a parameter, SILT will warn you about these mistakes. To correct these problems, use either the DOS edit.com or the OS/2 e.exe to load the control file, move to the problem line number, fix the error, and then re- compile using SILT. 3.8. Step 8: Starting Maximus Once you have compiled your control files, you are finally ready to start Maximus. Although your BBS is still fairly ge- neric, it is now usable. 3. Installation 41 To start up Maximus for the first time, enter the following sequence of commands. This example assumes that you have in- stalled Maximus in the c:\max directory: c: cd \max max -c The "-c" parameter tells Maximus to create a new user file, so you should only do this the first time you run Maximus. However, if you are converting from another BBS program, you should run the CVTUSR program before entering the above com- mand. (See section 8.3 for more information on the CVTUSR program.) Warni By default, Maximus encrypts all passwords in the Maximus ng! user file. While this adds an extra layer of security to your system, it means that you will be unable to convert your Maximus user file to the file format of any other BBS pro- gram. If you want to disable the password encryption, see the No Password Encryption feature in the system control file.) After entering "max -c", Maximus will display a copyright banner and print out a warning about the lack of an existing user file. Maximus will then display the prompt: "Your Name Here [Y,n]?", where "Your Name Here" is the name entered in the "SysOp" box in the installation program. Type the letter "Y" to continue your logon. After doing this, Maximus will display some text that de- scribes your BBS. This text is contained in the \max\misc\applic.mec file. (Files with an extension of .mec will be discussed in greater detail later in this document.) Maximus will also prompt you for a few pieces of information, including your city, phone number, and password. Maximus will also prompt you for ANSI screen control support, the MaxEd editor, IBM-PC characters, hotkeys, and RIPscrip graphics support. Answer "y" to the first four prompts, but answer "n" to the RIPscrip graphics question. After Maximus has finished configuring your account, it will display a welcome screen and a bulletin file. Finally, it will place you at the main system menu. All of the screens that you see are completely customizable. The steps required to customize these files are described later in this manual. Now that Maximus is working, you will probably want to look around for a while. Feel free to explore the different fea- tures of your new BBS. If you want to send some test NetMail messages, try going into the user editor (from the SysOp menu) and giving yourself some NetMail credit. 3. Installation 42 When you have finished looking around at your new BBS, type "g" from any menu to log off, and Maximus will exit back to the command prompt. 3.9. Step 9: Support for Remote Callers To handle non-local callers, Maximus must be run from a batch file. Unlike local log-ins, Maximus requires a batch file to recycle after remote callers. There are two mutually-exclusive methods of running Maximus: * Max can be run using the internal Waiting For Caller (WFC) subsystem. WFC takes care of answering the phone and talk- ing to the modem, so no external programs are required. * Maximus can also be run under a front end. A front end takes care of answering the phone and performing additional processing. Front ends are normally only required for Fi- doNet or UUCP support. If you are running a standalone sys- tem, you do not require a front end. In some cases, systems that run multiple nodes may wish to run a front end only on a subset of the BBS lines. In many cases, only one node needs to run a front end program, while the others can all use the internal WFC module. The command line is used to configure the system for WFC or front end op- eration, so no changes to the control files are required to support this. 3.9.1. Running the MODE command OS/2 If you are running Maximus under OS/2, special care must be only! taken to set up the communications port before calling Maxi- mus. In most cases, the OS/2 MODE command is used to config- ure the port. MODE is used to set the port speed, flow con- trol characteristics, and buffer settings. In most cases, the following command should be issued before trying to run Maximus with a remote caller. This command must be entered all on one line without spaces: MODE COMport:speed,n,8,1,,TO=OFF,XON=ON, IDSR=OFF,ODSR=OFF,OCTS=ON,DTR=ON,RTS=HS In the above command, port is the 1-based com port number of your Maximus system. speed is the maximum communications rate supported by your modem. This line should be included in the command file that starts Maximus. 3. Installation 43 For example, to configure com port 1 for 38.4 kbps, the fol- lowing command should be used: MODE COM1:38400,n,8,1,,TO=OFF,XON=ON,IDSR=OFF, ODSR=OFF,OCTS=ON,DTR=ON,RTS=HS If your modem has special flow control requirements, please see the documentation for the MODE command for more informa- tion. (On-line help is available by typing "help mode" from the OS/2 command prompt.) 3.9.2. Using WFC Mode When run in this mode, Maximus handles incoming callers on its own. The first step in enabling WFC mode is to use the "-w" command line parameter. To start Maximus in the most ba- sic WFC mode, the following command is used: max -w "-w" instructs Maximus to enter WFC mode. After this command is executed, Maximus will load up, display a few windows, initialize the modem, and then wait for an incoming call. Maximus will automatically detect the incoming caller's speed and switch speeds automatically. By default, Maximus is set up to run on any Hayes-compatible modem. If the WFC subsystem does not seem to be answering the phone correctly, read through the comments in the Equipment section of the system control file. Some of the modem command strings may need to be modified, but almost all modems can be made to work with Maximus. In addition to the standard "-w" switch, you can also use the "-b" (baud rate) and "-p" (COM port) switches to specify an alternate port number and maximum baud rate for the current node, overriding the defaults in the control file. For example, to start WFC on port 2 with a baud rate of 38400, specify the following command: max -w -p2 -b38400 To run WFC mode with a high-speed modem (9600+ bps), you must use a locked COM port. The "-s" command line parameter tells Maximus the speed to use for locking the port. For example, the following command is used to run Maximus with a high-speed modem on COM2 (locked at 38.4 kbps): max -w -p2 -s38400 3. Installation 44 No matter which options you use, the command line must always include a "-w" if you wish to handle remote callers. This command must be placed in the batch or command file that starts Maximus. (The batch/command file is described in more detail later in this section.) The WFC module can also handle timed events which cause Maxi- mus to wake up on specific days of the week or at a specific time of day. Please see section 5.1 for more information on WFC mode. 3.9.3. Using an External Front End In this mode, Maximus will not answer the telephone by it- self. You must obtain a third-party "front end" or "mailer" program to handle incoming calls. There are at least a dozen freeware/shareware FidoNet front ends for DOS, and two or three similar programs for OS/2. (At the time of this writ- ing, the two most common front ends were BinkleyTerm and FrontDoor.) Although setting up your front-end mailer is beyond the scope of this document, you will find several sample batch files for different front end mailers in Appendix G. Your mailer's documentation may give some specific instruc- tions for interfacing it with a Maximus system; if so, you should just follow those directions. If not, read on. When Maximus starts up with a caller already on-line, it ex- pects to be given a minimum of one parameter: "-bspeed", where speed is the speed of the caller. Generally, these parameters are passed from the mailer via the spawnbbs.bat or exebbs.bat files. OS/2 Under OS/2, Maximus also expects to be passed the COM port only! handle from the calling program. This means that the minimum requirements for starting Maximus are: maxp -bspeed -phandle where speed is the speed of the caller and handle is the OS/2 file handle for the communications port. Unlike under DOS, the -p parameter is a COM port handle (which is not the same value as the COM port number). This means that this value must be passed to Maximus by your front end mailer. 3. Installation 45 3.9.4. Maximus Errorlevels Although the preceding commands allow Maximus to handle one remote caller, either through the WFC subsystem or through a front end program, Maximus normally exits back to the command prompt after it processes a caller. After Maximus terminates, it needs to tell your system what to do next. For example, if a user entered a message in an EchoMail area, you may want to use an external utility (such as Squish) to export that message, or you may wish to run some sort of logging utility. To provide for these external programs, Maximus tells the op- erating system to set a numeric value called an errorlevel. As mentioned earlier, Maximus supports several different er- rorlevels for various types of events, including users enter- ing EchoMail messages, users entering NetMail messages, log- ging off before the user enters a name, and so on. In several places throughout the control files, you can in- struct Maximus to use a certain errorlevel when a given event occurs. Errorlevels are always numeric, and they always have a value from 1 to 255. In most cases, the errorlevels values do not need to be modified, but you can change them if you must. (However, Maximus reserves errorlevels 1 through 4 to indicate errors, so you should not use these values in the control file.) Once Maximus is set up to use errorlevels, you must also write a batch file to detect the errorlevel returned by Maxi- mus and take the appropriate action. The following statement is used to test an errorlevel in a .bat file (DOS) or in a .cmd file (OS/2): if errorlevel erl action erl is a number which corresponds to the errorlevel value for the event, as specified in the system control file. action is an action that is to be performed when the speci- fied errorlevel is detected. This action can consist of any normal batch file statement. However, if you wish to test for multiple errorlevels, be warned that both DOS and OS/2 examine errorlevels using a greater-than-or-equal-to comparison. This means that the fol- lowing statement: if errorlevel 10 echo Hi! 3. Installation 46 will be executed if Maximus sets an errorlevel value of 10 or greater. For this reason, if you have more than one errorlevel to process, the group of errorlevel statements must be listed in descending order. For example, to check for errorlevels 1, 3, 9, 10, 11 and 12, your batch file would look like this: max -w -p1 -b38400 if errorlevel 12 echo Do operation "A" here. if errorlevel 11 echo Do operation "B" here. if errorlevel 10 echo Do operation "C" here. if errorlevel 9 echo Do operation "D" here. if errorlevel 3 echo Do operation "E" here. if errorlevel 1 echo Do operation "F" here. Also, remember that all programs modify the errorlevel value when they are run. In the example given above, if you wanted to run a program called abcd.exe when errorlevel 12 was en- countered, the abcd.exe program would change the errorlevel to a new value after abcd terminated. Since the batch file is executed one line at a time, the following errorlevel checks (from 11 through 1) would be testing the errorlevel set by abcd.exe, not the errorlevel set by Maximus! To work around this limitation, you must use the goto state- ment for each errorlevel check. The goto statement allows your batch file to jump to a completely different location within the same batch file when a certain errorlevel is en- countered. An errorlevel-based goto statement looks like this: if errorlevel erl goto label As before, erl is the errorlevel value to be tested. The label value is a unique, alphanumeric, single-word name that indicates the destination of the jump. (Examples of valid label names are "GotCaller," "DidScanBld" and "Recycle.") In English, the above statement reads: If the errorlevel value is greater or equal to the value specified by erl, jump to the label in the batch/command file specified by label. To specify the destination of the jump, you must declare the label by placing the same name at another point in the same batch file. This lets the operating system know where it should jump to when it encounters the goto statement. 3. Installation 47 A label declaration looks like this: :label label is the same label name that was specified in the origi- nal goto statement. As soon as the command processor spots a statement of the form "goto label," it will jump to the loca- tion marked with ":label". For example, the following sample batch file: Line 1: :Top Line 2: echo Diamonds are forever Line 3: goto Top causes the line "Diamonds are forever" to be repeated over and over on the screen. When the operating system starts the batch file, it processes each line in sequence. After reading line 1, the OS recog- nizes that "Top" is simply a label definition, so it skips to the next line. After reading line 2, it processes the echo statement and displays "Diamonds are forever." Finally, after reading line 3, it realizes that it has to jump to the label marked "Top." Since the "Top" label is at the top of the file, it goes back to line 1 and repeats the entire process over and over again. However, the goto statement does have practical applications. The previous Maximus errorlevel example could be rewritten like this: max -w -p1 -b38400 if errorlevel 12 goto OpA if errorlevel 11 goto OpB if errorlevel 10 goto OpC if errorlevel 9 goto OpD if errorlevel 3 goto OpE if errorlevel 1 goto OpF :OpA echo Do operation "A" here. goto End :OpB echo Do operation "B" here. goto End :OpC echo Do operation "C" here. 3. Installation 48 goto End :OpD echo Do operation "D" here. goto End :OpE echo Do operation "E" here. goto End :OpF echo Do operation "F" here. goto End :End In this situation, the OS first compares the errorlevel re- turned by Maximus to those listed in the "if errorlevel" por- tion of the batch file. When it finds a match for the error- level, it jumps to the corresponding label. For example, if Maximus exited using errorlevel 10, the batch file interpreter would jump down to the "OpC" label and proc- ess the "echo Do operation `C' here" statement. (Most of the time, you would run an actual program after checking for an errorlevel, rather than simply echoing a string back to the console.) After processing the echo statement, the command processor reads and processes the next line of the batch file. The "goto End" statement ensures that the command processor skips over the following commands after the "OpD" label definition. (Recall that the command processor simply ignores label defi- nitions. Without the extra "goto End," the batch file would just "fall through" to the statements under the OpD and OpE labels. The extra goto statement specifically instructs the command processor to jump to the "End" label at the end of the file.) However, it may also be desirable to have the batch file "fall through" a set of errorlevels in certain cases. This allows errorlevels to be defined such that a certain error- level value, such as the "user entering EchoMail" value, also executes the command associated with another errorlevel value, such as the "user entered NetMail" value. 3.9.5. Sample WFC Batch File Maximus uses errorlevels 1 through 4 for internal purposes, but errorlevel values of 5 and greater can be configured by the user. A standard Maximus installation uses the following errorlevel values: 3. Installation 49 Errorlevel 255. Maximus terminated with an undefined error condition. Your batch file should return to your front-end mailer or restart Maximus in WFC mode. Errorlevel 12. A user entered EchoMail (and possibly also NetMail) during this session. In response, your batch file should call an external program to export mail to the net- work. If you are using the Squish mail processor, this com- mand should be "squish in out squash". In addition, if you use any *.MSG format message areas, you must also call SCANBLD at this point. Finally, after calling all of these external programs, your batch file should return to your mailer or restart Maximus in WFC mode. Errorlevel 11. A user entered NetMail (but no EchoMail) dur- ing this session. In response, your batch file should call your mail packer to export mail to the network. If you are using the Squish mail processor, this command should be "squish squash". In addition, if you use any *.MSG format message areas, you must also call SCANBLD at this point. Fi- nally, after calling all of these external programs, your batch file should return to your mailer or restart Maximus in WFC mode. Errorlevel 5. A user logged off and entered neither EchoMail nor NetMail. If you use any *.MSG format message areas, you must call SCANBLD at this point. Your batch file should then return to your mailer or restart Maximus in WFC mode. Errorlevels 4 and 3. A non-fatal error occurred. Your batch file should return to your mailer (or restart Maximus in WFC mode) if either of these errorlevels are detected. Errorlevel 2. The caller hung up before entering a valid name at the log-on prompt. Your batch file should return to your mailer or restart Maximus in WFC mode. Errorlevel 1. The SysOp pressed at the main WFC screen. Your batch file should exit back to the operating system. The following runbbs.bat (or runbbs.cmd for OS/2) can be used to start Maximus in WFC mode and accept callers: @echo off DOS rem * DOS users only: only! rem * rem * This line loads your FOSSIL driver. bnu 3. Installation 50 OS/2 rem * OS/2 users only: only! rem * rem * Comment out the above call to BNU rem * and uncomment the following MODE command. rem *(This command should be all be on one line.) rem * rem * mode com1:19200,n,8,1,TO=OFF,XON=ON, rem * IDSR=OFF,ODSR=OFF,OCTS=ON,DTR=ON,RTS=HS :Loop max -w -p1 -b19200 if errorlevel 255 goto Error if errorlevel 16 goto Error if errorlevel 12 goto EchoMail if errorlevel 11 goto NetMail if errorlevel 5 goto Aftercall if errorlevel 4 goto Error if errorlevel 3 goto Error if errorlevel 2 goto Loop if errorlevel 1 goto Done :EchoMail rem * Invoke scanner and packer here. Next, rem * go to the "Aftercall" label to process rem * any after-caller actions. rem * rem * For the Squish mail processor, use the rem * following command: rem rem SQUISH OUT SQUASH -fc:\max\echotoss.log goto Aftercall :NetMail rem * Invoke packer here, then go to rem * the "Aftercall" label. rem rem For the Squish mail processor, use the rem following command: rem rem SQUISH SQUASH goto Aftercall :Aftercall rem * Invoke after-each-caller utilities here. scanbld all 3. Installation 51 goto End :Error rem * Something bad happened, so let's say so. echo An error occurred! goto Down :End rem * This label should re-load your phone rem * answering program. If you are using rem * the Maximus WFC, you want to jump back rem * to the top of the loop: goto Loop :Down rem * The system arrives here if there was a rem * problem. echo Error! Maximus had a fatal error and echo could not continue! :Done exit To start Maximus, simply run the above runbbs.bat from the command prompt. Maximus will initialize and accept as many incoming connections as required. For sample batch files that demonstrate how to use Maximus with a front-end mailer, please see Appendix G. 3.10. Step 10: Miscellaneous Information You have now completed the installation procedure for Maxi- mus. Although Maximus is now mostly installed, please keep these things in mind: For users of *.MSG areas. A renumbering utility is required. If you carry any EchoMail areas with a lot of traffic, a re- numbering utility will be especially crucial. Maximus is bun- dled with the MR program. MR automatically deletes, renumbers and links messages based on information given in the message area control file. For more information on MR, please see section 8.9. For users of Squish areas. Although Squish normally renumbers areas messages are created, you may occasionally need to use the SQPACK utility. SQPACK compacts message area data files 3. Installation 52 by removing unused space between messages. Most systems will only need to run SQPACK once a week, but it may be beneficial to run SQPACK on a daily basis for systems with a lot of traffic. SQPACK is part of the Squish product, the companion mail processor for Maximus. The Squish product also includes a number of other useful utilities, including a diagnostic and repair utility for Squish areas. Your Maximus system should now be capable of handling call- ers, but many other options and features can be customized. The following section describes how to maintain some of the major components in a Maximus system. 4. Customization This section describes how to customize the main components of a Maximus system. This section is just an overview of the possible customizations. For a full list of features and/or control file keywords, please see section 18. 4.1. Events and Yelling The distribution copy of Maximus comes with a preconfigured event file. This event file serves two purposes: * With the internal WFC subsystem, the event file is used to schedule "external events." External events are used for running external programs at predefined times. These events are useful for performing daily system maintenance, general cleanup, and anything else you may require. * The event file also controls yell events. Yell events are used to define the times of the day when callers are al- lowed to page the SysOp. A yell event also controls how many times the SysOp can be paged and the tune to be played during the page. All events are kept in the file called events##.bbs, where ## is the node number of the task (in hexadecimal). For a sin- gle-line system, ## will be "01". Each node on a multinode system must have a separate events file. However, all of the event files use the same format, so you can simply copy a master events file to events01.bbs, events02.bbs, and so on. (If Maximus cannot find the event file for a specific node, it will try to read default event information from events00.bbs, regardless of the node number of the current session.) 4.1.1. Yell Events The distribution version of Maximus comes with an event file called events00.bbs. The standard event file contains a sin- gle yell event that looks like this: Event All 13:00 23:00 bells=3 maxyell=3 tune=random This yell event is active between 13:00 and 23:00. (This means that the user is allowed to page the SysOp between 1 pm and 11 pm.) 4. Customization 54 If desired, additional yelling time slots can be added by simply duplicating the "Event" line and changing the starting and ending times. The bells flag indicates the number of times that the bell or tune will be played. The maxyell flag indicates that a user is allowed to yell up to three times during one session before the SysOp page fea- ture is automatically disabled. (If the SysOp enters chat with the user, the yell count for that session is reset.) Finally, the tune flag indicates the tune to be played during the page. Maximus includes a large library of tunes in the \max\tunes.bbs file. Specifying "tune=random" instructs Maxi- mus to play a tune at random. However, you can also specify an explicit tune name, such as "tune=DigitalPhone". 4.1.2. External Events The event file also supports external events. An external event causes Maximus to exit with an errorlevel at a prede- fined time of day or on a certain day of the week. Events are only active when Maximus is started in WFC mode. To add an external event, simply add a line to events##.bbs with the appropriate starting time, and add an "exit=level" flag to the end of the line. level specifies the errorlevel that Maximus will exit with when the event time occurs. After creating an entry for the event in the events##.bbs file, you should modify your runbbs.bat file to handle the specified errorlevel and run the appropriate external com- mand. Please see section 18.11 for more information on the events file. 4.1.3. SoundBlaster Support OS/2 This section applies only to OS/2 users. only! Maximus-OS/2 includes internal support for the SoundBlaster and SoundBlaster-compatible sound cards. When playing yell tunes, Maximus will automatically determine whether or not a SoundBlaster is installed. If a SoundBlaster is found, Maximus will play the tunes from tunes.bbs on the 4. Customization 55 SoundBlaster, rather than making noises on the internal PC speaker. However, the SoundBlaster detection is not completely auto- matic. You must include the following line in your config.sys file to enable SoundBlaster support: SET OS2BLASTER=Abase Iirq Ddma NOCLI where base is the card's base address, irq is the card's IRQ level, and dma is the card's DMA channel. The "NOCLI" parame- ter must be included literally. This parameter tells the SoundBlaster code not to steal the CPU for long periods of time. Except for the last "NOCLI" flag, the OS2BLASTER settings are identical to the settings for the standard DOS "BLASTER" en- vironment variable. The settings for a standard SoundBlaster card are: SET OS2BLASTER=A220 I7 D1 NOCLI 4.2. Access Control: Classes, Privilege Levels and Locks This section describes the access control and security mecha- nisms supported by Maximus 3.0. 4.2.1. User Classes Maximus uses the class concept to control access to menu op- tions, message areas, and other system components. A class describes the access rights and privileges of a group of us- ers. The distribution version of Maximus includes 12 prede- fined user classes, but additional classes can be defined by the SysOp. A class definition typically includes the following attrib- utes (among many others): * maximum time limit, * maximum number of calls per day, * maximum daily download limit, * file download:upload ratio, * the name of a special display file to be shown at log-on, and * special system settings, such as the ability to write mes- sages in read-only areas, unlimited on-line time, the abil- ity to download any file on the system, and more. 4. Customization 56 (A complete list of class attributes can be found in section 18.9.) In addition, classes are associated with specific privilege levels. A privilege level is a numeric value from 0 to 65535. The privilege level is generally proportional to the level of access granted to users in that class. To make classes easier to manage, Maximus also assigns a name to each class. You can refer to classes either by name or by privilege level. The classes included in the distribution version of Maximus are listed below in Table 4.1: Table 4.1 Standard Privilege Levels Class Name Privilege Level Hidden 65535 SysOp 100 AsstSysOp 90 Clerk 80 Extra 70 Favored 60 Privil 50 Worthy 40 Normal 30 Limited 20 Demoted 10 Transient 0 The class names and privilege levels are completely configur- able, so if desired, the above names can be changed to re- flect the different types of users on your system. 4.2.2. Privilege Levels In the system user file, Maximus assigns a specific privilege level to each user. Since Maximus stores only the numeric privilege level, this means that you are free to rename a class or change its attributes at any time. (The privilege level assigned to new users is controlled by the Logon Level feature in the system control file.) When a user logs on, Maximus compares the user's privilege level to the level of all defined user classes. Maximus then selects the class with the privilege level that is closest to (but not over) the user's privilege level. 4. Customization 57 For example, assume that a user is assigned a privilege level of 20. When the user logs on, Maximus will scan the class definitions and notice that the "Demoted" class has a privi- lege level of 20. This is an exact match of the user's privi- lege level, so Maximus will treat the user as a member of the Demoted class. The user will inherit all of the characteris- tics of the class, including the associated time and file download limits. By separating the access limits from the user record, it be- comes easy to adjust the permissions for a broad group of us- ers by modifying a single class definition. Since the user record stores only the class's privilege level, you can eas- ily rename the class (or replace it with another one) without modifying the user file. In addition, a user's privilege level does not need to ex- actly match one of the class privilege levels. Assume that a user is assigned a privilege level of 45. Maximus will select the user class with the level that is closest to (but which does not exceed) the user's privilege level. Given these cri- teria, Maximus will select the "Worthy" class (which has a privilege level of 40). Although the user's privilege level is slightly higher than the Worthy privilege level, the user is still considered to be a member of the Worthy class. The user assumes the same access restrictions (including time limits and download lim- its) as all other members of the Worthy class. From this, we see that all possible privilege levels (from 0 to 65535) can be converted into a specific user class. If a class's privilege level is defined to be x, and if the privi- lege level of the next-highest class is defined to be y, all privilege levels in the range x to y - 1 (inclusive) are con- sidered to be part of the first class. This means that a user class actually encompasses a range of privilege levels. Assuming the standard class definitions given above, the standard privilege levels fall into the classes shown in Table 4.2: Table 4.2 Privilege Level Ranges Class Name Privilege Range Hidden 65535 SysOp 100-65534 AsstSysOp 90- 99 Clerk 80- 89 Extra 70- 79 Favored 60- 69 Privil 50- 59 4. Customization 58 Worthy 40- 49 Normal 30- 39 Limited 20- 29 Demoted 10- 19 Transient 0- 9 Now, since all users in a given class are granted the same access rights, you may wonder why Maximus allows multiple privilege levels to be assigned to a class. The answer lies in how Maximus processes access control definitions for com- mands and menu options: the access level for a menu command can be defined in terms of a class or in terms of a specific numeric privilege level. For example, although all members of the Worthy class (levels 40 through 49) have the same time limit and download restric- tions, the SysOp can define a menu option that requires a privilege level of 46, which means that only some of the mem- bers of the Worthy class will be able to access the option. From this, one can see that the 12 standard user classes can be logically subdivided into many more individual access lev- els. And should the original 12 classes not be enough to fit your needs, more classes can be added as necessary. In situations where Maximus needs to display a user's privi- lege level, such as on the status line at the bottom of the screen, Maximus will first examine the class records to see if the user's privilege level is an exact match for one of the classes. If so, Maximus will display the class name. Oth- erwise, if Maximus cannot find an exact match, it will dis- play the numeric privilege level. 4.2.3. SysOp and Hidden Attributes Of the 12 classes defined by Maximus, only two classes have extraordinary attributes: Users in the SysOp class have access to all system features and functions, including the ability to read private mes- sages, modify users in the system user editor, and examine any file on the local hard drive. Users in the Hidden class have no access to the system what- soever. If a user's privilege level is changed so that it falls into the Hidden class, Maximus will immediately hang up when the user calls. A user can be placed into the Hidden class to lock that user out of the system. 4. Customization 59 In addition, menu options can be assigned an access level of Hidden. A "Hidden" menu option cannot be accessed by any user on the system, regardless of the user's privilege level. Aside from the Hidden and SysOp classes, most of the other classes have only minor variations in time and download lim- its, so those classes can be assigned to normal users. 4.2.4. Locks and Keys In addition to the user classes and privilege levels de- scribed above, Maximus supports a set of keys that can be as- signed to each user. A key is equivalent to a "yes/no" flag that can be turned on or off on a user-by-user basis. Maximus supports a total of 32 keys. Keys are referenced by a single letter or number. The 32 keys consist of the letters A through X and the numbers 1 through 8. Any or all of these keys can be assigned to users on an individual basis. Keys are independent of a user's privilege level or class. For example, a user with a privilege level of 20 (in the "Limited" class) could have keys 1, 3, D and L. A user with a privilege level of 15 (in the "Demoted" class) could have keys 3, 4, A and L. Keys are useful when some commands or menu options are only made available to a certain subset of users, regardless of privilege level. To restrict access to an system feature, the SysOp can "lock" the feature using a certain key or set of keys. For example, a company BBS could have several different file areas dedicated to different products. Owners of a certain product could be given key A, while owners of a different product could be given key B. The file areas could be re- stricted so that a user needs key A to access information re- lated to the first type of product, while the other file area could be restricted to those with key B. If a user happened to own both products, the user could be given both keys A and B to permit access to both types of areas. Similarly, an area could be restricted to users with keys A, B and C, such that only users who owned all three types of products would be able to access the area. Keys are also independent of a user's privilege level, so you can still assign different time and download limits to dif- ferent classes of users, regardless of which keys are as- signed to each user. 4. Customization 60 4.2.5. Access Control Strings Maximus uses an Access Control String (ACS) to describe the access requirements for menu options, message and file areas, and various other system components. An ACS can restrict a certain feature based on a user's class, privilege level, key settings, and numerous other attributes. The simplest form of an ACS is simply a privilege level or the name of a user class. For example, if a specific menu op- tion is assigned an ACS of: 46 then only users with a privilege level of 46 or above would be able to access that option. Similarly, if you list the name of a user class, Maximus will convert the class name into a privilege level and compare it against the user's privilege level. For example, if a spe- cific menu option is assigned this ACS: Privil then only users with a privilege level of 50 or above would be able to access that option. (This example assumes that your class definitions assign a privilege level of 50 to the "Privil" class.) In addition to the names of the defined user classes, an ACS of NoAccess indicates that access is not granted to any user. The NoAccess string may be useful if you have removed the "Hidden" user class. An ACS can also be used to ensure that only users with a cer- tain set of keys are allowed to access an option. To add a key restriction, simply append a "/" to the end of the privi- lege level or class name, and then list the keys that the user must possess to access the command. For example, this ACS restricts a command to users who have a privilege level of at least 55 and who have keys 2, 3, 5 and A: 50/235A The name of a user class can also be used anywhere that a privilege level definition can be used, so the above ACS could be restated as: Normal/235A 4. Customization 61 An ACS can also restrict a command to users who do not have a certain set of keys. To add such a restriction, simply insert a "!" in front of the key that you wish to negate. For exam- ple, the following ACS: Worthy/23!6A!C restricts a command to users who: * have a privilege level of at least 40 (assuming the stan- dard class definitions), * have keys 2, 3 and A, and * have neither key 6 nor key C. All of the above ACS examples have restricted a feature to users with a privilege level that was greater than or equal to a certain value. An ACS can also restrict a command to us- ers with an exact privilege level, or perform other types of logical tests. To add a logical test to an ACS, insert one of the operators shown below in Table 4.3: Table 4.3 Access Control String Operators Operator Description = Grants access if the user's privilege level is exactly the specified level. > Grants access if the user's privilege level is strictly greater than the specified level. < Grants access if the user's privilege level is strictly less than the specified level. >= Grants access if the user's privilege level is greater than or equal to the specified level (default). <= Grants access if the user's privilege level is less than or equal to the specified level. <> or != Grants access if the user's privilege level is not equal to the specified level. For example, the following ACS: <=Normal/123 restricts access to those users who have a privilege level of 50 or less and who also have keys 1, 2 and 3. Assuming the standard user classes, this could also be restated as: <=30/123 4. Customization 62 In addition, an ACS can restrict an option to a user with a specific name or alias. The following ACS restricts a feature so that only the user named "John Doe" is able to access it: name=John_Doe Notice that the space in the user's name is replaced with an underscore. An ACS may not include any spaces. Similarly, the following ACS restricts a command so that only the user with an alias of "Peter Rabbit" can access it: alias=Peter_Rabbit Finally, boolean operators can also be included in an ACS definition. You can combine two existing ACSs by inserting the and operator ("&") between them: 10/123&<=Normal This ACS restricts a command to users who have a privilege level of at least 10 but less than 30 (the "Normal" privilege level). Users must also have keys 1, 2 and 3 to access this command. Similarly, the logical or operator can also be inserted be- tween two ACSs: <=Normal/12|AsstSysop/!J This ACS restricts a command to users who either: * have a privilege level of 30 ("Normal") or less and have keys 1 and 2, or * have a privilege level of at least 90 ("AsstSysOp") and do not have key J. Most major Maximus subsystems use the ACS concept to restrict access to features. For example, every message and file area can be assigned an ACS to control which users get access to that area, and many settings in the system control file also accept an ACS. However, a small number of features can only be controlled on the basis of privilege level or user class. 4.3. Display Files: *.mec and *.bbs All of the information files that Maximus displays to the user are stored in the .bbs and .mec file formats. Collec- tively, these are known as MECCA files or display files. Most of the system MECCA files are stored in the \max\misc and 4. Customization 63 \max\hlp directories, but you can add your own display files in other places. The names of many of the standard display files can be found in the system control file, but the names of some display files cannot be changed. Please see Appendix H for more in- formation on the names of these display files. You will notice that most of these files come in pairs: for every file with a .mec extension, there is always a file with a .bbs extension. Just like control files, MECCA files must be compiled before they can be used by Maximus. The .mec file is the source for a display file. You can edit the .mec file with a text editor to insert commands and dis- play text. After you have finished modifying the .mec file, the MECCA compiler must be run to convert it to a .bbs file. Compiling a file with MECCA is easy. Simply type in the com- mand "MECCA filename", where filename is the name of the .mec file to be compiled. For example, to compile the file ap- plic.mec into applic.bbs, enter the following at a command prompt: cd \max\misc mecca applic MECCA source files contain plain text to be displayed to the user, but they can also contain tokens to perform color changes, cursor control, conditionally display certain lines, and display system information. A MECCA token is a special keyword that is enclosed inside a pair of square brackets. For example, a .mec file that contains the following: [white]Hello there, [user]. Are you having a nice [lightblue]day [white]today? will display "Hello there, John Doe" in white (assuming that the user's name is John Doe). It will then display "Are you having a nice" in white, the word "day" in blue, and the word "today?" in white. MECCA supports many other tokens that display information to the user or change screen attributes. MECCA allows you to em- bed user-specific or system-specific information into any display screen. To see an actual MECCA file, load the \max\misc\newuser2.mec file with an ASCII editor. As you can see, the file consists mainly of ASCII text, but a few special MECCA tokens have been inserted to colorize the screen and perform other ac- tions. 4. Customization 64 One of the main advantages of using MECCA is that only one set of display files needs to be created. Unlike other bulle- tin board packages where the SysOp must create both an ASCII and an ANSI version of a specific display file, Maximus auto- matically filters out color and graphics codes for those us- ers who do not support ANSI or AVATAR graphics. For compatibility reasons, Maximus comes with a utility to convert files containing ANSI graphics into MECCA files. Please see section 8.2 for more information. Although MECCA files are normally viewed by running Maximus and displaying the menu option or command that contains the display file, you can also use the ORACLE utility to display a MECCA file from the command prompt. For more information on creating MECCA files, please see sec- tion 17. For more information on using the MECCA compiler, please see section 8.8. For more information on ORACLE, please see section 8.10. 4.4. Message Areas and File Areas The next step in customizing your system is to set up the message and file sections. The Maximus distribution kit comes preconfigured with a set of sample message and file areas, but most SysOps will want to customize these areas. All message areas are defined in the msgarea.ctl file. Like- wise, all file areas are defined in the filearea.ctl file. In Maximus, each area (whether a message area or a file area) must have a unique name. Area names can be up to 64 charac- ters long, and names can include both letters and numbers. Maximus supports a theoretically unlimited number of message and file areas, but it is better to start with a small number of areas and expand them as your system grows. 4.4.1. Message Area Definitions A message area definition looks like this: MsgArea name % Other message area definition keywords % go here. End MsgArea 4. Customization 65 where name is the name of the message area to be defined. All of the keywords related to that area must be placed between the MsgArea keyword and the following End MsgArea keyword. Note! By default, all log-off comments are placed in message area 1. If you wish to change the name for area 1, you must also change the Comment Area definition in the system control file. Some common message area definition keywords are described below. A complete list of keywords can be found in section 18.6. ACS string Restrict access to this area so that only those users who satisfy the ACS string are allowed to see or enter the area. This statement is required for all message areas. Desc text Use text as the description for this area. Maximus will display this description when the user requests a list of areas. Path filename filename specifies the physical disk file and/or directory to use for storing messages. For a Squish-format message area (default), filename must contain the path and filename of the area (without an ex- tension). For a *.MSG-format message area, filename must contain only the path of the area. (Only one *.MSG area can be stored in any given directory.) Style flags The flags option specifies a number of optional flags and toggles for the message area. Multiple flags can be speci- fied for a single message area by separating flag names with spaces. Table 4.4 describes some of the more common flags: Table 4.4 Message Style Flags Flag Description Pvt Allow private messages in this area. Private mes- sages can only be read by the SysOp, the sender, 4. Customization 66 and the addressee. Pub Allow public messages in this area. Public mes- sages can be read by anyone. Squish Store this area in the Squish format (default). *.MSG Store this area in the *.MSG format. Most of these flags are optional. Please see section 18.6 for information on other supported styles. Tag name This keyword tells Maximus to use name as the "tag" for this area. If a tag is assigned to an area, Maximus will write the tag out to the Log EchoMail filename after the user logs off. This feature is normally used in conjunction with EchoMail areas; the tag specified here should be the same as the tag that you have defined for that area in your EchoMail processor. 4.4.2. File Area Definitions A file area definition looks like this: FileArea name % Other file area definition keywords % go here. End MsgArea where name is the name of the file area to be defined. All of the keywords related to that area must be placed between the FileArea keyword and the following End FileArea keyword. Some common file area definition keywords are described be- low. A complete list of keywords can be found in section 18.7. ACS string Restrict access to this area so that only those users who satisfy the ACS string are allowed to see or enter the area. This statement is required for all message areas. Desc text Use text as the description for this area. Maximus will display this description when the user requests a list of areas. 4. Customization 67 Download path This keyword tells Maximus where to find the files con- tained within this file area. The files that the users are to download must be contained within this directory. Upload path This keyword tells Maximus where to place uploaded files. There are two options for defining an upload path: * Set the upload path to point to the same directory as the download path. With this configuration, files will be made available to other users as soon as they are up- loaded. (However, users must ensure that they change to the correct file area before uploading files.) * Set the upload path in all file areas to point to one common directory. This directory can then be configured as the download path for an area that can be accessed only by the SysOp. This option is the most secure, since it allows the Sy- sOp to check uploaded files before they are put on-line for other users. Users will only be able to see the file after the SysOp has checked the file and used the Hurl command to move it to another file area. 4.4.3. Custom Message and File Area Menus By default, Maximus will dynamically generate a menu when us- ers select the Area Change command from the message or file area menus. This display can be controlled to an extent, us- ing the Format MsgFormat and Format FileFormat definitions, but these commands may still be too restrictive for some Sy- sOps. Consequently, Maximus allows you to completely disable the automatic menu generation feature and replace it with custom .mec screens. The Uses MsgAreas and Uses FileAreas statements (in the system control file) instruct Maximus to display the specified file instead of generating an area menu of its own. While these files give you a large degree of flexibility, us- ing a custom display file means that you must remember to modify the display file when you add or remove an area. 4.4.4. Message Area and File Area Hierarchies Maximus allows you to group your message and file areas into logical, multi-level hierarchies. By default, all message and 4. Customization 68 file areas are stored in a "flat" name space, but you can add divisions to your message area and file area control files to group areas in a logical manner. For example, if your system supported the following message areas: Lexus Lawnmowers C BMW Pascal Shovels Jaguar the areas could be grouped in a more logical structure as follows: cars.lexus cars.bmw cars.jaguar programming.c programming.pascal garden.lawnmowers garden.shovels By adding the appropriate MsgAreaDivision records to your message area control file, Maximus can automatically insert the "cars." or "programming." prefix for each area. Maximus will also present the list of areas to the user in a logical manner. For example, the top level message area menu might look something like this: Message Areas -------------------- cars ... DIVISION: Cars programming ... DIVISION: Langs garden ... DIVISION: Gardening If a user selected "cars" at the prompt, Maximus would dis- play a submenu of all of the areas in that division, includ- ing cars.lexus, cars.bmw and cars.jaguar. Maximus also supports nested message area divisions. For ex- ample, the "cars" division could be subdivided into two sepa- rate groups of areas, such as "cars.luxury" and "cars.economy." All of the comments related to message areas also apply equally to file areas. The description below refers to mes- sage area divisions only, but you can apply the same concept to file areas by replacing MsgDivisionBegin with FileDivi- 4. Customization 69 sionBegin, MsgDivisionEnd with FileDivisionEnd, and MsgArea with FileArea. To create a message area division, you must place the follow- ing statement before the definition of the first message area to be included in the division: MsgDivisionBegin name acs display_file description In addition, you must place the following statement after the end of the last message area to be included: MsgDivisionEnd The name parameter is the name of the message area division. From the example above, one might use a name of "cars" or "garden." Maximus will automatically add this name, followed by a period ("."), to the names of any message areas defined within this division. The acs parameter is the ACS that controls access to the mes- sage area division. A user can only see this area division if the user's privilege level passes the access control check. Warni The acs parameter only controls the access level required for ng! users to see the division on the message area menu. Even if users cannot see a message area division, if they know the name of an area inside the division, and if they have a privilege level high enough to access the message area (but not the division), the users can change directly to that area anyway. For this reason, the ACS of a message area definition should be at least as restrictive as the ACS of the MsgDivi- sionBegin statement. The display_file parameter instructs Maximus to display the specified file when the user requests a list of areas in the division, rather than automatically generating a menu of its own. This display file is normally used in conjunction with the Uses MsgAreas definition in the system control file. If you do not wish to use a custom display file, specify a "." to instruct Maximus to generate the area list automatically. The description parameter is a short description of the con- tents of the division. Maximus will display this description on the message area menu when the user requests a list of ar- eas. For example, to implement the message division structure de- scribed in the previous example, use the following syntax: MsgDivisionBegin cars Demoted . DIVISION: Cars MsgArea lexus % Definitions for the Lexus area go here 4. Customization 70 End MsgArea MsgArea bmw % Definitions for the BMW area go here End MsgArea MsgArea jaguar % Definitions for the Jaguar area go here End MsgArea MsgDivisionEnd MsgDivisionBegin programming Demoted . DIVISION: Langs MsgArea c % Definitions for the C area go here End MsgArea MsgArea pascal % Definitions for the Pascal area go here End MsgArea MsgDivisionEnd MsgDivisionBegin garden Demoted . Gardening MsgArea lawnmowers % Definitions for the lawnmowers area go here End MsgArea MsgArea shovels % Definitions for the shovels area go here End MsgArea MsgDivisionEnd 4.5. Maintaining File Areas Message areas can be created quite easily, but file areas re- quire a fair amount of maintenance to run properly. Not only do you need to create file area definitions, but you must also create listings of files which can be downloaded by the user. (However, if you wish to create a blank file area, no extra work is required, since Maximus will create a file listing as soon as a user uploads a file to that area.) 4.5.1. Creating File Listings To place files in a newly-created file area, you must create an ASCII listing of the files in the area. If you already have a directory containing the files to be added, you should first copy those files to the directory specified in the file area's Download statement. Next, from the command prompt, change the current directory to the directory specified in the area's Download path. Next, 4. Customization 71 enter the following command to create the initial file cata- log: for %f in (*.*) do echo %f >>files.bbs If you wish to run this command from a batch file, instead of from the command prompt, enter this instead: for %%f in (*.*) do echo %%f >>files.bbs After a bit of disk activity, the file listing should be cre- ated for you. Although this will create a listing of file names, most users will also want to see file descriptions. To add file descriptions, run an ASCII editor (such as the DOS edit.com or the OS/2 e.exe) and load the files.bbs file. Inside files.bbs, you should see a list of the files in the directory. If you wish to add a description for a particular file, simply add one or more spaces after the filename and insert your description there. A description can be up to 1024 characters long; although only 48 characters can be dis- played on one line of the file catalog, Maximus will auto- matically wordwrap the rest of the text onto the following lines. The files.bbs in a hypothetical file area could look like this: DEMO.LST Description of product demonstration INFO.TXT Information about this system RESULTS.ZIP Results from the last quarter To add files to the file listing after performing the initial "for %f" command, you can simply use a text editor to insert a line in files.bbs and add the name and description for the file. Similarly, to delete a file from the listing, just remove the line containing the file entry from files.bbs. You should also delete the actual file from the download directory. When using the default File Date Automatic setting in the system control file, Maximus will automatically colorize the listing and place the file's size and date beside the file- name. In addition, Maximus allows files to be marked as "free down- loads". Files can be marked for "free download bytes" (the file does not count against the user's download limit) or "free download time" (the file does not count against the user's time limit), or both. 4. Customization 72 To mark a file as a free download, you must add a slash se- quence before a file's description. For a free time download, insert "/t" before the description. For a free bytes down- load, insert "/b" before the description. For both free time and free bytes, use "/tb". For example, to ensure that the Maximus 3.0 distribution files do not count against the user's download quota, use the following: MAX300C.ZIP /b This is Maximus 3.0. If you want to count the download against the user's byte to- tal (but not the user's time limit), use the following: MAX300C.ZIP /t This is Maximus 3.0. Similarly, if you want both free time and bytes to be given to the user, use the following: MAX300P.ZIP /tb This is Maximus 3.0. Finally, you can add comments to files.bbs which are not spe- cifically related to a file. If the first character on a line is a dash ("-") or a space (" "), Maximus will treat the line as a comment and display it to the user. In addition, if the first character on the line is a dash, the line will be dis- played in white. If the first character is a space, Maximus will display the line in the current color (which is normally cyan). 4.5.2. Global Downloading, Fast Locates and Duplicate Files The global downloading feature allows users to select a file for download from any point in the system, regardless of the file area where the file is stored. For example, if your sys- tem had a file in area "os2" called fix.zip, a user could en- ter "d fix.zip" from file area "dos" and still download the correct file. The fast locate feature allows Maximus to perform very fast file area searches using the Locate command. The duplicate checking (or dupe check) feature allows Maximus to compare the filenames of uploaded files with the files that are available for download. Maximus can be configured to automatically reject files that already exist elsewhere in the file areas. To enable any of these features, you must use the FB utility to create a compiled file database. FB scans the files.bbs catalogs in all file areas and creates a binary file data- 4. Customization 73 base. This database is required for all of the features men- tioned above. Every time you change your file areas, you should run the following command: fb -a This command tells FB to compile a database containing all of the file areas defined in filearea.ctl. (On large systems, this command may take a long time to execute. For information on incremental FB compiles, please see section 8.5.) After running FB, the global downloading and fast locate fea- tures are automatically enabled. However, you may need to en- able the Upload Check Dupe feature in the system control file to use duplicate file checking. 4.5.3. CD-ROM Handling To set up your system to retrieve files from a CD-ROM, you must first create a FileArea definition for each directory on the CD. However, to inform Maximus that the area is stored on slow media, you must add the following keyword to the file area definition: Type CD This line tells Maximus to do two things: * Maximus will only access the actual drive when absolutely necessary. For example, this means that Maximus will not try to validate the directory when displaying an area list. * Files to be downloaded from this area will be copied to a staging area on your hard drive before the transfer. This helps prevent thrashing when multiple users are downloading from a rotary CD changer. (The destination directory for this copy operation can be set with the Stage Path defini- tion in the system control file.) * SILT will not check to see whether or not the directory ex- ists. This means that you can compile your system with sup- port for many different CDs, even if your system only has one CD-ROM drive. DOS In addition, when setting up your system with a CD, do not only! forget to edit the Save Directories keyword in the system control file. This keyword tells the DOS version of Maximus to save the current directory for every drive in a list of drives. However, since CD-ROM drives have removable media, 4. Customization 74 you must remove the drive letter corresponding to the CD-ROM from the Save Directories statement. 4.5.3.1. File Listings Some CD-ROMs may already be set up for use with a Maximus system. Such CD-ROMs will come with a files.bbs file in every directory that contains files to be downloaded. If this is the case, you do not need to do anything further. However, a number of other CD-ROMs are not set up for BBS use (or do not have a standard Maximus files.bbs listing). If this is the case, you need to construct your own listing of files in each directory. To construct your own file listing for one area, add the fol- lowing line to the file area definition: FileList c:\path\filename.bbs The FileList keyword instructs Maximus to look for a files.bbs-like catalog with the specified name. The CD-ROM is read-only, so you need to point filename to a file on your hard drive. In this file, you must place a files.bbs-like listing of files in the area. The file name should come first, followed by the file description, just as in files.bbs. When a user accesses the area, instead of looking in the Download path for the files.bbs file, Maximus will look for the file list specified in the FileList statement. For example, a sample CD-ROM area definition might look like this: FileArea apl Type CD Desc The APL Programming Language Download g:\msdos\apl Upload c:\max\file\upload FileList c:\max\lists\apl.bbs End FileArea In this case, the c:\max\lists\apl.bbs file would be a file catalog listing all of the files in the g:\msdos\apl direc- tory. 4. Customization 75 4.5.3.2. Listing Date and Size Formats Maximus supports three different styles of "file dating." These formats are: Automatic dating. Maximus retrieves a file's date and size from the directory entry. This is the default style. When FB builds the file database, and when a user does a file listing for a single area, Maximus retrieves file information from the download path. List dating. Maximus assumes that a file's date and size are stored as part of the file description in the files.bbs list- ing (or the FileList catalog for the area). FB will read the file description and parse dates and sizes in the form "mm- dd-yy size" or "size mm-dd-yy." FB will incorporate this in- formation into the compiled file database. Maximus will also colorize the file information when displaying a directory listing. When list dating is used, the download directory is not examined at all. Manual dating. Maximus does not attempt to process or display file dates or sizes in any manner whatsoever. The File_NewFiles option and the "L*" (or "F*") commands cannot be used to search based on file dates when this dating method is selected. The Type keywords shown below in Table 4.5 can be used to specify one of these dating styles. Table 4.5 File Area Date Styles Keyword Style Type DateAuto Automatic file dates. Type DateList List dating. Type DateManual Manual file dates. The DateAuto style is well suited for file areas stored on your hard drive. Aside from file areas that never change, this is usually the best option to use. However, the DateList style is much more appropriate for CD- ROMs. If the CD comes with a file catalog that contains file sizes and dates, select the DateList style and use the FileList keyword to specify the name of the file containing the file list. For example, if the CD-ROM vendor has placed a DateList- compatible file list in the download directory (called 00index.txt), the following file area definition can be used: 4. Customization 76 FileArea apl Type CD DateList Desc The APL Programming Language Download g:\msdos\apl Upload c:\max\file\upload FileList g:\msdos\apl\00index.txt End FileArea If you use a DateList file area, Maximus will not examine the drive at all when the user requests a file listing. In addi- tion, the CD-ROM does not need to be in the drive when FB is asked to build the file database. For CD-ROMs, the DateList option is the quickest in terms of overall system perform- ance, and it is much easier to maintain than the other two options. 4.5.3.3. CD-ROM areas and DateAuto Processing If you still choose to use DateAuto processing with a CD-ROM file area, you must follow the following procedure to main- tain the file catalog. Normally, since DateAuto processing reads information from the file download directories, all of your file areas must be accessible when you run FB. However, if you have only one CD- ROM drive and many CDs, you may wish to create file areas for all of your CDs, even though only one CD can be on-line at a time. Using the DateList option is preferable when you want to do this. However, if you would like to use DateAuto processing, you must follow this procedure when building your file cata- log with FB: 1. Remove all CDs from the computer and run "fb -a". This com- piles the file database information for file areas on your hard drive. 2. Insert the first CD into the drive. Run FB only over those areas which are contained on that CD. (If you have subdi- vided your file areas using FileDivision statements, you can tell FB to compile only a certain file area tree using wildcards, such as with "fb simtel.*". Otherwise, you will have to specify each area separately on the command line like this: "fb area1 area2 area3".) 3. Remove the first CD and repeat step 2 for all remaining CDs. 4. After completing step 2 for all of your CDs, the file area database will be completely built. However, to prevent FB from trying to recompile CD areas when the CD-ROM is not in 4. Customization 77 the drive, you must always run FB with the "fb -s" parame- ter (which causes it to skip the CD areas). After the file database is built, if you omit the -s parameter even once, the compiled file information for your CD-ROMs may be over- written. 4.6. Barricades and Extended Barricade Files The Barricade keyword in the message and file areas tells Maximus that you wish to protect the area with a password, or that you want to grant different access levels to certain us- ers while they are in that area. When a user enters a barricaded area, the Uses Barricade file is shown, and the user is given three tries to enter the cor- rect access code. The access codes required to enter a barricaded area are con- tained in a barricade file. The Barricade keyword in the area definition must point to a barricade file. 4.6.1. Barricade Files A barricade file is a straight ASCII text file containing a list of passwords, with each password followed by the privi- lege level to grant to users who enter the correct password. Each line of the barricade file is in the following format: is the password which grants a privilege level of to the user. can only specify a numeric privi- lege level or a class name. (Keys are not valid in the string.) For example: helloworld SysOp kentucky Clerk cleanse Normal scum Demoted If a user enters an area with this barricade file and types "helloworld" at the password prompt, the user will be granted access to the area, and the user's privilege level will be set to SysOp while in the area. Similarly, if the user typed "kentucky," the user's privilege level would be temporarily altered to Clerk while inside that area. 4. Customization 78 In addition, if you specify "NoAccess" in the field, a user who enters the specified password will be denied access and told that the area does not exist. 4.6.2. Extended Barricade Files Maximus supports the "extended" barricade file concept. An extended barricade file allows users to be promoted without using passwords. Before displaying the Uses Barricade file, Maximus will quickly scan the barricade file to see if it uses the ex- tended barricade syntax. If so, Maximus skips the Uses Barri- cade display and processes the barricade file directly. Each line in an extended barricade file has the following format: ! or !All [priv] The "!" in the first column of each line is not optional. The "!" distinguishes an extended barricade file from a normal barricade file. is the name of the user whose access level is to be promoted. No spaces can be present in , so re- place spaces with underscores. (For example, to use Joe SysOp in an extended barricade, you would have to use "Joe_SysOp" for the .) If Maximus matches the name for the user trying to enter the barricaded area, the user's privilege level is altered to with no questions asked. In addition, if the user's name is not explicitly found in the barricade file, Maximus will "fall through" to the op- tional "!All" keyword. If you use "!All" by itself, without specifying a privilege level, Maximus will let other users into the area using their real privilege levels. If you do specify a privilege level after the "!All" keyword, Maximus will let all users enter the area and promote all of them to a level of [priv]. The "!All" statement must be at the very end of the barricade file to function properly. Finally, you can even use the "NoAccess" privilege level with extended barricades. This allows you to create a barricaded area that is completely invisible to certain users. 4. Customization 79 For example: !Jesse_Hollington Clerk !Steven_Bonisteel Clerk !Hubert_Lai Privil !All Demoted This file assigns the privilege level of "Clerk" to the first two users, assigns the "Privil" level to the third user, and gives all other users a privilege level of "Demoted". (To prevent anyone except the above three users from accessing the area, the "Demoted" could be replaced with a "NoAccess".) 4.7. Menus This section describes how to configure different parts of the Maximus menu system. 4.7.1. Customizing Menu Options The system menus are completely redefinable and offer a great deal of flexibility. However, if you are just starting a new Maximus system, it is best to skip making major menu changes until your system is up and running. However, even novices can change the access levels required to access particular commands in the menus control file. The access control string (ACS) for each menu option is normally located in the second or third column of each menu option. You can easily change these ACS definitions to suit your own system's privilege level or user class scheme. You can also modify the "Command as it appears to the user" field with a certain degree of safety. This command is what is shown on the screen when Novice-level menus are active. However, when changing menu commands, ensure that the first character in the command is unique among all options on that menu. When the user enters a letter at a menu, Maximus will process all commands that begin with that letter. Hence, if you use a letter that has already been used by another com- mand, confusing things will happen when a user gets to that menu. 4.7.2. Custom Menu Display Files Maximus allows you to create custom menus with relative ease. Instead of displaying the standard yellow and gray menu, Maximus can be configured to display a user-defined .mec or .bbs file. 4. Customization 80 To add a custom menu file, simply insert a MenuFile keyword at the top of the appropriate menu definition in menus.ctl. Some of the following tips may be helpful when creating cus- tom menus: * When using a custom menu that contains the [cls] token, the output from some of the internal commands (such as the Ver- sion command) may disappear, since the [cls] token in the menu erases it before it can be seen. To solve this problem, you must link a Press_Enter menu op- tion after the appropriate command. This will cause Maximus to wait until the user presses before redisplaying the menu. For more details, please see section 4.7.3. For example, to make Maximus wait after displaying the ver- sion screen, you can use something like this: Version Demoted "Version" NoDsp Press_Enter Demoted "V" This method is described in more detail in the following section. * When designing a custom menu with an input prompt at the bottom, you may have some trouble getting the cursor to stop in the appropriate place. Most text editors automati- cally insert an after the last line of the file; since Maximus reads the entire file, this causes the cursor to skip down to the next line when the entire file is dis- played. Three possible solutions to this problem are: 1.Use a text editor that does not insert carriage returns at the end of files. 2.If you are using a .mec file to create the menu, insert a [quit] token where you want the cursor to stop. As soon as Maximus encounters this token, it will stop dis- playing the file without displaying the extra carriage return. 3.If you are creating the menu file manually, you can in- sert the compiled equivalent of the [quit] token di- rectly into the .bbs file. The compiled equivalent is "Q". 4. Customization 81 4.7.3. Linking Menu Options When working with custom menus, the output of some of inter- nal Maximus menu options may occasionally not fit in with the layout of your menu. For example, if you are using a custom menu that always clears the screen, the output of some com- mands may disappear before the user has a chance to read it. The solution to this problem is menu option linking. When the user selects a key, Maximus will search the entire menu for a menu option that has a description starting with that key. When it finds one, it executes the specified op- tion. However, Maximus continues to search for other commands with that key, even after executing the first menu command. This means that a number of menu commands can be tied to a single keystroke. (To prevent the second and subsequent menu options from appearing on the menu, use the NoDsp modifier in front of the menu option.) Consider this scenario: a user selects a message area and be- gins to read messages. The standard message menu is quite large and it leaves little space on-screen for messages. How- ever, if you include something like this on the message menu: Read_Next Demoted "Next Msg" NoDsp Display_Menu READMSG Demoted "N" Read_Previous Demoted "Previous Msg" NoDsp Display_Menu READMSG Demoted "P" after the user selects a message with Next or Prior, Maximus will automatically display the READMSG menu. This menu can then display only a limited subset of commands that are use- ful when reading messages. 4.8. QWK Mail Packing Maximus includes a built-in QWK mail facility for off-line mail reading. This feature allows callers to log on, pack up messages from one or more message areas, and download a com- pressed mail bundle for off-line reading and reply. The packer is fully integrated with the rest of the BBS, and the packer will automatically adjust itself as message areas are added to or deleted from your system. All of the QWK-specific information is stored in the reader control file. To customize the off-line reader, you should edit a copy of reader.ctl with a text editor and make the following modifications. 4. Customization 82 * You must give a unique name (of up to 8 characters) for the Packet Name keyword. This keyword is used when creating QWK packets to send to your users. (Do not include the .qwk ex- tension.) Try to make this name describe your BBS in some way, such as an abbreviation truncated to eight characters. * You should also modify the Phone Number keyword to reflect your system's true phone number. Maximus does not use this information, but users who download QWK packets will re- ceive this phone number along with their mail. * You may also want to customize the Max Messages keyword. If you run a busy system and wish to restrict callers from downloading more than 200 messages at a time, you can set a maximum value here. In the distribution control file, users are prevented from downloading more than 1200 messages at a time. To completely disable this limit, comment out the Max Messages keyword. Beyond this initial configuration, the QWK packer is com- pletely self-maintaining. No extra maintenance is required. However, if you would like to add extra features to the off- line mail packets, such as bulletin listings and new file lists, please see section 5.3. 4.9. Multilingual Support Maximus 3.0 is fully multilingual. Up to eight different lan- guage files can be defined in the system language control file, and users can switch between languages at any time (using the Chg_Language option on the Change Setup menu). The language files contain all of the text strings that Maxi- mus sends to the user, including prompts, system messages and command keys. A separate language file can be created to use "Oui" and "Non" instead of "Yes" and "No"; even the key- strokes for various internal options can be changed. Language files are divided into two distinct sections. Each language file has a set of strings to be displayed to the user, and each also has a second set of strings to be dis- played to the SysOp. By default, the SysOp always sees the text strings contained in the first language file defined in language.ctl, regardless of the language selected by the user. This means that the user can go through a set of menus in German, but the SysOp will still be able to read the pop-up menus and the system log file in English. Maximus's multilingual support can be used to define differ- ent prompts, menus and custom display files for each individ- 4. Customization 83 ual language. Language files can be modified by simply edit- ing the appropriate .mad file with a text editor. However, a separate set of menus needs to be designed by the SysOp, since the screen display would look odd if the prompts were in German but the menu options were in English. Like- wise, display files should also be changed (using the [iflang] token) to accommodate new languages. The main method for supporting alternate menus and display files is to use the "%Y" external program translation charac- ter. When used in menu and display filenames, the "%Y" se- quence translates to the user's current language number, with 0 being the first language defined in language.ctl, 1 being the second language, and so on. The "%Y" sequence can be used in many places, including in the First Menu definition in the system control file, in all Display_Menu options. In addition, the text "+Y" can be used in all Display_File commands. (Note that Display_File re- quires a "plus-Y" instead of a "percent-Y".) For example, if you had the following language statements in language.ctl: Language English Language Deutsch using a First Menu MAIN %Y statement in the system control file tells Maximus to display MAIN0 for English callers, while MAIN1 will be displayed to German callers. You can also use this methodology for MECCA files. You can either use a Display_File D:\Path\File%Y option to display different physical files for each language, or you can embed the [iflang] token within an individual display file to make decisions based on the current language. By default, Maximus stores a user's language preference in the user file. However, if you want Maximus to prompt the user for a new language during every log-on, you can place the [menu_cmd chg_language] token at the top of welcome.mec. 5. Maximus Subsystems 5.1. Waiting for Callers Subsystem Maximus includes internal support for a Waiting for Caller (WFC) subsystem. This subsystem allows Maximus to initialize the modem, wait for a call, answer the phone, and pass con- trol to the main portion of the BBS. The WFC subsystem can be used on all nodes of a system, on selected nodes, or on no nodes. Nodes which do not use the WFC subsystem require an external "front end" program to answer the phone. 5.1.1. Starting WFC When starting Maximus, the WFC subsystem is enabled using the "-w" command line switch. Optionally, the "-p" and "-b" pa- rameters can be used to override the COM port and baud rate. If you specify just "-w", WFC starts up using the port and speed defined in the system control file. Before enabling WFC mode, you must ensure that the modem strings in the system control file are configured correctly. The distribution version of Maximus is configured to support most Hayes-compatible modems. However, if the WFC module does not seem to work, you may need to modify certain definitions (such as the Answer and Init strings) to make it perform as expected. In particular, the distribution version of Maximus attempts to use "manual answer mode." Instead of telling the modem to automatically answer the phone when it detects a ring, Maxi- mus will perform the ring checking on its own. This is the preferred method of operation, since the phone is only an- swered when Maximus is ready to accept a call. However, manual phone answering may not be compatible with all modems. If you wish to disable manual answering, change the last part of the Init string to read "S0=1" instead of "S0=0". You must also comment out the Answer string. This in- structs your modem to answer the phone automatically. 5.1.2. Screen Display and SysOp Keys After WFC mode initializes, four multicolored windows appear on the screen: 5. Maximus Subsystems 86 The first window, "Status," displays the time until the next system event, the current modem status, the number of calls made to your system (both today and in total), and the name of the last caller on your system. The second window, "Modem Responses," displays a scrolling list of responses from the modem. Maximus uses this window for storing result codes that are sent in response to command strings. (Maximus will automatically filter out any "OK" re- sults, so only meaningful responses will be displayed.) The third window, "Current Activity," displays system log messages as they occur. The fourth window, "SysOp Keys," contains descriptions for all of the keys that can be pressed while in WFC mode. Pressing starts Maximus in local mode. Maximus takes the phone off-hook and commences the normal log-on procedure. Pressing invokes a shell to the DOS or OS/2 command interpreter. Maximus takes the modem off-hook while you are in the shell. You can perform file maintenance, make changes to your batch files, or do other routine operations while in the shell. Type "exit" to return to Maximus. Pressing instructs Maximus to take the system down. Maximus will put the phone off-hook, clear the screen, and exit to your batch file with errorlevel 1. When using the internal WFC subsystem, Maximus also supports external events. External events can be used to run a par- ticular program at a certain time of day, normally by exiting to your batch file with a certain errorlevel. For more information on external events, please see section 18.11. For more information on installing WFC, please see section 3.9. 5.2. Local File Attaches 5.2.1. Description Maximus allows users to create local file attaches. A local file attach is a file that is associated with a message cre- ated by a user. To enable local file attaches, ensure that you have defined an Attach Path keyword in max.ctl. This keyword tells Maximus where to store uploaded files. 5. Maximus Subsystems 87 Next, add the Style Attach attribute to Squish-format mes- sage areas that you want to use for local file attaches. (The local file attach feature cannot be used with *.MSG areas.) To create a file attach, users simply change to that message area and enter a message. When the cursor is on the attrib- utes field in the message header (which is where the "Pvt" flag is normally displayed), the user can enable the "file attach" flag. (In the English version of Maximus, the A key is used to create a file attach.) After setting the flag, the user can continue to fill out the message header and create the message itself. After the mes- sage has been saved, Maximus will prompt the user to upload the file to be attached to the message. When the transfer is complete, Maximus will compress the at- tached file (using the archiver specified by Attach Archiver in the system control file) and store it in the file attach directory. Later, when the addressee displays the message, the user is given the option to download the file attach. Maximus will then decompress the file and send it to the user. In addition, a user can use the Msg_Download_Attach menu op- tion to display a list of all unreceived files attached to that user. 5.2.2. SysOp Configuration The local file attach subsystem is mostly self-maintaining. Using the Kill Attach keyword in the system control file, you can configure Maximus to automatically delete files after they have been received by users. The Message Edit Ask LocalAttach keyword can also be used to control the privilege level required to create a local file attach. If you expect to receive a lot of file attaches in one par- ticular message area, the holding area for the attaches can be overridden on an area-by-area basis using the AttachPath keyword in your message area control file. In addition, the [msg_fileattach] MECCA token can be used to conditionally display text if any unreceived file attaches are waiting for the current user. Finally, Maximus also supports inbound FTS-0001 style "NetMail file attaches" in areas that have both Style Net and Style Attach. 5. Maximus Subsystems 88 When Maximus encounters a message in a NetMail area with the network file attach bit set, it looks in the directory speci- fied by Path Inbound in the system control file. In that di- rectory, it tries to find a file with the name specified on the message's subject line. If that file exists, Maximus treats it as a file attach and sends it to the user. Warni If you add the Style Attach attribute to a NetMail area, you ng! may be compromising the security of your inbound directory. Do not use the local file attach feature in NetMail areas un- less you trust all of the users who have access to that area. 5.3. QWK Mail Packer From the Off-Line Reader menu, Maximus allows users to down- load mail to be read off-line. Maximus supports the popular QWK format, so the users can use popular third-party products such as Deluxe2, Qmail, SLMR and OFFLINE to read the packets generated by Maximus. Instructions on configuring the QWK packer are given in sec- tion 4.8. 5.3.1. Bulletins, News Files and File Lists QWK packets can include information other than just mail, such as bulletins, file lists and news files. Maximus sup- ports these files in an extremely simple manner: any file placed in the \max\olr directory is automatically placed in all mail packets sent to users. In addition, if a user has unreceived local file attaches, they are automatically placed in the QWK packet. The QWK format defines the names of several standard files that can be included in QWK packets. To use these features, simply place a file in the \max\olr directory with one of the filenames given in Table 5.1: Table 5.1 QWK Packet Filenames Filename Description hello Displayed when the off-line reader first starts up. This is typically the equivalent of your welcome.bbs screen. This file should be ANSI only; no AVATAR colors or MECCA codes are allowed. news Your BBS news file, equivalent to the \max\misc\bulletin.bbs file. This is usually available as an option from the QWK reader's 5. Maximus Subsystems 89 main menu. This is normally a flat ASCII file with no graphics. goodbye Displayed when the reader closes the packet from your BBS. This file can include ANSI graphics. blt-1.1 Bulletin file 1. This is usually displayed as an option on the reader's main menu. In this case, the file extension is ".1", but you can use anything from ".1" to ".99" to provide up to 99 different bulletins. newfiles.dat This file contains a new files listing for your BBS. Maximus does not generate this file for you, but a third-party file list generator can be configured to generate a file list and place it in the \max\olr di- rectory. Again, all of these files are optional. However, since Maxi- mus packs up everything in the \max\olr directory when creat- ing a packet for the remote system, simply placing one of the above files in that directory will cause it to be displayed on the remote side. 5.3.2. Message Packing for Remote Users The default Maximus configuration includes an Off-Line Reader menu, but mail can also be packed from the regular message menu. All of the QWK mail packing functionality is built into the Browse command; in fact, the Download command on the Off- Line Reader menu is a simple macro that invokes the Browse command. The default Download command passes the options t n p to Browse. This requests a scan of tagged areas, searching for new messages, and for the messages to be packed in QWK for- mat. Obviously, the flexibility of the Browse command allows many other search operations to be performed. Users can spec- ify a selective download by using the search function (complete with and and or operators). Using Browse, messages can also be packed only from the current area, rather than all tagged message areas. After selecting the Pack option from the Browse menu, Maximus will gather all of the specified messages, display some sta- tistics on the packed messages, and ask the user whether or not the messages should be prepared for download. If so, Maximus will compress the packet with the user's default ar- chiving program, count to ten (giving the user a chance to abort), and send the file using the default transfer proto- col. 5. Maximus Subsystems 90 The Off-Line Reader menu also includes an upload option. This option allows the user to upload a .rep file created by an off-line reader. The .rep file is automatically decompressed, regardless of the archive type or the user's default ar- chiver, and the messages within are placed in the appropriate message area. When processing uploaded messages, the QWK upload command al- ways checks to ensure that the user has enough access to write a message in a given message area. To do this, it first examines the definition for the target message area. If the area has a custom MenuName defined, Maximus will read that menu. Otherwise, Maximus will read the menu called "MESSAGE". Next, Maximus will search that menu for an option of type Msg_Upload. Maximus checks the ACS for that option and com- pares it against the user's access level. If the check suc- ceeds, the user is allowed to upload the message. This access control mechanism has one main implication: un- less you use a specific MenuName definition for all of your message areas, you must have a menu with a name of "MESSAGE," and that area must have a Msg_Upload option with an ACS that makes it accessible to users. 5.3.3. Local Mail Packing The QWK feature can also be used by local callers. After com- pressing a packet for a local user, Maximus will leave the packed QWK file in the off-line reader directory. (By de- fault, the file will be in the \max\olr\node## directory, where ## is the current task number in hexadecimal.) In local mode, if you want to "upload" a .rep packet, select the Upload option from the reader menu. If the caller is lo- cal, Maximus will prompt for the path and filename of the .rep packet. Enter the location of the packet (as created by your off-line reader), and Maximus will decompress and import the messages in that packet. 5.3.4. Unattended Mail Packing In conjunction with the "-j" command line parameter, Maximus can compress mail packets for users on a daily basis, without operator or user intervention. At predefined intervals, you can set up a system event (when running in WFC mode) to call Maximus with the "-j" command line parameter. The -j parameter tells Maximus to insert a list of keystrokes in the keyboard buffer, as if the key- strokes were entered by a local user. You can set up these 5. Maximus Subsystems 91 keystrokes so that Maximus will log on as a certain user, execute a download command, log off, and have your batch files copy the created QWK packet to a file area. By doing this, you can pack mail for certain users in ad- vance, or you can use it to save mail for yourself while on vacation. Since the packing process is completely controlled by the keystrokes you specify for the -j parameter, almost any type of mail download is possible. For example, suppose that the following keystrokes are re- quired to move from the bulletin menu (displayed just after the user enters a password) to the off-line reader menu, download a packet, and log off: n;o;d;y;m;g To instruct Maximus to log on as a specific user and execute these keystrokes, you only need to add the prologue that specifies the user name and password. Consequently, the fol- lowing command sequence can be used to automatically pack mail for a user, assuming the default menu and bulletin file structure. max "-jJoe User;y;Password;n;o;d;y;m;g" Note! If your log-on sequence includes a "Press ENTER to continue" prompt, you should specify the "|" character where you would normally press the key. In addition, you can pack mail for multiple users by simply replicating the above line in your batch file. However, your batch file must also copy the QWK packet from the \max\olr\node## directory into a safe place after each mail pack. 5.3.5. NetMail Messages The QWK format was not designed with NetMail messages in mind, so users must follow a special convention when reading and replying to NetMail messages. When downloading messages from a NetMail area, the first line of each message will look like this: From: where is the network address of the message sender. Since there is no place in the QWK header to store the true message origination address, Maximus places that information in the message body instead. 5. Maximus Subsystems 92 When creating or replying to a NetMail message, Maximus ex- pects to find a "To: " line as the first line in the message body. For example, to send a NetMail message to the address 1:123/456, the first line of the message must look like this: To: 1:123/456 The "To:" header will be stripped before the message is writ- ten to the Maximus message base, so your QWK messages will look like normal messages to everyone else. When replying to a message, there is an easy way to set the destination address; simply quote the original message and change the "From:" line to a "To:" line (after removing any quoting marks). This ensures that the destination address is correct, and Maximus will ensure that your reply is sent to the intended destination. 5.4. RIPscrip Support Maximus includes internal support for RIPscrip graphics com- mands. RIPscrip is a terminal protocol designed by TeleGrafix Communications, Inc. The RIPscrip protocol includes facili- ties for displaying buttons, icons and various other forms of graphics over a serial line. RIPscrip also allows the remote user to use a mouse to access system commands and features. The distribution version of Maximus comes with support for RIPscrip graphics, including a number of sample screens, but this support must be enabled before it can be selected by us- ers. To enable RIPscrip graphics support, set the Min RIP Baud definition (in the system control file) to the minimum speed that you require for users to be able to view RIPscrip graphics. (In most cases, setting this to 2400 or 9600 is usually a good idea.) After RIPscrip support is enabled, users will be able to se- lect RIPscrip graphics using the Chg_RIP command on the Change Setup menu. In addition, new users will be prompted for RIPscrip graphics support when they log on. Maximus does not display RIPscrip graphics on the SysOp screen. (In fact, the local output routines include a "smart" filter that automatically strip out RIPscrip graphics se- quences from local output.) However, Maximus includes the following RIPscrip-specific features: * When instructed to display a .bbs file, Maximus will first look for a file with a .rbs extension. To add a RIPscrip- 5. Maximus Subsystems 93 specific version of one of your system display files, sim- ply create the RIPscrip file using the same base name as the standard display file, but use a .rbs extension instead of .bbs. To create .rbs files, you have one of two options: 1.Use a third-party RIPscrip editor to create the .rbs file directly. 2.Use MECCA to compile a .mer file into a .rbs file. In addition to the standard .mec extension, MECCA also rec- ognizes .mer files as containing MECCA source. You can embed MECCA commands inside RIPscrip graphics in this manner. * If you decide not to create separate .rbs files, small RIPscrip sequences can still be included in standard dis- play files. To mark a section of a MECCA file so that it is only displayed to callers with RIPscrip support, use the [rip] and [endrip] tokens around the RIPscrip-specific text. * Similarly, the [norip] and [endrip] tokens can be used to mark a section of a MECCA file that is only displayed to callers who do not support RIPscrip graphics. * With RIPscrip enabled, many of the system prompts are dis- played using RIPscrip-specific buttons and features. * An alternate set of RIPscrip strings are used in the lan- guage file. The standard english.mad language file is con- figured to return different display strings for some system display fields if the user supports RIPscrip graphics. This allows the SysOp to define one set of responses for text- based callers and a second set of responses for RIPscrip callers. * The full-screen editor and full-screen reader are RIPscrip- aware. The message header is drawn using RIPscrip commands, and the header remains on the screen even when entering the message editor. * Maximus automatically parses the "set text window" and "set font" RIPscrip sequences. It uses this information to ad- just the user's virtual terminal size, control the "More [Y,n,=]?" prompts, size the full-screen editor, and so on. * A number of RIPscrip-specific display files are included with the standard distribution. * Maximus can automatically send RIPscrip scene and icon files to the remote user. The MECCA [ripsend] and 5. Maximus Subsystems 94 [riphasfile] tokens can be used to conditionally send a set of scene or icon files to the remote user. The equivalent MEX functions, rip_send and rip_hasfile, can also be used for this task. * When a user logs on, if that user's profile indicates that RIPscrip graphics are supported, Maximus will automatically send a query to the user's terminal program. If the termi- nal program does not report that it supports RIPscrip graphics, Maximus will display a warning to the user and offer to disable RIPscrip support. * Maximus keeps track of a "RIP path." This path is where Maximus looks for icon and scene files that are referenced by the [ripsend] and [ripdisplay] tokens. This path can be changed using the [rippath] MECCA token. (To implement mul- tilingual RIPscrip support, you may want to have a separate directory of RIPscrip files for each supported language.) * For consistency, when RIPscrip graphics are selected, Maxi- mus forces the user to enable hotkeys, the full-screen reader and screen clears. * Menu options can be made available only to RIPscrip callers by using the RIP modifier in front of a menu option. Simi- larly, menu options can be made available only to callers without RIPscrip support by using the NoRIP modifier. * If a user enables RIPscrip support after failing the inter- nal RIPscrip-detection test, Maximus will note this in the system log file. When Maximus queries the remote system and fails to obtain an intelligent response, Maximus will retry the command up to three times before aborting. At this point, Maximus assumes that the caller enabled RIPscrip graphics in error, so RIPscrip graphics are auto- matically disabled and Maximus displays a warning to the user. 5.5. User Expiration and Subscriptions Maximus includes an internal user subscription and expiry subsystem. Callers can be set to expire based on the current date, or also based on system time used (in minutes). When a caller expires, Maximus can optionally demote that caller to a lower privilege level, hang up, or delete the user's ac- count. To access the user subscription system, start up the Maximus user editor by running "max -uq". 5. Maximus Subsystems 95 To set up a user subscription, first press the E key to se- lect the expiry menu. Next, press E again to set the "expire by" method: If you want the user to expire after a certain date, select D. If you want the user to expire after having used a certain number of minutes on the system, select M. If you want to disable the subscription system, select N. Next, press E again to go back to the expiry menu, and press A to select an expiry action. This field controls how Maximus treats the user when the subscription expires. If you want Maximus to hang up and delete the user's account, select A. To have Maximus demote the user to a lower privilege level, select D and enter the new privilege level for the user. If you do not want Maximus to do anything when the subscription expires, select N. Finally, press E one last time to go back to the expiry menu, and press D to select the date/time for the user expiration. If you previously selected date in the "expire by" field, en- ter the user's expiry date here. Otherwise, enter the number of on-line minutes to be credited to the user. After setting up the expiry controls for a user, the sub- scription system is completely self-maintaining. When a user expires, the user's privilege level will be modified accord- ingly as soon as the user logs in. In addition, when a user expires using the "by date" expira- tion method, the file \max\misc\xpdate.bbs is shown. Simi- larly, when a user expires due to running out of on-line min- utes, Maximus will display the \max\misc\xptime.bbs file. 5.6. Message Tracking System 5.6.1. Introduction Maximus includes an internal Message Tracking System (MTS). This feature makes it easy for organizations to ensure that technical support queries are answered on a timely basis, and it provides audit trails for technical support queries. MTS is only supported for message areas stored in the Squish mes- sage format. Message areas can be designated as MTS areas, which means that Maximus will automatically place all messages entered into those areas in the MTS database. Whenever a message is created in an MTS area, Maximus will automatically set a de- fault message priority, status, and message owner. These MTS 5. Maximus Subsystems 96 fields are hidden from normal users, but they can be viewed and modified by technical support personnel. The owner field is used to "assign" a message to a specific support representative. After the representative assumes own- ership of a message, it becomes that representative's respon- sibility to ensure that the message is handled appropriately. MTS uses relational database links to store owner informa- tion, thereby making it easy to perform mass ownership trans- fers. For example, if a particular representative goes on va- cation for a number of weeks, a single database entry can be changed by the MTS administrator to assign all of the repre- sentative's messages to another user. The change can then be reversed when the original representative returns. Maximus handles this by assigning a four-character "alias" to each representative (or in MTS terminology, to each modera- tor). A message is actually owned by an specific alias, which is in turn linked to a moderator (representative). In terms of manipulating MTS data, the system works best when the moderator can log onto Maximus to read and reply to mes- sages. After a moderator replies to a message, Maximus pro- vides an option that allows the moderator to change the status of that message, if necessary. The Track menu option can also be used to modify the message's owner and priority, manually insert messages in the tracking database, generate reports, and perform database administration functions. MTS also works with off-line QWK mail readers. QWK support is implemented by placing a small template at the beginning of each tracked message in a .qwk packet. (This template is only placed in the QWK message if the user's access level is at least equal to the privilege level specified by Track View.) To modify the status of a message from a QWK reader, the off- line database moderator can simply quote that template in the reply message, marking an "X" in the appropriate box with a standard text editor. Maximus will automatically strip the template from the uploaded message and make the required changes to the message database. MTS can also be used as a central tracking system for mes- sages created on remote systems. Even if a message was en- tered on another system and transmitted as an EchoMail mes- sage, when that message arrives on a Maximus system that runs MTS, it will be entered in the database when the message is accessed or read by any user. (Distributed tracking databases are not supported, since all of the tracking files must be stored on one system. However, tracking of distributed mes- sage bases is supported by placing all imported messages into the local tracking database.) 5. Maximus Subsystems 97 By default, Maximus will add a message to the tracking data- base if: 1.the message area is declared with the "Audit" keyword, 2.the message area has a default owner assigned, and 3.the user entering the message is not the default owner. MTS also allows the moderators to generate reports based on tracking information. Reports can be generated on-line, writ- ten to a file, or even included in a QWK packet. The reports can be configured so that only a certain subset of tracked messages are displayed; for example, a moderator can easily request a report of all "Open" or "Working" messages, with a priority of "Urgent" or "Critical," owned by a specific mod- erators, across all of the message areas on the system. 5.6.2. Information Stored by MTS The Message Tracking System stores the following information for each message in its database: * The message owner, stored as a four-character alias. * The message status. The status field contains one of the following values: * New * Open * Working * Closed This field allows the moderators and the database adminis- trator to assess the current status of a problem report. * The message priority This field contains one of the follow- ing priority levels: * Notify * Low * Normal * Urgent * Critical This field can be used to assign a relative importance to a particular message. * The message audit trail. The audit trail is actually stored as part of the message body. The Msg_Kludges menu option can be used to toggle display of the audit trail. 5. Maximus Subsystems 98 * A message comment. This is also stored as part of the mes- sage body, but it can be examined or modified using the Modify command on the Track menu. The tracking mechanism is completely transparent to the end user. The MTS data can be displayed in the message header when a message is shown, but this information is only avail- able to the MTS moderators. 5.6.3. Configuration This section describes the settings and definitions that are required to enable support for MTS: To use MTS, the keywords listed in Table 5.2 must be present in the system control file. Please see section 18.2.4 for more information on these keywords: Table 5.2 MTS System Keywords Keyword Description Track Base Specifies the base path and filename for the MTS database. Track View An ACS that controls who can view tracking information in messages. Track Modify An ACS that controls who is allowed to ac- cess the Track/Admin menu and modify track- ing information. Track Exclude An optional file listing users whose mes- sages are to be excluded from the tracking database. To configure a message area to support MTS, the keywords listed in Table 5.3 must be added to the definition in the message area control file. Please see section 18.6 for more information on these keywords. Table 5.3 MTS Message Area Keywords Keyword Description Style Audit Indicates that the area supports MTS mes- sages. Owner Indicates the alias of the default owner for the area. See the following section for information on creating modera- tor/alias links. 5. Maximus Subsystems 99 5.6.4. Using MTS Administrators can access the MTS database using the Msg_Track command (which is normally the "%" option on the message menu). The main MTS menu contains the options shown below in Table 5.4: Table 5.4 MTS Main Menu Command Description Insert Manually inserts a message into the MTS database Modify Modify the tracking information for a spe- cific message Report Display a report based on messages in the MTS database Administration Change area and owner links or remove mes- sages. 5.6.4.1. Insert The Insert command allows a moderator to add an existing mes- sage to the tracking database. Normally, this command need not be used, since messages in MTS areas are automatically added to the tracking database when they are created. The Insert command prompts the user to enter the message num- ber of the message to add, plus the new owner for the mes- sage. The owner can be any of the existing moderators in the tracking database. The new message is assigned a priority of normal and a status of new. 5.6.4.2. Modify The Modify command allows a moderator to change the status of an existing message. This command allows moderators to modify the message's owner, status, priority and message comment. All changes made to the message are added to the audit trail. Every time a moderator replies to a message that he/she owns, Maximus will prompt the moderator for a new message status. Almost all status changes occur when a moderator replies to a message, so most moderators will not need to use this command on a frequent basis. 5. Maximus Subsystems 100 5.6.4.3. Report The Report command allows a moderator to generate a report of messages in the tracking database. The moderator can select a set of criteria for displaying information from the database, including message area, status, priority and owner. The tracking report contains a list of each message that matches the specified criteria, including the tracking iden- tifier of each message, the date it was placed in the track- ing system, the message status, priority and owner, and the location of the message (area and message number). 5.6.4.4. Administration The administration menu contains options for tasks which do not normally need to be performed on a daily basis. Modera- tors must have a privilege level of at least Track Modify to access the administration menu. Owner/alias links. This menu allows the owner/area links to be created or modified. In the tracking database, the message owner is recorded as a four-letter abbreviation. The owner/alias link is used to associate a specific moderator with an abbreviation. Use the Add command to provide a four-character alias, fol- lowed by the name of the owner to associate with that alias. Use the Delete option to remove an existing owner/alias link. Use the List option to list existing owner/alias links. Area/owner links. This menu allows the default area owner links to be modified. Although SILT will automatically update these entries based on the Owner keyword in the message area definition, this menu can be used to manually add, delete, or list the current owner/area links. The area/owner links control the default owner for newly- created messages in the specified area. Unless an area has a default owner, messages entered in the area will not be added to the MTS database. Remove message. This option removes a message from the MTS database. The user is prompted to enter a message number, and the message matching that number is then removed from the da- tabase. 5. Maximus Subsystems 101 5.6.5. QWK Message Processing In addition to manipulating tracking data while on-line, MTS can also be accessed through the QWK mail packer. When Maxi- mus packs a message that is stored in the MTS database, it adds a special "tracking header" and "tracking footer" to the top and bottom of the message. A user's privilege level must satisfy the Track View ACS in order to be able to see this information. The first header line, ACTRACK, contains the MTS identifier for the message being downloaded. This is a used as a unique identifier in the MTS database. The second header, STATUS, contains the status of the mes- sage. The curly braces, ("{ }") indicate the current status of the message. The other fields have square brackets ("[ ]") to indicate the other possible settings for the message status. In the message trailer, the OWNER line contains the four- letter identifier for the owner of the message. The priority line, PRTY, indicates the current priority of the message. As before, the braces indicate the current pri- ority, and the square brackets indicate the possible priority selections. The comment line is a one-line field that the moderators can use to assign a comment to each message. The comment can be as long as will fit inside the square brackets. The QWK moderator can modify these headers and footers in a reply message, causing Maximus to change the status of the message or perform some other operation when the .rep packet is uploaded. To communicate a change back to Maximus, the moderator must reply to the message, using the off-line reader's quoting feature to copy the tracking lines into the reply. The ACTRACK line must always be quoted, since it gives Maxi- mus the information that it needs to link the reply with the original message. Following the ACTRACK line, any of the other tracking lines can be quoted (and in any order). To change the status or priority of a message, simply put an "x" inside the set of square brackets for the desired status/priority. Do not add or delete any characters from the line; simply quote it ver- batim and use overtype mode for making any necessary modifi- cations. 5. Maximus Subsystems 102 The owner and comment lines can be changed by overtyping in a similar manner. If an "x" is placed in the "Discard Reply Text" checkbox, Maximus will throw away the reply message after processing the tracking database changes. This should be used if a mod- erator does not wish to post a message but still wants to make a change to the message status. When saving a message to disk, Maximus will automatically strip out the tracking lines (and the preceding quote marks). The tracking reply messages are uploaded normally, just like any other .rep packets. Upon upload, Maximus will display a few status lines indicating the changes that it is making to the tracking database. 5.6.6. EchoMail support Maximus also supports tracking of EchoMail messages. Messages can be imported into the tracking database by a standard EchoMail tosser, and Maximus will automatically add the mes- sages to the tracking database as they are read by users. Maximus will automatically add remotely-entered messages which meet the following criteria: 1.The message area is already configured to add locally- entered messages, including the Style Audit and Owner definitions. 2.The message does not contain an "ACGHOST" kludge line. 3.The "local" attribute is not set. 4.The "date written" field is not the same as the "date arrival" field. 5.6.7. Audit Trails Maximus keeps an audit trail for all messages in the tracking database. This audit trail takes the form of timestamped en- tries which are added to the bottom of each message. An entry is added to the audit trail when: 1.the message is entered in the database, 2.the message is removed from the database, 3.the message status is changed, 4.the message priority is changed, 5.the message owner is changed, or 6.the message comment is changed. To view the auditing information on-line, use the "!" key (Msg_Kludges) to toggle the display of auditing information 5. Maximus Subsystems 103 and other kludge lines. Auditing information is also avail- able to off-line reader users whose privilege level is at least that given by the Message Show Ctl_A definition in the system control file. 5.6.8. Import/Export Facilities MTS provides facilities for exporting and importing the tracking database to a delimited ASCII file. The TRACKEXP program is used to export the tracking database. It creates the files shown below in Table 5.5: Table 5.5 Tracking Export Data Files Filename Description trkmsg.dbf Message ID / status / owner / location trkarea.dbf Default area / owner links trkown.dbf Owner / alias links The format of trkmsg.dbf is given below. The system creates one line per message. All fields are enclosed in double quotes: ,,,,,, ,