Maximus-CBCS Version 2.00 Operations Manual
Copyright 1990, 1991 by Scott J. Dudley. All rights reserved.
Created November 3, 1991.
Documentation produced by Bob Davis, Scott Dudley,
Jesse David Hollington and Erik Van Riper,
with Don Dawson and Hubert Lai.
TABLE OF CONTENTS
LICENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 6
Notes from the Author . . . . . . . . . . . . . . . . . 6
Maximus, Money and You . . . . . . . . . . . . . . . . . 7
Credits . . . . . . . . . . . . . . . . . . . . . . . . 9
It's Canadian, eh? . . . . . . . . . . . . . . . . . . . 11
SYSTEM REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . 12
MAXIMUS OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 13
Logging On . . . . . . . . . . . . . . . . . . . . . . . 13
The Main Menu . . . . . . . . . . . . . . . . . . . . . 15
The Message Section . . . . . . . . . . . . . . . . . . 18
The Message Menu . . . . . . . . . . . . . . . . . . . . 19
Message Entry . . . . . . . . . . . . . . . . . . . . . 26
Message Editors . . . . . . . . . . . . . . . . . . . . 27
The File Menu . . . . . . . . . . . . . . . . . . . . . 31
The Change Setup Menu . . . . . . . . . . . . . . . . . 35
The SysOp Menu . . . . . . . . . . . . . . . . . . . . . 39
The Chat Menu . . . . . . . . . . . . . . . . . . . . . 40
The Off-Line Reader Menu . . . . . . . . . . . . . . . . 41
INSTALLATION INSTRUCTIONS . . . . . . . . . . . . . . . . . . 43
Step 1: Where do I put these files? . . . . . . . . . . 43
Step 2: Configuring your Modem . . . . . . . . . . . . 44
Step 3: Installing a FOSSIL . . . . . . . . . . . . . . 46
Step 4: Editing Configuration Files . . . . . . . . . . 48
Step 5: Setting Up Control Files . . . . . . . . . . . 50
Step 6: Compiling the Control Files . . . . . . . . . . 51
Step 7: Starting Maximus . . . . . . . . . . . . . . . 52
Step 8: Support for Remote Callers . . . . . . . . . . 53
Step 9: Events and Yelling . . . . . . . . . . . . . . 62
Step 10: About Priv Levels and Locks . . . . . . . . . 64
Step 11: Customizing *.BBS Files . . . . . . . . . . . 66
Step 12: Customizing Msg/File Areas . . . . . . . . . . 68
Step 13: Maintaining File Areas . . . . . . . . . . . . 72
Step 14: Customizing Menus . . . . . . . . . . . . . . 76
Step 15: Configuring the QWK Mail Packer . . . . . . . 77
Step 16: Miscellaneous Information . . . . . . . . . . 78
MAXIMUS UTILITY DOCUMENTATION . . . . . . . . . . . . . . . . 79
ACCEM: MECCA Decompiler . . . . . . . . . . . . . . . . 79
ANSI2BBS/MEC: ANSI to MEC conversion . . . . . . . . . 81
CVTUSR: User File Conversions . . . . . . . . . . . . . 83
EDITCALL: Call Fudging Utility . . . . . . . . . . . . 85
FB: File Database Compiler . . . . . . . . . . . . . . 86
MAID: Language File Compiler . . . . . . . . . . . . . 89
MECCA: Display File Compiler . . . . . . . . . . . . . 91
MR: Maximus Renumbering Program . . . . . . . . . . . . 92
ORACLE: Display File Viewer . . . . . . . . . . . . . . 93
SCANBLD: Database Builder . . . . . . . . . . . . . . . 95
SILT: Control File Compiler . . . . . . . . . . . . . . 98
RUNNING EXTERNAL PROGRAMS . . . . . . . . . . . . . . . . . . 100
Execution Methods . . . . . . . . . . . . . . . . . . . 100
ErrorLevel Batch Files . . . . . . . . . . . . . . . . . 101
Restarting After Chain/Errorlevel . . . . . . . . . . . 103
External Program Translation Characters . . . . . . . . 105
Running Doors . . . . . . . . . . . . . . . . . . . . . 108
On-Line User Record Modification . . . . . . . . . . . . 112
MULTI-LINE OPERATION GUIDE . . . . . . . . . . . . . . . . . 113
Installation . . . . . . . . . . . . . . . . . . . . . . 113
Multi-Node Chat Operation . . . . . . . . . . . . . . . 115
USING CUSTOM MENUS . . . . . . . . . . . . . . . . . . . . . 118
WAITING FOR CALLER SUBSYSTEM . . . . . . . . . . . . . . . . 120
Starting WFC . . . . . . . . . . . . . . . . . . . . . . 120
Screen Display and SysOp Keys . . . . . . . . . . . . . 120
EXPIRATION/SUBSCRIPTION SYSTEM . . . . . . . . . . . . . . . 122
MULTILINGUAL SUPPORT . . . . . . . . . . . . . . . . . . . . 123
QWK MAIL PACKER . . . . . . . . . . . . . . . . . . . . . . . 125
Configuration . . . . . . . . . . . . . . . . . . . . . 125
Bulletins, News Files and File Lists . . . . . . . . . . 125
Remote Message Packing . . . . . . . . . . . . . . . . . 126
Local Mail Packing . . . . . . . . . . . . . . . . . . . 127
Unattended Mail Packing ("Vacation Saver") . . . . . . . 127
NetMail Messages . . . . . . . . . . . . . . . . . . . . 128
MISCELLANEOUS INFORMATION . . . . . . . . . . . . . . . . . . 129
Filename Specifications . . . . . . . . . . . . . . . . 129
Hard-Coded Filenames . . . . . . . . . . . . . . . . . . 129
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
LICENCE
Copyright 1991 by Scott J. Dudley. All rights reserved.
COMMERCIAL DISTRIBUTION AND/OR USE PROHIBITED WITHOUT WRITTEN
CONSENT FROM THE AUTHOR.
Noncommercial distribution and/or use is permitted under the
following terms:
1) You may copy and distribute verbatim copies of the Maximus-
CBCS source, documentation, and executable code as you
receive it, in any medium, provided that you conspicuously
and appropriately publish on each copy a valid copyright
notice "Copyright 1991 by Scott J. Dudley"; keep intact the
notices on all files that refer to this Licence Agreement
and to the absence of any warranty; PROVIDE UNMODIFIED
COPIES OF THE DOCUMENTATION AS PROVIDED WITH THE PROGRAM;
and give any other recipients of the Maximus-CBCS program a
copy of this Licence Agreement along with the program. You
may charge a distribution fee for the physical act of
transferring a copy, but no more than is necessary to
recover your actual costs incurred in the transfer. Under no
circumstances is Maximus-CBCS to be distributed in such a
way as to be construed as "value added" in a sales
transaction, such as, but not limited to, software bundled
with a modem or CD-ROM software collections, without the
prior written consent of the author.
2) You may modify your copy or copies of Maximus-CBCS or any
portion of it, and copy and distribute such modifications
under the terms of Paragraph 1 above, provided that you also
do the following:
a) cause the modified files to carry prominent notices
stating that you changed the files and the date of any
change;
b) cause the executable code of such modified version to
clearly identify itself as such in the course of its normal
operation;
c) if the modified version is not a "port", but operates in
the same hardware and/or software environment as the
original distribution, make the original version equally
available, clearly identifying same as the original,
unmodified version;
d) cause the whole of any work that you distribute or
publish, that in whole or in part contains or is a
Maximus-CBCS v2.00 Operations Manual - Page 1
derivative of Maximus-CBCS or any part thereof, to be
licensed at no charge to all third parties on terms
identical to those contained in this Licence Agreement
(except that you may choose to grant more extensive warranty
protection to some or all third parties, at your option);
and:
e) send the complete source code modifications to Scott
Dudley at the addresses listed below, for the purpose of
evaluation for inclusion in future releases of Maximus-CBCS.
Should your source code be included in Maximus-CBCS, Scott
Dudley retains all rights for redistribution of the code as
part of Maximus-CBCS and all derivative works, with
appropriate credit given to the author of the modification;
f) You may charge a distribution fee for the physical act of
transferring a copy, but no more than is necessary to
recover your actual costs incurred in the transfer, and you
may at your option offer warranty protection in exchange for
a fee;
g) when distributing modified versions of Maximus-CBCS, you
must not change the name of the program or the official
version number, except to append an identifier which
indicates that modifications have been made. For ports to
other operating systems, the following convention must be
followed:
Maximus-CBCS v<v>.<os>.R<r>
...where <v> is the official Maximus-CBCS version number,
<os> is the name of the operating system which the port runs
under, and <r> (optional) is the OS-specific revision
number. For example, the second OS/2 revision of Maximus-
CBCS 1.02 must have a version string in this format:
`Maximus-CBCS v1.02.OS/2.R2'
Similarly, modifications to Maximus-CBCS which are designed
to run under MS-DOS must also follow a naming convention.
The version string must read:
Maximus-CBCS v<v>.<i>.<r>
where <v> is the official Maximus-CBCS version number, <i>
is three initials (indicating your first, middle and last
names), and <r> (optional) is the revision number of your
modifications.
Maximus-CBCS v2.00 Operations Manual - Page 2
For example, a version of Maximus-CBCS 2.00 modified by Joe
T. SysOp must have a version string in this format:
`Maximus-CBCS v2.00.jts.1'
3) Mere aggregation of another unrelated program with this
program and documentation (or derivative works) on a volume
of a storage or distribution medium does not bring the other
program under the scope of these terms.
4) You may copy and distribute Maximus-CBCS and its associated
documentation (or a portion or derivative of it, under
Paragraph 2) in object code or executable form under the
terms of Paragraphs 1 and 2 above provided that you also do
one of the following:
a) accompany it with the complete corresponding
machine-readable source code, which must be distributed
under the terms of Paragraphs 1 and 2 above; or,
b) accompany it with a written offer, valid for at least
three years, to give any third party free (except for a
nominal shipping charge) a complete machine-readable copy of
the corresponding source code, to be distributed under the
terms of Paragraphs 1 and 2 above; or,
c) accompany it with the information you received as to
where the corresponding source code may be obtained. (This
alternative is allowed only for noncommercial distribution
and only if you received the program in object code or
executable form alone.)
For an executable file, complete source code means all the
source code for all modules it contains; but, as a special
exception, it need not include source code for modules which
are standard libraries that accompany the operating system
on which the executable file runs.
5) You may not copy, sublicense, distribute or transfer
Maximus-CBCS and its associated documentation except as
expressly provided under this Licence Agreement. Any
attempt otherwise to copy, sublicense, distribute or
transfer Maximus-CBCS is void and your rights to use the
program under this Licence agreement shall be automatically
terminated.
However, parties who have received computer software
programs from you with this Licence Agreement will not have
their licences terminated so long as such parties remain in
Maximus-CBCS v2.00 Operations Manual - Page 3
full compliance, and notify Scott Dudley of their intention
to comply with this Agreement.
6) You may not incorporate parts of Maximus-CBCS into a program
which is NOT completely free for ALL users. If you wish to
use Maximus-CBCS in such a way, you must obtain written
permission from Scott Dudley before using any of the
Maximus-CBCS code.
7) You may not incorporate parts of Maximus-CBCS into a
FUNCTIONALLY SIMILAR program, including other bulletin board
packages or tossers/scanners. If you are writing another
BBS or remote host package, you must contact Scott Dudley
before using any of the Maximus-CBCS code.
8) The privileges granted above apply only to noncommercial
users of the Maximus-CBCS software. You are a NONCOMMERCIAL
user only if you are running Maximus-CBCS a private
individual with no "sponsors", "backers", and only if your
BBS is not making (or helping to make) a profit. You are a
COMMERCIAL user if you make a profit from running your BBS.
You are also a COMMERCIAL user if your BBS is being run by
(or for) any corporation, government, company, foundation,
church, school, or any other organization You are also a
COMMERCIAL user if your system is used to advertise such a
commercial organization for the purposes of making a profit.
This licence only governs NONCOMMERCIAL users. If you are a
COMMERCIAL user, you are not licensed to use or distribute
this software without the prior written consent of Scott
Dudley. If you wish to run Maximus-CBCS as a commercial
user, please see the section below on site licences.
9) This licence may be revoked by Scott Dudley without prior
notice.
NO WARRANTY
BECAUSE MAXIMUS-CBCS IS LICENSED FREE OF CHARGE, WE PROVIDE
ABSOLUTELY NO WARRANTY. EXCEPT WHEN OTHERWISE STATED IN WRITING,
SCOTT DUDLEY AND/OR OTHER PARTIES PROVIDE MAXIMUS-CBCS "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF MAXIMUS-CBCS,
AND THE ACCURACY OF ITS ASSOCIATED DOCUMENTATION, IS WITH YOU.
SHOULD MAXIMUS-CBCS OR ITS ASSOCIATED DOCUMENTATION PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR
OR CORRECTION.
Maximus-CBCS v2.00 Operations Manual - Page 4
IN NO EVENT WILL SCOTT DUDLEY BE RESPONSIBLE IN ANY WAY FOR THE
BEHAVIOUR OF MODIFIED VERSIONS OF MAXIMUS-CBCS. IN NO EVENT WILL
SCOTT DUDLEY AND/OR ANY OTHER PARTY WHO MAY MODIFY AND
REDISTRIBUTE MAXIMUS-CBCS AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS) MAXIMUS-CBCS, EVEN IF SCOTT DUDLEY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY
ANY OTHER PARTY.
You can contact the author at any of the addresses listed below:
FidoNet: 1:249/106
IMEXnet: 89:487/106
Internet: sjd@f106.n249.z1.fidonet.org
CServe: >INTERNET:sjd@f106.n249.z1.fidonet.org
BBS: (613) 389-8315, 14.4K/HST
Surface mail:
777 Downing St.
Kingston, Ont.
Canada K7M 5N3
The author can also be reached through the EchoMail conferences
called MUFFIN (Max support) and TUB (Squish support).
Sending correspondence via electronic mail is strongly preferred.
However, if you expect to receive a reply via surface mail,
please enclose a self-addressed, stamped envelope. Maximus users
outside of Canada should include an international postal reply
coupon instead of a stamp.
DO NOT ATTEMPT TO CONTACT THE AUTHOR BY TELEPHONE! VOICE SUPPORT
WILL NOT BE PROVIDED FOR NONCOMMERCIAL USERS!
Please feel free to contact the author at any time to share your
comments about this software and/or licensing policies.
Our thanks to Richard Stallman at the Free Software Foundation,
Inc. and BBS Co. for most of the wording of this licence.
Maximus-CBCS v2.00 Operations Manual - Page 5
INTRODUCTION
Notes from the Author
Maximus-CBCS v2.00 is the first major upgrade since Maximus 1.0
was released. Although 1.02 added several new features and
functions, it has taken over a year to complete Max 2.0. When
writing version 2, major portions of the message and file
sections were gutted and rewritten. Both the file and message
sections now use compiled database for quick access; indeed, one
of the biggest new features in Max 2.0 is the message system.
Max now uses a generic message API (Application Program
Interface) when dealing with messages. Under OS/2, this means
that a new message format can be used by simply replacing the
MSGAPI.DLL! Max 2.0 still supports the standard *.MSG format,
but Max 2.0 also supports the proprietary "Squish" message
format, selectable on an area-by-area basis.
As promised in the 1.02 documentation, Max 2.0 includes full
multilingual support, a new message base format, and more. I
have some unique ideas planned for the next release; in fact, one
of the planned features for the next version has been in
development for the past nine months (in parallel to Max 2.0). I
can't release any more information at this point, but I did want
to say that there are some neat things ahead.
If you are having trouble installing Maximus, in spite of the
automated installation program, please have a look in the
troubleshooting section of this manual. If you still can't get
Maximus to work correctly, then either post a message in the
MUFFIN echomail conference, or send NetMail to the Maximus Help
node at 1:1/119.
Scott Dudley
October 14th, 1991
For contact information, please see the program licence.
Maximus-CBCS v2.00 Operations Manual - Page 6
Maximus, Money and You
In general, Maximus is a freeware program. If you are a
noncommercial user and you abide by the terms given in the
licence, there is NO CHARGE for running Maximus. NONCOMMERCIAL
USERS ARE STILL WELCOME TO RUN MAXIMUS WITHOUT PAYING A CENT.
Unlike other software, this program does not have crippled
features or "registration incentives". Maximus does not have any
"registered only" commands. There is one simple difference
between the commercial and noncommercial versions of Maximus:
the commercial version entitles you to legally use Maximus in a
commercial environment.
If you are a COMMERCIAL USER as defined in point 8) of the
licence above, you must obtain a licence before using Maximus.
Please see ORDER.FRM for more information. If you did not
receive a copy of the order form with this document, contact the
author at one of the addresses listed in the licence for more
information.
If you are a NONCOMMERCIAL user as defined in the licence above,
you are welcome to use Maximus for free. However, Maximus is an
extremely large and complex program, and simply maintaining the
existing code is consuming a large percentage of my time.
Donations of any value (or even just a postcard) will be gladly
accepted. However, noncommercial donations are on a VOLUNTARY
basis and are NOT REQUIRED.
However, BOTH commercial and noncommercial users must abide by
several restrictions before using Maximus. The main points in
the licence are:
* You may not distribute Maximus on a CD-ROM, WORM, or as any
other form of a "value added" good in a sales transaction.
You may not bundle Maximus with other software without prior
written permission of the author.
* You may modify Maximus, but only under the conditions given
in the licence.
* You may not incorporate parts of Maximus into another BBS
package.
* You may not incorporate parts of Maximus into another
program which is not completely free for all users.
Maximus-CBCS v2.00 Operations Manual - Page 7
Other than the above, there are few restrictions on the use of
Maximus. However, because additional restrictions or
qualifications may apply to you, the licence agreement should
still be read carefully.
Maximus-CBCS v2.00 Operations Manual - Page 8
Credits
Even though Maximus is almost all original code, several other
people contributed a great deal to the project and deserve to be
acknowledged.
First and foremost, my thanks go to Wynn Wagner III. Without
Wynn, there would be no Opus; without Opus, there would be no
Maximus, or at least not in the format that it is today. Maximus
does not use any of Wynn's code, but he did provide the program
after which Maximus was originally modeled. Wynn also wrote a
large number of utilities and established the WaZOO handshaking
standard.
Secondly, my thanks go to Peter Fitzsimmons, for all of his help
and code. Peter is the head of the Max-OS/2 development team,
but he has also contributed a good deal of code to the DOS
version. Comments can be sent to him at 1:250/628.
As well, I should also thank Bob Hartman, Vince Perriello and
Alan Applegate. These three people created the BinkleyTerm front
end, and they also contributed all of Max's file transfer
protocols.
I would also be remiss if I failed to thank all of my alpha and
beta testers. Although the list is too long to include here, my
sincere gratitude goes out to all of them, not only for their
help in tracking down the many bugs which were visible in earlier
Maximus releases, but also for their helpful suggestions and
comments. My thanks also go to the rest of the documentation
team, as listed on the front page of each manual.
Thanks go to the following people who have contributed to the
Maximus source, by donating algorithms, structures, ideas, or
even code. (My sincere apologies if someone has been left out.)
Peter Fitzsimmons
Vince Perriello and Bob Hartman
Andrew Farmer
Scott Friedman
Ray Duncan
Thomas Plum
Alan Hughes
Anders Brink
Jim Lin
Gordon Benedict
Maximus-CBCS v2.00 Operations Manual - Page 9
Finally, I wish to acknowledge several products and trademarks
which have been mentioned in this document. Use of these names
and trademarks neither constitutes an endorsement nor suggests
any affiliation with the specified products.
ARC, SEAlink & SEAdog: Thom Henderson
BinkleyTerm: Bob Hartman & Vince Perriello
BNUcomm: David Nugent, Unique Computing
Courier HST: U.S. Robotics Inc.
DESQview: Quarterdeck Office Systems
DoubleDOS: SoftLogic Solutions Inc.
FEND: David Luong
Fido & FidoNet: Tom Jennings, Fido Software
FrontDoor & FDterm: Joaquim Homrighausen
FView: Doug Boone
IBM-PC, PC-DOS, OS/2: International Business Machines
Lharc and LZH: Haruyasu Yoshizaki
Minimus: John Cuccia
MS-DOS: Microsoft Inc.
Opus-CBCS: Wynn Wagner III
OpusComm & ConfMail: Bob Hartman, Spark Software
PCBoard: Clark Software Development Corp.
QuickBBS: Pegasus Software, Inc.
QM, QMail & AreaFix: Greg Dawson & George Peace
RBBS: Capital PC Users Group
TBBS: eSoft, Inc.
Telix: Colin Sampaleanu, Exis Inc.
TheDraw: Ian Davis, TheSoft Services
TinyTerm, OECC: George A. Stanislav
Turbo C: Borland International
V-Series and Hayes: Hayes Microcomputer Products
VT-100: Digital Equipment Corporation
X00: Ray Gwinn, RENEX Co.
Xmodem: Ward Christiensen
ZIP: Phil Katz, PKWare
Zmodem and MobyTurbo: Chuck Forsberg
Maximus-CBCS v2.00 Operations Manual - Page 10
It's Canadian, eh?
Maximus is a Canadian product. As such, proper English spellings
are used in most places. Carbon-based life forms living in the
United States of America should make the following mental
translations:
Proper spelling American spelling
Colour Color
Favoured Favored
Licence License
Neighbour Neighbor
For your viewing pleasure, an alternate language file called
AMERICAN.MAD is included in the Maximus distribution package.
This language file is an "Americanized" version of the standard
English file, including many of the above changes.
Maximus-CBCS v2.00 Operations Manual - Page 11
SYSTEM REQUIREMENTS
Although it is possible to run Maximus on a system with less than
the following equipment, the following should be considered the
realistic minimum with which you can get by:
* An IBM (or compatible) personal computer running MS-DOS or
PC-DOS, with at least 256K of available RAM, with at least
164K free.
* MS-DOS or PC-DOS version 2.0 or greater, 3.2 or above
preferred.
* A Hayes-compatible modem. It is possible to use Maximus
with a modem which is not Hayes-compatible. However, doing
so will make your life unnecessarily complicated.
* A hard disk. Capacity of 30 megabytes or greater is
preferable.
* A FOSSIL communications driver, revision level 5 or higher.
(Common FOSSILs are X00, BNU and OpusComm.)
Maximus-CBCS v2.00 Operations Manual - Page 12
MAXIMUS OVERVIEW
This section of the documentation is designed to give you, the
SysOp, a general overview of what Maximus can do. By any means,
this is not complete, but it should give you a general idea of
how the system operates.
Logging On
When Maximus starts up with a caller on-line, the Maximus name
and version will be displayed, followed by the SysOp-created log-
on screen (usually \MAX\MISC\LOGO.BBS). This screen should be
kept under 2K in length, and it should not use ANSI graphics and
high-bit IBM characters.
After the logo screen has been displayed, Maximus will then
prompt the user to enter a name. Unlike other BBS programs,
Maximus allows a user to use names with more than two words, so
even a name such as "Jesse David Hollington" will be accepted.
(On the other hand, Maximus will reject callers with a one-word
name, unless you have the `Alias System' keyword uncommented in
MAX.CTL.)
However, if the user does NOT exist in the user file, Maximus
will display the NOTFOUND.BBS file. This serves to confirm that
the user really wanted to enter the name which was entered at the
prompt. In addition, Maximus will disable key stacking, just in
case the user entered a name in the format of `Joe SysOp Y
Password', and misspelled the name `Joe SysOp'. With other BBS
software, this would result in a new user account being created
under the wrong name.
If the name was not in the user file, Maximus will go through the
new user routine. First, Maximus will display APPLIC.BBS; this
normally gives the caller some information about your system, and
it may also present an application form to be filled out. (If a
caller hangs up before APPLIC.BBS has completed displaying, then
the user's configuration will NOT be saved, and no entry will be
made in USER.BBS.)
When APPLIC.BBS ends, Maximus will then prompt the user to enter
his/her city, alias (if applicable), phone number, and so on.
Finally, Maximus will display NEWUSER2.BBS, which can be yet
another screen directed toward educating new users.
On the other hand, if the user's name was found in the user file,
then Maximus will ask that user to enter his/her password. The
user will get five tries to enter the correct password; if all
Maximus-CBCS v2.00 Operations Manual - Page 13
five tries fail, or if the user pressed <enter> five times,
Maximus will hang up and recycle. However, Max will display the
file \MAX\MISC\BAD_PWD.BBS before doing so, which means that you
can prompt the user to enter a message of explanation before
hanging up.
If the user enters the correct password, Maximus will proceed
with the log-on sequence, and display WELCOME.BBS to the user.
Note! If a user's account has a BLANK password, then Maximus
will treat that user as a `guest account'. This means that
Maximus will ask a user who is using this account for his/her
configuration settings at every log-on, and Maximus will also
skip the password prompt. This allows the SysOp to create an
account specifically for new users (while using a `Logon Level
Preregistered' statement), such that users can look around the
system, but the user file won't get cluttered with users who
choose not to register. (User registration would presumably be
done through an on-line questionnaire.)
Maximus also supports a concept known as a `custom welcome
screen'. A special welcome screen can be created to display to
each individual user, BEFORE displaying the main WELCOME.BBS. By
placing a file called `#.BBS' in the Maximus system directory,
where `#' is a user number, Maximus will display that .BBS file
to the caller with that user number. (You can find out a user's
user number by looking in the log file, or also by doing a find
in the user editor.) For example, if you wanted to show a custom
welcome to user #5, then you might create a file called
`\MAX\5.BBS'.
As an added security feature, you can also disable remote sysop
logons. If you place a "[isremote sequal hangup]" at the top of
your WELCOME.MEC, Max will automatically hang up on remote
callers with a priv level of SysOp. If you never call your
system from remote, using this option can help prevent accidents.
If the user has ANSI or AVATAR graphics support, the user can use
the cursor keys to edit any of the text on the command line.
Editing can be performed through the <left>, <right>, <bs>,
<del>, <ctrl-left>, and <ctrl-right> keys. To use this feature,
the caller's terminal must support either "Doorway mode" or VT-
100 keyboard codes.
Maximus-CBCS v2.00 Operations Manual - Page 14
The Main Menu
Although Max's menus are completely redefinable, this section
attempts to explain the commands which would normally be found on
the main menu. This is also where the commands appear in the
default configuration.
Message Section
This enters the message section. From here all the message
entering and reading features are available. See the
section on the message areas for more detail.
File Section
This takes the user to the Files Section. From here a user
can exchange files by uploading or downloading, or simply
see what files are available. See the section on the file
areas for more detail.
Change Setup
This takes the user to the Change Setup menu. From here, a
user can modify his/her user profile. The user can set the
screen length, change the graphics mode, password, toggle
the full-screen editor, and more. See the section on the
Change Setup menu for more details.
Goodbye
This option logs the user off the system and hangs up the
phone. This is almost identical to what happens if a user
simply drops carrier. Maximus will not `hang' if a user
drops carrier, but will recycle as if they logged off using
this command. This command simply asks the user to confirm
that they want to disconnect, asks if he/she wants to leave
a message to the sysop, and then hangs up on the user. By
default, comments are placed in message area 1, although
this is selectable in MAX.CTL.
Comments to the sysop are saved in the "Comment Area", as defined
in MAX.CTL. (By default, comments are stored in area 1.) If
message area 1 does not exist, or if you use a "Comment Area"
statement with no area listed, users will not be asked if they
want to leave you comments.
Maximus-CBCS v2.00 Operations Manual - Page 15
Statistics
This option displays the user's statistics, including the
time the user has been online for the current call, the time
online for the day, amount uploaded, amount downloaded,
NetMail credit, and so on.
Yell
This command allows the user to attempt to contact the SysOp
while he/she is on-line. You can set when you want users to
be able to page you with this command, and you can toggle
the local speaker noise with the local "!" command.
Userlist
This command simply displays a list of all the users who are
currently in the user file. You can set the maximum and
minimum privilege levels to display in the list through
options in the control file. By default, will not display
users with a privilege of SysOp, Hidden or Twit. These
privilege levels are also selectable in the control file.
Version
This displays the version number and a few other statistics
about the current revision of Maximus and the version of the
operating system currently in use.
SysOp Menu
This command takes you to the Maximus SysOp menu. See below
for more details.
Chat Menu
If enabled, this menu can be used to access all of Max's
multi-node chat features, including paging, toggling chat
availability, and the chat itself. This feature allows
callers to talk with one or more other callers. Chatting
with the SysOp is performed through the Yell command.
Maximus-CBCS v2.00 Operations Manual - Page 16
Who is On?
If the multi-node chat system is enabled, this command can
be used to display a list of callers who are currently
logged onto other nodes of the same system. This command
will display the user name, the node number, and that user's
status. The status message indicates the current activities
of the user, such as "Downloading a file", "Entering a
message", and so on.
In addition, you can define other options in the main menu to
call sub-menus, display text files, or run external programs.
See the control-file reference section for more details on
defining menus.
Maximus-CBCS v2.00 Operations Manual - Page 17
The Message Section
There are four basic types of message areas within Maximus.
These area types are Local, NetMail, EchoMail and conference
mail.
Local messages are messages entered by a user on your BBS. They
can be either public or private, and they remain on your BBS.
Other users can only read these messages by logging onto your BBS
and selecting that particular message area.°
NetMail messages are messages that are sent from one BBS to
another through a network that you are connected to. They are
generally private messages.
Unless you are a host or hub, most NetMail messages you encounter
will either be entered on your system, or will be sent to your
system from another. Maximus is fully compatible with the
FidoNet mail standard for these messages. A user entering a
NetMail message will be prompted to enter additional information
to tell your mail processor where to send the message. Maximus
is capable of reading a FidoNet compatible Version 5 or Version 6
nodelist file in order to get its address and cost information.
Generally your users will need to have credit in their user
accounts in order to send NetMail. Under most circumstances you
should only have one of these areas.
EchoMail messages are messages that are shared between several
bulletin board systems over a wide area. An EchoMail message
will be sent through your network to all other systems
participating in that same conference. Generally, EchoMail areas
only permit public message. To a Maximus user, an echo area
appears identical to a local message area, except that messages
entered in EchoMail areas will have special control information
added to the end, such as origin and tear lines. In addition,
when a user enters a message in an EchoMail area, Maximus will
add that area's tag to your echo tosslog.
Maximus also supports a variety of message area toggles (or
"attributes"), each of which can be set independently. Although
a complete list can be found in the MSGAREA.CTL reference in the
Maximus Technical Reference Manual, some of the more common
attributes are:
Maximus-CBCS v2.00 Operations Manual - Page 18
Private Only
All messages entered in these areas will be marked private,
and can only be read by the user who sent the message, the
user it is addressed to, and the sysop.
Public Only
All messages entered in these areas will be public and can
be read by any user. This flag is recommended for EchoMail
areas.
Read-Only
Messages in these areas can be read by users, but only users
with a privilege level of assistant sysop or higher can
enter messages.
Anonymous OK
In an area has this attribute set, users can optionally
enter messages under a pseudonym instead of that user's real
name. Maximus will embed the user's real name within the
message in such a way that only the SysOp can see it. If
this causes some sort of security or anonymity problem, this
embedding of the user's real name can be disabled. Please
refer to the MSGAREA.CTL reference (in the Maximus Technical
Reference Manual) for more details.
Maximus is also capable of assigning passwords to message and
file areas, and re-assigning privileges within the area for
certain passwords. In addition, you can assign user names to the
barricade file, so only certain users can enter an area. See the
section on extended barricades in MAX_REF.PRN for more details.
In addition, the private and public message-area attributes can
be defined individually by privilege level, rather than globally
for all callers. (In other words, you can allow the SysOp to
enter anonymous messages, while still forcing normal users to use
their real names.) See the control-file reference for more
information on how to assign these attributes to areas.
The Message Menu
The following attempts to explain the options that would normally
be used in a message area menu:
Maximus-CBCS v2.00 Operations Manual - Page 19
Area Change
This command allows the user to change to another message
area. The user will be prompted to enter the message area
they want to go to, or to enter a "?" for a list of the
areas that are available to them. The user can also enter
the "<" or ">" characters to go to the previous or next area
in the list, respectively. If entering a barricaded area
where a password is required, he/she will be prompted for
the password before they are allowed to enter the area.
Next
This command will display the next message in the current
area. To keep reading messages in this direction, the user
can press the ENTER key at the next prompt. The ENTER key
will repeat the last N)ext or P)revious command.
Previous
This command will display the previous message in the
current area. To keep reading messages in this direction,
the user can press the ENTER key at the next prompt. The
ENTER key will repeat the last N)ext or P)revious command.
Enter a Message
This command will allow the user to enter a message. After
the user selects this command, Maximus will prompt them for
some information is needs to know to send the message, such
as who the message is to, the subject of the message, and
whether the message is public or private, and any other
information allowed by the configuration of the current
area.
If the area does not allow public messages, or does not
allow private messages, the user will not be able to select
whether they want the message to be public or private.
If the area allows anonymous messages, the user will be able
to change who the message is from as well. If the message
area is a NetMail area, the user will be prompted for a
network address to send the message to. When entering the
address, the user can either enter the address, or use the
following keys to get listings:
# This will display a list of all the nodes in the
current net.
Maximus-CBCS v2.00 Operations Manual - Page 20
/ This will display a list of all the nets in the
nodelist.
If you only enter a node number, Maximus will automatically
default to your current net.
A special shortcut exists for addressing points off the
current system. Suppose that you are currently entering a
message on 1:106/114. If you wish to write a message to
John Doe at 1:106/114.22, simply enter `.22' at the
destination prompt. Maximus will automatically expand this
address to the full `1:106/114.22'.
After entering this information, the user will be placed in
the message editor to enter the message. For more details,
refer to the section on message editors.
Finally, if your nodelist processor can create a
FIDOUSER.LST, Maximus is capable of finding a network
address based on a user's name. If you enable the "FidoUser
D:\Path\Fidouser.Lst" statement in MAX.CTL, Max will search
the nodelist for a particular SysOp name. If that name was
found, Max will automatically enter that SysOp's netmail
address for you.
Change a Message
The Change command allows users to modify an existing
message. Before allowing a user to change a message, Max
will check to make sure that the user actually WROTE that
message. Max will also check to see if the message has been
scanned out or read by the recipient. If either of these
conditions is true, Max will display a message to that
effect and abort the change. (However, this acts only as a
warning to callers with a priv level of SysOp; Max will
always let the SysOp modify a message, whether or not the
message has been read or scanned out.)
Both the message header and the message body can be
modified. When graphics are turned on, the message status
bits in the NetMail area (such as crash, hold, and so forth)
can also be modified.
Maximus-CBCS v2.00 Operations Manual - Page 21
Reply to Message
This command allows the user to send a response to the
author of the current message. The reply command is similar
to the enter command, except that some of the message fields
will be filled in (the name of the author of the message to
which you are replying will automatically be inserted in the
To: field). Also, once in the editor, the user will be able
to QUOTE the message they are replying to. See the section
on the message editor for details. "RK" [R)eply/K)ill] will
kill the original message after the reply is finished.
Read Non-Stop
This command will allow a user to read all of the messages
in the current area, starting with the current message,
without pausing between each message. This is useful if
users want to capture the messages to a disk file for later
perusal.
Read Original
This command will allow the user to display the original
message to which the message they are reading is a reply.
Messages that are replies to another will have a "*** This
is a reply to #xx" tag at the bottom of the message.
Read Reply
This command will allow the user to display any messages
that are replies to the message they are reading. Messages
that have replies to them will have a "***See also #xx" tag
at the bottom of them.
Read Current
This command will allow the user to redisplay the current
message number. This command is useful when first entering
an area (to re-read the message you read in your last
session), and also when trying to redisplay a message which
scrolled off the screen.
Maximus-CBCS v2.00 Operations Manual - Page 22
Browse
Browse is an extremely powerful command; it replaces the
functionality of Max 1.02's Scan, Inquire, List, and
mailchecker commands. Browse acts as a powerful database
engine for the message bases. Users can select a set of
messages and operations to perform, and have Maximus
automatically identify and display the messages which were
requested. Browse is broken down into 3-4 separate menus.
The first menu allows the user to select a set of areas to
query. The user can select either the current area, the set
of areas selected with the T)ag command, or all message
area.
The second menu allows the user to specify a set of messages
to select. The user can specify ALL MESSAGES (each message
in every area specified), NEW MESSAGES (messages above the
lastread pointer in each area), YOUR MESSAGES (messages
above the lastread pointer and addressed to the current
user), and FROM A MESSAGE NUMBER (such as from message #200
and up). Maximus also allows the user to perform a search
based on keywords in the to, from and subject fields, in
addition to the message body. Complex searches can be
defined using the logical OR and the logical AND operators.
The third menu selects an operation to perform on the
specified messages. Selected messages can be listed (one to
a line, to/from/subject only), read (displayed in full, with
the option to reply or kill), or packed into a QWK bundle
for off-line reading.
Tag
The tag command allows each user to select a subset of
message areas available on the system. Each individual user
can select his or her own set of message areas to be stored
across calls. This set of areas can be used with the Browse
command, or also with the Download command on the off-line
reader menu.
Edit User
This function invokes the user editor from the message menu;
however, it also reads in the current message, checks the
'From:' field, and automatically positions the user editor
on that user's user record. This may be useful for
validating users, since you can pull up a user's record at
the press of a key. (This command is for SysOps only.)
Maximus-CBCS v2.00 Operations Manual - Page 23
Goodbye
This is identical to the G)oodbye command at the main menu.
It will log off the user.
Main Menu
This will return the user to the main menu.
Kill a Message
This command allows a user to delete a message in the
current area. Unless a user has SysOp privileges, a user
will only be able to kill messages which are addressed TO or
FROM that individual.
Upload a Message
This command allows a user to directly upload a text file as
a message to the current area. This is identical to the
E)nter message command, except instead of invoking the
editor, Maximus will start a file upload. The user may then
upload a pre-typed ASCII text file which will be stored as a
message. Any file transfer protocol may be used for
uploading the message text. The maximum length of an
uploaded message is 8K.
Forward
This command allows a user to make a copy of a message in
the current area, and send it to someone else. The user
enters the message number to forward, and the name of the
person to forward it to. The user can also forward the
message directly into another area by typing the area number
when prompted. The F)orward command supports two special
modifiers, as follows:
"FK" [F)oward K)ill] will delete the original message after
forwarding it.
"FB" [F)orward B)ombrun] will allow a user to specify a
filename containing a list of users to forward the message
to. In order for a user to use this command,their privilege
level must be equal to the privilege level required to
create a message from a file as defined in the Maximus
control file. (See the control file reference in
MAX_REF.PRN for more information.) The format of the
bombing run file is as follows:
Maximus-CBCS v2.00 Operations Manual - Page 24
<username> <dest_net/dest_node> [-x]
-x can be one of the following switches:
-h Message should be marked as HOLD FOR PICKUP
-c Message should be marked as CRASH
-n Message should be marked as NORMAL (default)
The bombing file can contain any number of lines.
The <dest_net/dest_node> and [-x] fields are only used for
NetMail messages, and should be omitted for local bombing
runs.
In the username field, spaces in a user's name must be
represented by underscores.
For example:
SysOp 225/337
Scott_Dudley 249/106 -c
Hubert_Lai 249/102 -h
Vince_Perriello 141/191 -n
Jesse_David_Hollington 225/1 -c
This would send carbon copies of a message to the five
people names, sending the messages to SysOp and Vince
Perriello as NORMAL messages, and the messages to 249/106
and 225/1 as CRASH messages.
Note! If you are performing a NetMail bombing run, make
sure NOT to route your messages through anyone else.
Routing bombing-run messages is against FidoNet policy.
Hurl
This command is used to move messages from one area to
another. It will ask the user which message to hurl and
which area to hurl it to.
In addition, you can define other options in the message
menu to call auxiliary menus, display text files, or run
external programs. See the control-file reference for more
details on defining menus.
Xport
The Xport command, normally available only to SysOps, can be
used to export a particular message to a specified filename.
Maximus-CBCS v2.00 Operations Manual - Page 25
This message will be formatted for 80 columns, and the file
will also include the message header. TO PRINT A MESSAGE ON
THE PRINTER, specify an Xport filename of "prn".
Message Entry
For ANSI and AVATAR callers, Maximus supports a sophisticated
message entry screen. After selecting one of the options which
begins the message entry process (such as E)nter, R)eply, or
U)pload), Maximus will then display a "template" for the user to
fill in. The template indicates whether or not the message is
private or public, the name of the recipient, the recipient's
matrix address (if in a netmail area), the subject of the
message, and optionally, an "alias" or alternate name for the
sender.
The user can move back and forth through the various items if
they have an ANSI/VT-100 or IBM-compatible terminal emulator, and
if not, users can also use the WordStar-like Control-E and
Control-X keys to move up and down the fields (respectively).
Control-Y will delete the contents of the current field, and
pressing <escape> TWICE will abort the message. Assuming that
all of the fields in the template have been filled, Maximus will
invoke the message editor when the user presses <enter> on the
last field in the header.
Maximus also supports a carbon copy feature. To utilize this,
simply include your carbon copy list at the top of the message
body in this form:
cc: name1, name2, name3, etc.
or this form:
cc: name1
cc: name2
cc: name3
cc: etc.
If you are in the Matrix area, you may optionally specify a
matrix address after each name. However, Maximus will also look
up the SysOp name in your FIDOUSER.LST and NAMES.MAX files; if a
match can be found, the message will be automatically addressed
to the right node.
Maximus-CBCS v2.00 Operations Manual - Page 26
Message Editors
Maximus supports two types of message editors:, MaxEd, the full
screen editor, and BORED, the line-oriented editor. Maximus also
supports an external editor for local use, but that is covered in
the control file documentation.
MaxEd
MaxEd is the Maximus full screen editor. This can only be used
by users who are capable of receiving ANSI or AVATAR graphics,
and have a screen width of 80 columns and a length of at least 23
rows. The full screen editor has a number of advantages over the
line editor, the most obvious being that it is far easier to use.
MaxEd is more like a word processor than a BBS editor; you can
use the cursor keys to move around, insert and delete text in the
middle of paragraphs, and so on.
MaxEd uses a mixture of WordStar, generic VT-100 and IBM-PC
commands, a list of which can be obtained by typing ^n
(Control-N) from within the editor. (The help file is contained
in \MAX\HLP\FSED.MEC.)
Also, if the message you are editing is a reply to another, then
you can quote text from the original message, and place it inside
your own, which greatly increases readability. You can look at
four lines at a time through a "quote window", and optionally
copy those lines into the message you are writing. You can also
page through the original message in either direction, forward or
backwards.
MaxEd also has a special menu, which is accessible via either ^kH
(Control-K and then 'H'). or the <F10> key The options available
on the MaxEd menu are similar to those found on the BORED menu,
and includes the following:
Continue
This will return to MaxEd and allow the user to continue
entering the message.
Maximus-CBCS v2.00 Operations Manual - Page 27
To
This allows the user to change the addressee of the message.
Subject
This allows the user to change the subject of the message.
From
This will allow the user to change who the message is from.
The privilege level of this command should be set rather
high, as this command can be used from any area, whether
it's anonymous or not.
Handling
This is another command for which the privilege level should
be set high. It will allow the user to change the flags on
the message. Flags such as Private or Public can be
changed, in addition to NetMail-type flags such as Crash,
Hold or File Attach.
Read File
This will allow the user to enter a path to a file on your
hard disk and read it in as a message. The privilege level
of this command should be set fairly high.
BORED
BORED is the Maximus line-editor. BORED can be used by anybody,
regardless of whether they have graphics or not. Most users who
have graphics will most likely prefer to use MaxEd.
BORED allows the user to enter a message, one line at a time.
When the user is finished entering the message, they are
presented with the editor menu. The commands available on the
editor menu are as follows:
Save
This will save the message the user has just entered.
Maximus-CBCS v2.00 Operations Manual - Page 28
Abort
This aborts the message without saving it.
List
Lists the message, preceding each line of the message with
it's line number.
Edit
This command edits a line in the message, to correct any
mistakes. Firstly, the user must select the line number
that they wish to edit, then enter the text that they wish
to replace, followed by the text you wish to replace it
with. To insert at the beginning of the line, just press
<Enter> for the "Text to replace" prompt.
Insert
This command will insert a blank line in the message
preceding a specified line number.
Delete
This command will delete a specified line of the message.
Continue
Allows the user to continue entering their message, by
appending to the end.
Quote
This command allows the user to quote text from the message
to which he/she is replying. The user must enter the
starting and ending numbers of the lines that he/she wishes
to quote.
To
This allows the user to change the addressee of the message.
Maximus-CBCS v2.00 Operations Manual - Page 29
Subject
This allows the user to change the subject of the message.
From
This will allow the user to change who the message is from.
The privilege level of this command should be set rather
high, as this command can be used in any message area,
whether or not the area is declared as anonymous.
Handling
This is another command for which the privilege level should
be set high. It will allow the user to change the flags on
the message. Flags such as Private or Public can be
changed, in addition to NetMail-type flags such as Crash,
Hold or File Attach.
Read File From Disk
This will allow the user to enter a path to a file on your
hard disk and read it in as a message. The privilege level
of this command should be set fairly high.
Maximus-CBCS v2.00 Operations Manual - Page 30
The File Menu
The following attempts to describe the options that would
normally be used in a file area menu, and how they are displayed
in the default configuration.
Area Change
This command allows the user to change to another file area.
The user will be prompted to enter the file area they want
to go to, or to enter a "?" for a list of the areas that are
available to them. The user can also enter the "<" or ">"
characters to go to the previous or next area in the list,
respectively. If entering a barricaded area where a
password is required, they will be prompted for the password
before they are allowed to enter the area.
Locate
This command allows a user to search all of the file areas
accessible with his/her priv level. The text that the user
enters will be matched anywhere in the filename or
description, so wildcards are not required. There are a
couple of modifiers to the L)ocate command.
"L*" [L)ocate New] will search all of the file areas for any
files that have been uploaded since the user was last on the
system.
"L?" [L)ocate ?)Help] will display help information on the
L)ocate command.
File Titles
This command will display a list of files in the current
area, along with their descriptions. New files will be
identified by a flashing asterisk (*). An argument to this
command can be specified in the same manner as for the
L)ocate command, however F)ile Titles will only search the
CURRENT file area.
Maximus-CBCS v2.00 Operations Manual - Page 31
View
This command will allow a user to display the contents of
any ASCII text file. The file is checked to make sure that
it is an ASCII file, and the user is informed if it is not.
NOTE! In prior versions of Maximus, this command was called
T)ype.
Goodbye
This is identical to the G)oodbye command at the main menu.
It will log the user off.
Main Menu
This will return the user to the main menu.
Download
The download command allows the user to download one or more
files from the file areas. Max 2.0 has a new format for
downloading; now, users can enter the files to download on
as many lines as they like, pressing <enter> after each
file. Wildcards will be automatically expanded. If FB (the
Maximus file database builder) is used, files can be quickly
downloaded from any file area on the system, regardless of
the current area. (Of course, the user's priv level is
checked before allowing such an operation.) If files were
T)agged earlier, those files will be automatically added to
the current download.
If no default protocol is selected, the user will also be
prompted to select a file transfer protocol. Maximus
supports Xmodem, Xmodem-1k, SEAlink, Telink and Zmodem
internally; more protocols, including DSZ, BiModem and Mpt,
can be directly added as external protocols.
The user can also specify one of several operations before
beginning the transfer. Entering "/q" causes Max to abort
the transfer without sending anything. Entering "/e" causes
Max to revert to "edit mode"; this mode allows the user to
delete and list files in the download queue. Entering "/g"
causes Max to hang up after the transfer is completed.
To start the download, simply press <enter> on a blank line.
Tag
Maximus-CBCS v2.00 Operations Manual - Page 32
The Tag command allows the user to queue one or more files
for later downloading. The Tag command is also accessible
through the "t" command (on the More [Y,n,t,=] prompt) when
performing a F)iles listing or a L)ocate.
Max will prompt the user to enter the filename to tag.
Wildcards are allowed, and if FB is used, global downloading
is also permitted. Max will NOT print a newline when
tagging from a file listing to prevent the rest of the list
from scrolling off the screen.
To download previously-tagged files, simply select the
Download option and press <enter> at the "File(s) to
download" prompt.
Upload
This is the reverse of the download command, and allows a
user to send files to your system. Maximus will ask the
user which protocol they are using to upload, and in some
cases the name of the file they are uploading (if the user
selects a batch protocol, such as Zmodem or SEAlink, the
filename is transmitted automatically in the transfer, so
Maximus won't bother prompting the user). The protocols are
identical to those used for the Download command.
Statistics
This option displays the user's statistics, including the
time the user has been online for the current call, the time
online for the day, amount uploaded, amount downloaded,
NetMail credit (if any), and so on.
Contents
The C)ontents command will allow a user to look into a
compressed file and see what files are contained inside.
The C)ontents can view any .ZIP, .ARC, .PAK, .ARJ or .LZH
file. For other compression methods, you are on your own.
Raw Directory
This will display a listing of ALL the files in the current
file directory, not just the files listed in the files
listing. The privilege level of this command should be set
fairly high.
Maximus-CBCS v2.00 Operations Manual - Page 33
Override Path
This will allow the user to supply a path to a different
directory than the one specified in the FILEAREA.CTL file
for the current file area. This command should, for obvious
reasons, be accessible only to users with high privilege
levels. All changes made with this command are temporary,
and the area's path will revert back to normal once you
leave the area.
Hurl
This command will allow a user to move a file from one area
to another. It will ask the user the name of the file to
move, and the number of the file area to hurl it to. This
command should be set to a rather high privilege level.
Kill File
This command will allow the user to delete a file from a
file area. They will be asked for the name of the file to
kill, and will then be asked to confirm that they want to
delete it. If they answer "n" to the "Delete?" prompt, they
will be given the option of leaving the file but simply
removing the entry from the file listing. For obvious
reasons, this command should be set to a high privilege
level.
In addition, you can define other options in the file menu
to call auxiliary menus, display text files, or run external
programs. See the SILT Documentation for more details on
defining menus.
Maximus-CBCS v2.00 Operations Manual - Page 34
The Change Setup Menu
From this section, a user may change as many of their settings as
you permit. Upon entering the change menu, the user's profile
will be displayed. The menu options are as follows:
City
Allows the user to change his/her city.
Phone Number
Allows the user to change his/her phone number.
Real Name
Designed for an alias system. Allows user to change his/her
real name.
Password
Allows the user to change their password. The user will be
prompted to enter his/her old password, then enter his/her
new password twice. If the user gets his/her old password
wrong five times, he/she will be quietly disconnected. If
the new passwords don't match, the password will not be
changed. Users should be encouraged to change their
passwords every so often to prevent other people from
finding them out.
Help Level
Allows the user to change his/her help level. There are
four different help levels available in Maximus:
NOVICE: Full Menus.
REGULAR: Abbreviated Menus.
EXPERT: No Menus
HOTFLASH: Full-screen, hotkey interface.
Nulls
Allows the user to change the delay after each transmitted
line. Most users won't need to use this unless they are
using a really ancient terminal.
Maximus-CBCS v2.00 Operations Manual - Page 35
Width
Allows the user to change the width of his/her screen. The
screen width is used to determine where Maximus should
word-wrap, and how wide the menus should be,among other
things.
Length
Allows the user to change the length of his/her screen. The
screen length is used to determine when the "More?" prompts
appear.
Tabs
Allows the user to toggle the translation of tabs. Normally
tabs are sent unaltered, which speeds up the display time
marginally. If this option is off, tabs will be translated
to spaces before being sent.
More
This allows the user to toggle the `More [Y,n,=]?' prompts
on and off.
Video Mode
This allows the user to change Video modes. Currently, only
TTY (plain), ANSI and AVATAR video modes are supported.
More video modes will be added in future releases of
Maximus-CBCS for compatibility with other systems.
Full-Screen Editor
This command allows users to toggle the use of the MaxEd
full-screen editor. If MaxEd is turned off, BORED will be
turned on by default.
Screen Clear
This allows the user to toggle the sending of screen
clearing codes in case his/her terminal cannot handle the
TTY clearscreen (ASCII character 12) or the ANSI`CLS'
command.
Maximus-CBCS v2.00 Operations Manual - Page 36
IBM Graphics
This allows the user to toggle whether or not Maximus will
send IBM extended ASCII characters. The IBM (and
compatibles) have a special `extended' 8-bit character set,
which allows things such as box-drawing and block graphics,
while running in text mode. Most non-IBM systems do not
support these extended ASCII characters. For those users
that have this option turned off, Maximus will translate IBM
extended ASCII characters into standard ASCII characters in
the range of 32 (decimal) to 128.
Hotkeys
This option allows the user to turn the hotkeys setting on
and off. Turning on hotkeys instructs Maximus to execute
commands as soon as they are received, without requiring an
<enter> after every second keystroke.
Language
The Language command allows the user to select an alternate
system language. Max supports up to eight different
language files, all of which can be available at the same
time. Simply add the appropriate "Language" statements to
LANGUAGE.CTL, and those languages will become available for
the Language command. The user's language preference is
automatically saved across calls; to prompt users for an
alternate language every time they log on, place a
"[menu_cmd chg_language]" token at the top of WELCOME.BBS.
Protocol
The Protocol command allows the user to select a default
transfer protocol. If a default file transfer protocol is
selected, the Download command will immediately shift to the
"File(s) to download" prompt instead of asking the user to
choose a protocol.
Archiver
The Archiver command allows the user to select a default
archiving and compression program. Max will shell out to
the archiver when performing certain functions, such as
compressing QWK bundles and decompressing REP packets. Max
will use the information defined in COMPRESS.CFG to display
a list of supported archivers, and will then prompt the user
to choose one of the selected options. (See the READER.CTL
Maximus-CBCS v2.00 Operations Manual - Page 37
section in the Maximus Technical Reference Manual for more
information.)
Show in Userlist
The Show in Userlist option allows each individual user to
select whether or not his/her name should be displayed in
the system userlog. By default, the user's name will be
displayed. If you wish to stop users from using this
command, simply change the priv level of the Chg_Userlist
command to Hidden.
Full-screen Reader
The Full-Screen Reader option allows users to toggle between
the old-style Max 1.0x message header (the default) and the
Max 2.0 full-screen reader box. The full-screen reader
(hereafter referred to as FSR) displays a pretty blue box at
the top of the screen, including the to/from/subject fields,
reply links, and net/node information. However, this box
takes a bit longer to display on a remote system, so it is
turned off by default.
Alias
The Alias command allows each user to select an alternate
alias. (Note: by default, this command is disabled in the
distribution MENUS.CTL.) This command will change the
"alias" field in the user record to whatever the user
desires, as long as the specified alias doesn't already
exist on the system.
Quit
This will return the user to the main menu.
Due to the dynamic menu structure of Maximus, it is possible to
configure the change menu to include any commands. The above are
only the commands that are most often used in the change menu on
most systems.
Maximus-CBCS v2.00 Operations Manual - Page 38
The SysOp Menu
User Editor
This invokes the Maximus Internal User Editor. This command
should be made available only to SysOps, for obvious
reasons. See the section on the user editor for more
details.
OS Shell
The OS shell permits either a local or remote shell to the
operating system. Note that <Alt-J> can always be used for
a local shell to the OS. (Note: OS/2 users should use
MaxPipe to run CMD.EXE, as opposed to redirecting
COMMAND.COM.)
If you are using an alternate command processor under DOS
(such as 4DOS), make sure to change the menu entry for this
command to reflect the command processor (ie. 4DOS.COM)
instead of COMMAND.COM.
Maximus-CBCS v2.00 Operations Manual - Page 39
The Chat Menu
Maximus supports a full-fledged, internal multi-node chat module.
Users on different nodes can hold private discussions with one
another; users can even engage in large group discussions on a
"virtual CB channel".
CB Chat
The CB Chat function allows two or more users to participate
in a real-time multi-node chat. Messages can be sent back
and forth, one line at a time, to all users who are
participating in that particular conference channel.
(Maximus supports up to 255 virtual CB channels.)
Page User
The Page User command allows for private chatting between
two nodes only. Selecting Page causes Maximus to send a
"chat request" to the specified node number, and it will
automatically place the paging user in chat mode, waiting
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 message from
another user, the paged user can select Answer Page to
engage in a private chat with the first user.
Toggle Status
The Toggle Status function allows a user to toggle his/her
chat availability. Users which are unavailable for chat
will be unpagable through the Page User command.
Maximus-CBCS v2.00 Operations Manual - Page 40
The Off-Line Reader Menu
The Off-Line Reader menu is the key to Max's internal QWK mail
packer. This menu can be used to select a default protocol and
archiving program, select a set of message areas, download
messages from those areas, and upload 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 for access with the Browse or Download
commands. This area selection will be saved across calls,
so it's possible to select a set of message areas that
interest the user and keep referring to those tagged areas
for future calls.
Download New Msgs
The Download command packs new messages from all of the
currently-tagged areas, compresses them into an archive, and
prepares the file for download. (This option is the
equivalent of specifying the argument "t;n;p" for the Browse
command.) If no default archiver or protocol is selected,
Max will prompt the user to select a protocol before
commencing the download.
Upload Replies
The Upload Replies option allows users to upload a .REP
reply packet into the message areas. Max will automatically
determine the type of archive (even if it's different from
the one selected as the user's default archiver), decompress
the reply packet, and toss the replies into the appropriate
areas.
Protocol Default
The Protocol option allows the user to select a default file
transfer protocol; this option is identical to the one found
on the Change menu,
Maximus-CBCS v2.00 Operations Manual - Page 41
Archiver Default
The Archiver option allows the user to select a default
archiving program; this option is identical to the one found
on the Change menu.
Maximus-CBCS v2.00 Operations Manual - Page 42
INSTALLATION INSTRUCTIONS
This section of the manual describes how to install Maximus from
scratch. There is no conversion procedure available for other
BBS programs aside from CVTUSR, the Maximus user file conversion
utility.
Users of Maximus/2 should also read OS2.DOC before beginning the
installation.
Step 1: Where do I put these files?
This is the easiest part of installing Maximus. Max is
distributed in four separate parts: MAX200-1.LZH, MAX200-2.LZH,
MAX200-3.LZH and MAX200-4.LZH. Each file contains crucial system
information, so you'll need ALL FOUR FILES to install Maximus.
The first step in the installation is to unarchive all four files
into an empty subdirectory using LHarc. (Obviously, since you
are reading this file, you already know how to operate LHarc!)
Most of the files in the distribution kit are packed using a
proprietary FIZ compression method, so you'll see a few files
with a .FIZ extension, some documentation files, and the install
program itself. The only way to unpack the .FIZ files is through
the installation program, so that's what you should run next.
When run, the installation program will display some copyright
information, and then proceed with the installation. It will ask
you where to place the contents of each .FIZ file; unless you
know what you are doing, or if want to use a different directory
structure, the defaults are recommended. To select the default
path, simply press <enter> at each prompt. (The installation
program will create directories which do not exist.)
You should make sure to specify that you are performing a NEW
installation (the default), since you need to extract ALL of the
Max 2.00 files.
After extracting each .FIZ file, the installation program will
then proceed with the first-time configuration. Simply type in
the appropriate text at each box, and use <tab> (or click with
the mouse) to move between fields. To select a particular option
from a radio button group, use the left/right keys to cursor over
to the appropriate location and press <space> to select that
option. Click or press <enter> on the OK button when you have
specified the correct values.
Maximus-CBCS v2.00 Operations Manual - Page 43
Step 2: Configuring your Modem
The modem is your gateway to the rest of the world. It can also
be your biggest headache. Since this documentation can't cover
all aspects of installing your modem, you should refer to your
modem's manual if you are experiencing difficulties.
To begin with, a Hayes-compatible modem is strongly recommended.
Although you may be able to use Maximus with a non-Hayes-
compatible modem, Maximus will be unable to use your modem to its
full potential.
If you do have a Hayes-compatible modem, but you can't get it to
work, chances are that are that your problems have to do with
DCD, or Data Carrier Detect. DCD is a signal which your modem
sends to your computer when it is connected to another modem.
However, when most modems are shipped from the factory, they have
DCD forced on all the time. Unfortunately, this default is
exactly the opposite of what most bulletin board packages
require, including Maximus. Without DCD set correctly, Maximus
will not be able to tell when a user has hung up, and your mailer
software may have problems handling incoming phone calls. There
are two ways to change the way your modem handles DCD, depending
on the type of modem you have.
If you own a 1200 bps modem, then chances are that your modem's
DCD handling is controlled through DIP switches. DIP switches
are those miniscule plastic bits on the front, rear or bottom of
your modem. (You may have to remove one or more panels to access
these switches.) On most 1200 bps modems, DIP switch #6 toggles
whether or not DCD is forced, and it should usually be set in the
UP position. (However, it is a good idea to check your modem
manual, just in case the switch settings are different.) Set the
switch so that DCD reflects the modem's actual state, instead of
being forced on. Also make sure that your modem will send back
verbal result codes (as opposed to numbers). The DIP switch to
control these result codes varies by modem manufacturer, so you
will need to consult your modem's manual to determine which one
to use.
If you own a 2400 bps (or greater) modem, then you will be spared
the trouble of fiddling with DIP switches. Since almost all of
these modems use non-volatile RAM (or NVRAM) instead of DIP
switches, you can modify the modem's settings directly using a
terminal program. Once you load up a communications package,
type in the command `AT' and press <enter>. If everything is
well, your modem should emit a response of "OK". After you have
established that your modem is working, type in the command
Maximus-CBCS v2.00 Operations Manual - Page 44
`AT&C1&S1&D2&W' and press <enter>. (This command may not work
for all 2400 bps modems; consult your modem manual for details.)
This command will set up your modem so that DCD will always
reflect the modem's actual state, rather than being always forced
high.
One other thing which may caused problems is your modem cable.
If your cable does not have the right number of signals wired
through, your modem may also behave as if DCD was set
incorrectly, regardless of DIP switch or NVRAM settings. One way
you can verify your cable configuration is by borrowing a modem
cable from a fellow SysOp. If you determine that your cable is
at fault, you can go to your local computer store or service
centre, and ask them for a cable that has at least pins 2-8 and
20 wired straight through.
Maximus-CBCS v2.00 Operations Manual - Page 45
Step 3: Installing a FOSSIL
Note! Unlike DOS, OS/2 does not require a FOSSIL driver. OS/2
includes a device driver to handle serial output, so Maximus/2
users can skip this section.
Under DOS, Maximus uses an external serial port driver. Like
most FidoNet-compatible packages, Maximus requires a FOSSIL.
`FOSSIL' is an acronym which stands for `Fido/Opus/SEAdog
Standard Interface Layer'. A FOSSIL is a program which handles
all of Maximus' low-level serial communication needs, including
sending and receiving characters.
Using a FOSSIL allows Maximus to be used on semi-compatible
computer systems which don't have 100% compatible serial
hardware. The Maximus distribution package is shipped with a
copy of David Nugent's BNU FOSSIL, which will be more than enough
to get your system running. However, if BNU is not suitable or
will not run on your system, other FOSSILs are available. Some
of the most common FOSSILs are X00 and OpusComm. (Later versions
of BNU may also be available.) If you can't find any of these
programs on a BBS near you, one can be usually be obtained from a
local Software Distribution System ("SDS") node, or from the
author's BBS. (See the program licence for details on the
author's BBS.)
When you are searching for a FOSSIL driver, make sure that the
FOSSIL supports at least "FOSSIL Revision 5" or above, since
Maximus won't work with lower FOSSIL versions.
There are two principal techniques used to install a FOSSIL.
Some FOSSILs, such as OpusComm and BNU, are loaded as TSR
(Terminate and Stay Resident) programs in your AUTOEXEC.BAT file.
Others, such as X00.SYS, are loaded via your CONFIG.SYS file.
Although different FOSSILs have different set-up instructions,
it's fairly easy to install a FOSSIL for a basic configuration.
Here are the basic installation instructions for the three most
popular FOSSILs. These cover only a generic 2400 bps modem on
COM1; you should consult your FOSSIL manual to use Max on a
different COM port or at higher speeds.
Maximus-CBCS v2.00 Operations Manual - Page 46
OPUSCOMM Installation:
To install OpusComm on COM1, simply insert the following
command at the beginning of your AUTOEXEC.BAT:
OPUSCOMM
Make sure that OPUSCOMM.EXE is on your current PATH, or else
this will not work.
BNUCOM Installation:
To install BNUcom on COM1, simply insert the following
command at the beginning of your AUTOEXEC.BAT:
BNU
Make sure that BNU.COM is on your current PATH, or else this
will not work.
X00 Installation:
To install X00 on COM1:, simply insert the following command
at the beginning of your CONFIG.SYS:
DEVICE=X00.SYS
Make sure that X00.SYS is in your C:\ root directory, or
else this will not work.
If you have advanced requirements (such as if your modem is on
COM2, or if you are running a 9600 bps modem), you should consult
your FOSSIL's documentation for more information.
Maximus-CBCS v2.00 Operations Manual - Page 47
Step 4: Editing Configuration Files
In order to run Maximus on your system, you will need to make
several changes to your system set-up, especially in your
CONFIG.SYS and AUTOEXEC.BAT files. (DOS only.)
Note! The default OS/2 CONFIG.SYS does not need to be modified
to use Maximus/2. OS/2 users should skip this section.
In the CONFIG.SYS file, you'll either need to EDIT the following
items if they already exist, or ADD them to the end of CONFIG.SYS
if they do not. A generic text editor can be used to edit your
CONFIG.SYS file, but a word processor in `non-document' mode will
also get the job done.
The first change you have to make is to the `BUFFERS=' statement.
(Again, if you don't already have a BUFFERS= statement, add it to
the end of CONFIG.SYS.) If the system you are using is an XT or
a PC, make sure that the line reads `BUFFERS=20'. However, if
you are using an AT or an 80386, this line should read
`BUFFERS=30' for improved performance. The BUFFERS statement
controls the amount of space that DOS uses for buffering files
that are being read from or written to disk. Setting the BUFFERS
command to the wrong number may slow down your system, but
Maximus will still function correctly.
A second change must be made to the `FILES=' statement. Unlike
the BUFFERS= statement, Maximus will not be able to run properly
unless you have this statement set to a number GREATER THAN OR
EQUAL TO 20. If you are running under a multitasking environment
such as DESQview or DoubleDOS, then this number should be at
least double that. In other words, if you have no multitasker,
use `FILES=20'. However, if you are running a multitasker, you
should use at least `FILES=40', or else Maximus will probably
exhibit erratic behaviour. Again, if you do not already have a
`FILES=' statement, simply add it to the end of your CONFIG.SYS.
The third change you must make is to add the line
`DEVICE=ANSI.SYS' to the end of your CONFIG.SYS. If you look on
your MS-DOS distribution disk(s), you should find a file called
`ANSI.SYS' on one of them. After making the aforementioned
change to CONFIG.SYS, copy ANSI.SYS from your DOS disk to the
root directory of your hard disk.
NOTE! If you are using IBM-compatible hardware and wish to set
Maximus up to use direct screen writes (using "Video IBM" or
"Video BIOS"), you do not need to install ANSI.SYS. Please refer
Maximus-CBCS v2.00 Operations Manual - Page 48
to the MAX.CTL documentation for more details, since your system
may or may not be able to handle this video mode.
Finally, if you are planning on using Squish areas in a multinode
environment, you MUST install a copy of DOS's SHARE.EXE. This
sharing module allows Max to share Squish message bases with
other nodes or tasks; using Squish areas in a multinode
environment without SHARE will certainly cause damage. To
install share, simply make sure that SHARE.EXE is in your root
directory, and then add the line "share" to the end of your
AUTOEXEC.BAT.
Note to Novell users: Installing SHARE is not completely
necessary. As long as you load INT2F.COM after Netware shell,
you can get away without loading SHARE.
Once you have made all of these changes and saved the
configuration files, you should press <Ctrl-Alt-Del> to reboot
your computer. Unless you reboot, changes made to CONFIG.SYS and
AUTOEXEC.BAT will not take effect.
Maximus-CBCS v2.00 Operations Manual - Page 49
Step 5: Setting Up Control Files
This is the most complicated step in setting up your BBS.
Maximus has four basic configuration files which control the
operation of your system: MAX.CTL, FILEAREA.CTL, MSGAREA.CTL, and
MENUS.CTL. MAX.CTL is the main control file, and it controls
almost everything about your system from the log-on screens
displayed to the time `reward' given to users who upload.
MSGAREA.CTL controls all of the message areas on your BBS;
FILEAREA.CTL controls all of the file areas, and MENUS.CTL
controls all of the menus and options. The control files are all
straight ASCII text, so to edit these files, you must either use
a text editor, or a word-processor in a "non- document" or ASCII
mode.
There are a lot of fairly complicated commands in these control
files, but they give you control over even the most minute
aspects of your BBS. Along with this power to tailor your BBS to
your particular needs, there also comes the potential for
screwing things up. Therefore, if you are a new SysOp, it is
advised that you refrain from playing too much with these files
until you get your BBS up and running, and have become more
familiar with the various options which are available.
The installation program has already customized most of the
system control files, so you don't need to do anything just yet.
However, make sure that you know how to edit your control files,
and make sure that your editor can handle plain ASCII files.
Maximus-CBCS v2.00 Operations Manual - Page 50
Step 6: Compiling the Control Files
Once you have made all of the required changes to MAX.CTL, the
next step is to `compile' your control files. If you make any
changes to your control files and forget to compile them, Maximus
will not realize that anything has changed, and will still run
using your old configuration.
Note! The idiot-proof configuration program already compiled
your control file for the first time. However, it's a good idea
to compile it again here, just so that you can learn how to
compile everything properly.
Compiling your control files is easy; the program that compiles
all of your control files is called SILT. Just type in the
command `SILT <ctlname>' and press <enter>, where <ctlname> is
the name of your main control file. If you are working with the
default configuration, then `SILT MAX' should get you running and
compile all four of the control files.
The main MAX.CTL has `Include' statements near the end which tell
SILT to read in MENUS.CTL, FILEAREA.CTL and MSGAREA.CTL
automatically. You cannot compile the other control files
individually, so you must always give SILT the name of the main
control file.
The first time you run SILT, it will probably complain that a few
directories didn't exist, and that it is creating them for you.
You need not worry, since this is perfectly normal. If you have
made any errors in the control file, such as misspelling a
keyword, SILT will warn you about those too. If you have made
any errors, restart your text editor, move to the specified line
number, fix the error, and then recompile using SILT.
Maximus-CBCS v2.00 Operations Manual - Page 51
Step 7: Starting Maximus
Once you have compiled your control files, you are finally ready
to start Maximus. Although your BBS is still fairly bare-bones,
it will be partially usable.
To start up Maximus for the first time, CD to the \MAX directory
and type in the command "max -c". The `-c' switch tells Maximus
to create a new user file, so you should only do this the first
time you run Max. (If you are converting from another BBS
program, now would be a good time to run CVTUSR.)
After a bit of disk activity, Maximus should display a copyright
banner, and print out a message 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 of the installation program. Type the
letter `Y' to continue your logon.
After doing this, Maximus will display a bit of text which
describes your BBS. This text is contained in a file called
\MAX\MISC\APPLIC.MEC. (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 controls, the MaxEd editor,
IBM-PC characters, and hotkeys. Answer `Y' to all four of these
prompts.
After Maximus has finished the interrogation, it will display a
welcome screen and a bulletin file, and will then finally place
you at the main menu. All of these screens are completely
redefinable. Such customization will be described later in this
manual.
Now that you have Maximus working, you will probably want to look
around for a while. Feel free to play around, and explore the
different features of your new BBS. If you would like to send
some test NetMail, try going into the user editor and giving
yourself some matrix credit.
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.
Maximus-CBCS v2.00 Operations Manual - Page 52
Step 8: Support for Remote Callers
To handle non-local callers, Maximus needs to be run from a batch
file. Although Max can be run locally from the command-line, to
properly support external callers, a batch file must be created
to recycle your system after a caller hangs up. In the case of a
power failure, your batch files should also be capable of
restarting the BBS without intervention.
There are two mutually-exclusive methods of running Max:
1) Max can be run using the internal Waiting For Caller (WFC)
subsystem. WFC handles all of the modem manipulation inside
of Maximus, so no external programs are required to answer
the phone. Max will answer the phone, flush out any MNP
garbage, and drop immediately to the main BBS.
2) Max can also be run under a "front end". A front end is a
program which answers the phone, optionally performs some
additional processing, and then passes control to the BBS.
Front ends are commonly used for FidoNet support, since the
FTSC-0001 protocol layer is not built into most BBS
software. If you wish to become a member of FidoNet, you
must run a front end.
In addition, a combination of these two methods is available for
multi-node systems. In most cases, only one node needs to have a
FidoNet address, so one line of your system can run a front end,
whereas the other lines can use the internal WFC module. (All of
this is possible using the same set of control files!)
Using the Internal WFC Module
When run in this mode, Maximus will handle incoming callers on
its own. The first principle of WFC mode is the "-w" command
line switch. To start Max in the most basic WFC mode, the
following command should be 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 wait for an incoming call. Max will autodetect
the incoming caller's speed and switch baud rates automatically.
By default, Maximus is set up to run on any Hayes-compatible
modem. If WFC doesn't seem to be answering the phone correctly,
read the comments in the Equipment section of MAX.CTL. You may
Maximus-CBCS v2.00 Operations Manual - Page 53
have to fiddle with the command strings, but most 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 with a locked baud rate, either see your FOSSIL
documentation about locking your FOSSIL driver, or see the
documentation on the "-s" command-line switch in the Maximus
Technical Reference Manual.
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 your batch file where you wish Max to
be run.
The WFC module can also handle timed events which are run at
specified times of the day. Please see the section entitled
"WAITING FOR CALLER SUBSYSTEM".
Using an External Front End
In this mode, Maximus will not answer the telephone by itself.
Since you are probably using this mode for FidoNet compatibility,
you'll need a "front end" or a "mailer" to handle incoming and
outgoing calls. There are six or seven FidoNet-compatible
mailers freeware/shareware market, and three or four in the
commercial market, so you have plenty to choose from. (At the
time of this writing, the two most common mailers are 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 mailers in the appendices in the Maximus Technical
Reference Manual.
Your mailer's documentation may have some specific details for
hooking it up to a Maximus system; if so, you should follow those
directions. If not, read on. When Maximus starts up with a
caller already on-line, it expects to find a minimum of one
parameter: `-b<speed>', where <speed> is the baud rate of the
caller currently on-line. Generally, this is handled through
Maximus-CBCS v2.00 Operations Manual - Page 54
errorlevels or through a batch file called SPAWNBBS.BAT or
EXEBBS.BAT.
Maximus Errorlevels
Once you are able to run Max for a remote caller (either through
the WFC or from your front end), you are halfway there. When
Maximus terminates, it needs to tell your system what to do next.
For example, if a user entered an EchoMail message, you may want
to run a utility (such as Squish) to process that message, or you
may wish to run some sort of logging utility. To accomplish
this, Maximus sets a numeric variable in DOS called an
`errorlevel'. As mentioned earlier, Maximus has several
errorlevels to juggle for various events, such as a user entering
an echomail message, a user entering a netmail message, logging
off before the user enters a name, etc.
You'll note that in several places throughout the control file,
you can tell Maximus which errorlevel to use in certain
situations. Errorlevels are always numeric, and always have a
value from 1 through 255. (However, Maximus reserves errorlevels
1 through 4 to indicate errors, so you should not use these in
the control file.) The control file comes pre-set with certain
errorlevels, so unless you have a special case, you should not
need to modify these.
Once Maximus is set up to use errorlevels, the only other task is
to make your batch file detect the errorlevel Maximus used, and
react accordingly. Errorlevels can be detected in a batch file
quite easily, through the use of the `If Errorlevel <e> <a>'
statement. <e> is a number, and should indicate the actual
errorlevel to check for, and should also correspond to the
errorlevel specified in MAX.CTL. <a> specifies an action, which
is simply a normal batch file command.
However, there is one item which you should pay special attention
to: DOS process all errorlevels using a greater- than-or-equal-to
operation. In other words,the statement `If ErrorLevel 10 echo
Hi!' will display the word `Hi!' if the errorlevel was set to 10,
but will ALSO display `Hi!' if the errorlevel was set to 11, 12,
or above. For this reason, if you have more than one errorlevel
to check for, you should always arrange the group of errorlevel
statements in a DESCENDING order. For example, to check for
errorlevels 1, 3, 9, 10, 11 and 12, this would be the proper way
to place the statements in your batch file:
Maximus-CBCS v2.00 Operations Manual - Page 55
MAX -p%1 -b%2 (other switches here; use "-w" instead for WFC
mode)
If ErrorLevel 12 (Do op `A' here.)
If ErrorLevel 11 (Do op `B' here.)
If ErrorLevel 10 (Do op `C' here.)
If ErrorLevel 9 (Do op `D' here.)
If ErrorLevel 3 (Do op `E' here.)
If ErrorLevel 1 (Do op `F' here.)
The only other point to remember is that ALL programs modify the
DOS errorlevel. In the example given above, if you were to run a
program called (for example) ABCD.EXE for the 'If ErrorLevel 12'
statement, ABCD would RESET the DOS errorlevel after ABCD.EXE
terminated. Since the batch file is executed one line at a time,
the errorlevel statements which follow would use the errorlevel
set by the ABCD program, rather than the value set by Maximus.
To get around this DOS limitation, you must instead use a GOTO
statement for the `action' portion of the errorlevel statement.
The GOTO command allows your batch file to jump to a completely
different location within the same batch file, and start
executing commands from that point. This is accomplished by
using a statement in the form of `GOTO <l>', where <l> is a
LABEL. A label is a unique, alphanumeric, ONE-WORD name, which
indicates where in the batch file you wish to jump to. Some
valid labels could be called `DoScan', `Heres_The_Scoop', and
`ScanBLD'. However, a GOTO statement alone is not enough to
complete the GOTO operation. You must also place the same label
somewhere else within the batch file, which lets DOS know where
the GOTO statement should end up. You can do this simply by
placing a colon (`:') at the beginning of a line, simply followed
by the label name.
For example, the following sample batch file:
Line 1: :BigLoop
Line 2: echo This will be shown repeatedly
Line 3: goto BigLoop
...would cause the line `This will be shown repeatedly' to
continuously display on the screen, until the user hits control-C
to abort. (Omit the `Line X:' tags when typing this in.) When
DOS starts the batch file, it will process each line in sequence.
When DOS reads line 1, it will recognize that `BigLoop' is simply
a label definition, and will ignore it. Next, DOS will read line
2, and process the ECHO command, by displaying `This will be
shown repeatedly' on the screen. Once DOS encounters line 3, it
will realize that it contains a GOTO statement, and will parse
Maximus-CBCS v2.00 Operations Manual - Page 56
the label `BigLoop' out of the command. Having done that, DOS
will then scan for the prior `:BigLoop' label, and jump back to
line 1, thus continuing the cycle.
However, the GOTO command does have practical applications. The
above example could be re-written like this:
MAX (command line switches here)
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
REM * Do operation `A' here.
goto End
:OpB
REM * Do operation `B' here.
goto End
:OpC
REM * Do operation `C' here.
goto End
:OpD
REM * Do operation `D' here.
goto End
:OpE
REM * Do operation `E' here.
goto End
:OpF
REM * Do operation `F' here.
goto End
:End
In this situation, DOS would first compare the errorlevel
returned by Maximus to those listed in the `If ErrorLevel'
portion of the batch file, and then jump down to the
corresponding label. For example, if Maximus exited using
errorlevel 10, DOS would jump down to `:OpC', and process the
statements which followed. The REM statement is simply a remark,
Maximus-CBCS v2.00 Operations Manual - Page 57
and is ignored by DOS. (Typically, there would be one or more
programs run in that portion of the batch file, as opposed to
just the REM command.) After processing the REM command, DOS
then reads the next line of the batch file, and processes it.
The `goto End' statement is necessary, to make sure that DOS
doesn't keep going, and execute the commands for `OpD' as well.
(Recall that DOS just ignores LABEL DEFINITIONS, such as `:OpD'.
Without the extra `goto End', the batch file would just `fall
through' to the statements under OpD, OpE, etc. The extra goto
specifically instructs DOS to jump to the `:End' label, which is
located at the end of the batch file. On the other hand, some
times you may WANT the batch file to `fall through', since it
allows one to have several similar commands to be processed, when
using the same errorlevel. Fortunately, cases where intentional
fall-throughs are needed are few and far between.)
Arranging the batch file like this allows for more than one
command to be executed for a certain errorlevel, and in addition,
gets around the above-mentioned problem of other programs
changing the errorlevel.
Max's errorlevel numbers higher than 5 are completely
configurable, but if you are using the default configuration, the
following errorlevels will be used:
* Errorlevel 255: This means that Maximus terminated with an
undefined error condition. Your batch file should return to
your front-end mailer.
* Errorlevel 12: This indicates that a user entered EchoMail
and perhaps also NetMail during this session. In response,
your batch file should call whatever scanner/packer program
you use, such as SQUISH OUT SQUASH. If you are using *.MSG
areas, you should also call SCANBLD at this point. After
calling all of these external programs, your batch file
should then restart your mailer.
* Errorlevel 11: This indicates that a user entered NetMail
but no EchoMail during this session. In response, your
batch file should call your mail packer, such as SQUISH
SQUASH or oMMM. After calling the packer, your batch file
should then restart your mailer.
* Errorlevel 5: This indicates that a user logged off without
entering either EchoMail or NetMail during his/her session.
In response, your batch file can execute a program such as
the SCANBLD mail database utility. Alternatively, you may
have your batch file simply restart your mailer.
Maximus-CBCS v2.00 Operations Manual - Page 58
* Errorlevels 4 and 3: These errorlevels are used to indicate
an error condition. Detecting either errorlevel 4 or
errorlevel 4 should cause your batch file to restart your
mailer (or to reload Max in WFC mode).
* Errorlevel 2: Errorlevel indicates that the caller hung up
before entering a valid name at the log-on prompt.
* Errorlevel 1: This errorlevel indicates that the SysOp
pressed <Alt-X> at the WFC screen. When your batch file
receives this errorlevel, it should exit back to the
operating system.
A generic batch file for Maximus (in WFC mode) might look
something like this:
echo off
rem * This is where you call Maximus itself. Change
rem * the `%1' and `%2' as necessary, to make Maximus
rem * work with your mailer. (See the appendix on Sample
rem * Batch Files for more information.)
:Loop
MAX -w (command line switches here)
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 Loop
:EchoMail
rem * Invoke scanner and packer here. Next, go to the
rem * 'Aftercall' label to process any after-caller actions.
rem *
rem * For the Squish mail processor, use the following command:
rem
rem SQUISH OUT SQUASH -fc:\max\echotoss.log
goto Aftercall
Maximus-CBCS v2.00 Operations Manual - Page 59
:NetMail
rem * Invoke packer here, then go to the 'Aftercall' label.
rem
rem For the Squish mail processor, use the following command:
rem
rem SQUISH SQUASH
goto Aftercall
:Aftercall
rem * Invoke after-each-caller utilities here.
goto End
:Error
rem * Something funky happened, so let's say so.
echo There has been an error!
goto Down
:End
rem * This label should re-load your phone answering program.
rem * If you are using the Maximus WFC, you should use the
rem * following line to jump back up to the top of the loop:
goto Loop
rem * If you are using FrontDoor, BinkleyTerm or another front
rem * end, you should comment out the above 'goto' and
rem * uncomment the following line:
rem
rem runbbs
rem
rem * This assumes that you use RUNBBS.BAT to start your
rem * front end. If not, simply insert the name of that
rem * batch file above.
rem *
rem * WARNING! OS/2 users must always use the "Spawn"
rem * method of executing Maximus. Please see OS2.DOC for
rem * more information on setting up your batch files to
rem * work with OS/2.
:Down
Maximus-CBCS v2.00 Operations Manual - Page 60
rem * The system arrives here if there was a problem
echo Error! Maximus had a fatal error and could not continue!
exit
Finally, if you are using any *.MSG message areas, it would be a
good idea to read the chapter on SCANBLD right now. (SCANBLD is
discussed in the "Maximus Utility Documentation" section of this
manual.) When using *.MSG areas, SCANBLD updates the index file
for each area, so you'll have to use it after every caller. In
the sample batch file above, the call to SCANBLD would go under
the label marked ':Aftercall'.
Maximus-CBCS v2.00 Operations Manual - Page 61
Step 9: Events and Yelling
The distribution copy of Maximus comes with a pre-configured
event file. This "event file" serves two purposes:
1) With the internal Waiting for Caller subsystem, the event
file is used to schedule "external events". External events
are used for running external programs at predetermined
times. These events are useful for nightly maintenance,
general cleanup, and anything else you may desire.
2) "Yell events" are also controlled through the events control
file. Yell events are used to define when callers are
allowed to page the SysOp, how long the page should last,
and which tune to play while the SysOp is being paged. Yell
events are configured just like external events, except that
a yell number is specified instead of an errorlevel.
All events are kept in the file called EVENTSxx.BBS, where 'xx'
is the current task number. (For a system with no task number,
use '00' for 'xx'.) Each node on a multi-node 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.
Yell Events
The distribution version of Maximus comes with an event file
called EVENTS00.BBS. This event file contains a single yell
event which is active between 13:00 and 23:00 (local time). You
should read the comments in the event file for details, but you
can add alternate yell time slots by simply duplicating that line
and inserting the appropriate starting and ending times.
One thing to note are the numbers in the "Y3/3/1" flag. The
first "3" specifies that the bell or tune will be played three
times. The second "3" specifies that the user can yell up to
three times in a row before Max will automatically turn off the
Y)ell command. The final "1" specifies that tune #1 will be
played from TUNES.BBS.
Max has an external file called TUNES.BBS which can be used to
play simple notes and melodies on the local speaker. The
comments in TUNES.BBS describe the structure of the file in more
detail, but it essentially contains any number of notes, each
note consisting of a frequency and a duration.
Maximus-CBCS v2.00 Operations Manual - Page 62
The tunes file can contain more than one tune; Max will play the
tune "Yell1" when a user yells, since the distribution events
file includes a "1" in the default yell event. The distribution
version of the tunes file also includes "Yell2", "Yell3", "Yell4"
and "Yell5", so you can try changing the last number of the yell
event to produce different sounds. If you desire, you can also
create your own tunes file.
External Events
As mentioned above, the events file also supports external
events. (These events are only active when using the internal
WFC.) To add an external event, simply add a line to
EVENTSxx.BBS with the appropriate starting time, and add an
"E<erl>" flag to the end of the line. <erl> specifies the
errorlevel that Max will exit with at the specified time. After
creating an entry for the event in EVENTSxx.BBS, you should
modify your batch files to "trap" the specified errorlevel and to
run your external event when that errorlevel is found.
For more information, see either the comments in the distribution
EVENTS00.BBS or the section entitled "EVENTS.BBS CONFIGURATION"
in the Maximus Technical Reference Manual.
Maximus-CBCS v2.00 Operations Manual - Page 63
Step 10: About Priv Levels and Locks
Unlike other BBS programs, Maximus does not use numbers to
represent a user's access level. Instead, Maximus uses a series
of keywords, which are called `Priv Levels'. Listed in
descending order, the following privilege levels are currently
supported:
Hidden (special, see note below)
SysOp
AsstSysOp
Clerk
Extra
Favored
Privil
Worthy
Normal
Limited
Disgrace
Twit
All of these privilege levels, except for `Hidden', can be
applied to an ordinary user or menu command. The`Hidden'
privilege level is a special case, and if applied to a user, it
ensures that the user will NOT be able to log onto your system,
since Maximus will disconnect as soon as the user enters his/her
password. Similarly, setting a menu option or a message/file
area priv of `Hidden' means that nobody can access that option -
not even the SysOp. This is useful for hiding commands that you
don't want even yourself to be able to access.
The only privilege level which confers special capabilities is
that of `SysOp'. For example, users with the privilege level of
SysOp can read private messages in any area, regardless of who
the actual addressee is. It should be noted that simply having
your name listed in the `SysOp' section of the control file does
NOT automatically confer SysOp privileges upon you. Your actual
user profile, contained in the USER.BBS data file, must have your
privilege level set to `SysOp'.
The remaining privilege levels do not confer any special
capabilities and can be assigned to any users you wish,
regardless of what the name of the privilege level implies. The
privilege levels that are required to access menu options and
message/file areas are controlled in MENUS.CTL and
MSGAREA.CTL/FILEAREA.CTL, respectively. These three files will
be discussed later in this document.
Maximus-CBCS v2.00 Operations Manual - Page 64
When first setting up your BBS, try and define a set of rules for
using privilege levels. For example: "First-time callers get a
privilege level of DISGRACE, validated users get a privilege
level of NORMAL, and users who have donated money to the SysOp
receive a privilege level of PRIVIL." If you don't lay out a
plan for assigning privilege levels when you first start out, you
will find it very easy to lose track later in the game of who has
access to what.
Privilege levels are not the only way to control user access to
various areas or menu options, since Max has a "lock and key"
system. Using Max's locks, you can give specific users access to
certain areas or options independently of that user's priv level.
Once an option or area is `locked' with a specific lock number, a
user must have the same key number to access that particular
option or area. Valid lock/keys are numbers from 1 to 8 and
letters from A to X. To add a lock to a message/file area or a
menu option, simply add a forward slash after the privilege
level, followed by the lock characters you wish to use. To
illustrate, an area with an access level of `Privil/167AQX' would
be accessible to only those users whose privilege level was at
least `Privil', and who had keys 1, 6, 7, A, Q, and X.
You can modify a user's keys in the user editor (through the keys
command). User keys can also be modified on-line, using the keys
1 through 8 on your keyboard. Alphanumeric keys can be also
toggled through the priv level window, accessible through the 'S'
option on the SysOp screen.
Maximus-CBCS v2.00 Operations Manual - Page 65
Step 11: Customizing *.BBS Files
Now that Maximus is functional, you are probably interested in
customizing the screens and menus. Your first step will probably
be to modify the welcome screens and information files which came
with the default Maximus package.
Almost all of the display files are stored in your \MAX\MISC
subdirectory, so this is where you will be doing most of your
customization work. Different files are used for different
purposes, and each file has its own unique name. For example,
the first screen displayed to a new user is stored in a file
called APPLIC.BBS, the bulletins are stored in BULLETIN.BBS, etc.
You can change these filenames in MAX.CTL if you want, but it
will be simpler if you leave the names alone for now.
Each file which can be displayed to the user ends with the
extension .BBS. However, you will not be working directly with
these files; just like the *.CTL files, display files need to be
compiled before they can be displayed. Although it is possible
to directly enter text into the *.BBS file, it is usually much
easier to edit the "source code" which contained in the .MEC
file.
"MEC" is an acronym which stands for `Maximus Embedded Commands'.
However, if you really have a burning urge to insert compiled
MECCA codes directly into a .BBS file, a list of the MECCA codes
and their translations can be found in the MECCA language
reference, in the Maximus Technical Reference Manual.
Two of the advantages to using MECCA (as opposed to simply
creating files with ANSI graphics) are:
1) You can imbed user- or system-specific information into any
screen displayed to the user, which gives your BBS a
personal touch.
2) Secondly, MECCA allows you to directly enter colour tokens
and cursor controls. The advantage to this is that Maximus
will STRIP OUT these colour and cursor controls for callers
who don't support them, which makes the *.ANS and *.ASC
kludges of other BBS programs unnecessary. Only one file is
needed for any given screen, and Maximus will convert it
on-the-fly for callers with or without ANSI graphics, with
or without the ability to display IBM graphics characters,
or any combination of the above. This greatly reduces the
time required to maintain your BBS, and it saves disk space
too.
Maximus-CBCS v2.00 Operations Manual - Page 66
A *.MEC file is composed of straight text, plus some optional
"embedded commands". If you want to see an actual *.MEC file,
start up your text editor, and load the file
`\MAX\MISC\NEWUSER2.MEC'. As you can see, the file is mainly
composed of straight ASCII text, but with a few special commands
inserted in, mainly to control colour and to perform special
functions such as displaying the user's name.
Generally speaking, anything in a *.MEC file which is NOT inside
a pair of square brackets is treated as straight text, and is
therefore displayed to the user without alteration. Anything
which IS enclosed in square brackets is called a `token', and is
interpreted specially by Maximus. Tokens have various functions,
which can range from changing the colour of the text, to running
an external *.EXE or *.COM program, to invoking the internal
mail- checker
Although you can see many MECCA tokens in use in the distribution
\MAX\MISC\*.MEC files, a complete list of these tokens is
available in the MECCA documentation, in the Maximus Technical
Reference manual. A complete walkthrough to creating a MECCA
source file is given in that same documentation, so you should at
least read the first few pages of that section.
Once you have finished creating or modifying a *.MEC file, you
must then compile it using MECCA, the Maximus Embedded Command
Compiler (Advanced). Compiling a file with MECCA is easy.
Simply type in the command `MECCA <filename>', where <filename>
is the name of the *.MEC file you wish to compile. For example,
to compile the file called `APPLIC.MEC' into the file called
`APPLIC.BBS', type in `MECCA APPLIC'. MECCA will then compile
the specified file, and warn you if you made any errors.
It's also a good idea to test your creations before allowing your
users to log on. Chances are that some of your compiled *.BBS
files will have problems, so users might get stuck in an endless
loop (or something equally embarrassing). The Oracle utility
will allow you to view *.BBS files off-line without having to
start up a local Maximus session. Please see the section on
Oracle for more information.
Maximus-CBCS v2.00 Operations Manual - Page 67
Step 12: Customizing Msg/File Areas
The next step in customizing your bulletin board system is to set
up your own message and file areas. Although the Maximus
distribution kit came pre-configured with three message and three
file areas, you will probably want to expand beyond this,
particularly if you are a member of FidoNet and carry a number of
EchoMail conferences.
The first thing you should know is that all message areas are
defined in MSGAREA.CTL, and file areas are defined in
FILEAREA.CTL. Both message and file areas have 9-character area
"names", so you can have an unlimited number of message and file
areas, in theory. However, it is usually a good idea to start
with a small number of areas, and then create new ones only as
the need arises.
Each area definition in both MSGAREA.CTL and FILEAREA.CTL begins
with an `Area <area_no>' line and ends with an `End Area' line.
Everything between those lines pertains to that specific area
only. <area_no> specifies the area `number' that is being
defined. Max supports alphanumeric area "numbers" up to nine
characters long; area names such "CHATTER" and "HELP" are
acceptable, as are numbers such as "1", "2" and "3". You can
even mix the two, such as "SYSOP249".
Inside each area definition are a number of keywords which
describe that area. There are many advanced options available,
but only a small subset of those are required for a basic
configuration.
Remember that message areas are defined in MSGAREA.CTL, and file
areas are defined in FILEAREA.CTL. It's possible to mix and
match the two, but your system will be much easier to handle if
the message and file areas are separated into two different
control files.
Options in MSGAREA.CTL
Maximus-CBCS v2.00 Operations Manual - Page 68
MsgAccess <priv>
This statement defines the access level that a user must
possess to access this message area.
MsgInfo <desc>
This statement tells Maximus what to describe this message
area as to the user.
Local <path>
EchoMail <path>
Matrix <path>
Depending on what type of message area this is, you will use
ONE of the above three statements to tell Maximus the type
of messages that are in this area and in what subdirectory
the messages are located. The area type can be LOCAL
(Messages entered in this area stay on your system alone.),
ECHOMAIL (Messages entered in this type of area are
broadcast to other systems who are participating in the
EchoMail conference.), or MATRIX. (Messages entered in this
area are sent directly to the destination node, sometimes
referred to as `NetMail'.) <path> specifies the directory
in which the messages are located. Note: Each message area
must have its own separate subdirectory! Yes, that is
correct. You must have a separate subdirectory for each
message area, just as you must have a separate subdirectory
for each file area. SILT will create this directory for you
if it does not already exist.
Private Only
Public and Private
Public Only
Read-Only
Again, you can use only one of these four statements in a
given message area. These commands tell Maximus which type
of messages to allow users to enter in this area. The first
three statements perform as expected. Users may enter only
private messages, they may be given the option of entering
either private messages or public messages, or they may
enter only public messages. For most users, a read-only
message area means that they cannot enter any messages.
Instead, they can only read existing messages. This is
useful for those sysops who want to set up a message area in
which he/she can post bulletins for users to read.
Obviously, there must be some way for messages to be
entered, or users would have nothing to read. Users with a
Maximus-CBCS v2.00 Operations Manual - Page 69
with a privilege level of at least AsstSysOp are permitted
to enter messages in read-only areas. Users below AsstSysOp
will receive the message, `This is a read-only area', and
Maximus will not allow them to enter a message.
MsgName <tag>
THIS IS ONLY REQUIRED FOR ECHOMAIL MESSAGE AREAS:
This keyword tells Maximus what the `echo tag' of the
current message area is. This tag should be the same as the
one which you have defined for this area in the control file
for your EchoMail utility, usually called AREAS.BBS. For
example, `MUFFIN' is the echo tag of the Maximus SysOp
support echo.
Options in FILEAREA.CTL
FileAccess <priv>
This statement defines the access level that a user must
possess to access this file area.
FileInfo <desc>
This statement tells Maximus how to describe this file area
to the user. You can add some descriptive comments if you
like, so long as all of the text will fit on one line. For
example, the <desc> could be: "General purpose utilities".
Download <path>
This statement defines the subdirectory in which the files
for this file area are contained. In other words, this is
where users will be able to download files from.
Upload <path>
This statement defines the subdirectory in which uploads for
this file area will be placed. You have two options for
defining an upload path:
* Set it to the same subdirectory as the download path.
This means that users should be in the correct area
when they upload files, since the file will be
available for download from the specified area as soon
as the user finishes uploading.
Maximus-CBCS v2.00 Operations Manual - Page 70
* Set ALL upload paths in ALL file areas to point to the
DOWNLOAD path for area 0, which is normally accessible
by only the sysop. This is the most secure option,
since it allows the sysop to check files which are
uploaded before they are put on-line. Only after the
sysop has checked the file out and Hurled it to the
appropriate area is the file available for download by
users. This also means that users can upload a file of
any type anywhere and not have to worry about getting
it in the correct area, since there is only one area
for uploads.
Note! By default, all log-off comments will be placed in message
area 1. However, if you wish to change the comment area, you can
edit the "Comment Area" string in SESSION section of MAX.CTL.
One last reminder. Don't forget to recompile your control files
with SILT after you make any changes!
Maximus-CBCS v2.00 Operations Manual - Page 71
Step 13: Maintaining File Areas
Although message areas are easy to create (by simply adding the
appropriate area definition to MSGAREA.CTL), file areas require a
bit more maintenance. Not only do you still need to create the
area definition, but you also need to create a listing of files
which are available for download in each file area.
If you have no files to go into a particular area, you don't have
to do anything. Maximus will create a file catalog as needed
when a user uploads a file.
Creating File Listings
If you already have some files that you would like to place in a
certain file area, setting up that area is a bit more involved.
For starters, do a CD to the DOWNLOAD directory for that file
area, as you specified it in FILEAREA.CTL. From the download
directory, just copy in all of the files that you wish to have in
that file area.
Once you have done that, to create the initial file catalog,
simply type in the following command at the DOS or OS/2 command
prompt:
FOR %F IN (*.*) DO ECHO %F >> FILES.BBS
You should see a bit of disk and screen activity as the file
catalog is created for you. Although this creates the file
names, you are not done yet. Next, load up an ASCII text editor,
and load in FILES.BBS. Inside this file, you should see a list
of the files in the directory. If you wish to add a comment for
a particular file, you can just add one or more spaces after the
filename, and insert your comment there. (You can use up to
forty-eight characters if you wish to keep the comment on one
line. If the comment is any longer, then Maximus will
automatically wordwrap it onto the next line. You can make the
comment as long as you want, up to 255 characters in length.)
Here are the contents of a sample FILES.BBS for a hypothetical
file area:
TEST.ZIP This is a text file
ABCDEFGH.TXT This is another interesting text file
ACKTHPPT.ZIP A digitized Bloom County comic strip
Maximus-CBCS v2.00 Operations Manual - Page 72
If you want to add files to your catalog after performing the
initial `FOR %F' command, you can simply use your text editor to
place the filename on a new line of FILES.BBS, followed by the
description. Similarly, to delete a file from the catalog, just
delete the line containing the file entry you wish to remove.
You will also need to delete the actual file from the
subdirectory.
When using the default `File Date Automatic' setting in the
control file, Maximus will automatically place the file size and
date beside the filename, in addition to adding a bit of colour
to the catalog.
In addition, you can have files selected for "free download
bytes" (doesn't count against user's download limit), "free
download time" (doesn't count against user's time limit), or
both. Before a file's description, place a slash and a flag
character. For a free time download, use "/t". For a free bytes
download, use "/b". For both free time and bytes, use "/tb".
For example, to make the Max 2.00 files not count against the
user's DL quota, use the following:
MAX200-1.LZH /b This is Max 2.00!
If you want to count the download against the user's byte total
(but not the user's time), this would do:
MAX200-1.LZH /t This is Max 2.00!
Similarly, if you want both free time AND bytes to be given to
the user, the following also works:
MAX200-1.LZH /tb This is Max 2.00!
Finally, you may add comments to the FILES.BBS listing which are
NOT specifically related to one 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. All of the usual *.BBS file
colours and tokens are acceptable. If the first character on the
line is a dash, the colour will be set to WHITE before displaying
the line. If the first character is a space, the colour will be
left alone (usually cyan).
Maximus-CBCS v2.00 Operations Manual - Page 73
Global Downloading and Dupe Checking
If you want to enable global downloading, upload dupe checking,
and the fast locate function, you must use a compiled file
database (as created by FB.EXE).
Global downloading allows users to download a file from an area
other than the current area. For example, if a file in area 10
is called QWERTY.LZH, a user could enter "d;qwerty.lzh" from area
1 and successfully download that file.
Upload dupe checking tells Max to check for duplicate file
uploads. Whenever a user uploads a file, Max will check the
compiled file database to see if that file already exists in one
of your other file areas. If it does, Max will abort the upload
and display a short message to the user.
The fast locate command simply makes the Locate and Newfiles
commands much faster. The search times on a large system will be
sped up by several magnitudes, especially if you have a CD-ROM or
WORM available to users. The fast locate command will be
automatically used if a compiled file database exists in the Max
root directory.
To create a file area database (and to use all of the above
features), you must run a program called FB (Filebase Build). FB
scans the FILES.BBS directories in each file area, compiles it
into a flat binary file, and creates a sorted index at the end.
Max can use this index to process global downloads and dupe
checking; the flat binary files are used for the Locate and
Newfiles commands.
Creating a compiled file database is easy; after making any
change to the file areas (whether it be adding, deleting,
receiving a TICK file, or even modifying a file description), the
following command should be run from the Max root directory:
FB
This tells FB to scan all of the file areas listed in AREA.DAT.
This command creates all of the binary and index files, and so as
long as you remember to run FB, global downloading and upload
dupe checking can be used with no special effort. (You may need
to enable upload dupe checking through the "Upload Check Dupe"
keyword in the SESSION section of MAX.CTL.)
If you have a large system, running FB in this manner can take a
long time (especially if you make a lot of small changes). For
information on compiling only one or two areas at a time, or for
Maximus-CBCS v2.00 Operations Manual - Page 74
using an area data file other than AREA.DAT, please see the
section on FB in this manual.
Maximus-CBCS v2.00 Operations Manual - Page 75
Step 14: Customizing Menus
Max's menus are completely redefinable and can become difficult
to manipulate. If you are just starting out, leave the menus
alone until you become more comfortable with Maximus. However,
even novices can change the access levels of particular commands
in MENUS.CTL. The access level is usually located in the second
or third column of each menu option. The only other "safe" field
is the "Command as it appears to user" option. This command will
be shown on the user's screen for NOVICE-level menus. Remember,
the FIRST character in the command will be used to activate that
option, so make sure that no more than one of your commands uses
a given letter as its first character. (For example, don't use
both "F)ile List" and "F)ind File" on the same menu.)
The last thing which is safe to play around with is the
`MenuFile' option. This option tells Maximus to display a
customized *.BBS file, as opposed to generating a canned file.
This will allow you to completely customize your BBS and make it
look different from any other. Please see the section entitled
`Using Custom Menus' for more information on this topic.
Maximus-CBCS v2.00 Operations Manual - Page 76
Step 15: Configuring the QWK Mail Packer
Maximus supports a built-in QWK offline mail packer. This
feature allows callers to log on, pack up messages from one or
more message areas, and download a compressed mail bundle for
off-line reading and reply. This packer is fully integrated with
the main BBS, so the packer will automatically adjust itself as
areas are added to or deleted from your system.
All of the information for the off-line reader is stored in
READER.CTL. Your next task is load this file into your text
editor, since several keywords need to be modified.
1) First of all, you will need to modify the "Packet Name"
keyword. This keyword specifies the filename to use when
sending QWK packets to your users, minus the ".QWK"
extension. This name should be eight or fewer characters,
case insensitive, with no spaces. Try to make the name
describe your BBS in some way; an abbreviation of your BBS
name is normally used. For example, a BBS called "Fowl
Weather Post" might use a packet name of "FOWLPOST", and a
BBS called "123 Systems Inc." might use a packet name of
"123SYS".
2) Second, you should modify the "Phone Number" keyword to
reflect your actual phone number. Maximus doesn't use this
information, but your system's phone number is normally
placed in the .QWK download packets. The phone number
format given in the control file is suggested, even if you
live in another country, since some external readers depend
on this number being in a certain format. Unfortunately,
this is a problem with the readers, so there's nothing that
Maximus can do about it.
3) Finally, you may want to customize the "Max Mesasges" limit.
If you run a busy system and you want to restrict callers
from downloading more than 200 messages at a time, you can
set a maximum here. In the distribution control file, a
maximum of 600 messages is set. To completely disable the
maximum, comment out the "Max Messages" keyword.
That's all there is to it! Beyond the initial configuration, the
QWK packer is completely self-maintaining. No extra maintenance
is required. However, if you would like to add some features to
your mail packer (such as bulletins and new file lists), please
see the section entitled "QWK MAIL PACKER".
Maximus-CBCS v2.00 Operations Manual - Page 77
Step 16: Miscellaneous Information
You have now completed the installation of Maximus-CBCS.
Although you are now officially finished, there are a few things
that you should keep in mind:
For users of *.MSG areas: A renumbering utility is required. If
you carry any EchoMail conferences, a renumbering utility will be
especially crucial. Maximus comes bundled with a program caller
MR; this will automatically delete, renumber and link messages
based on information given in MSGAREA.CTL. MR doesn't use low-
level disk calls, so it's safe to use on all systems. For more
information on MR, please see the Maximus Utility Documentation.
For users of Squish areas: Although Squish normally handles
renumbering on-the-fly, you may need to use the "SQPACK" utility
on a semi-frequent basis. (Typical systems only need to run
SQPACK once a week, but large systems may need to use SQPACK on a
daily basis.) Squish areas gradually develop small holes over a
period of time, and the SQPACK program can be used to remove
these holes. In addition, if you are performing renumbering by
date, you must use SQPACK, since renumbering by date cannot be
performed on-the-fly. SQPACK is part of Max's companion mail
processor, SquishMail. The SquishMail package includes a number
of other useful utilities (such as diagnostic and repair aids for
Squish-style areas), so getting a copy of SQSH_*.* is a good
idea.
Finally, if you are having trouble installing Maximus, chances
are that you have not followed these instructions to the letter.
Try reading through the installation instructions once more to
see if you forgot anything.
Maximus-CBCS v2.00 Operations Manual - Page 78
MAXIMUS UTILITY DOCUMENTATION
ACCEM: MECCA Decompiler
ACCEM does the reverse of what the MECCA utility does: it takes a
compiled .BBS file, and converts it back to a human- readable
.MEC file. This can be useful if you have lost the source for
one of your .BBS display files, or if you are trying to change a
compiled .BBS file which someone else has given you.
After running ACCEM on a .BBS file, you can freely edit the
resulting .MEC file, and recompile it as you wish. ACCEM can
convert a .BBS file back to the complete .MEC file. The .MEC
file created with ACCEM should be identical to the original .MEC
file, with one small exception: since label names are not stored
in the .BBS file, MECCA will simply convert these into numeric
labels in the form of `/L0', `/L1', `/L2', etc. However, the
reverse-engineered .MEC file will still compile correctly, and
after compiling, the output from the new .MEC file should be
identical to the original .BBS file.
The format for ACCEM is:
ACCEM <infile> [outfile] [-s]
<infile> is the name of the .BBS file to convert. If no
extension is given, then ACCEM will automatically use an
extension of .BBS.
[outfile] is the name of the .MEC file to write to. If no
extension is given, or even if [outfile] is omitted, then ACCEM
will default to the <infile> filename, but using an extension of
.MEC.
[-s] tells ACCEM to split lines which are over 100 characters.
Using this will make ACCEM place an empty brace at the end of
each line, thereby limiting the length of lines in the .MEC file,
but without affecting the .BBS output. This is useful if you are
decompiling a .BBS file with some very long lines, and if your
editor can only display a limited number of columns.
For example, to convert TEST.BBS to TEST.MEC, all of the commands
following would work equally well:
Maximus-CBCS v2.00 Operations Manual - Page 79
ACCEM TEST
or
ACCEM TEST.BBS
or
ACCEM TEST.BBS TEST
If one wanted to split lines over 100 characters in length, the
following would work, too:
ACCEM TEST -s
ACCEM TEST.BBS -s
ACCEM TEST.BBS TEST -s
Maximus-CBCS v2.00 Operations Manual - Page 80
ANSI2BBS/MEC: ANSI to MEC conversion
ANSI2BBS and ANSI2MEC are two programs which will process a file
containing ANSI graphics, and convert it into a file displayable
by Maximus. ANSI2BBS will convert a file containing ANSI
graphics directly into a .BBS file, which can be immediately
displayed by Maximus. On the other hand, ANSI2MEC will convert a
file with ANSI graphics into a file containing MECCA commands, as
opposed to the compiled AVATAR sequences which are generated when
ANSI2BBS is run. ANSI2BBS is useful for a one-time translation,
when you are sure that the output will look right. ANSI2MEC is
useful if you wish to display a file containing ANSI graphics,
but also want to add some special effects, such as customizing
the screen with MECCA tokens, or adding menus. After running
ANSI2MEC and making any changes,the .MEC file must then be
compiled into a .BBS file through MECCA, the Maximus Embedded
Command Compiler. Please refer to the MECCA command language
reference manual for more details on the operation of MECCA.
The format for ANSI2BBS (and ANSI2MEC) is as follows:
ANSI2BBS <infile> [outfile]
or
ANSI2MEC <infile> [outfile]
<infile> is the name of the input file which contains ANSI
graphics. If no filename extension is specified, then ".ANS"
will be used by default.
[outfile] is the name of the file to place ANSI2BBS/ANSI2MEC's
output in. If no output filename is specified, then ANSI2BBS
will add a `.BBS' extension to the input filename, and send the
output to that file. ANSI2MEC will do similar, except it will
use an extension of `.MEC' instead.
Although ANSI2BBS and ANSI2MEC will try do the best job they can
when converting an ANSI file, due to some ambiguities in the ANSI
cursor-movement syntax, it is not always possible to correctly
convert all ANSI graphics files. ANSI2BBS and ANSI2MEC will
particularly have problems with some `highly-animated'
screens,including some of TheDraw's alternate scanning modes,
such as `Diagonal', `Gate', `Squiggle', etc. Maximus can handle
almost all straight-through ANSI files, so unless you are using
one of those scanning modes, you should not have any problems.
However, once you have converted an ANSI screen, it is a good
idea to put it in a place where Maximus can access it, and test
it in local mode, or with the Oracle utility. If the file didn't
Maximus-CBCS v2.00 Operations Manual - Page 81
convert correctly and has some formatting glitches, then you have
two choices:
* If the file is animated, load the file using TheDraw, an
excellent ANSI screen editor by Ian Davis, and turn off the
animation by pressing Alt-J and then `N' to convert the
drawing to normal mode. Then try ANSI2BBS again, and hope
it works.
* Convert the file using ANSI2MEC, and try to edit the MECCA
tokens to fix the problem, and then compile the .MEC file
using MECCA.
* Leave the file as-is, and send straight ANSI codes to the
caller. Although it won't be viewable by AVATAR or TTY
callers, and it will look icky if you have the `Video IBM'
statement enabled, it should work okay for remote ANSI
callers, if you enclose the graphics inside `[colour]' and
`[endcolour] tokens.
Maximus-CBCS v2.00 Operations Manual - Page 82
CVTUSR: User File Conversions
CVTUSR is a utility which will allow you to convert foreign user
files into a format Maximus can handle, from several other
popular BBS programs. In addition, CVTUSR is also capable of
generating an Opus 1.10-style USER.DAT file (for use with
external programs) FROM Maximus' own USER.BBS.
The command-line format for CVTUSR is
CVTUSR [[-x]...]
where valid switches are:
-l and
-m These switches tell CVTUSR to reset the lastread
pointers in a Maximus-style USER.BBS. This option is
normally only used to fix cross-linked lastread
pointers, so it should only be used when "Lastread ptr
xlinked" error message appear in the log. This
function may reset the lastread pointers for some or
all users, but it will correct any crosslinked
pointers. Both -l and -m function identically.
-o110 This switch tells CVTUSR that you are converting an
Opus 1.10-style USER.DAT to a Maximus-style USER.BBS.
This procedure will convert almost all of the Opus 1.10
fields, with the exception of the expiry dates,
personal welcome screens, and any utility-specific
fields which may be stored in the user file. Your old
USER.DAT is NOT overwritten by this procedure, so you
don't need to make a copy of it.
-q This switch tells CVTUSR to convert a QuickBBS or RA-
style USERS.BBS to a Maximus USER.BBS. This conversion
function is not as complete as some of the others; it
will leave out things such as ANSI graphics and "More
[Y,n]?" prompting. However, the next time the user
logs on, Maximus will ask for all the information which
couldn't be converted, so the loss is minimal.
Maximus-CBCS v2.00 Operations Manual - Page 83
When converting QBBS security levels, CVTUSR will use
the following conversion system:
QBBS User Level Max Priv Level
100-32000 SysOp
90-99 AsstSysOp
80-89 Clerk
70-79 Extra
60-69 Favoured
50-59 Privil
40-49 Worthy
20-39 Normal
1-19 Disgrace
-x110 This switch CVTUSR to convert the Maximus-style
USER.BBS to an Opus 1.10-style USER.DAT. CVTUSR will
translate all of Maximus' fields into the equivalent
Opus 1.10 fields, and will also attempt to store some
Maximus-specific information in some "spare" fields.
This means that it MAY be possible to convert the
Maximus USER.BBS to the Opus USER.DAT, run a program
which modifies the Opus version of the user file, and
convert it back. Although this theoretically should
work without problems, it is not advised, and doing so
may cause some fields to be lost in the Maximus portion
of the user file.
-n This flag tells CVTUSR to convert an older Maximus 1.0x
USER.BBS to a Maximus 2.00 USER.BBS file.
-s This flag tells CVTUSR to swap the `alias' and `name'
fields in a Maximus 2.00 USER.BBS file. This function
is used to accommodate the changes in the alias system
available in Maximus 2.00 from older Maximus systems.
Maximus-CBCS v2.00 Operations Manual - Page 84
EDITCALL: Call Fudging Utility
EditCall is a small utility which was written to dummy up the
`number of callers' count contained in BBSTATxx.BBS. This
program is useful if you have recently changed from another BBS
package, and want to set the caller count to reflect the actual
number of callers to your system.
The command-line format for EditCall is:
EDITCALL <task_num> [num_calls]
<task_num> should indicate the task number whose caller counter
you wish to set. If you are running only one line, then use 0
for <task_num>.
[num_calls] should indicate the new number-of-calls variable you
wish to set for the specified task. If you don't specify this
parameter, then EditCall will simply display the number of
callers for the specified task number, without changing anything.
Maximus-CBCS v2.00 Operations Manual - Page 85
FB: File Database Compiler
FB is the Maximus File Database compiler. FB compiles the ASCII
listings in FILES.BBS into a format which can be used by the
global downloading routines, upload dupe checker, and the fast
Locate command. FB is not required, since Max can use FILES.BBS
directly, but you'll be missing out on a lot of the new features
if you don't use FB.
WARNING! FB can only be used for automatic file dating. If you
are using "File Date Manual", you should make sure to remove all
file dates from FILES.BBS before running FB. Using manual dating
is much less of a necessity with FB anyway, since file sizes and
dates are stored in the binary database.
The command line format of FB is as follows:
FB [[area_dat] [area...] [/u]]
[area_dat] specifies the name of the area data file. If no
command line parameters are specified, FB will default to
AREA.DAT in the current directory.
[area...] is a list of zero or more area "numbers", as specified
in the "Area <anum>" statement in FILEAREA.CTL. If no area
numbers are specified, FB will rebuild the entire file database.
Otherwise, FB will only process the file areas given.
[/u] is the optional `upload' switch. This causes Maximus to
scan the UPLOAD path of the specified file areas rather than the
download path. This parameter is used internally by Maximus in
RUNFB.BAT (see below for more information).
When compiling a file area, FB will parse FILES.BBS and create
the following files in each file area:
FILES.DAT A compiled version of each file's name, size,
timestamp, privilege level and flags.
FILES.DMP A compiled version of each file description.
Maximus-CBCS v2.00 Operations Manual - Page 86
FILES.IDX A sorted binary index of all files in the current
area.
If you are using a FileList statement in FILEAREA.CTL, Max will
simply chop off the file list's extension and add .DAT, .DMP and
.IDX as appropriate. For example, if you specified the following
in FILEAREA.CTL:
FileList D:\AREA1.LST
FB would then create files called D:\AREA1.DAT, D:\AREA1.DMP and
D:\AREA1.IDX. This allows owners of CD-ROMs to store all of the
file area information in an alternate location.
Max also supports a special feature for updating the file
database after a file is uploaded. After processing all of the
files uploaded in a single U)pload command, Max will try to find
a file called RUNFB.BAT (or RUNFB.CMD for OS/2) in the Max root
directory. After the upload, if this batch/command file is
found, Max will execute it with the following parameters:
RUNFB <area_dat> <areanum> -u
where <area_dat> is the name of the current AREA.DAT file,
<areanum> is the area into which the files were uploaded. (-u
specifies that FB should check the upload paths rather than the
download paths.)
In the default distribution, RUNFB.BAT looks like this:
fb %1 %2 %3
This causes RUNFB to automatically run FB, which causes the file
database to be updated on the spot. However, if you don't have
enough memory to run FB in the BBS window, or if you don't wish
to waste time by compiling the file database while the user is
on-line, you can use the following in RUNFB instead:
echo fb %1 %2 %3 >>do_fb.bat
(OS/2 users should use 'do_fb.cmd' instead of 'do_fb.bat'.)
The above command creates a log of file areas to update. If you
are using this deferred file database updating, you should insert
the following command in your batch file after each caller:
(DOS 3.0-3.2 only)
if exist do_fb.bat command /c do_fb.bat
Maximus-CBCS v2.00 Operations Manual - Page 87
del do_fb.bat
(DOS 3.3 and above only)
if exist do_fb.bat call do_fb.bat
del do_fb.bat
(OS/2 only)
if exist do_fb.cmd call do_fb.cmd
del do_fb.cmd
These lines cause Max to perform all file database updating after
the caller logs off, which saves on both memory and on-line time.
Make sure to select the command which is appropriate for your
system and DOS revision, and make sure that it's run after EVERY
caller, regardless of whether or not that caller entered NetMail,
EchoMail, or no mail.
Maximus-CBCS v2.00 Operations Manual - Page 88
MAID: Language File Compiler
MAID is Maximus Language File compiler. MAID takes a language
file source, such as ENGLISH.MAD, and turns it into a form usable
by Maximus. The language file support can be used to support
non-foreign languages, or simply to change the prompts in the
English version of Max.
MAID reads the source language from a file called <langname>.MAD.
The distribution version of Maximus comes with one language file
called ENGLISH.MAD. The different files associated with language
file processing area:
<langname>.MAD: The Maximus International Definitions file.
This file contains the language "source".
This file can be edited with an ordinary text
editor, and this file is used as the input
file for MAID.
<langname>.LTF: The Language Translation File. This is the
compiled version of the <langname>.MAD file,
as produced by MAID. This is the only file
that Max uses; if you don't want to change
the language source, feel free to delete the
<langname>.MAD file.
ENGLISH.LTH: The dynamic language include file for the C
language. This is only required when
recompiling the source code.
ENGLISH.H: The static language include file for the C
language. This is only required when
recompiling the source code.
If you are planning on changing the language files, you must keep
ENGLISH.MAD and ENGLISH.LTF as a minimum. By default, the
install program places language files in the \MAX\LANG directory.
The command line format for MAID is as follows:
MAID <langname> [-s] [-d]
<langname> is the full path and name of the language file. Do
NOT include an extension; MAID will add the ".MAD" automatically.
-s Specifies that you want the static language include file to
be generated. This is only required when recompiling the
Maximus-CBCS v2.00 Operations Manual - Page 89
source code. The <langname>.LTH file is not created unless
you use this switch.
-d Specifies that you want the dynamic language include file to
be generated. This is only required when recompiling the
source code. The <langname>.H file is not created unless
you use this switch.
If you wish to change the source in ENGLISH.MAD, you must be wary
of three points:
1) Make sure NOT to change the order of the statements within
the file! Disastrous consequences may result if the strings
get out-of-sync. You can add and delete blank lines or
comments, but leave the order of the strings alone.
2) After changing the language file source, the file must be
recompiled with MAID to create the .LTF version of the
language.
3) After compiling the language file, you MUST recompile your
.PRM file with SILT! Since Max overlays strings in memory,
Max needs to know how long your language files are; the
summary of this information is stored in MAX.PRM. SILT
collects this information while compiling the .PRM file, so
you can simply run SILT to create the language file. If
Maximus detects that the language file has been changed at
start-up, it will print out "Old language <langname>:
recompile PRM file with SILT!" and exit. It is vitally
important that the .PRM file be recompiled after changing
any of the language files.
Finally, if you wish to create a modified language for other
people to use, you can simply copy ENGLISH.* to MYLANG.* (or
whatever you wish to call the language), and then add that
language as a "Language MYLANG" statement in MAX.CTL.
NOTE! We are attempting to set up a "Maximus Language File
Repository". If you have written a Maximus language file for
another language (or if you have done a take-off of the English
language, such as JIVE, VALLEY, etc.), please upload a copy of
the .MAD file to the author's BBS. A special portion of the
Maximus distribution area will be set up for alternate language
files, acting as a central location for obtaining new language
files. Language files are also welcome in SDSMAX, the Software
Distribution System area dedicated to Maximus and related
utilities.
Maximus-CBCS v2.00 Operations Manual - Page 90
MECCA: Display File Compiler
MECCA is a companion utility which will compile *.MEC input files
into binary *.BBS files, which can then be displayed by Maximus.
The operation of MECCA itself is fairly simple. The command-line
format is:
MECCA <infile> [outfile] [-t]
<infile> is the name of the input file, and if no extension is
specified, an extension of `.MEC' will be used by default.
<infile> can include wildcards, so entering `MECCA *.MEC' is
perfectly valid.
[outfile] is the name of the compiled output file. This
parameter is optional, and if not specified, it defaults to
<infile>, using an extension of `.BBS'.
In other words, typing `MECCA BULLETIN' would cause MECCA to try
to compile the file `BULLETIN.MEC' into a file called
`BULLETIN.BBS'.
[-t] tells Maximus to compare the date stamps of the input and
output files, and to skip the current file if the output filename
is newer than the input filename. This is useful for recompiling
an entire directory of .MEC files, if you can't remember what has
changed. Simply type `MECCA *.MEC -t', and MECCA will
automatically scan all of the files in the current directory, and
recompile those which have changed.
Documentation on the internal format of a *.MEC file itself, and
the keywords used therein, is contained in the MECCA Command
Language Reference, in the Maximus Technical Reference Manual.
Maximus-CBCS v2.00 Operations Manual - Page 91
MR: Maximus Renumbering Program
MR is the Maximus-specific renumbering program. MR is only used
for *.MSG-style areas, since Squish areas renumber themselves on-
the-fly. MR automatically reads the information given in
AREA.DAT, renumbers, deletes and relinks messages in *.MSG-style
areas.
The command line format for MR is:
MR <area_dat> [area...]
[area_dat] specifies the name of your Maximus AREA.DAT file.
This parameter must be given for MR to operate properly.
[area...] specifies one or more message areas to be renumbered.
If no message areas are specified, MR will process all *.MSG
areas on your system.
When renumbering, MR will check the "Renum Days" and "Renum Max"
settings for each message area. (For more information on Renum
Days and Renum Max, please see the MSGAREA.CTL section of the
Maximus Technical Reference Manual.) If either of those two
keywords are set, MR will also purge messages based on the
specified criteria. Messages can be killed by message number, by
age, or both.
MR automatically updates the Maximus lastread files and message
area links. Essentially, just include a call to MR in your daily
batch file, and all of your renumbering needs will be taken care
off. If you want to delete messages, make sure to include a
"Renum Max" or "Renum Days" statement in MSGAREA.CTL for the
areas to be trimmed.
Maximus-CBCS v2.00 Operations Manual - Page 92
ORACLE: Display File Viewer
ORACLE is an off-line .BBS file viewer. Unlike other BBS
programs with embedded command languages, Maximus allows you to
view compiled .BBS files without logging on, while still having
the screens displayed exactly as they would be through Maximus
itself.
The command line format for ORACLE is:
ORACLE <bbsfile> [[-x]...]
<bbsfile> is the name of the compiled .BBS file you wish to view.
If no extension is supplied, then .BBS will be used by default.
[-x] can be any of the following command-line parameters:
-hX Sets the current help level to `X', where `X' is the
first letter of a valid help level. Valid options are
`hN' (Normal), `-hR' (Regular), `-hE' (Expert), and `-hH'
(Hotflash).
-i Disables high-bit IBM characters. With this option
enabled, ORACLE will automatically translate IBM Extended
ASCII to the ASCII equivalent.
-kX Sets the user's keys to X, where X is simply a listing of
keys to assign to the user. Valid keys are from 1-8 and
A-X. For example, using `-k1237AD' would give keys 1, 2,
3, 7, A and D to the user.
-mX Sets the local video mode to X, where X is one of `D'
(DOS), `F' (FAST), 'B' (BIOS) or `I' (IBM). By default,
ORACLE will use the video mode defined in the control
file. However, if you wish to use ORACLE from remote, it
may be necessary to use the DOS video mode, since output
from the IBM and FAST video modes normally cannot be
redirected to a COM port.
-pX This tells ORACLE to read the Maximus .PRM information
from the file `X'. If no PRM file is specified, then
ORACLE will default to using MAX.PRM, in the current
directory. THIS PARAMETER IS REQUIRED!
-q This option enables the `quick' hotkey mode.
-slX This option sets the virtual screen length to `X' rows.
This doesn't change your physical screen length; however,
Maximus-CBCS v2.00 Operations Manual - Page 93
it does determine when the `More [Y,n,=]?' prompts are
displayed. This option defaults to 24 lines.
-swX This option sets the virtual screen width to X columns.
This doesn't change your physical screen width; however,
it does change the screen width, and controls when
virtual screen wraps will occur.
-t The -t parameter forces Oracle into TTY video mode. This
will disable all ANSI and AVATAR graphics commands, and
display the file just as it would be shown to a TTY
caller.
-vX This sets the user's privilege level to `X', where `X' is
the first letter of a valid priv level. For example,
`-va' would set the user's priv level to AsstSysOp, while
`-vl' would set the user's priv level to Limited.
In addition to specifying the above parameters on the command
line, you can also permanently set these options through an
environment variable. Instead of typing all of the parameters on
the command line, you can simply place the same options into the
ORACLE environment variable.
For example, issuing the following sequence of commands:
SET ORACLE=-pD:\Max\Max2.Prm -vS -q
ORACLE D:\Max\Misc\Bulletin
is identical to entering all of this at once:
ORACLE D:\Max\Misc\Bulletin -pD:\Max\Max2.Prm -vS -q
Although the first example looks like more typing, you can easily
place the SET command into your AUTOEXEC.BAT, and only type
`ORACLE <filename>' for each future file you wish to display.
Maximus-CBCS v2.00 Operations Manual - Page 94
SCANBLD: Database Builder
SCANBLD is the Maximus *.MSG database update utility. SCANBLD is
only required if you are using *.MSG areas; if you are using
Squish-format areas (which have their own indexing), SCANBLD is
not required and this section may be skipped.
SCANBLD's primary function is to speed up Max's internal
mailchecker, plus a few of the other internal commands. Since
the *.MSG storage system is very slow, an index file must be
built for each area to provide reasonably fast mailchecking.
SCANBLD is not REQUIRED for using the mailchecker, but running
the checker on a non-SCANBLD-compiled *.MSG area will be
extremely slow.
When SCANBLD runs, it creates a database of all of the messages
in each area of your system. SCANBLD must be run after certain
actions, including after running a message renumbering utility,
after receiving EchoMail, and so on. This is somewhat
inconvenient; however, unless you switch to the Squish message
format, you'll have to use SCANBLD to maintain speed in your
*.MSG areas.
The command line format for SCANBLD is as follows:
SCANBLD <user_bbs> <area_dat> ...
[ [All | Local | Matrix | Echo | Conf | @<afile> | ...
<areaname> | !<areaname> | /x]...]
<user_bbs> specifies the name and location of your USER.BBS file.
This parameter is required.
<area_dat> gives the name and location of your AREA.DAT file.
This parameter is required.
After the two mandatory parameters, any of the following commands
can appear in any order:
ALL Specifies that SCANBLD is to scan ALL areas,
regardless of what type of message area it is.
This is the default, and all areas will be scanned
if no parameters are specified. Note that SCANBLD
will only scan *.MSG areas. Even if a Squish-
format message area is specified for processing,
that area will be automatically skipped.
LOCAL Specifies that SCANBLD should scan LOCAL areas.
Maximus-CBCS v2.00 Operations Manual - Page 95
MATRIX Specifies that SCANBLD should scan MATRIX areas.
ECHO Specifies that SCANBLD should scan ECHOMAIL areas.
CONF Specifies that SCANBLD should scan CONFERENCE
areas.
@<afile> Specifies that SCANBLD should read the named file
which contains a list of area tags. SCANBLD will
compare those tags to those specified for the
`MsgName' keyword in each area, and process areas
with matching tags. <afile> can be Max's own
ECHOTOSS.LOG, or it can be the import data files
produced by Squish, ConfMail or QM.
<areaname> Specifies a specific area number/name for SCANBLD
to process.
!<areaname> Specifies that this area is to be excluded from a
normal scan, and is not to be processed. This is
useful if you have two separate area numbers
pointing to the same physical message path, or if
you want to exclude certain areas from one of the
above EchoMail/Matrix/Local scans.
/c Forces SCANBLD to do a full compile of each area
processed. By default, SCANBLD will normally try
to update the mail database in the areas processed
without rebuilding the entire area. You should
ALWAYS use this option after renumbering messages,
or else the message database will become out of
sync with the actual messages.
/nd Informs SCANBLD that you do NOT want the @<afile>
specification to be deleted after processing.
This is useful if you have other utilities which
need the specified file, even after SCANBLD has
finished with it.
/q This switch forces SCANBLD into quiet mode.
Instead of displaying each area's statistics,
SCANBLD will instead display a single hash sign
(`#') for each area processed.
The options specified on SCANBLD's command-line are cumulative,
so entering the following:
SCANBLD user.bbs areas.dat echo matrix 45 !22 @et.log
Maximus-CBCS v2.00 Operations Manual - Page 96
would cause SCANBLD to process all EchoMail areas, in
addition to all NetMail areas, plus area number 45, plus the
areas listed in the ECHOTOSS.LOG-format ET.LOG, with the
exception of area number 22.
It is suggested that you run SCANBLD as follows, since this
procedure ensures that the mail databases always remain
synchronized with the actual messages.
AFTER A USER ENTERS ECHOMAIL (usually errorlevel 12):
SCANBLD user.bbs area.dat local matrix @echotoss.log
AFTER A USER ENTERS MATRIX MAIL (usually errorlevel 11):
SCANBLD user.bbs area.dat local matrix
AFTER A USER ENTERS LOCAL MAIL (usually errorlevel 5):
SCANBLD user.bbs area.dat local
AFTER IMPORTING ECHOMAIL:
SCANBLD user.bbs area.dat local matrix @echotoss.log
AFTER RUNNING ANY MESSAGE-RENUMBERING UTILITY:
SCANBLD user.bbs area.dat all /c
Finally, after using an external message editor, you must SCANBLD
all of the areas which you entered messages in. If your editor
can produce an ECHOTOSS.LOG-like file, then you should run
SCANBLD after your editor, using the command shown for `If a user
enters EchoMail'. On the other hand, if your external editor
does not produce an ECHOTOSS.LOG (or similar) file, then you must
scan all areas, using the following command:
SCANBLD user.bbs area.dat ALL
IF THESE INSTRUCTIONS ARE NOT FOLLOWED TO THE LETTER, SCANBLD may
miss messages which would otherwise be flagged as new mail.
Maximus-CBCS v2.00 Operations Manual - Page 97
SILT: Control File Compiler
SILT is the Maximus control file compiler. SILT takes the raw
ASCII control files which you have created and turns them into
something that Maximus can use directly. Optionally, SILT can be
instructed to parse only part of your system control files.
Starting SILT is fairly easy; the command syntax of SILT is:
SILT <ctl_file> [-a] [-m] [-o] [-p] [-s103] [-s110] ...
[-u] [-x]
<ctl_file> specifies the name of the control file you want SILT
to process, and is the only required argument. If only the name
of the control file is given with no other arguments, then SILT
will process everything EXCEPT the SYSTEM*.BBS files. Otherwise,
SILT will only process the parts of the control file which are
given on the command- line. When specifying the control file, do
not include the .PRM extension.
-a Tells SILT to compile only MSG/FILEAREA.CTL.
-m Tells SILT to generate the *.MNU files from MENUS.CTL.
-p Instructs SILT to generate MAX.PRM, and if requested,
the Opus version 14 and 17 *.PRM files.
-s103 Tells SILT to create SYSTEM*.BBS files for Opus 1.03
compatibility, in addition to compiling only
MSG/FILEAREA.CTL.
-s110 Tells SILT to create SYSTEM*.DAT files for Opus 1.10
compatibility, in addition to compiling only
MSG/FILEAREA.CTL.
-u Tells SILT to run in "unattended mode". Normally, SILT
will prompt the user for input in certain situations,
including when a specified directory doesn't exist.
(In such a case, SILT would ask the user whether or not
s/he want to create the directory.) Using `-U' will
tell SILT not to stop to ask for directions, and to
create any nonexistent directories.
-x Causes SILT to compile everything, INCLUDING the
SYSTEM*.BBS and SYSTEM*.DAT files.
-y This switch tells SILT _not_ to sort message and file
area numbers into alphanumeric order. By default, SILT
Maximus-CBCS v2.00 Operations Manual - Page 98
will sort message and file area numbers before writing
the final index. If you wish to override the default
sort order, using the -y switch tells SILT to use areas
in the order that they are processed (with no sorting).
This option can be used to override the default sorting
order.
Maximus-CBCS v2.00 Operations Manual - Page 99
RUNNING EXTERNAL PROGRAMS
Although Maximus itself offers a large selection of internal
features, chances are that you'll want to execute programs
OUTSIDE of Maximus while a user is on-line. Maximus can run
almost all types of external programs, from customized file-
transfer protocols, to `door' programs written for another BBS
program.
Maximus can execute as many external programs as you wish, from
either a menu option, or from a MECCA embedded command file.
Since these two pieces comprise the whole of the Maximus
software, it means that you can run any external program
anywhere, at any time.
Execution Methods
In general, Maximus supports four different methods of running
external programs. You can determine what type of exit you need
by looking at the list below, and comparing the methods'
advantages and disadvantages to the requirements of the program
you wish to run.
DOS: This is the so-called `normal' exit type. Maximus will
load a second copy of COMMAND.COM, and then run the
external program.
* This is the only way to run a batch file as an
external program.
* Since COMMAND.COM has to be loaded, your external
program will have about 174K less space to work
in. (164K/Maximus + 10K/COMMAND.COM = 174K)
* If the program is located on the DOS PATH, no
explicit path needs to be given.
You can execute internal DOS commands using this
method, such as DIR, TYPE, CHDIR, etc.
RUN: This exit is identical to `DOS', except that
COMMAND.COM is NOT loaded. This means:
* Your program will have a bit more memory to run
in, since a second COMMAND.COM is not in memory.
* You cannot run a batch file with this command.
Maximus-CBCS v2.00 Operations Manual - Page 100
* This method will run faster than the DOS method,
because COMMAND.COM doesn't have to be loaded.
CHAIN: This command is just like `RUN', except the external
program will be loaded ON TOP of Maximus. In other
words, the external program will overlay Maximus in
RAM. NOTE: this execution format may not work with all
hardware and software combinations.
* Since the program is loaded on top of Maximus, it
will be able to use all available system memory.
* This is a one-way command, and control will not be
passed back to Maximus when the program
terminates. It is the responsibility of the
external program to reload Maximus with the
appropriate parameters once the program has been
executed. (See below about restarting Maximus
after a CHAIN command.)
ERRORLVL: This command tells Maximus to exit completely from
memory, and exit to the calling batch file or program.
* This command is slow, since the transient portion
of COMMAND.COM must be reloaded.
* The only interface Maximus has with the external
program is an errorlevel. (However, this is not
totally true. See below about Errorlevel Batch
Files.) Also, see below about restarting Maximus
after an errorlevel exit.
ErrorLevel Batch Files
When exiting via an errorlevel exit, Maximus uses a concept
similar to BinkleyTerm's `BBSBATCH' command, which allows Maximus
to pass command-line parameters to an external program. To
create an errorlevel batch file, instead of specifying only an
errorlevel as the command to execute, add a single SPACE
character (or an underscore, if you are running the external
program through a menu option), and then the name of the command
you wish to run.
ie. `Xtern_Erlvl 65' -> `Xtern_Erlvl 65_Myprg_Arg1_Arg2'.
When Maximus encounters an argument after the errorlevel, it will
write a file called ERRORLVL.BAT in the Maximus startup
directory, containing the argument specified after the
Maximus-CBCS v2.00 Operations Manual - Page 101
errorlevel. (If you have a task number defined in MAX.CTL, then
Max will write a file called `ERRORLxx.BAT' instead, where `xx'
is the task number, in hexadecimal. However, aside from the
filename change, the use of ERRORLVL.BAT is identical to that in
a single-node environment.) In the case of the above example
with MYPRG.EXE, the ERRORLVL.BAT file would contain:
Myprg Arg1 Arg2
Once the errorlevel batch file has been written, then Maximus
will exit with the specified errorlevel. You can then trap this
errorlevel in your batch file, and use a `CALL ERRORLVL.BAT'
command to execute the command. (If using DOS 3.2 or under,
replace the `CALL' with `COMMAND /C'.) After executing the
external program, you can then restart Maximus by the method
described in the next section.
Maximus-CBCS v2.00 Operations Manual - Page 102
Restarting After Chain/Errorlevel
After executing an external program via the CHAIN or ERRORLEVEL
exit methods, Maximus can restart itself exactly where it left
off and appear as if Maximus had remained in memory for the
entire time.
This feature is made possible through the `-r' command-line
parameter. When Maximus is invoked using `-r', it will read a
file called RESTAR*.BBS from the root directory. This file was
written to disk just before Maximus executed the chain/errorlevel
command. This file contains all of the information that Maximus
needs to start up again, so Maximus will simply pick up right
where it left off, whether Maximus was displaying a menu or in
the middle of a *.BBS file.
Also make sure to specify the *.PRM file name on the
command-line, if you are not using MAX.PRM. In addition, if you
are using a NON-ZERO task number, then you MUST accompany the
`-r' option with the `-nXX' (set task number) option.
WARNING! Never attempt to use an `[xtern_erlvl]' token before a
new caller has reached the NEWUSER2 file. Maximus cannot perform
a restart until it knows who the user is, and that means that the
user must have entered their name, password, graphics selection,
etc.
This is an example batch file which utilizes errorlevel batch
files, and also the restart option:
Maximus-CBCS v2.00 Operations Manual - Page 103
REM * These first "%1 %2 %3" parameters will be passed to
REM * the batch file by your mailer. However, they
REM * are not really important when dealing with errorlevel
REM * batch files, so we'll just assume that they are
REM * correct. Also, make sure that the `:DoErlvl' label
REM * comes AFTER the main `Max -b%1 ...' command.
Max -b%1 -p%2 -t%3 -n2
:DoErlvl
if errorlevel 65 goto Outside
REM * [..more errorlevels here..]
if errorlevel 1 goto end
goto end
:Outside
REM * Replace the `Call' with a `Command /C', if using DOS
REM * 3.2 or below! Also, make sure that the number after
REM * the `-n' parameter specifies the Maximus task number
REM * to use, if not the one specified in the control
REM * file.
REM *
REM * Finally, if you are using a non-zero task number, keep
REM * in mind that the filename Maximus writes will be
REM * `ERRORLxx.BAT', where `xx' is the hexadecimal task
REM * number.
call C:\Max\Errorlvl.Bat
Max -r -n2
goto DoErlvl
:End
After you have created a batch file such as this, using
errorlevel exits becomes just as easy as any of the other exit
types. In MECCA, instead of using something in this format:
[xtern_run]D:\Path\Progname.Exe Arg1 Arg2
one could easily replace it with something like this:
[xtern_erlvl]65 D:\Path\Progname.Exe Arg1 Arg2
As you can see, once you have added the errorlevel code to your
batch files, adding new options requires only a minimal amount of
work.
Maximus-CBCS v2.00 Operations Manual - Page 104
External Program Translation Characters
When passing a command-line to an external program (and also when
parsing some special MECCA tokens), Maximus can include
information about the user and SysOp by using special translation
tokens. A format token consists of a percent sign and a single,
case-sensitive letter or symbol. Maximus will interpret the
character following the percent sign, and replace it with the
variable which that character represents.
Maximus currently supports the following external program
translation characters:
Char Translation
%! Embeds a newline in a string.
%A The user's FIRST name, in upper-case.
%b The user's baud rate. If the user is a local caller,
then this will translate to `0'.
%B The user's LAST name, in upper-case. (If the user has
no last name, then this will translate into `NLN', `No
Last Name'.)
%c The user's city.
%C The response to the last `[menu]' MECCA token.
%d The area number of the current message area
%D The area number of the current file area
%e The user's password
%E The user's screen length, in rows
%f The user's first name, in mixed case.
%F Path to the current file area.
%g User's graphics mode -- `0' for TTY, `1' for ANSI, and
`2' for AVATAR.
%G User's Daily DL limit, in kilobytes
%h The user's phone number.
%H Number of kilobytes downloaded today
%i Total downloads
%I Total uploads
%j Minutes on-line, this call
%k The current node's task number. (`0' for no task
number.)
%K The current node's task number in hexadecimal format
padded with leading zero to make it two characters.
(`0' for no task number.)
%l The user's last name, in mixed case. If the user has
no last name, then this will translate into `NLN'.
%L If the user is REMOTE, this will translate into the
string `-pX -bY', where X is the port number (1=COM1,
Maximus-CBCS v2.00 Operations Manual - Page 105
2=COM2, etc) and `y' is the baud rate. If the user is
LOCAL, this will translate into a simple `-k'.
%m The name of the first file to transfer when invoking an
external protocol.
%M Path to the current message area.
%n User's full name, in mixed case.
%N The name of your BBS, as defined in MAX.CTL.
%p The current port number (0=COM1, 1=COM2, etc).
%P The current port number (1=COM1, 2=COM2, etc).
%q Path to the current msg area (NO trailing backslash)
%Q Path to the current file area (NO trailing backslash)
%r The user's real name, if applicable.
%R All remaining stacked text, as entered at the last
menu.
%s The SysOp's last name, in mixed case. If the SysOp has
no last name, then this will translate into `NLN'.
%S The SysOp's first name, in mixed case.
%t The amount of time the user has left, in minutes.
%T The amount of time the user has left, in seconds.
%u The user's user number.
%U Simply translates to an underscore.
%v Path to the current upload area (with trailing
backslash)
%V Path to the current upload area (NO trailing backslash)
%w The path to the current FILES.BBS-type file. This
takes into account the alternate names which may be
used by the `FileList' option.
%W The "steady baud rate", as passed via the -s
command-line parameter.
%x Drive letter of current drive, in upper case.
%X The last read message number for the current message
area. This only works while in a message area.
%Y The user's current language number, zero based (0 is
first language, 1 is second, etc.)
%Z Translates to the user's full name, in caps.
In addition to the above translation characters, there is also
another set of almost-identical characters, which can be used
when giving Maximus the name of a file to display. However, the
first character in sequence should be a "+", rather than the
usual "%". The second character WILL be treated as shown above,
and translated normally. For example, to display a file called
D:\<#>.BBS, where <#> is the user's number, you would use the
following command in MENUS.CTL:
Display_File D:\+u.BBS Twit "Display It!"
Maximus-CBCS v2.00 Operations Manual - Page 106
Please keep in mind that the usage of the "+" is only required
when specifying a filename to display. The percent sign should
be used in all other cases.
Finally, there is one additional shortcut for *.MNU menu names.
If you wish to substitute the current task number in a filename,
then substitute the "*" character where you wish the task number
to appear, and Maximus will translate it automatically. For
example, the following line...
First Menu MAIN*
would cause task 0 to display a menu called MAIN00.MNU when first
executed, task 1 to display MAIN01.MNU, etc. (Keep in mind that
the task number is in hexadecimal, and therefore the menu
displayed for task 12 would be MAIN0C.MNU.)
Maximus-CBCS v2.00 Operations Manual - Page 107
Running Doors
A `door' is just a fancy name for an external program which can
be run and can communicate with an on-line user. Most door
programs contain modem routines, so they can keep track of a
user's time limit, make sure that the user doesn't drop carrier
while inside the door, etc.
However, running a door program presents a special problem.
There are several conflicting standards for `door interfaces',
which are what controls the way the BBS program passes
information to the door. Most modern door interfaces can pass
out the user's name, whether or not the user supports ANSI
graphics, the name of the SysOp, etc.
Maximus includes built-in support for the Opus 1.03 LASTUSER.BBS
standard, as well as the capability to DIRECTLY write ANY
text-based door interface file. The distribution version of
Maximus comes with MECCA scripts which allow you to create door
interface files for the following formats: DORINFO1.DEF (QuickBBS
and RBBS), CHAIN.TXT (WWIV), CALLINFO.BBS (WildCat!) and
DOOR.SYS. In addition, you can write your own MECCA scripts,
which allow you to generate a door interface file for almost any
other system type.
Maximus can achieve this through the use of the `[write]' MECCA
token. Although the `[open]' and `[post]' commands were
originally used for on-line questionnaires, they serve a dual
purpose under Maximus. The `[write]' token will simply write a
line of text to the previously-opened file, while making
translations to the string, as described in the `External Program
Translation Characters' section, above.
For example, the only requirement to make Maximus write a
QuickBBS or RBBS-compatible DORINFO1.DEF file is to copy the
following MECCA script into a file called DORINFO.MEC, and
compile it. (Note! If you are using the standard distribution
package, then you can find this file, including the compiled .BBS
version, in the \MAX\MISC subdirectory.)
When copying this into a file, be sure to line up all of the text
against the left margin. Also make sure to change the [delete]
and [open] tokens to reflect the path where you want the
DORINFO1.DEF interface file to be placed.)
Maximus-CBCS v2.00 Operations Manual - Page 108
[delete]C:\Max\Dorinfo1.Def
[open]C:\Max\Dorinfo1.Def
[write]%N [ comment Write the BBS name]
[write]%S [ comment Write the SysOp's f.name]
[write]%s [ comment Write the SysOp's l.name]
[islocal write]COM0 [ comment Write the COM port]
[isremote write]COM%P [ comment (local is always COM0)]
[write]%b BAUD,N,8,1 [ comment Write the baud rate]
[write] 0 [ comment Say we are not networked]
[write]%A [ comment Write the first name]
[write]%B [ comment Write the last name]
[write]%c [ comment Write the city]
[write]%g [ comment Write the graphics]
[sequal write]100 [ comment Write the security level]
[sxclude write]50 [ comment Ditto]
[write]%t [ comment Write the time remaining]
[write]1 [ comment Say we are using a FOSSIL]
[quit] [ comment And we are done!]
You can create similar files for other door interface types, by
simply creating another MECCA file containing the appropriate
commands. (A list of the external program translation characters
has been provided in the prior section; however, you can use the
above DORINFO.MEC file as a guide to designing your own door
interface files.)
There are three ways to have DORINFO1.DEF (or any of the
above-mentioned files) created when running an external program:
TO CREATE DORINFO1.DEF FROM A .MEC FILE:
To have the appropriate door file created, simply include
the following line, whenever you wish to have DORINFO1.DEF
written:
[link]C:\Max\Misc\Dorinfo
As mentioned above, the distribution version of Maximus also
comes with MECCA scripts to generate several other types of
door interfaces. The format for using these is similar to
the interface described above:
[link]C:\Max\Misc\WWIV - To create CHAIN.TXT
[link]C:\Max\Misc\CallInfo - To create CALLINFO.BBS
[link]C:\Max\Misc\DoorSys - To create DOOR.SYS
TO CREATE DORINFO1.DEF FROM A MENU OPTION:
Maximus-CBCS v2.00 Operations Manual - Page 109
Similarly, you can achieve the same results through a menu
option, by simply linking the appropriate .BBS file to the
menu option. (For more information, please see `Linking
Menu Options' in the Maximus Technical Reference Manual.)
For example, to create a DORINFO1.DEF file for running a
program called `C:\Max\Prg.Exe', you would use something
similar to the following in MENUS.CTL:
NoDsp Display_File C:\Max\Misc\Dorinfo Twit "Run Prg.Exe"
Xtern_Run C:\Max\Prg.Exe Twit "R"
Again, the same concept can also be applied to the other
MECCA-created door scripts, by simply substituting the name
of the script into the Display_File command.
TO HAVE DORINFO1.DEF CREATED AUTOMATICALLY:
If you wish to have DORINFO1.DEF written every time Maximus
exits for an external program, for whatever reason, you can
simply edit the `Uses Leaving' statement in MAX.CTL, such
that it reads like this:
Uses Leaving C:\Max\Misc\Dorinfo
This will instruct Maximus to create DORINFO1.DEF whenever
Maximus runs an external program, without needing to be
specifically instructed to.
What follows is a demonstration of how to install a non- Maximus
door in a menu file, assuming that you have NOT implemented the
above `Uses Leaving' statement in MAX.CTL.
In MENUS.CTL, you should add the following to the menu which you
wish the door to appear on.
Display_File Misc\DorInfo Disgrace "Play BoreDoor"
NoDsp Xtern_Dos BD\Bore.Bat Disgrace "P"
The `Display_File' command tells Maximus to write the
DORINFO1.DEF file, which will always be written to the C:\MAX
directory (unless you have changed the .MEC file).
The `Xtern_Run' command tells Maximus to run the batch file
called BD\BORE.BAT, which you'll need to create later. (The
`NoDsp' in front tells Maximus not to show `P' on the menu a
second time, since you only want the first `Play BoreDoor' to be
visible. See the section on Linking Menu Options (in the Maximus
Technical Reference Manual) for more details.)
Maximus-CBCS v2.00 Operations Manual - Page 110
When a user selects `P' from the menu, Maximus will execute the
above options in order. That means that DORINFO1.DEF will first
be written, followed by the execution of BORE.BAT.
Although the contents of the batch file are highly specific to
the door program you'll be running, in general, you should use a
format similar to this, in BORE.BAT:
echo off
REM * Change to the right directory
cd \Max\BD
REM * Copy the DORINFO1.DEF file from the
REM * main Maximus directory into the
REM * current directory, which is probably
REM * where the door program will look for
REM * it.
copy \Max\Dorinfo1.Def
REM * This is the door program itself. The
REM * command-line parameters will be
REM * specific to the door you are running, so
REM * you should consult your door's installation
REM * instructions for more details.
BoreDoor
REM * Now change back to the Maximus
REM * directory.
cd \Max
REM * And exit back to Max!
exit
Maximus-CBCS v2.00 Operations Manual - Page 111
On-Line User Record Modification
Some door programs may be written specifically for Maximus, and
may need to directly change part of a user's profile (such as the
user's remaining time, ANSI/AVATAR preference, phone number,
etc.), even while the user is on-line. Maximus supports this
feature through a series of special keywords and characters,
which cause it to re-read the LASTUSxx.BBS file after returning
from an external program.
If you are running the external program through an option in
MENUS.CTL, then the fastest way to enable on-line modification is
to place the `ReRead' modifier in front of the usual `Xtern_xxx'
option. In other words, instead of invoking the program like
this:
Xtern_Run D:\Path\Prog.Exe Disgrace "Program"
you would place the following line in MENUS.CTL, which would
enable on-line modification:
ReRead Xtern_Run D:\Path\Prog.Exe Disgrace "Program"
Similarly, you can perform the same operation when using the
[xtern_xxx] MECCA tokens, by using an `@' as the first character
in the program name. For example, instead of using this:
[xtern_run]D:\Path\Prog.Exe
you would use this, instead:
[xtern_run]@D:\Path\Prog.Exe
However, keep in mind that most programs don't need this feature.
For security reasons, you should not use this feature, unless the
external program's documentation states that on-line modification
will be performed.
Maximus-CBCS v2.00 Operations Manual - Page 112
MULTI-LINE OPERATION GUIDE
In addition to general multi-line support, Maximus 2.00 supports
an integrated paging and inter-node chat facility, which makes it
ideal for multi-line systems. In addition, Maximus uses
NetBIOS-compatible file opening calls (using the SH_DENYNONE
attribute), which makes Maximus even more suited for network
applications.
This section is merely a guide to running Maximus in a multi-line
environment. Undoubtedly, there will be some problems which are
not covered by this section, and there will be some questions
left unanswered. However, this section will hopefully answer
most of the basic questions, and at least give you a head start
on installing a multi-node version of Maximus.
Installation
Installation of a network version of Maximus is fairly similar to
a normal installation. Simply run the INSTALL program, and
answer all of the questions it asks.
However, there are several important things to consider:
* Normally, you'll need a SEPARATE batch file for EACH copy of
Maximus you wish to run. You can reduce duplication by
moving common parts of the batch file into a separate file
and calling it with CALL or COMMAND/C, but you'll still need
a separate batch file for each node you wish to run.
However, all Max tasks can be run out of the same directory,
so you can run everything out of \MAX.
Fortunately, you only need one copy of the MAX.PRM file:
you can use the `-nXX' and `-lX' command line parameters to
adjust the task number and log filenames at runtime.
However, you DO need to specify a separate log file for each
task. Naming the log Line01.Log for task 1, Line02.Log for
task 2, and so on is a reasonably way of handling log files.
(If you don't want a log file for a certain node, then
simply use the `-l' command line parameter without
specifying a filename.)
Even if you use the same .PRM file for all tasks, you can
still display node-specific files to the user through the
use of the `*' token. When display a .BBS file, `*'
translates into the current two-digit task number, zero-
padded and in hexadecimal. For example, if you specified
`D:\Max\Misc\Welcom*' as the welcome file in MAX.CTL,
Maximus-CBCS v2.00 Operations Manual - Page 113
Maximus would display WELCOM01.BBS for task 1, WELCOME02.BBS
for task 2, and so on.
Advanced users: Actually, it's possible to run multiple
copies of Max with only one batch file. If you set an
environment variable to equal the current node number, you
can use that variable as a replaceable parameters in a
single batch file. However, this requires a bit of
knowledge about DOS, so it is not recommended for normal
users.
* When setting up your batch files, you should make sure that
ALL copies of Maximus are started from the same directory.
This will allow you to share some files between nodes, in
addition to providing a cleaner directory structure.
* If you are part of FidoNet, you may want to run a mailer on
one line only. Fortunately, the internal WFC module can be
used on a node-by-node basis with the same set of control
files. For more information on using WFC, please see the
section of the installation entitled "Support for Remote
Callers".
* When looking for a compatible FOSSIL, it may take a bit of
work to find one that runs correctly under your network
software. If you are having mysterious communications
problems, then try switching to a different FOSSIL. There
are at least three different types for the IBM PC, so you
should have no problem finding one which works with your
hardware.
* In your AUTOEXEC.BAT, you may wish to include commands to
delete ACTIVE*.BBS and UTASK*.* from the main Maximus
directory, and IPC*.BBS from the inter-process
communications directory. These are temporary files created
by Maximus during execution, so they should not be left
lying around. If you need to restart the network while
Maximus is running, these files won't get deleted which may
cause future problems. To fix this, you should include the
above-mentioned delete commands in your AUTOEXEC.BAT to make
sure that you start with a clean slate whenever you reboot.
(In the case of a network, the delete commands should be
placed in the server's AUTOEXEC.BAT. If you are running
DESQview or some other multitasker on a single node, then
you can also place those statements in your main
AUTOEXEC.BAT.)
Maximus-CBCS v2.00 Operations Manual - Page 114
* If you wish to use either of the multi-node chat or the
paging features, your operating system must support file and
record locking. Under DOS, this means that you must load
the DOS "SHARE" program. Under OS/2, file locking is built
into the operating system, so no special utilities are
necessary. Although it is possible to use Maximus in a
multi-node environment without loading SHARE (through the
`No Share.Exe' option in MAX.CTL), this is strongly
discouraged, and no guarantees are made if you don't load
SHARE.
* Make sure that all copies of Max have a unique and NON-ZERO
task number. If the task number is set to zero, Maximus
will assume that you are running in a single-node
environment, and won't bother to check the inter-process
communications area. In fact, none of the multi-node
features will work if you are using a task number of zero.
Multi-Node Chat Operation
The main way in which Maximus takes advantage of multiple lines
is through the integrated multi-node chat and paging facility.
These features are much like those found in the commercial
PCBoard and TBBS programs and are just as flexible. Users can
toggle whether or not they can be paged by others, they can
display a list of who is on-line, and they can actually enter
into a real-time conversation with other callers.
The first step in configuring the multi-node chat is to enable
the `Path IPC' statement in MAX.CTL. (Make sure to follow the
instructions in the `Path IPC' description about installing
SHARE.EXE and creating a RAM disk!)
The second step is to edit MENUS.CTL and uncomment the
Display_Menu option which calls the CHAT menu. Although you can
use a custom MenuFile for the chat section, it is best to leave
this for later, and use the built-in `MenuHeader Chat' for now.
You can worry about tweaking the cosmetics once everything is
running smoothly.
Having changed MENUS.CTL, the only remaining step is to recompile
the control files. But before allowing users to call the system,
you should first test it yourself, by logging onto two nodes
locally. (You'll have to use two different user names, since
Maximus will only let one user hog one node at a time.)
Before testing the chat mode itself, enter the Chat Section, and
look at the menu display. The table should show the node number
Maximus-CBCS v2.00 Operations Manual - Page 115
which you are logged on to (including your name, and the `(you)'
designation), in addition to the same information about the
second node. (If there is no display, check to make sure that
you have implemented the `Path IPC' keyword, and that it points
to a valid drive and directory. Another possibility is that you
have forgotten to load SHARE.EXE.)
If the menu display seems to be in order, the next step it to try
toggling your chat availability a few times. After your status
has been toggled, the table should indicate whether or not you
are available for chat, in the `Status' portion of the table.
You can also check that the other node was informed of the
change, by simply entering the Chat Section on the second node,
and looking at the table on that system.
Finally, after you have confirmed that everything else is
working, you can enter the multi-node chat itself. To initiate a
chat, select the P)age option. Then enter the number of the
other node you have logged onto, and wait for the chat request to
register. (This should take no longer than about 15 seconds.)
After you have paged the user, you should see a `You are being
paged by Joe SysOp (node XX)' message on the other node. This is
the canned page message; to modify it, you can either edit the
ENGLISH.MAD language file, or you can create a
\MAX\MISC\CHATPAGE.MEC file. (For information on the latter, see
the section on hardcoded filenames.)
To answer the chat request, simply select the A)nswer Page option
and enter the node number of the user who sent the request. This
should place you inside chat mode: the other user should see a
`User Name joins the conversation' message, which indicates that
the other user answered the chat request.
The user who answered the page won't see anything immediately; to
find out who is participating in the conversation, you can simply
type a `/w' command at the beginning of a line, and Maximus will
display the list of callers on the same channel. To list all of
the callers on the system, whether or not they re in chat, type
'/s'.
Once in chat, users can send messages to each other by simply
typing the text that they wish to send. Maximus will
automatically word-wrap at the end of lines, and the text will be
transmitted one line at a time. If possible, it's best to try
typing a few times from each node to make sure that the chat
function is working properly.
Maximus-CBCS v2.00 Operations Manual - Page 116
Once you are finished testing, you can use the `/q' command on
each node to exit chat mode. (When a node exits chat, the other
nodes participating in the same chat should see a `User Name
leaves the conversation' message.)
In addition to the private chat facility (which is what you just
tested), Maximus also supports a group chat, or a `virtual CB'
chat. The CB chat is useful when you have three or more nodes,
and want to have more than two callers in one conference.
Maximus supports 255 concurrent `channels', which means that
there can be up to 255 separate group conversations going on at
the same time. However, the CB chat has no paging ability; it's
up to the callers to look at the status screen in the Chat
Section, and see which channel everyone else is using.
Aside from the differences in invoking the CB chat, once you get
inside the chat mode itself, Maximus will behave just as it does
inside the private chat, even using the same commands. For more
information on using Max's multi-line chat, please see the chat
help file, included in the Maximus distribution package.
(Assuming a standard system, the help file is accessible using
the `?' command from the chat menu, or through the `/?' command
inside chat mode.)
Maximus-CBCS v2.00 Operations Manual - Page 117
USING CUSTOM MENUS
Maximus allows you to create custom menus with relative ease:
simply insert a `MenuFile' command in the appropriate section of
MENUS.CTL, and you are done. However, there are several tips and
tricks you may find useful when designing custom menus,
especially when using fancy ANSI or AVATAR graphics.
* When using a menu which contains a `[cls]' MECCA token,
you'll notice that output from some of the internal commands
(such as Version or Statistics) disappears, since the [cls]
command in the menu erases it, before it can be seen by the
user. The solution for this is to link a `Press_Enter' menu
option after the appropriate command, which will cause
Maximus to wait until the user presses <enter>, before
re-displaying the menu. (For more details, see the section
entitled `Linking Menu Options' in the Maximus Technical
Reference Manual.) For example, to make Maximus wait after
displaying the user's statistics, you might use something
like this:
Statistics Disgrace "Statistics"
NoDsp Press_Enter Disgrace "S"
* If you are using a custom MenuFile statement in the message
or file areas, you should never disable the MenuHeader
statement. If all you want to do is to suppress the
'MESSAGE Section' banner and statistics information, use
"SilentMenuHeader Message" or "SilentMenuHeader File"
instead of the equivalent MenuHeaders. This will cause the
appropriate menu processing to take place, but nothing will
be displayed on-screen.
However, if you REALLY need to disable even the
SilentMenuHeaders, for whatever reason, you must modify your
MenuFile to compensate for this. Due to the flexible way
that Maximus handles menus, you need to inform the menu
handler that a particular menu represents a message/file
area so it can read certain pieces of information from
AREA.DAT. Since the MenuHeader statement usually informs
Maximus of this, disabling it will make Maximus think that
the menu just represents a normal area. The solution for
this is to place either the `[message]' and `[file]' MECCA
tokens at the top of the custom MenuFile, depending on the
type of area (message or file) you want the menu to
represent. These tokens must be used before any of the
message- specific tokens (such as `[msg_cname]') are used.
The [message] or [file] token only needs to be used when a
message area is first entered - this means that you can
Maximus-CBCS v2.00 Operations Manual - Page 118
place the [message] or [file] token in the custom HeaderFile
as well, although it will work equally well in the MenuFile.
* When designing a custom menu with an input prompt at the
bottom, you may have some trouble getting the cursor to stop
at the appropriate place. Most text editors automatically
insert a carriage return after the last line of the file,
and since Maximus reads the entire file, this will cause the
cursor to skip down to the next line after the entire file
is displayed. There are two solutions to this: the first is
to use a text editor that DOESN'T insert a carriage return
at the end of the file. The other solution, if you are
using a .MEC file to create the menu, is to insert a
`[quit]' token where you want the cursor to stop. As soon
as Maximus encounters this token, it will stop displaying
the file, without displaying an extra carriage return. On
the other hand, if you are creating the MenuFile manually,
you can insert the compiled equivalent directly into the
text, which is `^oQ'. (Control-O and then a capital letter
`Q'.). This has the same affect as would the [quit] token,
and this token will caused Maximus to behave in the desired
fashion.
Maximus-CBCS v2.00 Operations Manual - Page 119
WAITING FOR CALLER SUBSYSTEM
Max 2.00 supports an internal Waiting for Caller (WFC) module.
This module allows Max to initialize the modem, wait for a call,
answer the phone, and pass control to the main BBS. WFC can be
used on all nodes of a system, on selected nodes, or on no nodes.
Nodes which do NOT use WFC will require an external program to
answer the phone, such as BinkleyTerm or FrontDoor.
Starting WFC
The WFC module is activated with the `-w' command line switch.
Optionally, the `-p' and `-b' switches can be used to override
the starting com port and baud rate. If you specify just `-w',
WFC will start up using the com port and baud rate specified in
the control file.
Before using WFC, you must make sure that the modem strings in
MAX.CTL are configured correctly. The distribution version of
Max comes with a modem configuration which supports most Hayes-
compatible modems. However, if the WFC module doesn't work out
of the box, you may have to fiddle with certain strings (such as
the "Answer" and "Init" strings) to make it perform as expected.
In particular, the distribution MAX.CTL defaults to using "manual
answer". This means that, instead of telling the modem to
automatically answer the phone when it detects a ring, Max will
take care of ring checking itself. This means that the phone
will only be answered when Max is ready to take a call, which is
the preferred method of doing things.
However, this manual phone answering may not be compatible with
all systems. If you wish to disable manual answering, change the
last part of the Init string to read "S0=1" instead of "S0=0",
and comment out the "Answer" string. This will instruct your
modem to answer the phone automatically, which may work better on
several brands of semi-compatible modems.
Screen Display and SysOp Keys
When WFC starts up, assuming that you are using Video IBM or
Video BIOS, you will see four multicolored windows displayed on
the screen.
The first window, "Status", gives you the time until the next
event, the current modem status, the number of calls made to your
Maximus-CBCS v2.00 Operations Manual - Page 120
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 past responses from the modem. In this window, Max will print
out result codes send from the modem.
The third window, "Current Activity", is a scrolling window which
displays log messages as they appear.
The fourth window, "SysOp Keys", contains descriptions for all of
the keys which can be pressed while in WFC mode.
Pressing <Alt-K> will start a local copy of the BBS. Maximus
will take the phone off-hook and then commence the normal log-on
procedure.
Pressing <Alt-J> will start an OS shell. You can do file
maintenance, make changes to your batch files, or perform other
small changes while in the shell. Type `exit' to return to
Maximus. Maximus will take the modem off-hook while you are in
the shell.
Pressing <Alt-X> will take the system down. Max will put the
phone off-hook, clear the screen, and exit to your batch file
with errorlevel 1.
For more information on installing WFC, please see the section in
the installation entitled "Supporting Remote Callers".
When using the internal WFC, Max can also handle "external
events". External events are used to run a particular program at
a given time, usually by exiting to your batch file with an
errorlevel. Events are covered in detail in the EVENTS.BBS
section of the Maximus Technical Reference Manual.
Maximus-CBCS v2.00 Operations Manual - Page 121
EXPIRATION/SUBSCRIPTION SYSTEM
Maximus supports a full-fledged user subscription and expiry
system. Callers can be set to "expire" based on the current date
or time used (in minutes). When a caller expires, Max can
optionally demote that caller to a lower priv level, hang up, or
delete that user's account.
To access the user subscription system, start up the Max user
editor with "max -u". Until you get the hang of Max's
subscription system, create a new user for testing purposes.
(The "A" key will append a blank record to the end of the user
file.)
To create a subscriber, first select the "," key; this allows you
to set the "expire by" field. If you want the user's account to
expire after a certain date, select "D". If you want the user's
account to expire after a certain number of minutes, press "M".
If you don't want the user to expire at all, press "N".
Next, press "." to set the expiry action field. If you want Max
to hang up and delete that user's account, press "A". If you
want Max to demote that user to a lower priv level, press "D" and
enter the priv level. If you don't want any action to take
place, press "N".
Finally, press "<" to set the expiry date/time. If you selected
DATE for the "expire by" field, you can enter the expiry date of
the user here. Otherwise, if you selected MINUTES, you can enter
the number of on-line minutes to give the specified user.
After setting up the expiry controls for a user, the subscription
system is completely self-maintaining. If a user expires, that
user's account will be modified accordingly whenever that user
logs on again.
In addition, when a user expires due to the current date, the
file \MAX\MISC\XPDATE.BBS will be shown. When a user expires due
to running out of minutes, the file \MAX\MISC\XPTIME.BBS will be
shown.
Maximus-CBCS v2.00 Operations Manual - Page 122
MULTILINGUAL SUPPORT
Maximus 2.00 includes full-fledged multilingual support. Up to
eight different languages can be defined in MAX.CTL, and users
can switch to any of these languages at any time. The language
files themselves encompass almost everything that Max displays 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 keystrokes for various 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 displayed to the
SYSOP. By default, the SysOp interface always uses the FIRST
language file defined in LANGUAGE.CTL, regardless of the language
currently in use by the user. This means that the user can be
walking through the menus in German, but the SysOp will still be
able to read the pop-up menus in English. Max also comes with a
second language file, AMERICAN.MAD, which was modified to handle
certain American spellings.
Max's multilingual support can be used to define different
prompts, menus and custom display files for each individual
language. Prompts are all handled by the language file itself,
simply by editing the appropriate <langname>.MAD file. However,
menus must be specially designed by the SysOp, since a separate
set of menus should normally be used for each language.
Likewise, most display files should be changed to accommodate
each new language.
The principal method of supporting alternate menus and display
files is through the "%Y" external program translation character.
The "%Y" character translates to the user's current language
number, with 0 being the FIRST language defined in MAX.CTL, 1
being the second, and so on. "%Y" can be used in many places,
including the "First Menu" option in MAX.CTL, all Display_Menu
options, and also as "+Y" in all Display_File commands. The
careful placement of the "%Y" token can be used to handle most of
Max's multilingual support.
For example, if you had the following language statements in
LANGUAGE.CTL:
Language English
Language Sanskrit
using a "First Menu MAIN%Y" statement in MAX.CTL would cause
"MAIN0" to be displayed for callers who selected the English
Maximus-CBCS v2.00 Operations Manual - Page 123
language, and "MAIN1" would be shown to callers who selected the
Sanskrit language.
This methodology can also be applied to display files; you can
either use a "Display_File D:\Path\File%Y" to display different
physical files, or the "[iflang]" MECCA token can be used within
an individual display file to make decisions based on the current
language.
By default, Max stores a user's language preference in the user
file. However, if you want Max to prompt the user for a new
language each time he/she logs on, you can do this by placing the
token "[menu_cmd chg_language]" at the top of WELCOME.MEC.
Maximus-CBCS v2.00 Operations Manual - Page 124
QWK MAIL PACKER
Through the reader menu, Max allows users to download mail for
off-line reading. Max supports the popular QWK format, so
readers such as Deluxe2, Qmail, SLMR and OFFLINE can all be used
to read the downloaded mail packets.
Configuration
The QWK mail packer is largely self-maintaining, since it uses
most of the Max configuration files to a full extent. However,
you do have to edit READER.CTL at least once to configure it for
your system.
The first keyword to change is the "Packet Name" option. You
should set this to a name describing your BBS, eight characters
or less, with no spaces. Maximus will use this as the base
filename when sending QWK mail packets.
You should also configure your phone number properly, and also
make sure that you have all of the archivers defined in
COMPRESS.CFG.
For more information on configuring the QWK mail packer, please
see the section in the installation entitled "Configuring the QWK
Mail Packer".
Bulletins, News Files and File Lists
In addition to mail, the QWK format also supports bulletins, news
files and new file lists. Max supports these files in an
extremely simple manner; anything which exists in the \MAX\OLR
directory will be packed up with each mail packet.
The QWK format defines several standard files which will be
displayed to the user. To use these features, simply place a
file with the specified name(s) in the \MAX\OLR directory.
HELLO Displayed when the reader first starts up. This
is typically the equivalent of your WELCOME.BBS
screen. This should be ANSI only; no AVATAR or
MECCA codes allowed.
NEWS Your BBS news file. This is usually available as
an option from the QWK reader's main menu. This
is normally a flat ASCII with no graphics.
Maximus-CBCS v2.00 Operations Manual - Page 125
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 can contain a new files listing for your
BBS. Max won't generate this for you, but it's
easy to have your file list generator create a
copy of a new files list in the off-line reader
directory.
Again, all of these files are optional. However, since Max packs
up everything in the \MAX\OLR directory when creating 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.
Remote Message Packing
The default Max 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 reader menu is a
simple macro which invokes the Browse command.
The default Download command passes the options "t/n/p" to
Browse. This requests a scan of T)agged areas, N)ew messages,
and P)ack in QWK format. Obviously, with the flexibility of the
Browse command, many more operations can be performed. A
selective download can be performed by using the search function
(complete with AND/OR operators), and messages could be packed
from only the current area, as opposed to all areas on the
system. Since the QWK packer is seamlessly integrated with the
rest of the Browse logic, an infinite number of combinations are
possible.
When selecting the Pack option from the Browse menu, Max will
gather all of the specified messages, print out how many it
captured, and find out if the user wants to download them. If
so, Max will compress the packet with the user's default
archiving program, count to ten (giving the user a chance to
abort), and then send the file using the default transfer
protocol.
Maximus-CBCS v2.00 Operations Manual - Page 126
The reader menu also includes an upload option; this allows the
user to upload a .REP file (created by one of the off-line
readers). This .REP file will be decompressed based on the
information given in COMPRESS.CFG, and messages contained within
will be tossed to the appropriate message areas.
Local Mail Packing
In addition to remote use, the QWK routines can also be used in
local mode. After compressing a packet, Max will simply leave
the packed QWK file in the off-line reader directory. (By
default, the file will be in the \MAX\OLR\NODExx\ directory,
where 'xx' is the current task number). Max normally deletes the
QWK file after it's sent, but Max will leave it there for a local
session.
In local mode, if you want to "upload" a .REP packet, select the
Upload option from the reader menu. If the caller is local, Max
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 Max will then decompress and toss that packet.
Unattended Mail Packing ("Vacation Saver")
In conjunction with the "-j" command-line parameter, local mail
packing is an important feature. At predefined intervals, you
can set up your batch files to call Max with the "-j" command
line switch. This switch can be used to 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 "in advance" for certain users,
or use it to save mail for yourself while you are on vacation.
Since the packing process is completely controlled by the
keystrokes you specify for the -j switch, almost any type of mail
download is possible.
For example, if the keystrokes required to get from the main menu
to the reader menu, download a packet and log off were
"n;o;d;y;m;g", the following command-line would automatically
start up Max, pack mail for the specified user, and then log off.
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 use the "|" character where you
would normally press the <enter> key.
Maximus-CBCS v2.00 Operations Manual - Page 127
In addition, you can create multiple lines in your batch file for
multiple users, as long as you remember to copy the packet from
\MAX\OLR\NODExx into a safe place after each mail pack.
NetMail Messages
Since the QWK format was not designed with NetMail messages in
mind, you must follow a special convention when reading and
replying to NetMail messages in a QWK reader. When you download
messages from your NetMail area, the first line of each message
will look like this:
From: <addr>
where <addr> is the 4D network address of the sender. Since
there's no place in the QWK header to store the origination
address, Max places this information in the message body instead.
If you wish to create or reply to a NetMail message, Max expects
to see a "To: <addr>" line as the FIRST line in the message body.
For example, to send a NetMail message to 1:123/456, the first
line of your message should look like this:
To: 1:123/456
Note that the "To:" text will be stripped before the message is
written to the Max message base, so your QWK messages will look
like normal messages to everyone else.
When replying to a message, there's an easy way to set the
destination address; simply quote the original message, then
change the "From:" line to a "To:" (after removing any quoting
marks). This ensures that the destination address is correct,
and Max will make sure that you reply is sent to its intended
destination.
Maximus-CBCS v2.00 Operations Manual - Page 128
MISCELLANEOUS INFORMATION
This chapter is for miscellaneous information which didn't fit
anywhere else in this documentation.
Filename Specifications
Wherever you specify a filename, make sure to specify a FULL
path, including drive specifier and leading backslash. For speed
reasons, Maximus changes the current directory as it executes.
This mean that you can never assume anything about the current
directory. SILT will try to compensate for this, but cannot do
so in all circumstances.
Hard-Coded Filenames
Maximus uses several hard-coded filenames, whose names are not
changeable:
<areaname>.DSC: For Squish areas only. This file will be
displayed to a user when entering an area, only if that
user's lastread pointer is set to zero. This is useful for
giving a brief description of a message area, including the
topics allowed and other appropriate information. For *.MSG
areas, see DESCRIPT.BBS.
<areaname>.SQR: For Squish areas only. This file can be
placed in the subdirectory containing the messages for that
area. <areaname> is the same as the name for the Squish
message database (defined by Matrix, Local, Echomail, or
Conference keyword in MSGAREA.CTL). It will be displayed to
callers each time they enter a message area. For *.MSG
areas, see RULES.BBS.
<areaname>.SQX: For Squish areas only. This file will be
displayed to a user who attempts to enter a message in a
read-only area.
ACTIVExx.BBS: This file is created by Maximus whenever a
user logs onto a given node. 'xx' is the hexadecimal task
number of the node in question. This file will be deleted
when the user logs off.
ATTRIB.BBS: This is the file displayed to users who press a
"?" at the attribute prompt in the full-screen message entry
header. This file explains the various attributes
Maximus-CBCS v2.00 Operations Manual - Page 129
available, such as private, crash, hold, and so on. This
file is located in the \MAX\MISC directory.
BADUSER.BBS: If a file named BADUSER.BBS resides in the
main Maximus directory, Maximus can use it as a screen when
a new user logs on, to keep out users with unwanted names.
This file is a simple ASCII text file, containing a list of
names not to be allowed on the BBS, one to a line. Each
name listed in the file will be matched to either the first,
last, or the entire name of the user. If Maximus finds a
match, then it will try to display a file called
BAD_USER.BBS in your miscellaneous directory, and then hang
up. This file should be located in the \MAX directory.
BLT-1.1 - BLT-1.99: Bulletins to be displayed to the users
of the QWK packer. Please see the section entitled "QWK
Mail Packer" for more information. This file should be
located in the \MAX\OLR directory.
BROWSE.BBS: The help file for the Browse command. This
file should be located in the \MAX\MISC directory.
CHATHELP.BBS: This is the help file which will be displayed
inside the multi-node chat. It is located in the Maximus
MISC\ directory.
CHATPAGE.BBS: This file is displayed to the user when a
chat request is received from another node. Maximus will
display the "You are being paged ..." message first,
followed by this file. For example, this file could be used
to display information on how to access the Answer Page
command. CHATPAGE.BBS should be located in the Misc
directory.
CHG_SENT.BBS: This is the help file displayed when a user
tries to edit a message which has already been sent, packed,
or scanned as EchoMail. CHG_SENT.BBS should be located in
the Misc directory.
CHG_NO.BBS: This is the help file displayed when a user
tries to edit a message which was written by someone else.
It is located in the \MAX\MISC directory.
DESCRIPT.BBS: If this file exists in a *.MSG directory, the
contents will be displayed to users who enter this area, and
whose lastread pointer is set to zero. For Squish areas,
see the comments for <areaname>.DSC. To display a file to
all users who enter an area (regardless of lastread pointer
settings), see also RULES.BBS
Maximus-CBCS v2.00 Operations Manual - Page 130
EVENTSxx.BBS: The ASCII event control file used by Max's
event controller, where 'xx' is the current node number.
See the section in the installation entitled "Events and
Yelling" for more information, and also see the "EVENT FILE
CONFIGURATION" section in the Maximus Technical Reference
Manual. These files should be located in the Max root
directory.
EVENTSxx.DAT: The compiled version of the Maximus event
file, where 'xx' is the current node number. The ASCII
event file, EVENTSxx.BBS, is compiled by MAX.EXE at runtime.
These files should be located in the Max root directory.
EXCBYTES.BBS: This file will be displayed to a user who
attempts to download too many kilobytes in one session.
(Maximus will display this after printing "That would exceed
your daily download limit.") This file should be located in
the \MAX\MISC directory.
EXCRATIO.BBS: This file will be displayed to a user who
attempted to download a file that would exceed his/her file
download ratio. (Maximus will display this file after
printing "That would exceed your download ratio.") This
file should be located in the \MAX\MISC directory.
EXCTIME.BBS: This file will be displayed to a user who
attempted to download a file that would exceed his/her time
limit. (Maximus will display this file after printing "That
would exceed your time limit.") This file should be located
in the \MAX\MISC directory.
FILES.BBS: This is the name of the ASCII file listing in
each file directory. For more information on creating a
FILES.BBS, please see the section in the installation
entitled "Maintaining File Areas".
FILES.DAT: This is the name of the compiled file name
listing in each file directory. The FB utility creates
FILES.DAT and several other files from the master FILES.BBS.
FILES.DMP: This is the name of the compiled file
description listing in each file directory. The FB utility
creates FILES.DMP and several other files from the master
FILES.BBS.
FILES.IDX: This is the name of the compiled file index in
each file directory. The FB utility creates FILES.IDX and
several other files from the master FILES.BBS.
Maximus-CBCS v2.00 Operations Manual - Page 131
FILE_BAD.BBS: This file is displayed when an uploaded file
fails the upload virus check. Please see the MAX.CTL
reference for more information on the "Upload Check Virus"
keyword. This file should be located in the \MAX\MISC
directory.
FILE_OK.BBS: This file is displayed when an uploaded file
passes the upload virus check. Please see the MAX.CTL
reference for more information on the "Upload Virus Check"
keyword. This file should be located in the \MAX\MISC
directory.
GOODBYE: This is the name of the file displayed (by the
off-line reader) to a QWK user who closes your system's mail
packet. This file should be located in the \MAX\OLR
directory.
HELLO: This is the name of the file displayed (by the off-
line reader) to a QWK user who opens your system's mail
packet. This file should be located in the \MAX\OLR
directory.
LASTUSxx.BBS: This file is created by Maximus as a record
of the last caller on the system. In addition, this file is
used by Maximus-specific door programs to obtain information
about the user who is currently on-line. This file simply
contains a copy of that user's user record, with the "time
remaining" and "baud rate" fields filled out appropriately.
MAXFILES.IDX: This is the system-wide file index, as
created by FB. This file is used for performing global
downloading and upload dupe checking.
MTAG.BBS: This is a binary file used by Maximus to store
message area T)agging information for each individual
caller. This file is located in the \MAX directory.
NAMES.MAX: Max has a feature similar to FrontDoor's
NAMES.FD. If you place a file called NAMES.MAX in your
system directory, you can use it as an "alias" file for
entering NetMail messages. NAMES.MAX has the following
format, one alias definition to a line:
<alias>,<name>,<address> [,<subject>]
You can have any number of aliases listed in NAMES.MAX. If
Max spots a message addressed to "alias" (which can be done
by entering the name directly at the prompt, when doing
carbon copies, etc.), the message will be automatically
Maximus-CBCS v2.00 Operations Manual - Page 132
readdressed to "name". <subject> is optional; it can be
used to enter a default subject for the message. Example:
jdh,Jesse David Hollington,1:225/1
adf,Andrew Farmer,1:163/115
sjd,Scott Dudley,1:249/106
afx,Areafix,1:106/116,gronk
jimbo,Jim Jones,1:106/114.5
Entering the initials in the left column instructs Max to
readdress the message to the appropriate person, using the
specified address.
If a "*" is placed at the beginning of an alias definition,
that definition can only be used by callers with a priv of
SysOp. This may be useful for protecting Areafix and Raid
passwords. The NAMES.MAX file should be located in the \MAX
directory.
NEWFILES.DAT: This file is displayed to a QWK user (by the
off-line mail reader) when that user requests a new file
listing from your BBS. Please see the section entitled "QWK
Mail Packer" for more information. This file should be
located in the \MAX\OLR directory.
NEWS: This is displayed to a QWK user (by the off-line mail
reader) when that user requests a news file display from
your BBS. Please see the section of the documentation
entitled "QWK Mail Packer" for more information. This file
should be located in the \MAX\OLR directory.
NOTIN.BBS: When a user yells and the sysop does not respond,
Maximus will look for this file in the Maximus MISC\
directory. If it exists, then this file will be displayed.
If it does not exist, Maximus will display the standard
`Sorry, there's no answer'. (Compare to YELL.BBS.)
RAWDIR.BBS: If a file of this name exists in a file area
directory, it will be displayed to the user when s/he
attempts a R)aw directory command. It will be displayed
AFTER the command is selected from the menu, but BEFORE the
`Enter mask:' prompt.
READONLY.BBS: If this file exists in a read-only message
area, and a user tries to enter a message, then this file
will be displayed, as opposed to the built-in, "canned"
message which Maximus normally displays.
Maximus-CBCS v2.00 Operations Manual - Page 133
RESTARxx.BBS: This file is created by Maximus (where 'xx'
is the current node number) when performing an [xtern_erlvl]
exit. This file is used to store state information about
the current caller, and it was designed to put Maximus back
exactly where it was before the xtern_erlvl was performed.
This file is deleted by Max after restarting with the -r
switch. Also, this file can be used to change some
information which is normally not modifiable by external
programs, such as the "time user logged on system" field,
the current menu, and more. This file is located in the
\MAX directory.
RULES.BBS: When placed in a *.MSG directory, Max will
display this file to all callers who access this area. For
Squish areas, see <areaname>.SQR. To display a file to
callers only once, see DISPLAY.BBS and <areaname>.DSC.
TAG_FILE.BBS: This is the help file for the file area Tag
command. This file is located in the \MAX\MISC directory.
TAG_MSG.BBS: This is the help file for the message area Tag
command. This file is located in the \MAX\MISC directory.
TIMEUP.BBS: This file is displayed to callers when their
time limits expire. This message will be displayed after
Max prints "TIME LIMIT." This file is located in the
\MAX\MISC directory.
TUNES.BBS: This is the file referred to by the 'Uses Tunes'
command in MAX.CTL. This filename is not hardcoded, but
several utilities look for it in the \MAX directory.
WHY_ANSI.BBS: This is the help file for the "Want ANSI
[Y,n,?]" question at log-on. This file is located in the
\MAX\MISC directory.
WHY_FB.BBS: This is the help file for the "Goodbye [Y,n,?]"
question at log-off. This explains to callers why they
should leave feedback to the system operator. This file is
located in the \MAX\MISC directory.
WHY_FSED.BBS: This is the help file for the "Want MaxEd
[Y,n,?]" question at log-on. This file is located in the
\MAX\MISC directory.
WHY_HOT.BBS: This is the help file for the "Want Hotkeys
[Y,n,?]" question at log-on. This file is located in the
\MAX\MISC directory.
Maximus-CBCS v2.00 Operations Manual - Page 134
WHY_HU.BBS: This is the help file for the "Goodbye [Y,n,?]"
question at log-off. This file is located in the \MAX\MISC
directory.
WHY_PC.BBS: This is the help file for the "Want IBM Chars
[Y,n,?]" question at log-on. This file is located in the
\MAX\MISC directory.
WHY_PVT.BBS: This is the help file for the "Private [Y,n]?"
question when entering a message in TTY mode. This file is
located in the \MAX\MISC directory.
XPDATE.BBS: This file is displayed when a user's
subscription expires due to the current date. This file
should be in the \MAX\MISC directory.
XPTIME.BBS: This file is displayed when a user's
subscription expires due to that user's number of on-line
minutes. This file should be in the \MAX\MISC directory.
YELL.BBS: When yell is turned off and a user tries to yell
for the sysop, Maximus will look for this file in the
\MAX\MISC directory. If it exists, it will display the file
to the user. If it does not exist, Maximus will display the
standard `Yell is turned off' message.
Maximus-CBCS v2.00 Operations Manual - Page 135
INDEX
.FIZ 43 BULLETIN.BBS 66, 91
.LZH 33 BULLETIN.MEC 91
*.BBS 66, 67, 73, 76, 91, 103 cable 45
*.CTL 66 CALLINFO.BBS 108, 109
*.MEC 67, 91 Canadian 11
*.MNU 98, 107 CB chat 40, 117
*.PRM 98, 103 CD-ROM 1, 7, 74
\MAX 13, 14, 27, 52, 59, 66, chain 101, 103, 108, 109
67, 89, 94, 104, CHAIN.TXT 108, 109
108-111, 113, 116, chat 16, 17, 40, 113,
122, 125-128, 115-117, 130
130-135 COM2 47, 106
\MAX\HLP 27 command line 14, 53, 54, 57,
\MAX\MISC 13, 14, 52, 66, 67, 59, 86, 89, 92,
94, 108, 109, 110, 93-95, 113, 120,
113, 116, 122, 130, 127
131, 132, 134, 135 COMMAND.COM 39, 100, 101
80386 48 comment 15, 60, 71-73, 77,
9600 bps 47 109, 120
ACCEM 79, 80 CONFIG.SYS 46-49
ANSI 13, 14, 26, 27, 36, 48, ConfMail 10, 96
52, 66, 81-83, 94, control file 16, 24, 27, 50,
105, 108, 112, 118, 51, 54, 55, 62, 64,
125, 126, 134 70, 73, 77, 93, 98,
ANSI.SYS 48 120, 131
ANSI2BBS 81, 82 Copyright 1, 43, 52
ANSI2MEC 81, 82 custom menu 119
APPLIC.BBS 13, 66, 67 custom welcome 14
APPLIC.MEC 52, 67 CVTUSR 43, 52, 83, 84
ARC 10, 33 DCD 44, 45
Area 0 71 DESQview 10, 48, 114
AREA.DAT 74, 75, 86, 87, 92, DIP switches 44
95, 97, 118 door interface 108, 109
AREAS.BBS 70 DOOR.SYS 108, 109
AUTOEXEC.BAT 46-49, 94, 114 DORINFO.MEC 108, 109
AVATAR 14, 26, 27, 36, 81, DOS 2, 9, 10, 12, 39, 46, 48,
82, 94, 105, 112, 49, 55, 56-58, 72,
118, 125 87, 88, 93, 100,
BAD_USER.BBS 130 101, 102, 104, 110,
BADUSER.BBS 130 114, 115
barricade 19 DoubleDOS 10, 48
BiModem 32 DSZ 32
BinkleyTerm 9, 10, 54, 60, ECHOTOSS.LOG 59, 96, 97
101, 120 EDITCALL 85
BNU 12, 46, 47, 46 editor 14, 15, 21-24, 26-28,
BORED 27, 28, 36 36, 39, 48, 50-52,
BUFFERS= 48 65, 67, 72, 73, 77,
Maximus-CBCS v2.00 Operations Manual - Page 136
79, 82, 89, 97, 129
119, 122 lock 65
errorlevel 55-59, 62, 63, 97, locked baud rate 54
101-104, 121 LOGO.BBS 13
ERRORLVL.BAT 101, 102, 104 LZH 10, 33, 43, 73, 74
Event 120 mailchecker 23, 95
extended ASCII 37, 93 mailer 44, 54, 58, 59, 104,
extended barricades 19 114
external program 100-103, matrix 26, 52, 69, 95-97, 129
105, 108-110, 112, MAX.CTL 13, 15, 21, 49-51,
120, 123 53, 55, 66, 71, 74,
FEND 10 90, 102, 106, 110,
FidoNet 5, 10, 18, 25, 46, 113, 115, 120, 123,
53, 54, 68, 114 132, 134
FILEAREA.CTL Address 18, 20, 21, 26,
Download 23, 32, 33, 37, 53, 128, 132, 133
41, 70-74, 77, 86, Alias System 13, 35, 84
87, 125-128, 131 FidoUser 21
FileAccess 70 File Date Automatic 73
FileInfo 70 Name 2, 13, 17, 19, 21,
FileList 87 22, 24-26, 33-35,
Upload 24, 33, 41, 50, 38, 41, 51, 52, 55,
70, 71, 74, 86, 87, 56, 59, 60, 64, 66,
90, 106, 127, 132 67, 77, 79, 81, 84,
FILES.BBS 72-74, 86, 106, 131 86, 87, 89, 91, 92,
FILES= 48 93, 95, 96, 98,
FOSSIL 12, 46, 47, 54, 114 101, 103, 105, 106,
FrontDoor 10, 54, 60, 120, 108-110, 112, 116,
132 117, 121, 125,
FSR 38 129-133
goto 56-60, 104 No Share.Exe 115
guest account 14 Output 46, 79, 81, 91,
Hayes 10, 12, 44, 53, 120 93, 118
idiot-proof 51 Path IPC 115, 116
Inquire 23 Upload Check Dupe 74
installation 6, 43, 46, 47, Uses Leaving 110
50, 52, 78, 111, Video IBM 48, 82, 120
113, 114, 121, 125, MAX.PRM 90, 93, 98, 103, 113
131 MaxEd 27, 28, 36, 52, 134
Joe SysOp 13, 116 Maximus Help Node 6
label 56-61, 79, 104 MECCA 66, 67, 79, 81, 82, 91,
LANGUAGE.CTL 37 100, 104, 105,
lastread 23, 83, 92, 129, 130 108-110, 112, 118,
LASTUSER.BBS 108 124, 125
LICENSE 11 MECCA token 105, 108, 118,
Local 16, 18, 25, 27, 39, 45, 124
46, 53, 62, 67, 69, [cls] 118
81, 93, 95-97, 105, [delete] 108
106, 109, 121, 127, [file] 118, 119
Maximus-CBCS v2.00 Operations Manual - Page 137
[message] 118, 119 129, 130
[msg_cname] 118 End 68
[open] 108 MsgAccess 69
[post] 108 MsgInfo 69
[quit] 109, 119 MsgName 70, 96
[write] 108, 109 Private Only 19, 69
[xtern_erlvl] 103, 134 Public and Private 69
[xtern_run] 112 Public Only 19, 69
Menus 15, 17, 23, 25, 34-36, Read-Only 19, 69, 70,
38, 50, 51, 64, 66, 129, 133
76, 81, 98, 106, MUFFIN 6
110, 112, 115, 118, multi-line 113, 117
123 multi-node chat 16, 17, 40,
MENUS.CTL 38, 50, 51, 64, 76, 115, 116, 130
98, 106, 110, 112, NetBIOS 113
115, 118 NetMail 6, 16, 18, 20, 21,
Display_Menu 115, 123 25, 26, 28, 30, 33,
HeaderFile 119 52, 55, 58-60, 69,
MenuFile 76, 115, 118, 88, 97, 128, 132
119 NEWUSER2.MEC 67
MenuHeader 115, 118 nodelist 18, 21
Press_Enter 118 non-volatile RAM 44
ReRead 112 NOTIN.BBS 133
Statistics 16, 33, 96, Novell 49
118 OECC 10
Version 1-3, 6, 7, 9, oMMM 58
11-13, 16, 18, 62, Opus 9, 10, 46, 83, 84, 98,
63, 84, 86, 89, 90, 108
98, 108, 109, 113, OpusComm 10, 12, 46, 47, 46
118, 120, 131 Oracle 67, 81, 93, 94
Xtern_Run 110, 112 OS/2 2, 6, 9, 10, 39, 46, 48,
Minimus 10 60, 72, 87, 88, 115
modem 1, 12, 44-47, 53, 108, packer 41, 58-60, 77, 125,
120, 121 126, 130, 133
MPt 32 PAK 33
MR 78, 92 PCBoard 10, 115
MS-DOS 2, 10, 12, 48 phone number 13, 35, 52, 77,
MSGAREA.CTL 105, 112, 125
Anonymous OK 19 printer 26
Area 6, 15, 18-26, 28, Printing messages 26
30-32, 34, 41, 61, Privilege Level 19, 24, 28,
64, 65, 68-72, 74, 30, 33, 34, 64, 65,
75, 86, 87, 89, 90, 70, 86, 94
92, 95-99, 105, AsstSysop 64, 70, 84, 94
106, 115, 118, Clerk 64, 84
126-130, 132-134 Disgrace 64, 65, 84,
EchoMail 5, 6, 18, 19, 110, 112, 118
55, 58, 59, 68, 69, Extra 58, 64, 77, 84,
70, 78, 88, 95-97, 119
Maximus-CBCS v2.00 Operations Manual - Page 138
Favored 11, 64 security 14, 19, 84, 109, 112
Hidden 16, 38, 64 SHARE.EXE 49, 115, 116
Limited 1, 4, 5, 64, 79, SILT 34, 51, 69, 71, 90, 98,
94 99, 129
Normal 1, 19, 25, 34, Software Distribution
51, 55, 64, 65, 82, System 46, 90
84, 93, 96, 100, source code 2, 3, 66, 89, 90
113, 114, 118, 121, SPAWNBBS.BAT 55
128 support echo
Privil 64, 65, 84 MUFFIN 6
Sysop 3, 13-16, 19, 21, SYSTEM*.BBS 98
24-26, 39, 45, 50, SYSTEM*.DAT 98
52, 59, 62, 64, 65, TBBS 10, 115
70, 71, 84, 105, TheDraw 10, 81, 82
106, 108, 109, 116, trademarks 10
120, 121, 123, 133, translation characters 105,
135 106, 108, 109
Twit 16, 64, 106, 110 TSR 46
Worthy 64, 84 TTY 36, 82, 94, 105, 135
QM 10, 96 TUNES.BBS 62, 134
questionnaire 14 user editor 14, 23, 39, 52,
QuickBBS 10, 83, 108 65, 122
quote 22, 27, 29, 128 user file 13, 14, 16, 43, 52,
QWK 37, 41 83, 84, 122, 124
RAWDIR.BBS 133 USER.BBS 13, 64, 83, 84,
RBBS 10, 108 95-97, 130
READER.CTL USER.DAT 83, 84
Packet Name 77 WARRANTY 1, 2, 4
READONLY.BBS 133 WaZOO 9
real name 19, 35, 106 WELCOME.BBS 14, 37, 125, 37
remote sysop logons 14 WELCOME.MEC 14, 124
RENUM 92 WildCat! 108
REP 37, 41 WWIV 108, 109
RESTAR*.BBS 103 X00 10, 12, 46, 47, 46
restarting 53, 101, 103, 134 Xmodem 10, 32
result codes 44, 121 Xmodem-1K 32
reward 50 Yell command 16
run 2, 4, 7, 12, 17, 24, 25, YELL.BBS 133, 135
34, 39, 43, 46, 48, ZIP 10, 33, 72
51-56, 58, 63, 74, Zmodem 10, 32, 33
77, 78, 81, 84, 87,
88, 90, 95, 97, 98,
100, 101, 108, 110,
112-114, 121
SCANBLD 56, 58, 61, 95-97
scanner 58, 59
screen writes 48
SDSMAX 90
SEAlink 10, 32, 33
Maximus-CBCS v2.00 Operations Manual - Page 139