The N2GTE Packet Message Switch (GTEPMS) v1.2 Documentation.
*****************************************************************
Legal stuff:
GTEPMS v1.2 is copyrighted by Doug Miller, N2GTE.
PC-Node v3.59 is copyrighted by John Miller, G8BPQ.
NET v890421.1 is copyrighted by Phil Karn, KA9Q.
Enhancements to NET is copyrighted by Doug Miller, N2GTE.
DESQview is copyrighted by Quarterdeck Office Systems.

More Legal stuff: The suite of executables and
support files are free to Amatuer Radio operations and is NOT
authorized for commercial or military uses. A list of executables
and support files that comprise the GTEPMS are listed in Appendix A.
The GTEPMS must be copied and distributed to Amatuer Radio operators
free of charge, except for reimbursement of out of pocket expenses.
Plus, all files listed in Appendix A must be included and unaltered.
N2GTE does not accept any liability for any loss; data, hardware,
time or monies, through the use of the GTEPMS.

*****************************************************************
Preface about these docs from the Author:

The N2GTE Packet Message Switch is NOT for everyone, especially
the beginner packeteer. The program and documentation herein and
elsewhere assumes you already have a working understanding of
DESQview, the G8BPQ Node software, TCP/IP, DOS and BBS operations
in general. This documentation is not, nor does it claim to be,
a tutorial on how to be a BBS SysOp using the GTEPMS. What IS
covered in these docs is data needed to setup/operate the GTEPMS
and included are items about other support programs (DESQview,
BPQ and NET) that need either special configuation or have been
modified to enhance the GTEPMS. You should already own docs
for DESQview (they came with the program you bought) (what? you
didn't buy it? Shame on you!!!) I recommend you read them
carefully and keep them handy until you really get the feel for
DESQview. There are extensive docs supplied with G8BPQ's node
software and KA9Q's NET. These are not included in this
documentation, but are supplied on disk for you. I also recommend
you read those docs completely.
I don't think I can over stress the importance of reading and
comprehending all documentation supplied either with the commercial
software you bought or what is supplied in this package. Many people
have spend many hours writing and revising the words in these files
to help make using the GTEPMS easier and fun to operate. You owe
it to yourself and your BBS Users to understand what is contained
here.
There are places in these docs where certain items and procedures
are "recommended". I define that word as meaning, "unless you have
a VERY good reason to do otherwise, do it this way."

*****************************************************************
Preface about the software from the Author:

As can be seen by the hardware requirements, it takes a fairly capable
computer to execute the programs efficiently. The software is
not complicated, but is very complex. Several DESQview windows
are working together to act as one complete system. Rather than
running dupicate copies of the same BBS code in constantly open,
static windows, the GTEPMS opens and closes parts of itself as
needed, freeing system memory and clock time-slices. I have taken
the major functional parts of a BBS system and divided them into
logical groups of tasks, each being performed in its own DESQview
window. This approach to the system has greatly increased its
apparant speed to the User and other BBSs, and made the most
effective use of your computer resources (memory, cpu time, etc).
As you get comfortable with this system, you will get to know
LISTER, RESOLVER and PORTER on a first-name basis. These are the
only three GTEPMS windows which stay open all the time. The
USER, FWD and MODEM windows are only opened when needed and closed
immediately afterwards. (Exception, the NET window stays open
all the time too, and although not specifically part of the GTEPMS,
it is an important player if/when you have the GTEPMS cross between
AX.25 and the TCP/IP worlds.)
There are some files for you to edit and maintain thoughout
the life-cycle of the GTEPMS. I recommend you use an ASCII Text
editor that does not alter the structure of the file, nor insert
special formating characters and spaces.

*****************************************************************

Thanks from the Author:

I wish to express my deepest thanks to the beta-testers who
put up with the gliches, downtime, constant flow of upgrades and
bug fixes. To those who help with the docs, and to those which
said, "Gee, that's neat! But can you make it do this too?"; I
thank you.

WB3V Bill Howard
KA3DXX George Stickler
WA7NTF Gary Kohtala
N3ETI Dick Wolters
KA3RFE Ben "Pete" Hopping
N3GIY Steve Moore
WB3FFV Howard Leadmon
WA3MEJ Jim Sears


Also, thanks to Tom Clark, W3IWI, and Jim DeArras, WA4ONG, for moral
support and suggestions.

*****************************************************************
1. Software Requirements:

Two software packages are required to operate the N2GTE
DESQview-Specific Multitasking Packet Message Switch (GTEPMS)
software package; a third software package is recommended for
those wishing to run TCP/IP concurrently with their N2GTE Packet
Message Switch System.
a. DESQview 2.01 or higher or DESQview 386 (which includes
the QEMM 386 Extended Memory Manager for the 80386 Machines) is
required. This is a commercial software package and must be
bought by the SysOp/Owner of the system. Copywrites on DESQview
and QEMM 386 are held by Quarterdeck Office Systems.
b. The G8BPQ AX.25 Networking Software, version 3.57 (or
v3.59), is free to duly licensed Amateur Radio Operators and is
provided along with the N2GTE Packet Message Switch Software
Package (on the same or separate diskettes). Note: G8BPQ v4.x and
higher will NOT work due to major changes in BPQ interfacing. Thus
the only versions to use are v3.57 and v3.59.

c. (optional) The N2GTE version of NET v890421.1.5N2GTE
TCP/IP and interfaces with G8BPQ's AX.25 Networking Software is
recommended if you plan to run your TCP/IP system concurrently
with the GTEPMS and use the same radios and TNC's. The
TCP/IP files necessary to run N2GTE's modified version of NET
and documentation are provided with N2GTE's Packet Message Switch;
however, for documentation on TCP/IP in general, you should get
one of the later versions of KA9Q's Internet Protocol Software
package with documentation (available from many sources).

Strongly recommend 128K of ramdrive. You may use VDISK
or any other ramdisk utility you wish. If you choose not to use
a ram drive, you still must supply a valid drive letter in the
file \CONFIG.GTE (see later about this file). The PMS uses the
ram drive to spool temporary files during inter-window communications.


*****************************************************************
2. GTEPMS Hardware Requirements:

Minimum Equipment for Full Operations (with full BBS, Node,
and TCP/IP Operations) to run then N2GTE Packet Message Switch
code is as follows:

- An 80286-class IBM-Compatible Machine with at least two
megabytes of EEMS or LIM 4.0) RAM is required; or a 80386 with
two to four megabytes of RAM (4Mb would be best.)

- One or more KISS-Mode TNC-2 TNC's (or an internal HDLC
card with onboard TNC's) that will run with the G8BPQ AX.25 Net-
working Software.

*****************************************************************
3. Set up your directories and files on your hard drive:

The GTEPMS expects to find all its file in the root directory
of its default disk drive. For those which not NOT wish to actually
use a "real" root, you can place all GTE files in a subdirectory and
use the DOS SUBST command to substitute the subdirectory with a drive
letter. See your DOS manuals on how to do this. The author has used
a substituted drive letter T: for his system; so for here on after
the default root drive:\path will be refered to as T:\ (which is actually
C:\GTE). The following example can be placed in your \AUTOEXEC.BAT file:

SUBST T: C:\GTE (or whatever you call the directory)

This will create a T:\ drive for the N2GTE Program files
to operate from. Of course, you may use a "real" root drive.
Note: You may have to place "LASTDRIVE=Z" statement in your
\CONFIG.SYS file to allow DOS to use drive letters that high.

Whichever method you use, you should set up the following
subdirectories on your "root GTEPMS Drive":

\HELP
\LOG
\MSG
\PATHS
\QUEUE
\RSR
\USER

(there is a small batch file packaged along with the system which
can make these directories for you. It is called MAKEDIR.BAT)


If you plan to run the TCP/IP package, you must also create these
directories:
\SPOOL
\SPOOL\MAIL
\SPOOL\MQUEUE
\SPOOL\RQUEUE

(there is a small batch file packaged along with the NET code which
can make these directories for you. It is called MAKEDIR.BAT)

Copy all the main N2GTE Packet Message Switch System and
associated executable and command files to your GTEPMS root
directory (whatever drive designator you give it).

Copy all the G?-PIF.DVP files to your DESQview directory and use
the DESQview "Add Program" menu selection to add them to DESQview's
main menu.
a. Bring up DESQview.
b. Select Open a Window and the Add a Program option.
c. Select Other Programs from the Add a Program Menu and
mark all of the G?-PIF.DVP files to be added to the Open options.
d. Hit return to install them.
The PIF files come made to use substituded drive T:\. If you have
chosen not to use the letter T, you must then edit all the PIF files
for the GTEPMS to state the drive you wish to use. Thus to keep
things simple, and standardize from system to system, the author
recommends you follow his advice and use substituded drive T:\.

Edit the ASCII files according to the detailed information
following:

\CONFIG.GTE File - This file sets several functions and variables
within the GTEPMS environment. sample \CONFIG.GTE file:

BBSCALL=N2GTE
BBSADDR=MD.USA.NOAM
BBSQTH=Ft Meade
BBSZIP=20755
RAMDRIVE=F
TCPIP=YES
BBSALIAS=FMBBS
DVPATH=C:\DV
BPQPATH=C:\BPQ359
QUIET=23-03
ENFORCEQUIET=YES
PASSME=YES
BIDCHECK=YES

note: if you do NOT run the TCP/IP package, mark the TCPIP variable as NO.
With TCPIP=YES, then re-queued mail from NET (in the \spool\rqueue)
will be picked up by FWD.EXE. Mail can also be converted back to SMTP.
With TCPIP=NO, the BBS will ignore anything to do with IP.

Notes: With QUIET hours set, this means that your
GTEPMS BBS will NOT forward bulletins during this time frame (SB
type bulletins will NOT be forwarded during these times; however,
Bulletins sent to SP SYSOP are "personal" mail and WILL be for-
warded). SP and ST type mail will FWD during QUIET hours.
With ENFORCEQUIET set to Y or y your BBS will "enforce"
the quiet hours by disconnecting ANY BBS that "attempts" to
forward a bulletin to you during your established "quiet" hours.
As soon as the GTEPMS station senses the SB command, it will
disconnect the station attempting to forward the bulletin. In
setting the ENFORCEQUIET, you may enter YES or Yes or Y or y; or
NO or No or N or n, but the code only reads the first character,
so it doesn't really matter.
-----------------------------------------------------------------

\FWD. - you will have to edit this file to conform
to your forwarding needs. Here are some notes on the
Forwarding File:

The \FWD. file entries consist of at least two fields. The first is the
ultimate destination (be it callsign, partial callsigns, or H-addr
entries). Separated from the first field by any type of whitespace
(spaces or tabs) is the second field. This consists of the callsign
of the bbs you will send the mail to get it on its way to the final
destination. If you wish to export the mail to a file, simply place
the filename in the second field. (filenames must have full
drive:\path\filename.ext designators because GTEPMS uses the second
character being a ":" to detect it is to go to a file instead of a
bbs. Hopefully the FCC will never issue a callsign with a ":" in it.)
Sample lines from a \FWD. File:

K3AKK N4QQ -- this forwards all mail for K3AKK
to N4QQ; this type of entry may be an
individual user call or a PBBS station
call or may be a TNC MBOX call.

GB7* N4QQ -- this forwards all GB7xxx mail to N4QQ.
HB9* W3IWI -- this forwards all HB9xxx mail to W3IWI.
0* W3IWI -- this type entry sends NTS TFC to a
specified BBS call by ZIP (wildcards
are allowed) (in this case the BBS
station is W3IWI).

NTSCA KD3O -- this type entry sends NTS traffic to a
specified BBS call by STATE ZIP DIGRAPH
(in this case the BBS is KD3O).

.AZ KD3O -- this type entry sends Packet Mail
for stations in Arizona to KD3O for
further forwarding.

.AUS W3IWI -- The GTEPMS code can also key on
these type designators and route the
mail for them to a specific long-haul
forwarding BBS's.

KA3DXX C:\NODE\DXXMAIL.TXT -- this entry exports the mail to a file.

N2GTE (SMTP) -- this entry converts and queues the mail
to be sent SMTP over your TCP/IP links
if you are running the IP package.
If the entry is for your own call, your
mail will be sent directly to you BM
mailbox file.

.CA N4QQ W3IWI WA7NTF -- this entry will queue up anything
for California for those three BBSs.
Whichever BBS successfully gets the
mail first will kill it so the others
will not get it.

note: The \FWD. file is for SP and ST type mail ONLY.
Bulletins are handled completely separate from mail. Also note, the
H-addr routings must begin with a "." to denote they belong to the H-addr
and is not the bbs callsign.

Note: RESOLVER uses a "first hit - bailout" search algorythm.
W3IWI will get 209xx zips, but W3KDC will get all other 20xxx zips in
the example below.
209* W3IWI
20* W3KDC

Another example:
WA4ONG will get the Zips while W3IWI will get the stuff for overseas.
4X* W3IWI
4Z* W3IWI
4* WA4ONG

-----------------------------------------------------------------

\CHORE.xx Files - these files will have to be
edited to suit your forwarding needs. To import files, list
them in the CHORE files so that the FWD window picks them up.
Filenames are recognized by having a ":" in the second character place.
The following are examples of a \CHORE.xx file:

D:\SPREAD.OUT
D:\REQDIR.OUT
D:\REQMUF.OUT
WB3V
KA3DXX
KD3O
KB8AOB
N3DMC

The *.OUT files could be output files created by a server.
You may have as many chore files as you need. The author names his
chores by the minute he FWDs. example: CHORE.10, CHORE.40 and CHORE.55
Each chore file can be different, thus you would FWD to a different
group of BBSs during that particular FWDing cycle.
-----------------------------------------------------------------

\PORTER.CNF - this is the file that sets up the
forwarding times that PORTER will open a FWD window.
The SysOp can also use it to have PORTER open other windows at
certain times during the hour. These other windows could be batch
files to run servers or other things.
The file consists of four fields;
Normally there is only one type; "T" (for Timed function). All other
type are reserved for future enhancements.
The second field is the minute after the hour you wish this window to open.
The third is the filename of the DESQview PIF file which opens the
window. The last field is any parameters you may wish to pass to the
window when it opens. Sample PORTER.CNF File:

T 05 C:\DV\SB-PIF.DVP
T 10 C:\DV\GF-PIF.DVP CHORE.10
T 40 C:\DV\GF-PIF.DVP CHORE.40
T 55 C:\DV\GF-PIF.DVP CHORE.55

Note: In this example the line beginning with T
are "timed" chores for the BBS. T, of course, denotes "Timed
function". The 05, 10, 40, and 55 are the times in minutes past
the hour for the chores to take place. The SB-PIF.DVP file is
for a server. The GF-PIF.DVP (called at :10,:40,:55 minutes past the hour)
are forwarding chores for the FWDing window.

Note: Try to avoid assigning chores for timed functions
at :00, :15, :30, or :45 minutes past the hour, since these
times are the times RESOLVER will task PORTER to beacon
the "unresolved" mail, thus at these exact moments, the BBS
is fairly busy building the mail beacon.

Note: Remember, PORTER has a max limit of 16 timed chores,
so watch how many things you task PORTER to do.
-----------------------------------------------------------------

\DV-MAIL.DAT File - This file is the message database
and should not be tampered. Repeat -- Leave it alone!
-----------------------------------------------------------------

\BIDOK. - this file should be okay as is, but you
may need to add any local area distribution lists that may have
NON-STANDARD BID's. (BID is Bulletin ID [that funny $ thing on the end])
When the BBS receives a bulletin, it checks
its BID against one it formulates itself from the last header
line. Normal BIDs are of msg#_callsign type format. If the BID
that came along with the bulletin fails this check, it is placed
on hold until it either grows stale and expires or the sysop
manually goes in and release/kills it. But many bulletins do not
follow the msg#_callsign format on purpose. Examples are ARRL
and AMSAT buls. These have special BID formats that always begin
with certain letters. The BBS has a feature that if a bulletin
fails the BID check, the BBS checks the BIDOK file before placing
the bul on hold. This BIDOK file consists of the @BBS
designated followed by at least one whitespace (tab or space),
then the beginnings of the odd BID to try to match. If the odd
BID is only 3 characters long, then only the first three
characters of the bulletin BID is checked for a match. If the
odd BID is four characters long, then four characters of the bul
BID is checked, etc, etc.. Stars and questions marks CANNOT
be used as wildcards.
If the first characters of the bul BID
matches the odd BID, then the BBS releases the bulletin normally
(if it is not already stale). The SysOp may edit the BIDOK file
to add new NON-STANDARD BID forms to the file.
The following example is a good start for the BIDOK file:

AMSAT ANS
AMSAT ORB
ARRL ARL
USA RACESBUL
USA RTDX
USA SPC
SKYWRN NWS

Note: The GTEPMS will automatically accept BIDs with the following formats:
msg#_callsign
callsign_msg#
msg#callsign
and the Europe style of BIDs which encodes in the Date.
-----------------------------------------------------------------

\HADDR. - this is a file the GTEPMS will
create from message headers. The HADDR file is updated by the
HEADX.EXE program as it extracts header information from incoming
messages. The file has entries like the following:

KA5EJX.#WTX.TX.USA.NA [Lubbock] Z:79413
WG5F.#WTX.TX.USA.NA [Midland]
AE5I.#WTX.TX.USA.NA
AA5KG.#WTX.TX.USA.NA [San Angelo] Z:76901
WA6RDH.#NOCAL.CA.USA.NA [Dixon] Z:95620

This is one of the files the BBS checks for
Hierarchical information when it resolves a message for forwarding.
Note: you must run HEADX.EXE yourself from a DOS window. I
recommend running it about once every two days, or so, depending
on how many new message your system receives per day. HEADX.EXE
must be ran from the BBS-root directory and perferablly while all
activity is quiet (ie no new messages in the process of coming in).
-----------------------------------------------------------------

\LINKS. - this file will describe the Area names of
the files directories and the paths to them as shown in the
following example

ASCII G:
TCPIP Y:\TCPIP
NETDOCS C:\DOCS
NOSDOCS C:\DOCS\NOS
GTEDOCS C:\DOCS\GTE
SERVERDOCS G:\REQDOCS
HELPFILES T:\HELP
BBS-BY-STATE E:\HADDR

To use the LINKS file, create a file in the "root"
directory of the PMS called \LINKS. Enter the contents in two
columns -- the first column is the alias you want for the direc-
tory AREA; the second column is the drive:\path(s) for the real
directory. Do NOT include a trailing backslash.
What this file does is "link" these drive:\paths into a psuedo
directory for your users to upload and download ascii file to/from.
The user will only be able to use directories that you have linked
into your system. They cannot use sub-directories of the links
unless you have also linked them in with separate link names.
(See the above example in lines NETDOCS, NOSDOCS and GTEDOCS.)
-----------------------------------------------------------------

\MOD. - this file contains the Message of the Day
and you should edit it to suit your needs or desires. You should
keep it kind of short for the most part, but on certain occasions
you might have reason to include a short announcement of
some specific event or suggestion to read a given message.
The SysOp can enter something like "Read Message #12450 for
Important Notice" or something along those lines.
Edits to the \MOD. file take effect immediately and the changes
will be seen the next time a user (or bbs) connects.
-----------------------------------------------------------------

\MOUNT. - you will use this file to enter the BPQ-Node
Station Calls-SSID's to tell PORTER which other GTEPMS stations
it can inter-link with for Remote Service Requests (RSR).
An example of a \MOUNT. file:

N2GTE-6
WA7NTF-7
N3ETI-5
WB3V-2

Remember, this is the callsign of the BPQ node, not the BBS itself.

Remote Service Requests (RSR) is what make GTEPMS systems unique.
If your system cannot resolve a certain piece of mail, it can, thru
the RSR, task other GTEPMS system to assist. You virtually have
access and use of their \FWD., \HADDR., \USER\*. files to help your
system resolve mail. Once you ask (and get an answer) your system
"learns" and can resolve this mail again in the future without help.
Thus, a new GTEPMS can start with a very minimal \FWD. file and
actually learn and grow if there are other GTEPMS within netrom
range.
-----------------------------------------------------------------

\SEQUENCE.SEQ -- this is the file that maintains
your one-up message numbering for your BBS. On bootup the BBS reads
the file, but then never reads it again; only writes to it. The
only purpose of the \SEQUENCE.SEQ file is for message number
recovery during re-start of the BBS. The BBS keeps track of
sequence numbers, but continually updates that file so the data
in the file stays in sync with the count inside the BBS. The
only way to "force" a warp jump to another number would be to
close the BBS (using the shutdown procedures listed in the setup
section); change the number in the \SEQUENCE.SEQ; then start the
BBS back up.
-----------------------------------------------------------------

\SPAWN. - you may create this to suit your needs to
spawn other non-BBS windows upon boot-up. If you want to open
another DESQview window as soon as the BBS System is booted
up, you need to put the xx-PIF.DVP files in the SPAWN file.

CAUTION: DO NOT UNDER ANY CIRCUMSTANCES PUT PORTER (GP-
PIF.DVP) OR RESOLVER (GR-PIF.DVP) IN SPAWN -- THESE TWO
FILES ARE OPENED BY LISTER (GL-PIF.DVP) WHEN IT COMES ON LINE.

Here's an example SPAWN file:

C:\DV\IP-PIF.DVP
C:\DV\BD-PIF.DVP

where IP-PIF.DVP and BD-PIF.DVP are the DESQview
PIF files that will open the windows for N2GTE's version of
NET TCP/IP window and a "Big DOS" Window.
-----------------------------------------------------------------

\SWAP. - This file swaps out the BBS call or alias
and in the process strips off the state/province digraph, coun-
try, and continent codes, as well as the @BBS call for all mail
destined for the BBS. Example SWAP File:

KA3DXX
SEVBBS
WA7SSO W3YA <-- this is handy if someone has changed calls
K1LNJ WB3V.MD.USA <-- or upgraded like Bill did.
NTSMDC NTSMD <-- to correct misconceptions
ARL ARRL <-- to standardize incoming ARRL bulletins.
ARLB ARRL
ARLP ARRL
ARLS ARRL
USABBS USA <-- to standardize incoming USA bulletins.
ALLBBS USA
ALLUS USA
ALLUSA USA
WA7NTF.WA.USA WA7NTF.MD.USA <- he moved.

You may place H-addr info in the second field of the swap.
-----------------------------------------------------------------

\BULLETIN. File:
Each bulletin distribution list must have its
own line within this file (such as, ARRL, AMSAT, BSA, CBBS, EU,
MBLBBS, MDCBBS, REBBS, RLIBBS, SKYWRN, USA, etc.). Each of these
lines would contain the station calls that are to receive the
bulletins. Exporting bulletins to files is supported, enter the full
drive:\path\filename.ext in the file.

Its format is:
example:

MDCBBS WB3V KA3DXX WA7NTF N4QQ WA3ZNW WA3MEJ
AACO WB3V KA3DXX WA7NTF N3ETI KA3RFE
ARRL WB3V KA3DXX WA7NTF N4QQ WA3ZNW
USA WB3V KA3DXX WA7NTF N4QQ
NEWHDR WB3V D:\NEWHDR.TXT KA3DXX
SKYWRN WB3V

Notice (in NEWHDR) how files may be used also.
*****************************************************************

(2) Text Files in the GTEPMS Subdirectories and
Associated Directories:

a. \HELP Directory Files:
The help files are okay, as is, except for one; the \HELP\INFO. file.
You will need to edit it placing your own station information.
Standard help file are included in the GTEPMS package. They are contained
in the file HELPFILE.ZIP which should be unzipped in the \HELP directory.

Notes:
You may add any additional files you wish with one-letter
or one-number filenames as long as you DO NOT USE THOSE
LETTERS ALREADY SET ASIDE FOR BBS USE.
You may omit your additional single-letter or single-
number files from the master \HELP\HELP. file, if you wish, since they
do not have to be listed there for you to access them. This could be
a way to create personal "cheat-sheet" file for your own use as SysOp
and not advertise there existance to the world.
This directory contains or will contain all the help
files. Except for HELP and INFO, each of the single-letter files
contains the help file for that particular BBS command and is
invoked by the ?x command (where x is the single-letter command
for which help is needed). The command "I" will display the \HELP\INFO.
file, which contains Station INFOrmation prepared by the
station's SysOp. The command ? by itself will display the \HELP\HELP.
file, which gives a quick overview of the various commands.
-----------------------------------------------------------------

c. \PATHS Directory Files:
Files in the \PATHS directory are station callsigns (without SSIDs)
and contain the connect commands to get your BBS to the other BBS
stations you forward to. This directory contains the files with the
connect paths to the stations with which the BBS connects to
conduct forwarding. Filenames within the directory are the
station callsigns of receiving stations without any regional
suffixes (.MD.NA.USA, etc.) or SSID's (-4, etc.). The files
contain ONLY the connect commands and the calls necessary to make
the actual connection to the BBS or MAILBOX station getting the
mail. No other information should be included in the PATH files,
unless you want to specify forwarding times.

\PATHS Files - BBS Calls:
(1). Here is an example connect path from KA3DXX to N2GTE,
which share a common frequency and may work direct or via NetRom
compatible nodes: Filename: N2GTE

C FMBBS

(2). Here is an example connect path to W3IWI, which do not share
a common frequency, but which may forward via NetRom compatible nodes.

C DCA6
C DCA1
C W3IWI

(3). Part Time or Limited forwarding:
In GTEPMS, you may now specify a starting and ending time to forward to
a station if you do not want to forward full time. (ie HF FWDing)
To do so, you put the following in the specific callsign file
in the PATHS directory:

#05-17 <-------- Start/end hours. First entry in file.
C DCA1 <-------- The rest of a normal connect script.
C KA3XYZ

(4). Special NOS and NET handling.
Some BBS codes, particularly NOS and NET, require the connectee to
issue a after connection before the BBS will function. If you
need to FWD to such a system, the last line in your \PATHS\*. file
will be (NOS). This tells the FWD window to send a bare carrage
return after successful connection to the station. Here's an example:

C FGGM
C APLIP
C WA3WZA
(NOS)

(5). Special Scripts.
If your path must follow odd routes (such as going thru K-Nodes), you
will probably need to use a special script to control what you send
and what you expect to receive as the response. The use a special
script, the first line in the PATHS files for that particular BBS must
be (SCRIPT) and yes, include the parens and must be all caps. The
second line is the filename of the script to use. Thus a special script
for BBS WA3XXX would have a PATHS file looking like this:

(SCRIPT)
C:\EXTRA\PATHS\WA3XXX.SCR

Now, within the file C:\EXTRA\PATHS\WA3XXX.SCR is the script for the
BBS to follow. Initially the BBS will connect itself to the BPQ switch,
so the special script should start from just after that point. There
are two basic type of script lines, "." and "~". The line beginning
with the PERIOD is what you send; the line beginning with the TILDE is
what you wait for as a response. The file should end after you get
the final response you expect (in this case "Connect to WA3XXX").
The BBS will then start waiting for the other BBSs SID, welcome message
and finally its first ">" prompt.
While waiting for an expected response, there is a timer ticking.
If an unexpected response is RXed, it is ignored and the timer keeps
ticking. At timeout, the BBS will disconnect and continue with the
rest of its chores.

Here is an example script. (Remember you are already connected to the
BPQ switch).

.C DCA
~ to
.C VANODE
~ to
.X RIC220
~###LINK MADE
.C WA3XXX
~ to

Note: Maybe you can not see them, but there ARE spaces in front of and
behind the "to" in the TILDE lines. SPACEs and upper/lowercase _IS_
significant. The response phrase starts from the first chars immediately
after the "~" and continues to the end of the line. All spaces will be
part of the string the BBS will use to match the responses.
-----------------------------------------------------------------

d. \USER Directory Files:
The files in the \USER directory use callsigns
(without SSID's) as filenames; new user files and are created as
a new user connects into the system. The BBS creates the user
file and sets the user level at 0 for guest user; however, when a
BBS connects, it is set as a BBS automagically based on informa-
tion the two BBS's exchange. The SysOp can create a user file or
change the status of a user by editing an existing user file.

example user file \USER\WA3XXX.

3 <- user level
1 <- number of connects
15153 <- message number of last message listed
"Sam>W3IWI" <- user's name & Home BBS
"9010191610" <- user's latest login time

In the above example, the ">" tells the code where
the name stops and where the HOME BBS Call begins. This is
transparaent to all windows. If you ever edit these file, remember
the quotations and puncuation is important.

User levels are as follows:
0 - guest;
1 - user;
2 - expert;
3 - BBS;
4 - SysOp.
-1 - Excluded. <- the author was coersed into adding this feature.


Quirk: When starting the GTEPMS for the first time and when you
open the CONSOLE window, you will notice that you do NOT have
SysOp priviledges. Close the CONSOLE window and open a DOS window.
Change to the \USER directory and you will find there a file
with your callsign. Edit the first line of that file to be a 4.
Save the file. You are now set to be a SysOp of your own system.

-----------------------------------------------------------------

e. Other GTEPMS Directories:

(1). MSG Directory:
This directory contains the mail files.
The mail filenames are the message numbers of the mail messages
and contain the message text within them.
-----------------------------------------------------------------

(2). QUEUE Directory:
The BBS uses this directory to "queue up" messages
for forwarding to other BBS or Mailbox stations.
The filenames contained in the directory are callsigns and the
contents of the files are the various message numbers that are
"queued up" for that station callsign. The extention of the files
key to what type of message is queued. (ie WA3ZNW.P is an SP message)
-----------------------------------------------------------------

(3). RSR directory:
The PMS code creates and deletes files
in this directory to handle the Remote Service Requests (RSR)
orginated or received by the BBS. PORTER handles the RSR's in
both directions and makes the connects from one GTEPMS station
to annother. PORTER also tasks RESOLVER (and LISTER, if
necessary) to fulfill RSR's from another station.
-----------------------------------------------------------------

f. Your BPQCFG.TXT file:
You will need to edit the BPQCFG.TXT file to
conform to the needs of the GTEPMS system. If you are already
running the G8BPQ AX.25 Networking Software, all you will need to
do is make the pertinent changes in the file; the
TNCPORTS sections, and the APPLICATIONS section. You will have
to rerun your BPQCFG.EXE to create the new BPQCFG.BIN file that
BPQCODE accesses on bootup of the system to set up the node.
Specific TNCPORTS must be defined in the
TNCPORT section of the BPQCFG.TXT file to allow the GTEPMS
Code to work with the G8BPQ code.
The maximum number of TNCPORT Definitions in
the BPQCFG.TXT file is still sixteen; however, you should keep
your TNCPORTS to be used by BPQ above COM 4, since you may have
other peripherals, such as a mouse or an internal MODEM and other
SERIAL port connections, that use COM ports 1 through 4. If you
do NOT use COM 1 through COM 4 for anything else in your comput-
er, feel free to use them in the BPQCFG.TXT for APPLMASK=1 ports.

IMPORTANT: ALL ports defined in your BPQCFG.TXT must have an
appropriate APPLMASK= parameter. Even if you have read the
BPQ docs and know that if this is left out it defaults to APPLMASK=1.
INCLUDE IT ANYWAY! When PORTER comes alive, it reads you BPQCFG.TXT
file to see which ports you have set aside for BBS use. It keys in
on the phrase "APPLMASK=1". If it senses a commport that does not
have an APPLMASK statement, PORTER will ignore this port (and it will
tell you so as it boots). In this case PORTER is warning you of
an error in your BPQCFG.TXT file. Any connect made to a port that
PORTER is ignoring will result in just that, "a connect". And nothing
else will happen. No BBS, no welcome, nothing.
There are two type of ports GTEPMS will use: a normal emulated TNC,
and one emulated PK232/UFQ port. First decide on the maximum number
of user/fwd windows you wish to have open at one time. I recommend
no more than 4 or 5. Allocate those ports and normal TNC ports.
Next choose a tnc port to emulate the PK232/UFQ tnc. This will be
the RSR port. Also ensure the RSR APPLMASK is set to the proper
application listed in the APPLICATIONS= statement at the end of your
BPQCFG.TXT file. Read the BPQ docs for more info on how and why
these things must be done.

The following type changes/additions should be made in the BPQCFG.TXT File:
Sample TNCPORTS:

;
TNCPORT
COM=5 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS
APPLMASK=1
ENDPORT
;
TNCPORT
COM=6 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS
APPLMASK=1
ENDPORT
;
TNCPORT
COM=7 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS
APPLMASK=1
ENDPORT
;
TNCPORT
COM=14
TYPE=PK232/UFQ ; hardwired to the Remote Service Requests
APPLMASK=8 ; function.
ENDPORT
;
; Applications for GTEPMS:
APPLICATIONS=BBS,*HOST,*SYSOP,*RSR ;add the *RSR

(yes, the star in front of RSR is manditory.)


*****************************************************************
6. To Open the BBS:
a. To open the BBS manually, enter ALT, O, GL, to open the
LISTER window (GL-PIF.DVP).

b. To open the BBS on boot up, create a DESQview bootup
script (DESQview.DVS) to open JUST the LISTER window. Here's how
to do it from a text file. Enter the following text with your
your favorite text editor:

{Learn ! "!startup"}
{DESQ}OGL
{Finish}

That's all there is to the file. Make sure this is all
your text file contains. This will boot up LISTER.EXE and
LISTER.EXE will open RESOLVER.EXE and PORTER.EXE, and then will
open any other windows you have designated in your SPAWN file.
Then run the DESQview Convert a Script program (without DESQview
booted up -- the filename is CONVSCR.EXE); when the menu comes up
select T to convert a Text File to a Script File, enter your text
file filename and the name of the DESQview file -- that should
ALWAYS be DESQVIEW.DVS for the DESQview bootup script.
Once you do that, boot up your system, and watch
LISTER do its thing. After you boot up LISTER, go on with your
setup.

c. Whether the SysOp manually brings the BBS on line or uses
the GL-PIF.DVP file in a DESQVIEW.DVS script to bring it up at
system boot up, LISTER itself will spawn open the RESOLVER and
PORTER windows (in that order).

d. If you don't like the way the windows are arranged, you
may use DESQview Resize and Move Options, to rearrange LISTER and
RESOLVER so that they only take up a little less than half of the
screen. You can either put them on the bottom or at the top or
in the two right hand or left hand quadrants of the screen. It's
up to you how you want to see them on your screen.

e. Some of the windows you might want to bring up as full
screen. The G?-PIF.DVP files provided with the BBS software may
have the positions diffent than what is indicated here or the way
you want them to appear. Rearrange them to suit your own tastes,
BUT DO NOT CHANGE THE EXTENDED FUNCTIONS options, since they are
more or less HARDWIRED into the multitasking programming. Also,
DO NOT CHANGE THE RAM requirements in the G?-PIF.DVP file, since
N2GTE has already optimized them. Most of the programs require
about 80Kb, but some use more and some use less. You should
leave them as N2GTE has set them, so you will have enough RAM and
will not waste any.

*****************************************************************

7. To Close the BBS Gracefully:
a. First, check for activity. Do an ALT S to see the Open
Windows. DESQview will show what windows are active. If no
windows other than 1, 2, AND 3 (LISTER, RESOLVER, PORTER) and
your regular windows you have SPAWNed are open, close your
spawned windows, then continue on to step b. You may have
Users logged in or a BBS FWDing. Unless it is an emergency,
be kind to your Users and wait for them to disconnect before
continuing shut-down. If you continue on with step b while
people or connect, they will get disconnected.
b. Select the PORTER Window (Window 3). This will UNHIDE
the window. Next, press the ESCAPE key -- this will close the
PORTER Window.
c. Select the LISTER window and in all capital letters type
the word ABORT, then press Enter or Return. You will need to be
in the lefthand column for this to work properly. Closing LISTER
this way will also close RESOLVER and shut down the BBS..

*****************************************************************

8. The N2GTE Console Window:
a. To Open the Window:
Press ALT, then O, then select GC, and press Enter or
Return. This will open the Console Window. The Console Window
is for the SysOp to use locally, so he/she may read mail or
bulletins, kill mail/bulletins, or post mail or bulletins, either
to local users or to be forwarded. The SysOp may also use mail
messages to send requests to servers. The SysOp CAN NOT make
CONNECTS to the NODE or other stations from the CONSOLE window.
Use a terminal program of your choice that is compatible with the
BBS.
b. To Close the GTE Console Window, enter B (for Bye), and
press Enter or Return.

*****************************************************************

9. GTERM Window:
a. BPQCFG.TXT Notes for GTERM Version 2.01 (GTERM21.EXE):
This version is hardwired for COM=11 with APPLMASK=2;
it IS a HOST Mode application.
b. General Notes:
(1). The GT-PIF.DVP file is contained in the GTERM.ZIP
file along with this short documentation file.
(2). N2GTE does not recommend any changes to the DV
window sizes, since the program owns two windows -- an input
window and an output window. Function Key F2 will adjust the
size of the input window. There are four fixed sizes and press-
ing F2 will rotate through the window sizes in a "round robin"
fashion.
(3). Pressing Function Key F6 gets you help.
(4). This version DOES NOT support YAPP although it
says it does.
(5). The ASCII capture file is hardwired to "\CAP-
TURE.TXT" of whatever drive you have defaulted this application
to. If it is in your C:\ root directory, that is where CAP-
TURE.TXT will be -- it doesn't matter that you might have the
file in a directory called GTEPROGS\UTILS off D:\ drive -- the
path to CAPTURE.TXT will be C:\CAPTURE.TXT.

*****************************************************************
Section II - System Operation:

1. N2GTE Packet Message Switch Program Files -
Executable Program Files Associated with the GTEPMS:
-----------------------------------------------------------------

USER.EXE: This file interfaces the users with the BBS
portion of the system. On users entering their own calls as
their home BBS -- well, beginning with Prototype Version 0.4 of
the N2GTE code, USER.EXE will not allow this to happen. If
the user insists he is a BBS, then he will be prompted to send a
message to the SysOp for further negotiations.
-----------------------------------------------------------------

PORTER.EXE: This file does the necessary "porting" functions
of the Packet Message Switch and opens all the user and
forwarding windows. As its name implies, PORTER manages ports
and porting. It has its own configuration file (PORTER.CNF), for
the timed functions it manages, along with the other porting
functions. The T command assigns the times for PORTER to
execute the "timed" CHORE.xx files. PORTER, in turn, assigns
forwarding chores to available TNCPORTS configured in the
BPQCFG.TXT. Timed Batch files do not have to have TNCPORT as-
signments, but are handled in the same way as FWDing chores
are.

Servers:
You could build a batch file to run every
hour that actually executes your servers. To have the BBS call
it every hour, add a "T Command" line in your PORTER.CNF. Make
sure you pick a time that would not conflict with your FWDing
time or during "beaconing time". We do not want the FWD window
to try to read files that the servers may be trying to create,
all at the same time. An example PORTER.CNF line to do this would
be as follows:

T 05 C:\DV\SB-PIF.DVP F:\DBASE.DAT

The "05" means five after the hour. Next is the directory path
to the filename NOT OF THE BATCH FILE, BUT of the DESQview PIF
File (SB-PIF.DVP, for the SERVER.BAT Script) that runs the
batch file window. Last is an argument, or parameter you wish to
pass to the batch file.
-----------------------------------------------------------------

CONS.EXE: The SysOp Console program file. This is the
file that manages the SysOp's CONSole window. The SysOp uses
this window to do all the SysOp duties and can read mail or
bulletins, post mail or bulletins, read the help files (if
necessary) or other things, but the SysOp CAN NOT use the CONSole
window to make connects to other stations.
-----------------------------------------------------------------

FWD.EXE: Does the forwarding; uses the FWD. file to do
the forwarding. This is the executable file that PORTER.EXE
calls to perform the forwarding chores. You import files to the
BBS and export files from the BBS. You place the filename(s) you
wish to import in the "chore" files. Please ensure the second
character is a colon. Remember the BBS keys on that to know it
is a file you are talking about.
You export to servers from the FWD. file and import
from servers in the CHORE.* files.
Multiple forwarding windows are supported, but only one
should be started at a given time and they should be spaced apart
in time by about five minutes, at least. The reason this is
necessary is that message files could be corrupted by the
interaciton of windows, since the _mailGaTE_ will also be accessing
files and if two forward windows are going at exactly the same
time, some corruption of files could easily result. Most of the
time there won't be any problems, but a word to the wise should
be sufficent -- why take chances?
The FWD. file contains the forwarding information
(based on who gets the mail for whom or what. See the sample
FWD. File for examples. If you make changes in your FWD. file in
your GTEPMS root drive, you need to copy the new file over to
your virtual ram drive, which you set in the CONFIG.GTE file.

How to Force a Forward:
a. Open the Forward Window (GF).
b. The window will display FWD.EXE on a line by itself.
c. The SysOp will then MANUALLY enter the CHORE.##
filename that he/she wants to be execute (i.e., CHORE.10), then
the SysOp will press . That forces the forward cycle.
-----------------------------------------------------------------

LISTER.EXE: LISTER lists things and mangages temporary
spool files. One major function that LISTER performs on BOOTUP
of the BBS is to open the RESOLVER.EXE and PORTER.EXE windows.
LISTER.EXE may be opened by the DESQview STARTUP file
(DESQview.DVS) or manually by the SysOp. Additionally,
LISTER.EXE may also open other windows with the SPAWN file (see
SPAWN).
Typing "ABORT" (without quotes) in the LISTER
window closes RESOLVER and LISTER and cleans up files (especially
the DV-MAIL.DAT). All activity should be quiet and the PORTER
window should already closed (by hitting the key while the
PORTER window is top-most in the window stack).
-----------------------------------------------------------------

RESOLVER.EXE: This one handles the mail, traffic, and
bulletins. Its main goal is to get rid of messages. RESOLVER's
main job is to get rid of mail, so it uses the HADDR file to add
the HIERARCHICAL addressing suffixes and the FWD. file to determine
where to send the messages then hands them off to PORTER, which
opens the windows for forwarding at the forwarding CHORE times.
RESOLVER bounces mail back to LISTER, so LISTER
can try to get the User's HOME BBS and attach it to the address.
If LISTER does not have the User's HOME BBS it will take no
further action, but, if it does, it tacks the @BBScall onto the
message and sends the mail back to RESOLVER to try again.
If a user enters any @BBS call in the @BBS field of a
message that will cause RESOLVER to override what is in the USER
database that RESOLVER checks for HOME BBS's.
RESOLVER also initiates Remote Service Requests (RSR)
through PORTER to other GTEPMS stations (see MOUNT file).
-----------------------------------------------------------------

HEADX.EXE: This file scans the Message Headers and pulls
in information on new BBS stations, then it updates the HADDR
file, a Hierarchical Address (HADDR) file and creates the
HEADERS.IMG File - Don't mess with this file! It is an image
file that HEADX.EXE uses. HADDR is a working file that RESOLVER
uses to check for header information when it needs information as
it "resolves" messages and prepares them for forwarding. The
SysOp should run HEADX.EXE once every week (or every two to
three days on heavily used BBS's -- depends on the volume of
traffic through the BBS). HEADX.EXE pulls header information
from messages the BBS receives and adds new information to the
HADDR file. When the messages are resolved for destination and
there is no call in the @BBS field, then RESOLVER tasks LISTER to
check for and supply the HOME BBS of the User (if known); LISTER
will check for the call in the USERS directory and if it has the
call will pass it back to RESOLVER, which then continues to
resolve the message based on the HOME BBS. If HOME BBS is not
known, either by LISTER or by RESOLVER, the message should stay
on the BBS. If it IS known, then RESOLVER will queue it up for
proper forwarding to another BBS station with the call and the
Hierarchical addressing information added "automagically". HEADX
must be run by the sysop about once every two to three days. It
MUST be called from your root GTEPMS drive, so you must be sure
the change to the root drive is made or HEADX won't be able to do
its job. Also see HADDR information.
-----------------------------------------------------------------

MODEM.EXE: The MODEM.EXE code is now divorced from
USER.EXE. MODEM.EXE will auto-detect baud rates (300 to 9600)
There is a callsign validation on log-in (only amateur
calls accepted). MODEM.EXE will can echo the user's type back to
them. It also sends pairs. It comes with its own GM-
PIF.DVP. MODEM.EXE uses the initialization file MODEM.INI. This
file contains at least three lines:
a) the COMM port of your modem;
b) the maximum baud rate your modem can use
c) AT commands to configure your modem.

Example:

1
2400
AT E0 X4 Q0 &D2 S2=64
AT S0=1

The PORTER window accepts the commands "MODEM
ON" and "MODEM OFF". When you type MODEM OFF, PORTER then ig-
nores any modem state changes. This is handy for you to use
another modem program in another window temporarily. When fin-
ished, close the external modem program and type MODEM ON in the
PORTER window. PORTER will then try to reconfigure the modem
back to \MODEM.INI's setting. ** Be advised ** Some modem
programs leave the modem in a terrible state when they exit!
PORTER can not recover the modem parameters. If this happens,
you must reboot.
You MUST use some sort of COMxBIOS not only
to buffer RXed characters, but to also support other hardware
handshaking INT14 calls.
Also be advised, modem programs do not generally support
"shared interrupts" very well. A word to the wise here should be sufficient.
Your modem MUST be able to support DTR signals. This means
your modem must hang-up and enter command state when the DTR signal
is transistioned from high to low (or TRUE to FALSE). Usually this
is a software switch you set in MODEM.INI (AT &D2). In some external
modems, it is a switch setting on the modem itself. N2GTE also
advises, for your modem/bbs security that you change the ESCAPE char
of your modem to something other than the well-known "+". Choose
whatever character you like, but remember what it is so you can
still you it manually (as in other programs like SLIPNET.EXE).
You can change the ESCAPE char by placing in your MODEM.INI file
the command "AT S2={ascii}" where {ascii} is the ascii value of your
newly chosen ESCAPE char.
-----------------------------------------------------------------
Here is a short doc on how to set up your system to fwd via your modem.

1. In PORTER.CNF make another timed event entry using GZ-PIF.DVP and
the file CHORE.MDM. Mine looks like this:

T 20 C:\DV\GZ-PIF.DVP CHORE.MDM

2. In CHORE.MDM you put the callsigns of the stations you want to fwd to
just as you do in your CHORE.10, CHORE.40, etc. files.

3. In your T:\PATHS directory you want a .MDM file for each station
that you will fwd to via modem. For instance, in testing this code
I used N2GTE.MDM. In this file you will have the following lines:

SPEED
PHONE NUMBER PRECEDED BY THE LETTER 'T' (tone) or 'P' (pulse)
CONNECTION SCRIPT (see in other places in this Doc about scripts)

For example, my modem fwding file for N2GTE.MDM looks like this:

1200
T672-3959 (the dash is not necessary)
~: (the "enter your callsign" line ends with a colon)
.N3ETI

NOTE ON SCRIPTS: If you were calling an AA4RE TELINK board or
any other board that requires a password, your script could look
like this:

2400
T672-3959
~call
.N3ETI
~pass
.GUEST

-----------------------------------------------------------------

GTERM21.EXE: A DESQview-specific Terminal Program to
provide the SysOp with communications to other stations. This
program currently DOES NOT have YAPP Binary Transfer support and
is primarily for the SysOp to connect to other BBS stations or
nodes. There is a separate documentation file (GTERM.DOC) for
this program; GTERM21.EXE can be run without the BBS being up, if
necessary, although the BPQCODE must be running.

*****************************************************************
2. Command Summary - User Commands:

B - Bye

D - Download (ASCII files)
Syntax: D AREA FILENAME.EXT

H - Help

I - Info

J - Journal (list of users and BBS's connected since
system bootup)

K - Kill this message
KM - Kill Mine that I have already read
KT - Kill Traffic

L - List (all since last list)
L - List from nr (a 50-range limit is imposed.)
L - List between nr1 and nr2 (a 50-range limit is imposed.)
LL - List Last of msgs
LT - List all Traffic
L@ - List At
L< - List from callsign
L> - List to callsign
LM - List Mine (whether read or not)
LN - List Mine (only new and unread msgs)

N - Update Name in User database.
NH - Update Home BBS Call in User database.

O - Over to the node (not available from MODEM).

Q (or QS) - Query status of msg database.
QL - Query Links
QU - Query all users in the USER database
QU - Query User
QQ - Query the QUEUE directory

R - Read msg# (can have up to eight on a line.)
RM - Read Mine (whether new or not).
RN - Read Mine, but only those I have not read yet.

SP - Send Personal Message.
SB - Send Bulletin Message.
ST - Send NTS Traffic Message.
S - (will be converted to SP)
S ALL - (anything to ALL will be converted to SB)

T - Talk to the SysOp

U - Upload ASCII file
Syntax: U AREA FILENAME.EXT

V - Same as R but displays all the gory headers too.

W - What areas are available.
W area - What files are in that area.

X - Toggle UserType eXpert to normal.

The following commands are availble on the modem port only:
SET ECHO - either ON or OFF
SET PAGE - either ON or OFF
@ - make me a SuperUser (will be password challanged)
X - crossconnect me with the BPQ node (SuperUsers only)
FTP - switch MODEM in an FTP Server for SLIP sessions.

*****************************************************************
3. Command Summary - SysOp Commands/Console Macros/Etc.:
Extra Commands available from the CONSOLE window:

E - Allows the SysOp to edit certain field of a message.
F - forces RESOLVER to re-resolve that message.
K- - Clean up the DV-MAIL.DAT
LK - List Killed
LH - List Held
LX - List expired
LU - List unresolved msg (personal and traffic only,
bulletins are always supposed to resolve)
L- - List all msgs older than days. No spaces.
L? - List all msg with this status.
L? - List this type of messages with this status.
MT msg# filename - to copy just the text of msg# into filename.
MM msg# filename - makes filename out of what you would normal see
during a normal READ command.
MV msg# filename - makes filename out of what you would normal see
during a normal VERBOSE command. (all headers included)
RH - Release Held bulletins (see end of Docs)
RS - Release Stale Held only
RB - Release BadBID Held only
RU - Review and edit NonResolved mail
~r filename - to insert a prepared file into the message text.
This will read filename.ext into the message.
-------------------------------------------------------
Commands Available from the keyboard in a USER or MODEM window:

F10 Key - Go into "chat mode" on user window. When a user
uses their "T" command to get the SysOp's attention and the SysOp
decides to be available, he/she switches to the user window and
presses the F10 Key. To end a "chat mode" session all the SysOp
has to do is enter F10 again.

*****************************************************************
4. File/Directory Ownership:

a. Because this BBS is not only multi-connect, but multi-
tasking also, file access conflicts can become a problem. To
help keep things on the up-and-up, certain BBS windows "own"
certain files and/or directories. If another window wants info
from a resource it does not own, it must request the info from
the owner, NOT go get it on its own.

b. The following is a list of file/directories and their
respective owners:

File/Dir.: Owner (comments):

DV-MAIL.DAT LISTER (read/write/create)
\USER\*. LISTER (read/write/create)
SEQUENCE.SEQ LISTER (read/write/create)
SPAWN. LISTER (read only, during start-up)
SWAP. RESOLVER (read only)
FWD. RESOLVER (read only, copies to ramdisk for quicker searches)
BIDOK. RESOLVER (read only)
BULLETIN. RESOLVER (read only)
\QUEUE\*. RESOLVER (read/write/create/destory)
HEADERS.IMG HEADX (read/write/create)
HADDR. HEADX (write/create), RESOLVER (read only)
\LOG\*. RESOLVER (write/create)
MOD. USER,MODEM (read only)
MOUNT. PORTER (read only during RSRs)
\HELP\*. USER,MODEM (read only)
\PATHS\*. FWD (read only)
\MSG\*. USER,FWD (read/write/create); LISTER (read only/destory)
CONFIG.GTE ALL (read only)
CHORE.* FWD (read only)
PORTER.CNF PORTER (read only, during start-up)
GR-PIF.DVP LISTER (read only, during start-up)
GP-PIF.DVP LISTER (read only, during start-up)
**-PIF.DVP PORTER (read only during a winodw opening)

*****************************************************************
Section III - TCP/IP Support for GTEPMS/G8BPQ's TheNode:

1. There can only be one TELNET<->BBS pipe at a time. Second
sessions to socket 30 will receive a busy notice. TELNET is
handled by N2GTE's version of NET. It interfaces to BPQ thru TNC
port COM=8. When a session is started, it tells BPQ to connect
COM8 to any available BBS port (COM5 or COM6 or whatever you have
setup). The BBS has no idea whatsoever that the connect was via
telnet. The TCP/IP user will issue a connect using the following
syntax:

telnet n2gte 30

The IP user will be prompted for a callsign, then if there are
any USER ports available, the first available one will pop up and
the BBS itself will treat the connect as a normal AX.25 connect.

2. The following BPQCFG.TXT TNC Port Scripts deal directly with
the TCP/IP interfacing with the BBS and the Node:
a. The GTEPMS TELNET Port to Socket 30 via the Node allows
TCP/IP Stations to make TELNET connections to the AX.25
BBS/Mailbox. TCP/IP TELNET sessions to the BBS are tied to
Socket 30 AND to the node's COM 8.

TNCPORT
COM=8
APPLMASK=2
ENDPORT

b. This is the first port defined in the AUTOEXEC.NET file
as one of your radio ports and corresponds to it. In this case
it just happens to be a UHF port and is given the device name
"uhf" in the attach line of the AUTOEXEC.NET file. The device
name "uhf" is arbitrary.

TNCPORT
COM=9
TYPE=KISS
KISSMASK=1
ENDPORT
TNCPORT
COM=10
TYPE=KISS
KISSMASK=2
ENDPORT

c. This is the second port defined in the AUTOEXEC.NET file
and corresponds to it. This one just happens to be a 2M port and
is given the device name "vhf" in the attach line of the AUTOEX-
EC.NET file. The device name "vhf" is arbitrary.

*****************************************************************
4. Information for the AUTOEXEC.NET File:

a. Attaching the Shared Ports:

attach asy 0 8 ax25 uhf 1024 230 4800
attach asy 0 9 ax25 vhf 1024 230 4800

the above lines equate to two radio ports, defined as PORTNUM=1 and PORTNUM=2
(441.000, 147.570 respectively) and equate to the BPQCFG.TXT TNCPORT's
COM=9 and COM=10, respectively.
Note: The "asy 0" refers to the G8BPQ Node Software or
"io addr 0". If you run more than two ports, they will also have to
be "attached" in like manner and the number in AUTOEXEC.NET will
always be one less than the port number in BPQCFG.TXT.
b. Starting the protocol that allows the TELNET sessions to
the BBS:

start bbs

This is the protocol added by N2GTE, which allows
"telnet" connects to the BBS from TCP/IP stations. Telnet ses-
sions to the BBS are made to socket 30 (syntax: telnet n2gte 30)
and the user will get the messages "SYN sent", "Established",
then a prompt for your callsign. After you enter your call, you
will get the notice "Ok" from the node. Next, you will be connected
to the BBS, unless all the BBS ports are busy. After you are
through, you may issue a disconnect with the "b" command or issue
an "O" command to go to the Node before disconnecting.
c. To have the _mailGaTE_ functions of the BBS working the
correct way, one must add the following lines to your autoexec.net
file. What these lines actually do is covered on the NET docs.

smtp gateway #<-- for _mailGaTE_
smtp mode queue #<-- for _mailGaTE_

d. Remember, true hostnames are required for SMTP to work
properly, so ensure that your HOSTS.NET is arranged properly.
The proper placement in the HOSTS.NET file is as follows:

IP.IP.IP.IP hostname alias alias alias alias... #comments

where the "IP" denotes the digits of the IP Address. The
first name after the IP is supposed to be the hostname of whatever
the other operator calls his host. For Example:

44.0.60.34 ka3dxx.ampr.org ka3dxx # George Stickler

*****************************************************************
Section IV - GTEPMS Features and Special Notes from the Author:

1. N2GTE Comments on Multiple Forward Windows
a. Practical experience has shown me that about three
connects per freq is max that one station can handle at 1200
baud. If multiFWD were used, the SysOp MUST ensure they use
different freqs; i.e. force Lv2 connections with designated ports
(C 1 SEVBBS-1, C 2 W3IWI, C 3 NATCAP-1, etc). This would spread
out the freq loading. This would be a SysOp responsibility. Can
you imagine what 441.000 would be like if N2GTE FWDed to KA3DXX,
WB3V, WA7NTF, and N4QQ at the same time?
b. MultiFWD may not be the best uses of computer resources.
Every TNC set aside by BPQ needs about 2 to 3K memory. That's
not too bad and can be considered insignificant part of a 4Mb
RAM pool. But the FWD window needs about 100K. Allocating about
400K of the approximate two to four Mbytes you have available for
new windows IS a significant chunk. If a system is "gang FWDing"
there could be little memory left for user windows. The SysOp
should decide which is more important; FWD useless bulletins or
servicing his loyal Users?
c. Not only is memory required, but consider the time slice
allocation also. That is something most people forget. They
remember RAM and freq loading, but what about uP loading. This
factor does not exist in non-multitasking system. Many people
think about RAM-hogs and disk-hogs, but us multi-taskers must
also consider the time-hogs (or things that may degrade perform-
ance). In DESQview, each window is given a slice of uP time.
What that window does with it is up to the window. If there is
nothing to do, it should give the remaining mseconds back to DV
so DV can immediately switch to another window. All DV-friendly
programs do this. ALL GTE programs do this also. In fact,
LISTER and RESOLVER are truely DV-specific programs and actually
STOP executing until DESQview wakes them up with something to do.
SO while idle, LISTER and RESOLVER do not even get their time
slice handed to them. ALL other windows have something to do
with the COM ports (PORTER, USER and FWD). Thus they can not go
to sleep. Each time DV gives them a time-slice, they make a
quick check for incoming characters. If none are waiting, they
give up the remainder of their time. But as long as there are
characters coming in (or going out during FWDing) those windows
want all the uP time DV will give them. It has to be that way.
You only get one shot at pulling a character out of the comm
ports. Once you miss a character, it is gone forever, because
the TNC (or DRSI) has already sent its ACK saying it RXed all ok.
It did. The program simply failed to suck the data out of the
buffer before overflow. This will probably never happen on a
386@16MHz or above, but must be considered from a programmer's
standpoint. That is the only reason I mention it here.
d. As I coded it , a FWD window
will sense that another FWD using the same chore file and will
immediately shut down. I did that on purpose. If a long FWDing
session takes over an hour to complete, there has to be a hook to
keep another window from trying to FWD to the same stations next
cycle.
e. With multiFWD, the SysOp has the ability to be in a
constant (or near constant) state of FWDing. This could give one
the reputation of being a channel hog.
f. The USER window will REVerseForWarD to a BBS, thus
actually changing itself to a psuedo-FWD window upon the "F>"
command. With that consideration in mind, does one really need
so many other FWD windows open at once? Every USER window has
the potential of being a FWDing window, depending on the type of
connection.

2. Lifetimes for Bulletins, Mail, and NTS Traffic:

a. Personal Mail (SP type) and NTS Traffic (ST type) NEVER
goes stale. It would remain for years if the sysop lets it.
b. The following data applies ONLY to bulletins:
- Bulletins received from other BBS's that arrive at an
N2GTEPMS System are immediately marked as stale if they are over
14 days old.
- A bulletin created locally will be marked as stale
once it has aged over 14 days.
- Stale bulletins older than 14 days (whether created
locally or received from another BBS) are marked as killed.
c. Killed Messages (whether SB, SP, or ST) are deleted from
the system about 3 days after they were killed.
d. These times are hardwired into the code and are life-
spans recommended by W3IWI. These lifespan time frames will
always remain hardwired in the BBS code of the N2GTEPMS System
to assist the SysOp in keeping stuff too old to be useful out of
the network. If a particular SysOp has a beef about that, then
N2GTE recommends the SysOp choose another BBS code to run.


3. The Remote Service Request (RSR) Feature:

The RSR feature will let one GTEPMS system poll another one
in an attempt to "resolve" mail. This feature in a given GTEPMS
System will automagically interact with other GTEPMS stations
so that they will have the ability to share one another's Message
Switch files. If LISTER and RESOLVER on one system can't figure
it out, they will check with another GTEPMS station to resolve
problem mail. RSR is built-in. The RSR is one of the main
"selling" features of the Message Switch System; its ablility to
share another system's resources.

4. Associated with MODEM.EXE are two environment variables the user
can set. They are ECHO and PAGE. To turn them on, the user would
type "SET ECHO ON" or "SET PAGE ON" (without quotes, of course).
Turning them off should be intuitive. Typing "SET" by itself will
display the current environment. All new modem uses have both defaulted
to ON. What ECHO does should be self-explainitory. PAGE will allow
only about 20 lines of text to flow, then it will stop until the user
send a to continue, or an "A" (must be capitol) to ABORT the current
action.

5. LOG's: The BBS now Logs into a directory off of the BBS
root called \LOG - All logs will end up there. They are updated
every 15 minutes, so be advised not to have them open in to
viewer/word processor during "BEACONING" time.

6. FWDing is done, ST first, then SP, then SB. All queues are FIFO.

7. You should create a file called \PASSWD. It should contain one line of text.
Case of the letter WILL matter when responding to a password challenge.
You will be challenge when your own call connects to the BBS or when
giving the SuperUser command "@" in MODEM. If the PASSWD file does not
exists, then there will be no challenge. The challenge is in the form
of the BBS sending you five numbers. These number represent random position
within the line of text in the PASSWD file. You must respond correctly
with the appropriate charaters or get disconnected.
Example: BBS sends -> 5 26 32 2 50
Your respond with -> Tw.hq
(note puncuation characters are also valid)
Note: Your own callsign will not be challenge if you have place in your
CONFIG.GTE file the variable PASSME=NO.

8. From the MODEM, a user can gain access to the BPQ switch. First the
user must become a SuperUser by issuing the "@" command. The after passing
the password challenge, he issues an "X" command (for "Xlink"). He will
then be connected to the BPQ node and may do statuses and node listing;
even further connect out the node.


*****************************************************************
Late updates.

The \STOPBULL. file --
Due to recent FCC action, N2GTE has added a feature to RESOLVER which
will allow SysOps to automatically place selected bulletin distributions
on HOLD. These held bulletins can NOT be FWDed, nor even viewed by Users.
The SysOp must manually release these bulletins. The STOPBULL file simply
contains a list of @BBS designators of what bulletins are to be held.
To release these, the SysOp (from the console window) types RH (Release
Held). He/she will then get to view each bulletin in-turn and decide
on its fate. To release STALE bulletins, you must now use RS (Release
Stale) and for BADBIDs (RB). My personal STOPBULL contains this:

USA

STOPBULL only works on Bulletins, SP and ST mail are NOT effected.

*****************************************************************
Late Late Update --
To make the above STOPBULL feature more flexable, I have added a new
variable to the CONFIG.GTE file. It is called STOPBULL=x, where x
is a bit-significant value to control how the \STOPBULL. file will
be used. Here is how it is broken down:

STOPBULL bit# 2 1 0
| | \- Hold bulls ORGINATING at my BBS.
| \-------- Hold bulls FWDed to my BBS.
\---------------- Hold SB, SP and ST to/from a certain call.

Thus:
STOPBULL=0 will cause no action.
STOPBULL=1 will stop only bulls in \STOPBULL. that ORIGINATE from your BBS.
STOPBULL=2 will stop only bulls in \STOPBULL. FWDed to your BBS.
STOPBULL=3 will stop both ORG and FWDed.
STOPBULL=4 will stop only SB, SP and ST TO/FROM callsigns listed in \STOPBULL.
STOPBULL=7 will do it all.

Example:
The \STOPBULL. file has this:

USA
WA3QNS

and the CONFIG.GTE has STOPBULL=5
Thus all @USA orginating from my BBS will be held, plus all mail, be it
any @BULL, or SP/ST, to/from WA3QNS will be held.

I, N2GTE, DO NOT LIKE HAVING THIS FEATURE. IT GRATES AGAINST MY FEELINGS.
But, I have included it to allow the SysOp more control over what goes
out of his transmitter.



************************************************************************
APPENDIX A List of Files from the GTEPMS System

GTE12.ZIP
CONS.EXE
DV-MAIL.DAT
FWD.EXE
FWDMOD.EXE
GTERM21.EXE
HADDR
HEADERS.IMG
HEADX.EXE
LISTER.EXE
MAKEDIR.BAT
MODEM.EXE
PORTER.EXE
RESOLVER.EXE
SERVNET.EXE
USER.EXE
HELPFILE.ZIP
@
B
D
E
F
FTP
HELP
I
INFO
J
K
L
M
N
O
Q
R
S
SET
T
U
V
W
X
READ.ME
MDMBIOS.ZIP
GTE1BIOS.COM
GTE2BIOS.COM
GTE3BIOS.COM
GTE4BIOS.COM
DV-PIF.ZIP
GC-PIF.DVP
GF-PIF.DVP
GL-PIF.DVP
GM-PIF.DVP
GP-PIF.DVP
GR-PIF.DVP
GT-PIF.DVP
GU-PIF.DVP
GZ-PIF.DVP

SAMPLES.ZIP
BIDOK
BULLETIN
CHORE.10
CHORE.MDM
CONFIG.GTE
FWD
LINKS
MOD
MOUNT
PASSWD
PORTER.CNF
SPAWN
STOPBULL
SWAP

BPQ359.ZIP
220KISS
APPLS.DOC
BPQCFG.EXE
BPQCFG.TXT
BPQCODE.EXE
BPQDUMP.COM
BPQDUMP.DOC
BPQNODES.COM
BPQNODES.DOC
CHANGES.BPQ
COMMANDS.DOC
CONFIG.DOC
DRSI.CFG
HOSTMODE.DOC
INT14.DOC
JKISS
JKISSCW.DOC
JKISSP
KISS
KISS.CFG
KISS.DOC
KISSMODE.DOC
NODEDRV.COM
NOSBPQ.DOC
PAC2.COM
PAC2.DOC
PASSWORD.BPQ
PATCHID.COM
QUAD.CFG
SAMPLE.C
SWITCH.DOC
SYSOP.COM
SYSOP.DOC
WISHLIST

GTE-NET.ZIP
ALIAS
AUTOEXEC.NET
BM.EXE
BM.RC
FTPUSERS
HOSTS.NET
IP-PIF.DVP
MAKENET.BAT
NET.EXE
NET-DOCS.ZIP
ADVANCE.DOC
APPEND1.DOC
APPEND2.DOC
APPEND3.DOC
BM.DOC
COMMANDS.DOC
NETROM.DOC
README.DOC
SETUP.DOC
TCPIP.DOC
TESTDRV.DOC

END OF APPENDIX A List of Files from the GTEPMS System
************************************************************************