GT POWER - 16.00
Copyright (c) 1985, 1990: by P & M Software Co.
All rights are reserved.



Host Mode Documentation


December 10, 1990




P & M Software Company
3104 E. Camelback Rd. #503
Phoenix, AZ 85016
U. S. A.



Voice Phone: (602) 285-9914
Modem Phone: (602) 285-1146























- 1 -


Table of Contents
-----------------------------------------
A Brief Summary . . . . . . . . . . . . . . . . . . . . . . . 4
The Installation Of Host Mode . . . . . . . . . . . . . . . . 4
The Modem Init String . . . . . . . . . . . . . . . . . . 4
The Host Mode: Modem Init String . . . . . . . . . . . . 4
The Modem Answer String . . . . . . . . . . . . . . . . . 5
The Modem Result Codes . . . . . . . . . . . . . . . . . 5
Logging Status During Host Mode . . . . . . . . . . . . . 5
Hang-up During Host Mode . . . . . . . . . . . . . . . . 6
The BBS/CBS Path . . . . . . . . . . . . . . . . . . . . 6
The Default Message Base Path . . . . . . . . . . . . . . 7
The Default File Section . . . . . . . . . . . . . . . . 7
File Reception Directory . . . . . . . . . . . . . . . . 7
The Sysop Message Base . . . . . . . . . . . . . . . . . 7
Security Considerations . . . . . . . . . . . . . . . . . . . 7
DSZ.EXE, PCKERMIT.EXE and Other Externals . . . . . . . . 9
Host Mode Text Files . . . . . . . . . . . . . . . . . . . . 12
Forcing a "More?" Prompt . . . . . . . . . . . . . . . . 12
Disable the "More?" Prompt . . . . . . . . . . . . . . . 12
Nest the Display of Bulletins . . . . . . . . . . . . . . 12
Disable the ^K/^C Break . . . . . . . . . . . . . . . . . 12
The Variable Substitution Line . . . . . . . . . . . . . 12
ANSI Graphics (.BBS vs .CBS) . . . . . . . . . . . . . . 12
File Descriptions . . . . . . . . . . . . . . . . . . . . . . 13
GTSYSID.BBS . . . . . . . . . . . . . . . . . . . . . . . 13
GTWELCOM.BBS . . . . . . . . . . . . . . . . . . . . . . 13
GTPASSWD.BBS . . . . . . . . . . . . . . . . . . . . . . 13
Field Descriptions . . . . . . . . . . . . . . . . . 14
GTPASSWD Comment Entries . . . . . . . . . . . . . . 17
GTBULLET.BBS . . . . . . . . . . . . . . . . . . . . . . 17
BULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . . 17
GTMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 17
GTHELP.BBS . . . . . . . . . . . . . . . . . . . . . . . 17
GTBYE.BBS . . . . . . . . . . . . . . . . . . . . . . . . 17
GTBYEx.BBS . . . . . . . . . . . . . . . . . . . . . . . 17
GTUSER.BBS . . . . . . . . . . . . . . . . . . . . . . . 17
GTDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . . 18
Comment Lines . . . . . . . . . . . . . . . . . . . . 18
Directory Lines . . . . . . . . . . . . . . . . . . . 18
GTDDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 19
GTBMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 20
GTMDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . 21
GTDOORS.BBS . . . . . . . . . . . . . . . . . . . . . . . 22
GTDOORnn.BAT and GTDORnnn.BAT . . . . . . . . . . . . 23
ANSWERn.BBS . . . . . . . . . . . . . . . . . . . . . . . 23
QUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . 24
PQUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . 25
GTQMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . 25
PROTOCOL.BBS . . . . . . . . . . . . . . . . . . . . . . 25
WELCOME.BBS . . . . . . . . . . . . . . . . . . . . . . . 26
MBULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . 26
SYSOP.BBS . . . . . . . . . . . . . . . . . . . . . . . . 26
SCHEDULE.BBS . . . . . . . . . . . . . . . . . . . . . . 29


- 2 -


TRASHCAN.BBS . . . . . . . . . . . . . . . . . . . . . . 30
FILES.BBS . . . . . . . . . . . . . . . . . . . . . . . . 31
Host Mode Control Files and Directories . . . . . . . . . . . 32
Running Host Mode . . . . . . . . . . . . . . . . . . . . . . 34
SYSOP Commands . . . . . . . . . . . . . . . . . . . . . 34
Command Line Usage . . . . . . . . . . . . . . . . . . . 34
The HOST.BAT File . . . . . . . . . . . . . . . . . . . . 36
The HOST.SCR File . . . . . . . . . . . . . . . . . . . . 36
Using a LAN with GT . . . . . . . . . . . . . . . . . . . 37
The CB Simulator . . . . . . . . . . . . . . . . . . 38
The Host Mode LOG . . . . . . . . . . . . . . . . . . . . . . 41
The Shell to DOS . . . . . . . . . . . . . . . . . . . . . . 41
COMMAND.COM . . . . . . . . . . . . . . . . . . . . . . . 41
DOS 2.xx . . . . . . . . . . . . . . . . . . . . . . . . 41
Using the Shell to DOS . . . . . . . . . . . . . . . . . . . 42
The Usage of Color . . . . . . . . . . . . . . . . . . . . . 43
The Logon Doors . . . . . . . . . . . . . . . . . . . . . . . 43
The Logoff Doors . . . . . . . . . . . . . . . . . . . . . . 44
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Extended ASCII Codes . . . . . . . . . . . . . . . . . . 45
Sample ANSI Sequences . . . . . . . . . . . . . . . . . . 45
Power-Loss Protected Operation . . . . . . . . . . . . . 46
Sample Files For Power-Loss Protected Operation . . . . . 47
GT POWER under DESQview . . . . . . . . . . . . . . . . . 48

(tm) DESQview is the trademark of QuarterDeck Office Systems.






























- 3 -


Brief Summary
-------------
The host mode provided within GT POWER allows you to run an unattended
session with your system. That is, if you expect to receive calls
from other computer systems (say from clients or a set of authorized
remote users) then you can tell GT POWER that it should automatically
answer the telephone for you, verify the caller's credentials, and if
found to be valid, to provide that user with a menu of functions that
can be performed. All of that, of course, without further
intervention on your part.

Security is of paramount importance when running in host mode for
obvious reasons. Please read the section entitled 'Security
Considerations' before attempting to operate this system.


Installation of Host Mode
-------------------------
The most important thing about host mode is proper installation of the
modem control strings and result codes. These strings and codes must
not just control the modem, they MUST WORK TOGETHER. For example, if
the modem init strings specify "verbose" result codes, then the result
code table better have the "verbose" codes in it, not the "terse"
codes. There are 11 specific areas that *must* be installed; all of
these options and strings are accessible via the ALT-I command. Let's
discuss each of these items in turn:

1. The "Modem Init String". The default value is:

AT V1 Q0 E0 X1 S0=0 S2=43|

Assuming that one wants to use the default string, there is
really only one thing that one SHOULD DO to this string: change
the Xn command. The most powerful Xn command available on your
modem is the one to choose. With a USRobotics Courier 2400
modem, use either X5 or X6. With a normal Hayes-compatible 1200
baud modem, use X1. X4 would be normal for most Hayes-compatible
2400 baud modems. For other modems consult the modem manual.

NOTE:
Many so called "Hayes-compatibles" are compatible in name
only. We get many calls for support from individuals with
non-Hayes modems. Please read your modem manual carefully
because it is very hard to support all the different modems.

2. The "Host Mode: Modem Init String". This string is found under
item #30 of the configuration screen. The default value is:

AT V1 Q0 E0 M0 X1 S0=1 S2=255|

There are several things one could do to this string. First, one
must modify the X1 command to match the value added to the Modem
Init String above. Secondly, if one desires the speaker to be
heard during host mode, remove the M0 from the string. Thirdly,


- 4 -


the S0=1 may be changed to S0=0, THIS IS THE ONLY OTHER VALID
VALUE! If S0=0 is used, the modem will not answer automatically,
GT will count the rings and command the modem to answer after the
2nd ring (or if the /Rn command line switch is used, after the
Nth ring). This is why S0=1 and S0=0 are the only permissible
values! Refer to the main GT.DOC file for a complete
discussion of the available command line switches.

3. The "Modem Answer String". This string is located with the Host
Modem Init String under item #30 of the configuration screen.
The default value is:

ATA|

GT will issue this string to the modem whenever the ring count
reaches 2 (or the number indicated by the /Rn switch). This
string should not be changed, unless GT should not be allowed to
answer the modem. For example, one could erase this string and
set S0=5, so that the modem would answer on the 5th ring, but I
don't advise anyone do this.

4. The "Result Codes". Because the modem init strings above contain
V1, "verbose" result codes should be programmed. They can be
found under item #29 of the configuration screen. There are 16
possible results. If the modem does not support all of these,
simply leave the extra strings in their default state. The
program comes with the default result codes set for use with a
USRobotics Courier HST modem. Please consult the manual for the
modem in use and modify this table to match. Remember, use the
"verbose" (word codes), not the "terse" codes. It IS POSSIBLE to
use the "terse" codes, but they are not as compatible with such
services as PC Pursuit.

If one of the newer high speed modems is in use, such as a v.42
type, it is most likely that the modem has more CONNECT type
result codes than GT has space in its table. To get around this
problem, and avoid the necessity of continually expanding the
result code table, GT will automatically recognize CONNECT
messages that match the standard form. For example:

CONNECT 9600/REL

This code is not one of the default codes in the table, but GT
will recognize it, since it matches the standard form:

(1) The word CONNECT, followed by
(2) The DCE baud rate, followed by
(3) The error correction indicator.

GT will automatically recognize this and take the proper action.
To enable this smart result code handling, the modem *must* be
setup to return "verbose" codes.

5. It is highly recommended that logging be TRUE during host mode.


- 5 -


Otherwise, all records of the host mode activities will be
discarded.

6. How to allow GT to hang-up during host mode. Since the "escape
code" must be disabled during host mode, otherwise some caller
may crash your system, the normal hang-up string, "~+++~ATH",
will not work! Therefore, GT cannot hang-up the modem, unless
you set the modem to normal DTR operation. During host mode, GT
will drop the DTR signal whenever he wants the modem to hang-up.
Most modems come from the factory set so that they ignore the DTR
signal - you must reset a switch or, in the case of the Hayes
2400 modem, you must make an entry in the Modem init string to do
this. In any case, if the modem ignores DTR, it will not hang up
during host mode operations. Some modems which must be setup via
the init strings to handle DTR properly use either &D2 or &D3,
please consult the manual for the modem in use to determine the
correct setting.

7. How does GT determine when a connection is lost? The GT host
monitors the carrier detect signal from the modem, when this
signal goes low, then GT assumes that the connection has been
lost. Most modems come from the manufacturer with the carrier
detect signal forced high. "This is like having a telephone with
no ringer." Quote by Tom Jennings. Obviously, this must be
changed. Some modems have a switch that must be reset to enable
a true carrier detect, others require setup via the init string.
Many of the modems that require init string setup use &C1, please
consult the manual for the modem in use to determine the correct
setting.

8. If this path is set, GT will search that path for BBS/CBS files.
GT will also search the GTPATH directory for the files. The
GTPATH directory is search first, then the BBS/CBS path. This
feature will be of great interest to LAN users, who are advised
to become familiar with the DOS "subst" command, which will allow
GTMDIR.BBS and GTDIR.BBS to be the same across a LAN. Here is a
sample of the "subst" command:

subst e: c:\

If this command were invoked in the AUTOEXEC.BAT file on your LAN
server, then all references to drive E: on the server would be
translated to drive C. This would be extremely helpful if the
LAN workstations mapped the server's drive C to E also. This
would mean that both workstation and server could reference the
same physical drive with the same drive letter, i.e. E.

It is possible to also use the BBS/CBS path for the door batch
files, but it would be wise for LAN operators to make these files
Read-Only, otherwise they can cause a SHARE violation, as DOS
does not open them in a shared read mode. The following DOS
command can be used to make batch files Read-Only:

attrib +r *.bat


- 6 -



Assuming, of course, that the batch files to be altered are in
the current default directory.

9. Another option available under the Alt-I, #26, the pathname setup
section, is the "Default Message Base PATH". This option is to
be used to indicate to GT where the main or default message base
is located. This is the message base that the user will be
initially given access to upon calling the system. This should
be an open message base since all callers to the system that pass
the logon procedure will have access to this area.

10. Another option available under the Alt-I, #26, the pathname setup
section, it the "Default File Section". This option indicates to
GT where the main or default file section is located. This is
the file section that callers will see initially when they access
your system. This should be an area with the lowest security
access level, as everyone will be able to use it.

11. To designate the directory where the host mode receives files,
you should specify the DOWNLOAD directory path. This option is
specified under Alt-I, #26, the pathname setup section. The user
may be confused by the terminology here, so let me stress that
the DOWNLOAD directory is where GT POWER *receives* files,
whether in host or terminal modes. Further, the UPLOAD directory
path only pertains to Terminal Mode, as the host mode file areas
are otherwise controlled via entries in the GTDIR.BBS file,
described below.

12. To specify the directory where the host mode will save messages
to the sysop. These messages are entered with the 'M' command
from the main menu. This option is specified under Alt-I, #26,
the pathname setup section.


PLEASE NOTE:
The pathnames mentioned above are all found on the pathname setup
section, #26 of the Alt-I menu.


Security Considerations
-----------------------
Many of GT POWER's design considerations were directed towards
providing absolute system integrity while in host mode. This section
is designed to highlight some of those considerations with the
intention of making the System operator of a host mode fully aware of
both his protection and his responsibilities in that regard.

The fundamental truth about security is that essentially it is YOUR
responsibility. GT POWER's first line of defense in your behalf is
its password function. Without a preassigned password, a remote
caller cannot gain access to the functions provided by GT POWER!
Thus, it stands to reason that your first responsibility is to assign
those passwords and TO GUARD THEM. Because there are several sets of


- 7 -


facilities that you will wish to control and to allow various users to
be provided selectively, GT provides several 'levels' of authorization
that may be assigned to each password. In this way, all users who log
on with the same password will have identical (and only those that are
assigned) access to GT facilities. For example, GT POWER provides to
users who have a sufficiently high 'level' of authorization, the
ability to shell into DOS and, thus, have the ability to execute ANY
DOS COMMAND from their remote location! Obviously, you would not
casually distribute that password amongst your user community. Most
users should NEVER be allowed to Shell to your DOS! (While in DOS a
user could, for example, format your hard disk - that would, of
course, result in the end of subsequent functionality of the entire
system). To these users you would assign a lower 'level' of
authority. To do so you would simply change their access level to the
new level with the Sysop Tools program.

One of the nicest features of the host mode provided by GT POWER are
its message bases. With this feature the users of the system may
leave 'mail' for other users and receive mail for themselves. Indeed,
there are two kinds of mail: Public and Private. Public mail may be
read by any user of the system. Private mail, on the other hand, may
be read only by the person sending it or by the recipient. Here,
then, is another area of security that you need to be aware of and
control. For example, say that you allow your system to be called by
clients of your firm and that they are encouraged to leave messages to
you in your absence. It is possible that several of your clients are
competitors of each other. Thus, it would be improper to allow them
to read messages sent by others. This is the reason for Private mail.
At this point, I would like to point out that there is no such thing
as 'Private' from the Sysop! That is, the System operator may read
any message, whether addressed to him or not and whether they are
marked Private or not. Finally, lest the earlier remarks did not sink
in, any user who has access to the DOS via the Shell command (because
of his assigned extremely high 'level' of authorization) can easily
read any messages while he is in the DOS Shell!

As far as sending PRIVATE messages to the System operator is
concerned, any user may do that! There is an 'M' command on the Main
Menu that results in messages that only the Sysop may view. These
messages are automatically addressed to the Sysop and marked as
private. They are placed in the message base specified for sysop
messages, they may be read only by someone with the Sysop
authorization level. This message base needs to be accessed at least
once by the sysop during setup, to insure that a message is entered to
create all control files. Otherwise, the system will not be able to
process 'M' messages to the sysop.

The hierarchy of access 'levels' based on password enables the Sysop
to control which directories on the disk those users have access to
for purposes of downloading files. However, each caller to the system
will be granted access to the "Default file section", which is a
config option. So please be sure that this file section contains the
least sensitive material on your system.



- 8 -


For ease of use, it is recommended that the user construct a batch
file to invoke GT POWER, especially host mode users. It should look
like this:

C: To specify a default drive of C
set GTPATH=C:\GT Remember to set GTPATH!
:loop
GT1600 host.scr To invoke GT POWER
if errorlevel 255 goto loop To trap the quit 255, and
restart the host mode.

If the above batch file were called GT.BAT and placed in your system's
PATH then you could safely invoke GT by simply typing: GT. It is
important to note, that one of the most frequent errors reported to
the GT support staff is the incorrect setting of GTPATH.

As you will see when you read the next section (about the GTDIR.BBS
file), you can allow your users to have access to all directories that
have a matching authorization level OR LOWER. Further, you can
specify that particular directories are only available to specific
authorization levels.

Where is all this authorization level information kept within the GT
POWER system? In a file called GTPASSWD.BBS. That file is the key to
the security of your system. One of the subtle security features of
GT POWER is that it will not allow that file, even if it is contained
in a directory that the user has been authorized to Download from, to
be transmitted over the telephone!

NOTE: That the external protocols can transfer prohibited files and
for this reason, extreme care should be taken when using either
DSZ.EXE or PCKERMIT.EXE.

Similarly, because the Log file that is optionally maintained by GT
contains the user names and passwords of those who have logged onto
the system, it may not be transmitted over the telephone either.

When running in host mode the screen on the host system shows all
keystrokes entered by the remote user (except while he is in the DOS
Shell or using a DOOR, should that be allowed). In other words, if
the remote user, for example, entered a Private message to another
user, or to the Sysop, the text is showing on the host screen as it is
typed. If the user were to log off immediately after entering the
message then it would be possible that the text of the message
remained on the screen. GT POWER erases the screen after the caller
hangs up to prevent such a lapse in security. If you are running a
host mode system in an environment where others might be able to
observe the screen then it is recommended that you turn your monitor
off while you are not in attendance.

If others may be in the area as you are communicating (chatting) with
users and you wish to control the information on the screen you would
do well to remember that the Alt-W keystroke will erase your screen
instantly.


- 9 -



A user-name may be BANned from accessing the system. Note, however,
that doing so merely encourages an undesirable to log on with another
user name. With the advent of personalized passwords, this provision
has become more effective, since one could setup the system password
to have a low access level, which would be raised only after
validation.

Computer time is a resource that you can also control in host mode.
Each password may have a designated time limit beyond which the caller
will be automatically logged off. The number of calls per day made to
your system by an individual caller is also subject to control.

One of the more subtle security measures needed in a host mode
ennvironment is called a 'Watchdog'. In the GT POWER system, this
function is provided by a program called DOORMAN. DOORMAN is a TSR
program that should be loaded in your AUTOEXEC.BAT file, it has no
command line options, and is loaded simply by its name, DOORMAN.
Should an authorized user be in the DOS Shell or out in a DOOR, and if
for any reason he were to drop his carrier (hang-up), the system would
then be vulnerable to the next caller as that caller could find the
system "in" DOS and he would then have uncontrolled access to do as he
pleased to your system. In the situation mentioned, loss of carrier,
DOORMAN will force your system to reboot and if you setup the
AUTOEXEC.BAT file properly, when the system completes rebooting it
will invoke GT and put it back in host mode! The same thing would
happen if a power failure occurs during host mode operation. When
power is restored the system will automatically return to the host
mode of GT POWER. Note, however, that for those systems that do not
have a built in clock, the time and date of the system would no longer
be correct.

As a Sysop of a GT system you must be aware that there are some legal
considerations that you may face. For example, should you allow users
to place copyrighted programs onto your system and to then allow other
users to download those same programs, then you are participating in
an illegal activity! Naturally there is no way to prevent a user from
sending you copyrighted material, provided he has upload capability.
There are many things that you can do, however, to stop others from
having access to that material. For example, GT POWER allows you to
cause all files that are uploaded to your system to be placed into a
special receiving directory, rather than into the directory the user
is currently using. It makes good sense to make a receiving directory
PRIVATE, in the sense that it is NOT listed as available in the
GTDIR.BBS to your remote users. In this way, you may review the files
received at your convenience and move them over to the public
directories if you are satisfied that they are either public domain or
Shareware programs and files.

Another reason that you will want to do the above is that there are a
few people out in the world that like to send what are called Trojan
Horse programs to BBS's. A Trojan Horse is a program that causes some
form of damage when it is run. It would not be at all fair to your
users to expose them to such programs. So, when it is safe for you to


- 10 -


do so, run the programs you receive before making it publicly
available (using BOMBSQAD or a
similar program to prevent a problem for you). When you are satisfied
that the programs received are safe then you can move them to public
areas.

NOTE: Running programs uploaded to a BBS is extremely dangerous. And
can result is the crash of your system, i.e. someone may break-
in, because you have run what seems to be a harmless upload.
Please be carefull!!

And in the event that a user does send you a Trojan Horse or
copyrighted code, it is in your best interest to know who did so. GT
POWER provides an optional log file function. If that is enabled,
which is highly recommended, then the log contains the name of the
person who logged on and sent you the file. GT also puts the name of
the uploader with the file description given at the time of upload.

This section of the document is substantially larger than you may have
expected it to be. The reason should now be obvious.

YOU are the person responsible for security. It is necessary that you
know the previous information and take appropriate actions.

































- 11 -


Host Mode Text Files
--------------------
The following text files must be created and/or maintained with an
editor that can produce plain ASCII files. Any of the display type
BBS files may have a DC2, Ctrl-R, character inserted into column 1 of
line 1 to disable the "More?" prompt during display of the file, and a
DC4, Ctrl-T, character inserted into column 1 of line 1 to disable the
Ctrl-K and/or Ctrl-C user break, or a ENQ, Ctrl-E, character inserted
into column 1 of any line to force a "More?" pause at that line. A
NAK, Ctrl-U, can be inserted in column 1 of any line to introduce a
variable substitution line. The ACK, Ctrl-F, can be used in column 1
of a bulletin file to nest the display of other text files.

+--------------------------------------------------------------------+
| |
| Ctrl-E ... ENQ ... Insert a "More?" at current location. |
| Ctrl-F ... ACK ... Nest the display of bulletin files. |
| Ctrl-R ... DC2 ... Disable "More?" during file display. |
| Ctrl-T ... DC4 ... Disable ^K/^C break during file display. |
| Ctrl-U ... NAK ... Introduce variable substitution line. |
| |
+--------------------------------------------------------------------+

Please note that once the Ctrl-E command has been used the automatic
insertion of "More?" prompts are terminated for the duration of the
current display.

Using the Ctrl-R to disable the "More?" prompt is useful when the file
contains such graphic or annimation techniques that would be spoiled
by such interruption. Except for the GT?DIR.BBS files, every .BBS
file can have two versions: (a) a color graphics version or (b) a
plain text version. This is coordinated with the ANSI graphics
question asked of callers before they logon the system. The .BBS
extension is the default used if only one version of the file can be
found by GT, the .CBS extension is used to indicate to GT that a
graphics version is available. If both versions are available, the
.CBS version will be shown to callers who elect graphics, if graphics
are not elected by the caller, the .BBS version will be displayed.

The variable substitution line is interpreted by GT, and certain
substitutions can be made. The following are supported:

A ... The DTE baud rate.
B ... The DCE baud rate.
C ... The caller's number (i.e. the 100th caller).
D ... The current calendar date.
F ... The caller's first name.
G ... The caller's screen length setting.
H ... The caller's home - city and state.
L ... Time left for current session in minutes.
M ... The current message base description.
N ... The caller's full name.
R ... The caller's upload amount in kilobytes.
RF .. The caller's upload amount in number of files.


- 12 -


S ... The current file section description.
T ... The current time of day.
Wn .. Set width of the parameter that follows to 'n' columns.
X ... The caller's download amount in kilobytes.
XF .. The caller's download amount in number of files.
n ... 'n' number of blank columns.

In addition to these items, plain text may also appear on the variable
substitution line, it must be quoted however, like this:

"plain text between quotation marks"

For example:

^U" Name: "N
^U" First: "F
^U" Home: "H
^U"Time remaining: "L
^U" Current time: "T
^U" Blank Columns: "30"30 of them."
^U" Fixed width: "W30N"30 characters in width"

The nesting of bulletin files with the Ctrl-F character is extremely
useful, but also hazzardous, if the nesting is done to a great level.
For best results, the nesting should be kept to a single level. An
example of usage is:

^FC:\GT\FOO.BAR

Please note that there is no space between the Ctrl-F and the filename
and that the full pathname must be given for the file.

File Descriptions
-----------------
GTSYSID.BBS This file is displayed as soon as the GT host detects
a connection has been established with an incoming
call. After displaying this file, GT will ask the
user if the terminal program he is using supports ANSI
graphics.

GTWELCOM.BBS This file is displayed to a caller just before he is
asked for his name by the GT host. It should identify
the system to callers.

GTPASSWD.BBS This file contains the list of passwords that people
must know to access the system. The entries in this
file are composed of one line per password, and each
line contains the following information, beginning in
column 1:

Lvlx ([xx:xx(,n,hh:mm,path)]) Pwd Auth (1st-Name Last-Name Phone-Number)

These items can have a variable number of blanks
between them, but the "Lvl" must begin in column 1.


- 13 -


EACH PASSWORD, "Pwd", MUST BE UNIQUE and from 1-20
characters in length.

The () which have been shown around the call time
limit, the daily call limit, the daily time limit, the
name, and phone number fields, indicate that these
items are optional and need not be included in the
file.

Field descriptions:
-------------------
Lvlx ... The Access Level assigned to this entry. May
be any character from the following sets: 0-
9, A-Z, or a-z. NOTE: "0" is the highest
level and "z" is the lowest. The 'x'
following 'Lvl' is the bullet number that
this caller will be shown. Valid bullet
numbers are 0-9, A-Z. Read additional
instructions bellow under BULLETx.BBS.

xx:xx .. The Call Time Limit. This field is optional
and is enclosed within [...]. If omitted, it
defaults to approximately 24 hours.

n ...... The Daily Call Limit. This field is a sub-
field within the [...] of the Call Time Limit
field. It cannot be specified without the
Call Time Limit being specified also.
Example: [1:30,2] would grant two calls per
day of 1:30 duration each.

hh:mm .. The Daily Time Limit. This field is a sub-
field within the [...] of the Call Time Limit
field. It cannot be specified without the
Call Time Limit and the Daily Call Limit
being specified also. Example: [1:00,5,2:00]
would grant five calls per day, each of up to
1 hour each, but a maximum of 2 hours per day
total usage.

path ... The upload pathname. This specifies where
files uploaded by a particular class of user
are to be stored.

pwd .... The Password. As said above, the password
may be from 1-20 characters in length and
must be unique. If this line is a class
entry the "pwd" field should contain the word
CLASS in capital letters.

auth ... The Authorizations given to this entry. They
come from the following list:

UP : Upload authorized.


- 14 -


DN : Download authorized.
PR : Private mail authorized.
KL : Allow the killing of messages, the same
as the Sysop.
SY : Sysop priveledges authorized.
CH : Manual directory change is authorized
(in absence of the GTDIR.BBS file).
CB : CB Simulator authorized.
SH : Shell to DOS is authorized.
DR : Use of DOORS is authorized.
MS : Allows message reading.
FA : Allows file attach when using the
netmail programs.
FR : Allows file request when using the
netmail programs.
NL : Disable the L)ist directory command at
the main menu.
NE : Disable the E)nter message command.
NP : Disable the sysop P)age command.

These authorizations are listed seperated by
commas, following the "pwd" field. See
examples below. The CH authorization is a
"do nothing" authorization in most cases,
because most systems use a GTDIR.BBS file.
On these systems the CH option may be used as
a way to grant no authorization, because a
total lack of authorization yields the
default authorization set: DN,UP,PR,MS.

1st-Name Last-Name Phone-Number
These three fields are present when it is
desired to allow the caller "callback"
priveledges. In effect, if the caller's name
matches the name listed here and he gives the
correct password, the system will offer to
call him at the listed number. This allows
the host to assume the cost of the phone
charges for the session. The caller must be
prepared to accept the call, that is his
modem must be in "auto-answer" mode. Send
"ATS0=1|" to most Hayes type modems to set
auto-answer mode. The "|" represents a
"carriage return". If the conditions are met
GT will return the call within 15 seconds,
and will retry 3 times before giving-up hope
of establishing the connection. NOTE: the
password assigned here for the callback, must
*not* be the same as the caller's personal
password -- the callback password *MUST* be
unique.

NOTE: It is possible to append a single character to the
level indicator. Thus "A1" would be a valid level.


- 15 -


This extra character is used to identify a custom
bulletin file for this caller. This extra character
is optional, but if present MUST BE a character that
is legal within a file name. Read about BULLET files
below.

Examples:
A [2:00,100,5:00,c:\goodies] MASTER SY
B1 [1:00] FRIEND DN,PR
B1 [1:00,4,2:00,c:\up] CLASS DN,UP,PR
C [1:30] JOGGER DN,UP,PR,DR MARY ADAMS 1-213-555-1234
A [2:00,10,4:00] CLASS SY
C2 [2:00,3,3:00] CLASS DN,UP,PR,DR

In version 12.10 of GT POWER, personalized passwords
were introduced. When a caller gets his personal
password it is stored in the USER.CTL file, with the
other user information. The access level assigned to
the password used by the caller on the first call
(before a personal password was assigned) will be the
access level assigned to the caller until changed via
the SYSOP program. To provide a time limit, daily
call limit, and bullet#, a cross reference of the
access level stored in the users record in USER.CTL
file and the GTPASSWD.BBS file is required. This is
accomplished by placing CLASS cards for each access
level your system uses into the GTPASSWD.BBS file.
The format of the CLASS card is the same as a normal
password entry, except the word CLASS must appear in
uppercase letters. In addition, the CLASS entries
cannot be used to provide callbacks, normal password
entries must be provided for that purpose. Here are
some example CLASS entries:

Examples:
A1 [2:00,5,3:00] CLASS DN,UP,PR,DR,SH,MS
B3 [1:30,2,2:00] CLASS DN,PR,MS
K2 [:45,1,:45] CLASS DN,UP,PR,DR,MS

The first CLASS entry establishes a class for callers
with an 'A' access level, grants them 2 hours of
session time, and a daily call limit of 5 calls, 3
hours of time per day, and gives them the
authorizations: Download, Upload, Private mail, use
DOORS, Shell to DOS, and read messages. The other
entries grant lesser time amounts to the 'B' and 'K'
classes. The 'B' class is given Download, Private
mail, and read messages authorizations. The 'K' class
is given Download, Upload, Private mail, use DOORS,
and read messages authorizations. Note: if you
neglect to setup CLASS entries then once your callers
have been assigned their own personal passwords, and
this is automatically done by GT, then they will have
unlimited time access to your system, the default


- 16 -


authorizations, and they will not be given a bullet#.

It is possible to add comment lines to the
GTPASSWD.BBS file. Any line with a ';' in the first
column is a comment entry, and will be ignored by GT.

+----------------------------------------------------------+
| |
| Remember to give callers the MS authorization |
| so they can "read messages". And setup a CLASS |
| entry for each different access level in use. |
| |
+----------------------------------------------------------+

GTBULLET.BBS This file is displayed for the caller after he/she
completes logon. It is useful to leave notes here for
expected callers.

BULLETx.BBS The "x" may be any character that can be a legal part
of a filename. This character must match the
character which is found after the level indicator in
the password file, to enable custom bulletin files to
be displayed for callers. For example: if a caller's
level was "BZ", then the program would search for a
file named BULLETZ.BBS to display whenever the caller
logged onto the program.

NOTE: Custom bulletin files are OPTIONAL. If you do not
wish to use them, simply use single letters for access
level indicators.

GTMENU.BBS This file is displayed for callers as the main menu.
It may be suppressed by a caller by selecting X)pert
mode.

GTHELP.BBS This file is displayed if the caller requests help
from the main menu.

GTBYE.BBS This file is displayed for the caller when he/she logs
off, i.e. selects the G)oodbye command from the main
menu.

GTBYEx.BBS This is a custom bye file. The 'x' may be any
character that can be a legal part of a filename. It
comes from the GTPASSWD.BBS file, as the letter
following the level indicator. Most commonly a
number. See custom BULLETx.BBS files above.

GTUSER.BBS This file is created whenever a call comes into the
system. It will contain the access level and name of
the current caller, or if no call is in progress, the
previous caller to the system. The file contains just
this 1 line of text. The exact format is:



- 17 -


Lvl 1st-Name Last-Name auth baud ANSI-opt last-on limit event time

The line is free format with spaces delimiting fields.
The "Last-Name" field will consist of a single
character, a ';', if the caller has only 1 name. The
';' will act as a placeholder in that case, so that
DOOR programs will have an easier time unpacking this
data on the line. The "auth" field will contain the
authorizations given this caller from the GTPASSWD.BBS
file when he logged onto the system. The "baud" field
will two baud rates seperated by a ':', for example
19200:2400. The first baud rate is the DTE rate, the
second baud rate is the DCE rate. The split rate is
necessary for those using high speed modems. If the
current session is a local sysop logon, then the
"baud" field will contain the word LOCAL, if the sysop
is logged-on. The "ANSI-opt" field will contain
"NOANSI" if the caller doesn't want ANSI graphics, or
"ANSI" if he does want the graphics. The "last-on"
field contains the date the user last called the
system. The "limit" field contains the remaining time
the caller has left for the current call. The "event"
field contains the time remaining until the next event
is scheduled. The "time" field contains the current
time in "xx:xx" format. The time remaining fields are
integer showing time left in minutes.

The purpose of this information is to supply needed
control information to external programs that run
either in the Shell to DOS or DOOR environment.

GTDIR.BBS This file contains a list of directories that may be
accessed by callers. There are two types of lines in
this file: the actual directory lines and comment
lines. The comment lines are displayed to the caller
when he asks to see the list of directories. The list
displayed will contain only those directories the
caller is authorized to access. The formats:

Comment Lines:
Contain a blank in the 1st column, the remainder of
the line is displayed for the caller.

Directory Lines:
Column 1 - access Level. The minimum level required
to access the directory. If this column contains an
"=" then the actual line is shifted to the right 1
column and the "=" acts to reserve the directory for
the indicated access level - which would now be in
column 2. (See example.)

One or more blank columns follows the level, then the
complete DOS name of the directory, including all
drive and PATH information. One or more blank columns


- 18 -


follows the directory name, then a description of the
directory is given. When a caller selects the C)hange
directory command, the list of choices will display
the descriptions you provide here, so try to be
helpful.

Examples:

This is a comment. (Since column 1 is blank)
A C:\DOS\TEST The description goes here.
=B C:\LOTUS\DATA This is for "B" level callers only.
C A:\ The description again goes here.

This example shows three directories, one with an "A"
access level, one with a "C" access level. These are
the minimum levels that callers must have to "see"
these directories. The "=B" directory may be accessed
only by callers with the "B" access level.

GTDDIR.BBS This file controls access to the GT DOOR system. Its
function is much like GTDIR.BBS is for file
directories. It serves as a way to add security to
doors, document them and pass parameters to them.
Each door must have an entry in this file, there are
no comment lines in this file. Each line in this file
follows the this syntax:

Lvl ([comment_here_with_no_spaces]) (Prompt message here:)

The () indicate which fields are optional and need not
be included in the file.

As with the GTDIR.BBS file, the "Lvl" controls the
minimum access level required to open the door. The
[comment] is optional, but must be enclosed within
[...] if it appears and no blanks are allowed within
the comment field. If a parameter must be passed to
the DOOR, then the optional prompt field must be
added. The answer given to this prompt by the caller
will be passed to the DOOR as command line argument
%3.

Examples:
B [this-is-door-1]
Z [this-is-door-2] Enter filename:
S [this-is-door-3]

In the example above, the 2nd door has a prompt listed
that indicates that this door requires a filename be
passed. This could be for example to implement an ZIP
view type door, where the name of the ZIP file to be
processed might need to be supplied. The caller's
response will be passed as command line argument %3 to
the GTDOOR2.BAT file in this case.


- 19 -



If you are using the overlaid doors command line
option, /V:D, it is possible to selectively override
the feature and have some doors that are not overlaid.
This may be done by putting an '&' character as the
first character of the prompt (callers won't see it,
don't worry). If you have no prompt for a door, then
just end the line with the '&'. For example:

E [EDLIN_Door_#1] &Enter Filename:
E [EDLIN_Door_#2] &

Either method would serve to insure that this door
does not overlay GT when it is activated.

+----------------------------------------------------------+
| |
| Please note, the order of the lines in this file |
| must be 1st door on 1st line, 2nd door on 2nd line, |
| etc. The lines must be in 1, 2, 3... order. |
| |
+----------------------------------------------------------+

GTBMENU.BBS This file is the bulletin menu file. It should list
the numbered bulletin files. The numbered bulletin
files should be located in the "Default File Section",
and their file names should simply be 1, 2, etc. This
menu file will be displayed as users logon your system
and besides the numeric bulletins, two alpha options
should be listed: L)ist logon bullets and Q)uit
bulletin menu. An example of a GTBMENU.BBS file:

1. Bullet #1 description here.
2. Bullet #2 description here.
.
. etc.
.
L)ist logon bullets
Q)uit bulletin menu.

It is possible that these bulletin files can contain
ANSI graphics. If so, they should be named with a CBS
extension. For example:

1 Bullet #1, no extension, no graphics.
1.CBS Bullet #1, with .CBS extension,
contains graphics.
2 Bullet #2, no extension, no graphics.
2.CBS Bullet #2, with .CBS extension,
contains graphics.

Remember: These bullet files must be placed into the
"Default File Section", as defined under
the Alt-I pathname setup.


- 20 -



Starting with GT 16.00, these bulletin files may be
nested. When nesting bulletins, we will talk about
bulletin numbers with a decimal point embedded within,
i.e. 1.0.0 or 2.1.0. Each successive level of nesting
requires another decimal be added to the bullet
number, to a maximum of 5 levels deep. When equating
the bulletin numbers to file names, the periods are
first eliminated, for example 1.0.0 would equal
filename 100, and 2.1.0 would equal filename 210.
These files would be located in the "Default File
Section", as outlined above. If we consider this
situation for a bit, we see that there must be a sub-
menu structure applied to these bulletins, in order to
get them properly nested. For example, we might have
the following in the top level file, GTBMENU.BBS:

1.0 General Bulletins
2.0 Game Bulletins

The 1.0 would refer to the file 10 in the "Default
File Section" and the 2.0 would refer to the file 20
in the "Default File Section". Each of these files,
10 and 20, would be sub-menus, which then actually
referred to the actual bulletins. For example, file
10 might look like this:

;BMENU

1.1 Rules of the board
1.2 How to get more time
1.3 How to get higher access

The line beginning with ';BMENU' must be the very
first line of file 10, this signals GT that this file
is not actually a bottom level bulletin, but instead
is another bullet menu. Files 11, 12 and 13 are the
actual bulletin files (and therefore, would not
contain the ';BMENU' entry).

Because these bullet menus can be nested up to 5
levels deep, some new letter commands are available
for usage in navigation. As follows:

M Return to main bulletin menu (GTBMENU.BBS).
P Pop back to the previous bullet menu.

GTMDIR.BBS This file controls the multiple message bases that GT
can support. The format of this file is the same as
the format for the GTDIR.BBS file, except that you
have 1 additional option for column 1, you may place a
'*' in column 1 of an line in this file and then that
message area will become a 'by application only'
message base. The caller applies for entrance by


- 21 -


trying to select the message area via the A)rea change
command. GT will inform the caller that application
has been accepted and the Sysop must approve. The
users name will be placed into the GTMAIL.CTL file
associated with the message base, but the BAN bit will
be set, the Sysop must use Sysop Tools to reset the
BAN bit so that the caller can be admitted.

When setting up, the Sysop should insure that all sub-
directories listed in GTMDIR.BBS exist, but GT will
automatically provide all the control files and
message directories, as needed.

All message areas must have an entry in this file.
The main default message area must be open to all
callers and must use the same pathname as the message
base pathname in GT's configuration file. The
GTMDIR.BBS file must be located with the other .BBS
files in GT's home directory.

+--------------------------------------------------------------+
| |
| The PATH name portion of the lines in the GTMDIR.BBS |
| file may be prefixed with either '^', '~', '<' or '$'. |
| |
| ^ ... Designates a message area that can support |
| public messages only. |
| ~ ... Designates a message area that is used as a |
| netmail area (see netmail docs). |
| < ... Designates a message area that is Read-Only. |
| Only the Sysop can enter messages. |
| $ ... Designates a message area that can support |
| private messages only. |
| |
+--------------------------------------------------------------+

Examples:

Z ^C:\GTBBS\OPEN Public Message Base
E C:\GTBBS\GENERAL General Message Base
F C:\GTBBS\SPECIAL Special Message Base
Z ~C:\GTBBS\PUBLIC Public Netmail Area

GTDOORS.BBS This file is displayed for the caller when he selects
the O)pen DOORS option from the main menu. It is a
pure text file, which should contain your DOOR menu.
Each DOOR is assigned a number, 1-999, and should be
listed on this menu by the number needed to select the
door.

It is possible to have sub-menus, which work off of
the GTDOORS.BBS menu. If the GTDOORS.BBS file looked
like this:



- 22 -


Main Door Menu
--------------
A. Game Doors
B. Database Doors
C. Utility Doors

Then if the caller selected 'A', the sub-menu
GTDOOR-A.BBS would shown. Or if 'B' were selected
then GTDOOR-B.BBS would be shown. Then whenever a
numeric entry was made, the caller would be put into
the selected door. A simple carriage return would
take the caller back to the main door menu,
GTDOORS.BBS.

GTDOORnn.BAT These are the DOOR files themselves. These are batch
GTDORnnn.BAT files, much like the Shell to DOS batch file, but
instead of executing another copy of COMMAND.COM, it
executes your DOOR program. The mechanism of the DOOR
is actually the CTTY commands at the start and end of
the file. The CTTY redirects the console to the COM
port at the start of the DOOR file, and back to the
console at the end. Sample DOOR files are included
with the package. Here is a short example:

%1 com%2
edlin %3
%1 con

The %1 will become "ctty" or "rem", and the %2 will
become the port number, through substitution by DOS.
The "REM" substitution is used when the DOOR is being
run locally by the Sysop to check it out. A DOOR that
works in the local mode may not work for a remote
caller, because the DOOR program may not use the DOS
functions to perform I/O with the console.

Remember that the 3rd command line argument is passed
from the GT host to the DOOR containing the response
from the caller to a prompt you have placed into the
GTDDIR.BBS file. In this case, it would have asked
the caller which file he wanted to edit.

Please note the two forms of the door names.
GTDOORnn.BAT is used for door numbers 1 through 99.
For doors numbered from 100 through 999, use
GTDORnnn.BAT. For example:

Door #5 ..... GTDOOR5.BAT
Door #45 .... GTDOOR45.BAT
Door #125 ... GTDOR125.BAT
Door #999 ... GTDOR999.BAT

ANSWERn.BBS This file contains the answers supplied by the callers
to the 'n' questionaire, that you have stored in the


- 23 -


QUESTn.BBS file. The format of this file is as
follows: each answer given by a user is written on a
separate line to this file, the answers are grouped by
placing the users name, from logon, onto the first
line of the group, enclosed within << ... >>,
following this each answer appears on a separate line
and each group is terminated with a line containing a
single period. Here is an example:

<< Paul Meiners >>
9350 Country Creek #30
Houston, TX 77036
713-772-2090
.
<< Susie Meiners >>
1245 Sunnyside Dr.
Houston, TX 77081
713-894-3465
.

The example shown above contains two groups of
answers. As GT accumulates answers it will continue
to append them to the end of this file. If this file
does not exist, GT will create it. The Sysop should
avoid editing this file, because any attempt to do so
may render GT incapable of adding answers to it.

QUESTn.BBS This file contains the questionaire for callers to
fill out. This feature is optional. The file is in
template format, using the [------] construct to
indicate where GT should gather answers to questions.
For example:

[------------]
Enter Phone Number:

Would direct GT to collect the phone number, showing
GT where to collect the answer and the maximum width
answer to accept. Each answer can be up to 80
characters long and there may be up to 50 questions
per questionaire.

After having filled out the questionaire, the caller
will be asked if he wishes his answers to be recorded.
If he indicates in the negative, GT will discard the
answers.

The questionaire is optional, and if the user tries to
fill out a questionaire that cannot be found, GT will
indicate to the caller that there is no questionaire
currently available.

Date/time stamping can be done automatically by
including a special code in the questionnaire file.


- 24 -


For example:

[%DT]

Would cause the current date and time to be recorded
in the answer file (no question would be asked here),
of course the balance of the questionnaire would be
processed in a normal manner.

There can be up to 99 different questionnaires for the
caller to choose from. The GTQMENU.BBS file is
displayed with a list of all available questionnaires.

PQUESTn.BBS This file is displayed for the caller immediately
after he selects the questionaire he/she wishes to
complete from the questionnaire menu. It should
explain to the caller the basic purpose of the
questionaire and allow him to consider if he wishes to
continue to fill out the questionaire. Immediately
after this file is displayed, the caller will receive
a prompt, asking if he wishes to continue and fill out
the questionaire.

The PQUESTn.BBS file is optional.

GTQMENU.BBS This file is listed for the caller when he selects the
Q option from the main menu. It is a menu file that
should contain a list (in text format) for the user to
choose which questionnaire he wishes to complete. For
example:

1. Order form for GT POWER.
2. Order form for Turbo CALC.
3. User poll.

This shows only three options, as many as 99
questionnaires may be supported by the system.

PROTOCOL.BBS This file contains the protocol menu that will be
displayed for the caller if he initiates a file
transfer. It is provided so that the Sysop can
customize this menu to his own taste. It is pure text
format, except for the first line, which contains the
list of protocols the Sysop wishes to activate for his
system. The format of this activation line is as
follows:

;XYZB1TWKMSG

Where the ";" appears in column 1 of the line. Each
letter activates a specific protocol, as follows:

X ... Xmodem
Y ... Ymodem


- 25 -


Z ... Zmodem
B ... Ymodem Batch
1 ... 1k Telink
T ... Telink
W ... WXmodem
K ... Kermit
M ... MegaLink
S ... SEAlink
G ... Ymodem-G

By omitting the activation letter from this line, the
Sysop may disable the corresponding protocol. For
example:

;XYZT

Would activate and allow on the Xmodem, Ymodem, Zmodem
and Telink protocols. The other protocols would not
be allowed.

The PROTOCOL.BBS file is optional, if omitted GT will
display a canned protocol menu.

WELCOME.BBS Each message base may have a welcome screen. It
present, it resides in the directory with the message
CTL files and is displayed for the caller as he enters
the message base. It is in the nature of a conference
welcome screen. The WELCOME.BBS file is optional.

MBULLETx.BBS Each message base may have bulletins associated with
it. These bulletin files will reside in the directory
with the message .CTL files and will be displayed for
the caller after the WELCOME.BBS file has been
displayed. The bulletin numbers are coordinated with
the regular bulletin numbers in the main GT directory,
which come from the bulletin numbers on the entries in
the GTPASSWD.BBS file.

The MBULLETx.BBS files are optional.

SYSOP.BBS The SYSOP.BBS file contains almost all of the prompts
and short menus used by the host mode. They may be
customized to suite the sysop's taste. But there is a
danger in changing the file too greatly, the overall
length of each entry should not be greatly changed,
and each entry is limited to 1 line. In addition,
when new releases are made, it may be difficult to
transfer the custom changes to the new file.

There are some special lines in the SYSOP.BBS file.
The 1st line of the file is the welcome to chat mode,
it should be customized to let the caller know who
they are chatting with. The 3rd line of the file
should have the name of the sysop replace the word


- 26 -


'Sysop'. This will allow GT to personalize message
left to the sysop. On line 158, the minimum length of
passwords required by the host mode is configurable.
The minimum length may be set anywhere from 0 through
9 characters. This is accomplished by changing line
158 in SYSOP.BBS to reflect the desired width. For
example:

"Password is too short[!] Must be [6] - [20] characters."

GT scans this line looking for the very first number.
In this case, GT would find the number 6, and that
would become the minimum length for passwords.

Near the end of the SYSOP.BBS file are more special
lines. First, the and time
increment can be customized. If a caller is online,
the sysop can increment his time limit by a small
amount, use to decrease the available time or
to increase the available time. The amount
of the increment is shown on a line near the end of
the SYSOP.BBS file that begins like this:

"\n\n3 min. increment

The number following the "\n\n" is the amount of the
change. It can be any number from 1 to 9 minutes.

A little farther down in the SYSOP.BBS file is a line
that looks like this:

".ZIP .LZH .ARC"

This line contains the default extensions that are
used to satisfy download requests. Each extension
must be separated from the one before by a single
space, and each extension must begin with a '.'
character. This line can be changed or added to, if
need be, but there should probably be no more than 5
defaults listed, otherwise system performance may
degrade.

Even closer to the end of the SYSOP.BBS file are two
lines that look like this:

"MENU="
"MMENU="

These lines may be modified to add items to the menus
used in the GT host mode. The MENU= line is used to
add items to the main menu and MMENU= is used to add
items to the message menu. Each item that is added
must have a two character invokation sequence. For
example:


- 27 -



"MENU=[ZV]viewzip;Q;Enter filename:"

'ZV' is the command selection character (i.e. what the
caller will need to enter to execute this command).
'viewzip' is the name of the batch file that will be
executed. The 'Q' is the minimum access level
required before a caller can select this menu option,
and the 'Enter filename:' is a prompt for data that
will be passed to the batch file. The prompt for data
may be prefixed with a '&', as with entries in
GTDDIR.BBS, to selectively override the overlay
process (command line option /V:D). For example:

"MENU=[ZV]viewzip;Q;&Enter filename:;[MR]modread;Z;&"

The access level and prompt for data are optional, but
they may not be skipped over. That is, if you have
specified a prompt for data, you must also have an
access level specified.

In the example above, showing [MR] for the batch file
'modread', the '&' is shown without any prompt. In
this case, there would be no prompt for data, and the
command would not overlay GT.

Several commands can be added in the manner shown
above to each of these two lines in SYSOP.BBS, MENU=
and MMENU=, but one must be carefull not to extend the
lines past 255 characters in length.

The interface to the batch files invoked by these
items is similar to the command interface for door
batch file. As follows:

Param Description
----- -----------
1 The CTTY or REM indicator.
2 The COM port number.
3 The prompted for data.

The last param, #3, is optional, of course. And, for
items on the MMENU= list, GT automatically adds the
following four parameters:


4 -Ppathname, where 'pathname' is the path
to the currently active message base.
5 The message number previously read by
the caller.
6 Access control switch block, where a
0=false and 1=true:
a. Netmail message area.
b. Public message area.
c. Private message area.


- 28 -


d. Read-only message area.
7 Netmail credits available to this
caller.

For example:

medit CTTY 1 foobar -PC:\GT\MSGB1 103 0100 200

Where:

medit ......... The name of the batch file from the
MMENU= line in SYSOP.BBS
CTTY .......... The caller is coming in remote
1 ............. on COM port #1.
foobar ........ Data given by caller in response to
the prompt (optional).
-PC:\GT\MSGB1 . The currently active message base.
103 ........... The previous message read by caller.
0100 .......... Access control switch block:
0: Not netmail area.
1: Public messages only.
0: Not for private messages only.
0: Not a read-only message base.
200 ........... This caller has 200 netmail credits.

SCHEDULE.BBS The "scheduler" is code within the GT host mode which
allows the sysop to schedule events. The format of
the SCHEDULE.BBS file is very simple. The file is
composed of lines that begin with a time or range of
times, then the command to be executed at the
specified time. The entries in this file for the
schedule *must* be in strict ascending numeric order.
Notice the entry below for '24:50', in GT's
terminology this is 50 minutes past midnight. To GT
there is no 0 hour. The hour between midnight and 1
a.m. is the 24th hour, and *MUST* be shown at the
bottom of the schedule - remember, strict ascending
numerical sequence.

Examples:

03:00 copy file1 file2
03:30 QUIT 5
04:00-05:00 QUIT 6
06:00 maint
24:50 QUIT 8

Based on the above example, at 3 a.m. the GT host will
copy file1 to file2 (any DOS command can be executed
like this). Then at 3:30 a.m. the GT host will quit
execution and set an ERRORLEVEL of 5, the runstream
that is controlling GT must be prepared to deal with
this ERRORLEVEL, else nothing will be done. Also the
user must insure that the GT host is restarted. At


- 29 -


any time between 4 a.m. and 5 a.m. the GT host will
quit execution and an ERRORLEVEL of 6 -- this one is
meant to illustrate a quit to the netmail function,
which should always be started with a range of times,
so that in case it cannot start exactly on the button
of 4 a.m. the GT host will start it, even if it is
late starting. Again the runstream that is
controlling GT must be prepared to deal with the
indicated ERRORLEVEL, 6 in this case, and must restart
the GT host *after* 5 a.m. Then at 6 a.m. the GT host
will execute the 'maint' batch file. NOTE: when the
GT host starts a command like this, it is done via the
SHELL mechanism, this requires alot of memory and it
is not recommended if you are using multi-tasking
software.

A sysop may also add a special line to the
SCHEDULE.BBS file which will allow control of the
P)age function from the main menu. The OFFICE command
allows the sysop to specify when a P)age will be
acceptable. If a P)age is attempted outside of the
specified time range, then the caller will be notified
about the sysop's OFFICE HOURS.

Here is the format: OFFICE=08:00-21:00

The hours must be given in 24:00 notation, and please
notice that leading zeros, must be supplied. 08:00 is
correct, 8:00 is wrong! No embedded spaces are
allowed in this format. It must be as shown above.

+----------------------------------------------------------+
| |
| NOTE |
| |
| Five minutes prior to a external event, GT POWER |
| will cease accepting calls and wait for the event |
| start time. Callers who call in the vicinity of |
| an event will have their time on the system cutback |
| so that the caller will be off the system before |
| the event is to start. |
| |
| |
+----------------------------------------------------------+

TRASHCAN.BBS This file will test your creativity . All the
dirty words go in here, and then anyone, who uses one
of them in their name, will not be allowed to enter
your system. The words in the TRASHCAN.BBS must be in
_lowercase_, otherwise they won't be recognized. A
special wildcard character can be used in TRASHCAN
words, the '?' character can be used to match *any*
character other than a blank. The blank is treated as
a delimiter between first and last names, and each


- 30 -


name is checked against the trashcan individually.
The check is only performed on new callers to your
system, so it doesn't slow the regular logon. And use
of the trashcan is optional. Just leave it out, if
you don't want to use it. An example TRASHCAN.BBS
file:

d?mn
h?ll
scr?w
f?ck
sh?t

FILES.BBS When you create a directory to contain files, either
for upload or download, you should include within the
directory a file named FILES.BBS. It should contain
the descriptions of the files contained within the
directory. When the caller selects the "F" option
from the main menu, the content of this file will be
displayed.

The FILES.BBS that is located in the appropriate
upload directory will be updated automatically with
information supplied by the uploader as follows:

Position Description
-------- -----------
1-12 Filename
13 Blank
14-21 File size in bytes
22-23 Blank
24-31 File upload date
32-33 Blank
34-41 File creation date
42 Offline indicator: '*' means offline
43 Blank
44-78 Caller who uploaded the file.

Following this header line will come up to 10 lines of
description. Each line of description will begin with
a '|' as the first non-blank character (i.e. not equal
to 0x20). The format of the description may be
changed by the sysop from the default used by GT, the
only rule is that the first non-blank (i.e. not equal
to 0x20) must be the '|', otherwise GT will treat the
line as a header or a comment.

A header is a line that begins with a non-blank
character, i.e. not equal to 0x20 (except for
description lines, detailed above). A comment line is
any other line that begins with a blank (0x20).

NOTE: 0x20 means the character is hex 20. A blank. A
character whose decimal ASCII value is 32.


- 31 -


Host Mode Control Files and Directories
---------------------------------------
During the operation of the GT host mode, several files and
directories will be created automatically. The Sysop Tools program
must be used to maintain these files, when the need arises. Here is
an overview of the purpose of these files:

MESSAGE.CTL This file contains the header information for all
messages maintained by the GT host. Such information
as sender name, addressee name, date of entry and
whether or not the message has been received, are kept
here.

USER_MSG.CTL This file contains information about the messages
which have been read by each caller who has joined a
message base.

USER_MSG.IDX The index file for the USER_MSG.CTL file. Speeds
access to individual caller records.

USER.CTL This file contains information about the callers to
your GT host. Such as their name, where they are
calling from and their personal passwords and access
level.

USER.IDX The index file for the USER.CTL file. Speeds access
to individual caller records.

FILES.CTL This file contains information about all the files on
the system that are available for download. It is
built by the FILES_DB.EXE program (and the FILES_DB
must be run to build a new FILES.CTL whenever you move
files around on the system. The presence of this file
enables the universal download feature and helps to
eliminate duplicate uploads (that is, GT will lookup
filenames in this database prior to allowing an upload
from a caller - if you already have the file, the
upload will not be allowed to continue).

FILES.IDX The index file for the FILES.CTL file. Speeds access
to individual file records. Even on very large BBS
systems, access to the files database is accomplished
in less than a second or two.

GTMSGS This is a sub-directory where the text of the messages
is stored. Each message is stored without header
information, which is stored in the MESSAGE.CTL file.
The messages are stored in files with an extension of
.MES. Each .MES file contains 10 messages within it.
As follows:

00001.MES Contains messages #1 through #10
00002.MES Contains messages #11 through #20
...etc...


- 32 -



The messages are stored in plain ASCII text format.
Each message begins with a 'start of message'
indicator with the following format:

Col 1 = Ctrl-X
2-4 = 'SOM'
5 = '0' through '9', depending of the relative
position of the message within the file.

Within 00001.MES, message #2 would have a header of
^XSOM1, where ^X is the symbol for Ctrl-X. In
00002.MES, messages #12 would have a header of ^XSOM1
--- the same as message #2 in 00001.MES. This scheme
allows for the possibility of a "rapid" renumbering.
That is, the internal numbers in the header lines are
relative, not absolute. Changing the name of the MES
file, i.e. from 00002.MES to 00001.MES, automatically
would renumber the messages contained within.

Except for the files database (FILES.CTL and .IDX) these files will be
created as necessary by the GT host. The program SYSOP.EXE will
perform needed maintenance of these files: for example renumbering the
messages, deleting obsolete users, providing reports and listings.
HOWEVER, do not run SYSOP.EXE prior to establishing these files.

For batch usage, DELREN.EXE is provided to delete and renumber
messages - the command syntax for DELREN can be obtained by executing
the program with any parameters.



























- 33 -


Running Host Mode
-----------------
Once installed, host mode is fairly self-explanatory, but here is a
quick once over.

Host mode is started by pressing "ALT -". GT will automatically enter
"Half duplex" mode. This is so that anything typed on the host
console will echo so that it can be seen. Then GT will send the host
mode Modem Init String to the modem and wait for a call. While GT is
waiting for a call, there are 4 commands available: [Esc], which will
terminate host mode, carriage return, which allows the Sysop to logon
to GT's host mode from the local console, [Ctrl-L], which turns on the
system printer for logging, and [Ctrl-S] to load a fresh copy of the
schedule from disk. Note that you must have logging enabled in the GT
configuration, via Alt-I, the [Ctrl-L] command merely enables the
printer, so that whatever is logged will also appear on the system
printer. There also is a command line option to turn on the log
printer. If you place "/p" on the GT command line, the printing of
the log will automatically be turned on from the very start of the
program.

Once GT has answered an incoming call, there are several commands
available to the operator, as follows:

+--------------------------------------------------------------------+
| |
| SYSOP COMMANDS |
| |
| Alt-H List available sysop commands. |
| |
| Ctrl-D List current schedule on the screen. |
| Ctrl-L Toggle log printer on/off. |
| Ctrl-N Raise caller's access level while on-line. |
| Ctrl-P Sysop initiated chat mode. |
| Ctrl-R Reset time limit, gives caller more time. |
| Ctrl-S Load new schedule from disk. |
| Ctrl-T Terminate after current caller disconnects. |
| Ctrl-X Abort the caller. |
| Ctrl-Z Terminate chat mode. |
| Alt -_ Decrement the time available to caller. |
| Alt =+ Increment the time available to caller. |
| |
+--------------------------------------------------------------------+


Command Line Usage
------------------
When you start GT, there are several command line switches that are
available to you:


name You may indicate a script file to be executed upon start-up
of GT.



- 34 -


/D You may indicate whether or not you wish to have GT drop the
DTR signal to the modem when GT exits back to DOS.

/C You may indicate whether you are connected via cable to the
host computer.

/F This gives GT a "frontend" type interface. If you run a
"frontend" program like Binkley, you can use this command line option
with GT. The /F takes two sub-params, like this:

/F:nnnnn:m

Where:

nnnnn ...... The DCE baud rate.
m .......... The COM port number.

For example:

/F:2400:1

2400 baud on COM port #1.

When the caller logs off the system (or drops carrier), GT
will execute an exit to DOS with an ERRORLEVEL 254 or 255.
You should insure that the batch file traps these
ERRORLEVELs and returns control to the "frontend" program.
See documentation that comes with the "frontend" program for
further details.

/K You may initiate the capture mode from the very start of the
program.

/M Suppress the "Check for personal mail?" function.

/MN This would allow the "Check for personal mail?" function to
continue, *but* would change the default prompt from [Y/n]
to [y/N].

/P You may enable logging to the system printer.

/S This option will allow the Sysop Page to be heard during
quiet mode. Normally, nothing would be heard during quiet
mode.

/Tn This option will override the normal keyboard timeout value
of 10 minutes. When this timeout occurs, GT will disconnect
the caller. For example:

/T5 Lower the timeout to 5 minutes.
/T45 Raise the timeout to 45 minutes (my favorite).

/1 You may configure the port addresses in use by your serial
port. The actual port number to be configured, 1-4, is


- 35 -


placed after the slash. The new base address of the
indicated port is placed after the slash number with an
intervening blank. The address must be given with a leading
$ sign and be in hex notation, for example $3F1 would be a
valid address. Refer to your hardware documentation for the
correct address to use. GT uses standard addresses if you
do not override with this option.

GT allows you to also configure the IRQ used. To specify
the IRQ, simply follow the port address with a ':n', where
the 'n' is the new IRQ to be used. The IRQ must be in the
range '0' to '7'. Be sure that the IRQ is not being used by
any other device!

/Rn This option applies to the GT host mode. It specifies the
ring number upon which GT will answer incoming calls. For
example /R3 would cause GT to answer on the 3rd ring. NOTE:
that the host mode modem init string must contain S0=0 to
allow this to work properly.

/RBmm:nn This option applies to the GT host mode. It specifies that
GT should answer the modem after a "ring back". To enable
this to work properly, the host mode modem init string must
contain S0=0. Once installed properly this option makes the
GT host mode answer the phone on the 2nd or 3rd ring after a
gap of between 'mm' and 'nn' seconds. If the gap between
rings is less than 'mm' seconds or greater than 'nn'
seconds, GT will not answer the phone. This allows the use
of an answering machine on the same phone line as the
computer. The answering machine should be programmed to
answer on a later ring, the 4th for example. The 'mm:nn' is
optional, and will default to a 9 to 32 second gap.

/V:s This option will cause selected funstions to overlay GT when
they are executed. The 's' parameter represents the list of
functions that are to be overlaid. For example, 's' may
contains the following letters, representing the functions
shown:
E .... External protocols.
D .... Door batch files.
L .... Logon/Logoff batch files.

If GT is overlaid by a function, then when the caller
disconnects, GT will exit to DOS with an 'errorlevel' of
255. So, the HOST.BAT file must be built to trap the 255
'errorlevel':

HOST.BAT File
-------------
GT1600 /V:DL host.scr
IF errorlevel 255 HOST

HOST.SCR File
-------------


- 36 -


host

+------------------------------------------------------------------+
| |
| This listing of command line switches came from the main GT |
| documentation file. Please refer to that document for sample |
| usage of these switches. |
| |
+------------------------------------------------------------------+

Using a LAN with GT
-------------------
Running a multi-node BBS with GT is easy. GT will allow up to 32
nodes on a network to share common message bases and file areas. The
first thing you must do is decide on a structure for your network BBS.
One of the systems must be identified as the 'server' and it will be
referred to as "PID Zero" in the following description (however, you
can easily have multiple servers). The LAN Path must point to a
location on the server where all the caller records are stored, and
where the "PID_FILE.BBS" is maintained. Once you have decided on the
structure of the network, you must install GT on each node --- part of
the installation process for GT on a LAN node is setting the LAN
parameters under the Alt-I configuration. Three pieces of information
must be provided for each node:


PID Number ... Must be a unique number between 0 and 31.

PID Name ..... The name by which this node is known to the network
software.

LAN Path ..... This must be the home directory for GT on the
network server. The LAN Path will contain the
USER.CTL, USER.IDX and PID_FILE.BBS (at the least).
These are created automatically. It is assumed
that these files will be shared among the other
systems on the LAN.


The LAN Path must be specified to get file and message sharing fully
enabled. Without a LAN Path, GT will assume that a non-sharing
environment is established (like a regular single node BBS).

File sharing is implemented using the record locking facilities of DOS
3.1+ SHARE.EXE. It is recommended that you give this program adequate
facilities to do its job. This command line seems to work well, but
more resources may need to be allocated on busy systems:

SHARE /F:7168 /L:70

It should also be noted, that some LANs require your CONFIG.SYS
parameters to be changed. For example FCBS may need to be specified
on LAN servers, for example:



- 37 -


FCBS=24,12

And STACKS are very important under a LAN enviroment. If you are
using DOS 3.2, I would recommend switching to DOS 3.3. With DOS 3.3,
I would recommend:

STACKS=62,512

DOS 3.2 has some bugs that do not make it a good choice for the DOS on
the LAN server. It has also been observed that BUFFERS are critical
on a LAN. Setting BUFFERS above 40 is a sure formula for a crash. I
recommend:


BUFFERS=35

If this response of the server becomes to slow, due to the low setting
of BUFFERS, rather than raising the BUFFERS, I would suggest that you
obtain a LAN compatible disk cache program. Ask your LAN manufacturer
to recommend one to you.

Finally, resist the temptation to overload the directory indicated as
the "LAN Path". For example, do not have the workstations use that
directory for the log files. This would result in chaos. Each
workstation must have its own GTPATH and LOG Path.

Often times it is extremely handy to have a common pathname to reach
directories on the network. For this reason, the DOS SUBST command is
very useful. With it, you can assign a common pathname to shared disk
space on servers. For example:

SUBST e: c:\

Would allow the server to use drive E: to make reference to 'c:\', as
the workstations probably do. Thus E: becomes a common path to drive
C: across the whole network.

The CB Simulator is an online conferencing feature that is intended
for use on multi-node LAN based BBS systems (NetBIOS emulator is
required). The CB Simulator checks for the presence of NetBIOS before
allowing callers to get stuck in the CB mode.

Locally, when the host mode enters the CB Simulator, split screen mode
is automatically invoked. You should advise the caller to manually
invoke split screen mode on their terminals -- otherwise they will not
see what they type (remember, split screen is half-duplex, the host
mode will not echo the caller's keystrokes during CB Simulator
operations).

When using the CB Simulator, please make sure that you have allocated
adequate NCBs. I have setup the following command for my NetBIOS
startup:

lanbios irq=5 address=2 ncbs=35 sessions=15




- 38 -


I am not sure if 35 NCBs are enough, but it seems to work fairly well
on a 3 node LAN. On the server, if it is not dedicated, you should
insure that the server can manage sufficient simultaneous tasks - my
server was set for 2 simultaneous tasks, but I now have it setup for
5. This does consume memory, to be sure, each extra task requires
considerable buffer space, but it is required for the CB Simulator to
work alongside the other network tasks. On my server, I have found it
necessary to overlay *all* external processes, due to the lack of free
memory above GT.

The following files must be created by the sysop, if the CB Simulator,
command 'Z' from the main menu, is going to be used:

CBWELCOM.BBS ...... Welcomes callers to the CB Simulator.
CBHELP.BBS ........ Displayed in response to '@help' by the
caller.
CBPAGE.BBS ........ Displayed to a caller who receives an '@page'
from another caller.
CBGREET.BBS ....... Displayed for the caller after entering his
handle. The file should be short and to
the point, i.e. introduce the automatic
'@who" list and tell the caller how to get
help.

The following commands are available to callers in the CB Simulator:

@help ........ Display the CBHELP.BBS file.
@ignore ...... Ignore further pages from other callers.
@page ........ Invite another caller, by handle, into CB mode.
Ex: @page foxy
Where 'foxy' is the handle of the caller you are
paging. The handle is obtained from the '@who'
list.
@quit ........ Quit from CB Simulator to the main BBS menu.
@tune ........ Tune the CB Simulator to channels 1 through 98.
Ex: @tune 5
@who ......... Find out who else in on the system and which
channel, if any, they are tuned to.
@sys ......... For sysops only. Allows broadcast messages or
messages directed to specific pids.
Ex: @sys 5 Hello Mike!
Ex: @sys The system is going down in 5 minutes!
The first example sends a message to pid 5, where
Mike is logged on. The second example sends a
broadcast message, to all pids, telling them that
the system is about to go down. Please note, that
these pids do not have to be in the CB Simulator to
get the message. These messages will interrupt
most things, except file transfers.

NOTE: A pid corresponds to a "position" or "workstation" on the LAN.

The CB Simulator uses the NetBIOS Datagram feature to pass the
messages between pids on the LAN. The Datagrams are sent to the group


- 39 -


name 'GT_POWER_CB_SIM" (the 16th byte is 0x00). GT registers this
group name whenever the host mode is started under NetBIOS in a LAN
environment. The Datagrams used by GT are of a fixed format, as
follows (for those of you that want to try their hand at NetBIOS
programming):

Byte Offset Description
----------- -----------
0 'S' for special messages, such as '@sys'.
'C' for normal CB Simulator messages.
1-2 The channel number the message is addressed to.
Channels 1-98 are the normal CB channels. Channel
99 is used for broadcast messages.
3-4 The originating pid number. This is used to keep a
pid from processing messages that he originates.
Datagrams are received by *all* LAN stations having
registered the group name 'GT_POWER_CB_SIM'.
5-6 Transaction code:
'00' - Normal message. All 'C' type datagrams.
'01' - Who inquiry. 'S' type datagram.
'02' - Who reply. " " "
'03' - Page inquiry. " " "
The transaction codes '01' and '02' are now
obsolete, since the @who command uses the PID_FILE
to get its information. Transaction code numbers
up to '50' are reserved for future expansion. It
is anticipated that '04' will be used for remote
submission of DOS commands, and '05' will be used
to remotely shutdown all pids.
7 Unused. Reserved.
8 ','. Constant.
9-16 The sender's handle. If no handle, then the first
name of the sender.
17 ','. Constant.
18-127 Text. In a page transaction, this is the handle of
the caller being paged. In other transactions,
this may be blank or contain a regular message. It
is variable length, only the amount of data
required is transmitted, up to the maximum of 128
bytes.
















- 40 -


Host Mode LOG
-------------
A few sections above, I suggested that logging be TRUE, while GT is
running in Host Mode. Here is why: during Host Mode operations, GT
will log all of the calls received, who called and the password used.
A record will also be kept of who tranfered each file, how long it
took and the efficiency of the transfer. I consider the gathering of
this information to be critical to the operation of a GT Host.

The Shell to DOS
----------------
The DOS Shell allows remote callers to operate your computer remotely.
When the "Shell to DOS" option of the main menu is selected, GT will
shell to the file GTDOOR.BAT. This file will set up for the remote
shell by executing the proper CTTY command, then execute a secondary
DOS shell and let the user into the system. He will have the console,
so be cautious! The caller will be instructed to issue the "EXIT"
command to return to GT.

While the DOS Shell is active and the caller is out in the system, GT
will not be idle. GT will act as a watchdog. If the caller should
hang up while the DOS shell is active, GT will force the system to re-
boot and will drop the DTR signal to the modem. If commands to start
GT are placed in the AUTOEXEC.BAT file and a script is used to start
Host Mode, then GT will automatically recycle. The script command to
start Host Mode is simply HOST.

In order to get the DOS Shell to work, the DOOR.EXE or TDOOR.EXE file
must be available in the GTPATH directory (and the GTPATH directory
should probably be in the DOS PATH statement in the AUTOEXEC.BAT
file). DOOR.EXE is used with the "Rapid" version of GT and TDOOR.EXE
is used with the standard or "XT" version of GT.

NOTE: For this process to work correctly, the COMMAND.COM file must
reside in a directory pointed to by the PATH environment
variable. In order for this to work on a normal drive C: hard
disk, "C:\" should be added to the PATH variable. For example:


PATH=c:\dos;c:\lotus;c:\gt;c:\

This will ensure that the COMMAND.COM file can be located for
execution by the GTDOOR.BAT runstream.

A problem with the DOS Shell has been reported when using DOS
2.xx. This is caused by the fact that DOS 2.xx does not
support full pathnames when requesting the execution of a
program. To work around this problem, if you have DOS 2.xx,
you should place the GTDOOR.BAT file in some other directory
besides the GT home directory. If GT finds GTDOOR.BAT in his
home directory, then GT will issue an EXEC function with full
pathname, otherwise GT will not specify any pathname and will
rely on the DOS PATH command. The directory where GTDOOR.BAT
is stored must be pointed to by the DOS PATH command in this
case.


- 41 -


Using the Shell to DOS
----------------------
What can one do, once one is running DOS remote via a CTTY command?
Well, one can't use any of the Fn keys or the other special keys on
the IBM key-board! One can't run any program that does direct
hardware control of the screen or keyboard. All screen and keyboard
input must be done through DOS. Well, then what can one do? One can
run any DOS command; for example COPY, ERASE, DIR and others,
including EDLIN, all work properly. In fact, any program that uses
the standard DOS handles for input and output to the console will
work. But one still won't have F1 - F10 or the other special keys.
Well, that's not quite so...if the Host Mode computer is setup so that
the ANSI.SYS device driver is loaded via the CONFIG.SYS file. Just
put a line like this one into the CONFIG.SYS file:

DEVICE=ANSI.SYS

Naturally, ANSI.SYS must be located in the root directory of the boot
disk. After that has been done, re-boot the computer. ANSI.SYS will
then be loaded. One can now re-map the keyboard so that the special
keys are mapped to Ctrl keys instead. This will enable programs to be
run that use these keys; for example EDLIN uses the arrow keys as well
as several function keys.

How does one re-map keys with ANSI.SYS? The following sequence must
be issued for each key that needs to be re-mapped:

ESC [ ##;##;##;...p

The (...) indicate that the sequence may be repeated as needed, but
each sequence only re-maps one key. Once a file containing these
mapping commands has been created, they can be sent to ANSI.SYS by
TYPEing the file. The "##" in the sequence above indicate the ASCII
codes for the keys to be mapped. For example, let's map F3 to the
Ctrl-D key. The ASCII codes for F3 are 0,61 and the ASCII code for
Ctrl-D is 4. (Note: the special keys have two codes - the first is
always 0. These codes are really called extended ASCII codes.)
Therefore, the proper ANSI.SYS command to re-map F3 to Ctrl-D would
be:

ESC [ 4;0;61p

Note: Blanks are included for readability only, the "p" must be
lowercase, and the symbol ESC stands for the escape character,
CHR$(27).











- 42 -


Usage of Color
--------------
The GT Host mode now includes color built-in to the various prompts
and menus. These colors can be configured. The colors used are of
two different sets. The first set is composed of the colors for the
"Window foreground and background", and the "Phone directory high lite
foreground and background". These colors should be subdued, since
they are used for normal informational type displays. For important
command line and menu displays, the program will use the colors
designated for "Option high lite" and "Option low lite".

The user can customize the sysop prompt with these colors, by
including the color codes in the SYSOP.BBS file. Here is the code
scheme:

% ...... Used to kill the meaning of the next character.
%% ...... Used to display the % character.
$ ...... Shift the pallette to the "Window foreground /
background" set.
& ...... Shift the pallette to the "Option high/low lite" set
(the default).
[] ...... High lites whatever is between the [ and ].
~ ...... Kills the color. Goes back to standard B&W image.

For example:

$ [SYSOP] John~ here.

This would shift pallette to the "Window foreground/background" set,
high lite the word "SYSOP" and kill the color after the name "John".

Actually, this scheme was only intended to add color to the SYSOP.BBS
file and other built-in menus and prompts, but some have already
discovered that these colors can be added to the GTMDIR.BBS and
GTDIR.BBS files, to add color and emphasis.


Logon DOOR
----------
In the GT POWER home directory, it is possible to create a DOOR file,
with a special name, that will be executed whenever a user logs onto
your system. The file is named 'GTLOGON.BAT' and it is constructed in
the same manner as a normal DOOR batch file (shown above). For
example:

GTLOGON.BAT
-----------
%1 com%2
.
. { Logon door executes here }
%1 con

The sequence of events goes like this after a user calls your system:



- 43 -


1. The GTWELCOM.BBS is displayed.
2. Then any BULLETx.BBS is displayed.
3. Then the GTBMENU.BBS is displayed.
4. Then the GTLOGON.BAT is executed, if available.

It is possible to have a special logon door for new callers. It is
named 'GTNLOGON.BAT'. It will execute just prior to the regular logon
door. If you have logon/logoff doors overlaid, then you must chain
from the new caller logon door to the regular logon door. Remember,
this is only required if you use the command line options /V:L. For
example:

GTNLOGON.BAT
------------
%1 com%2
.
. { New user logon door executes here }
.
%1 con
GTLOGON { Chain to regular logon, if overlaying }


Logoff Batch File
-----------------
It is, also, possible to have a logoff batch file, 'GTLOGOFF.BAT', in
the GT home directory. This is not a DOOR, but simply a batch file
that GT POWER will run, if it is available, whenever a user has
disconnected from your system. It may contain any normal DOS command
or other processing as required, if enough memory is available.

GT remains in memory while this batch file executes in a normal DOS
Shell. It can be useful for sysops that want to backup their files if
they are using a RAM disk for things like the log file.

Please note, this is not a DOOR, that CTTY is not redirected, and that
the 'watchdog' is not enabled during the execution of this batch file.

In addition, when you have a new caller to your system, GT will run,
if available, a batch file called 'GTNLOGOF.BAT'. If you have
requested overlaid logon/logoff doors, then you must chain to the
logoff door (if you have one). Remember, this is only required if you
use the command line option /V:L. For example:

GTNLOGOF.BAT
------------
. { No DOS redirection in logoff doors }
.
. { New user logoff door executes here }
.
GTLOGOFF { Chain to regular logoff, if overlaying }






- 44 -


APPENDIX
--------
Here is a handy list of extended ASCII codes:

Key Codes Key Codes
--- ----- --- -----
F1 0,59 Right Arrow 0,77
F2 0,60 Left Arrow 0,75
F3 0,61 Up Arrow 0,72
F4 0,62 Down Arrow 0,80
F5 0,63 Home 0,71
F6 0,64 End 0,79
F7 0,65 PgUp 0,73
F8 0,66 PgDn 0,81
F9 0,67 Ins 0,82
F10 0,68 Del 0,83



Here are some sample ANSI sequences!

Escape Codes Meaning to ANSI.SYS
------------ -------------------
^[[4;0;61p F3 -> Ctrl-D
^[[5;0;62p F4 -> Ctrl-E
^[[19;0;77p Right Arrow -> Ctrl-S
^[[1;0;75p Left Arrow -> Ctrl-A

With these kinds of mappings, almost any program should be able to
run, if it uses the DOS handles for standard input and output. This
should make the "Shell to DOS" quite useful.

























- 45 -


Setup for Power-Loss Protected Operation
----------------------------------------
It is quite easy to prepare a set of files that will allow you to
bring GT POWER up into what I should like to call a Power-Loss
Protected Host Mode of operation. First, however, a few concepts:

Whenever power is first applied to your system, (or re-applied
following a blackout), the system will boot your DOS into memory and
that, in turn, will look for two files; CONFIG.SYS and AUTOEXEC.BAT.
Finding the CONFIG.SYS, the DOS will tailor your environment according
to its contents (such as setting a new maximum number of files and
file buffers). Finding the AUTOEXEC.BAT file will cause the system to
immediately execute the set of DOS instructions found therein.

GT POWER may be caused to run in an unattended Host mode either
through GT commands entered at the keyboard (Alt-dash) or via script.
The GT command to do so in a GT script is simply: HOST.

The user should have a TSR called DOORMAN loaded if the 'watchdog'
function is required during a remote shell to DOS or a remote door
activation. DOORMAN will reboot the computer in the event that a
caller drops carrier while is the shell or door.

Given the above, to set up the system for Power-Loss_Protected Host
mode operation of GT POWER you must construct the following files:

Your normal AUTOEXEC.BAT
A copy of the normal AUTOEXEC.BAT called AUTOEXEC.OLD
A new file called AUTOEXEC.GT
A new file called HOST.BAT
A GT script file called HOST.SCR

The first four of these files belong in your root directory while the
script file should be placed in the same directory as GT POWER
resides. When you want to enter the Power-Loss-Protected Host mode of
GT POWER you need only type the single word HOST from any directory.
The result will be the invoking of the HOST.BAT file which, in turn,
copies the AUTOEXEC.GT file on top of your normal AUTOEXEC.BAT (so
that if a re-boot occurs it will get control), it then sets a default
directory so that your private directories are not accessible to
callers into the system, and then it invokes GT POWER specifying the
name and location of the HOST.SCR script file you created. Thus, GT
will be given control and placed into Host mode. Upon normal
termination, GT exits to DOS which returns to the unexecuted portion
of the HOST.BAT file and continues by doing a copy of AUTOEXEC.OLD (a
copy of your original AUTOEXEC.BAT) on top of the current one and
ending.

In the event of a power failure while in Host mode, or loss of carrier
while in the DOS Shell, the AUTOEXEC.BAT file that is in place will
reset to the default (safe) drive and reinvoke the Host mode of GT
POWER.




- 46 -


Sample Files for Power-Loss Protected Operation
-----------------------------------------------
Original AUTOEXEC.OLD:

PATH=C:\DOS;C:\;C:\GT
set GTPATH=C:\GT

AUTOEXEC.GT:

PATH=C:\DOS;C:\;C:\GT
set GTPATH=C:\GT
host

HOST.BAT:

copy autoexec.gt autoexec.bat
cd \bullet
gt1600 host.scr
if errorlevel 255 host
cd \
copy autoexec.old autoexec.bat

HOST.SCR:

host































- 47 -


GT POWER under DESQview(tm)
---------------------------
GT POWER runs quite well as a task under the DESQview(tm) multi-
tasking system. There are a few things that should be kept in mind
when doing so, however.

GT will auto-detect DESQview, and if you have told BIOS Video = FALSE,
then GT will write directly to the DESQview screen buffer (greatly
speeding the screen update process). This may adversely affect
DESQview aware programs run in a shell of GT, since they may not
properly tell DESQview which portions of the screen to update. If you
run into this problem, tell GT BIOS Video = TRUE. This will cause
screen updates to be slower, but the shell programs will work better.

GT will automatically give up unused time to DESQview, so that
programs running in other windows are not severely impacted while GT
is idle.

Also, you will need to provide enough memory for GT to run while under
DESQview(tm). If you do not have to consider KERMIT or ZMODEM then
you can run GT in a partition of as small as 360K of RAM.
Experimentation has shown that in order to support ZMODEM and the
other protocols mentioned above you will need to set the partition
size to 460K.

GT, as it requires rapid access to the serial port you are using for
communications must be the first task loaded in DESQview(tm). And, a
performance option of DESQview(tm) (set by invoking the SETUP program)
must be set showing the existence of High Speed Communications. Other
options that need to be set include the fact that GT is NOT SWAPPABLE
to disk and time slices somewhere between 3 and 6 ticks in length per
partition.

Also, it would be best to tell DESQview not to virtualize the screen
output while GT is active. This will help in making screen output as
rapid as possible.

(tm) DESQview is the trademark of QuarterDeck Office Systems.


- THE END -















- 48 -