HAM Radio 1/HamRadio.cdr/packet/gtemisc/gtepms.doc

Text File | 1991-03-21 | 79KB | 3,545 lines

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; <type> <minute> <pif file> <parameter>

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: <designator> <callsign> <callsign> <callsign> <etc>

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 <CR> 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=<number> 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 <Enter>.  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 <ESC> 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 <CR><LF> 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 <msg#>  - Kill this message

KM        - Kill Mine that I have already read

KT <msg#> - Kill Traffic



L             - List (all since last list)

L <nr>        - List from nr (a 50-range limit is imposed.)

L <nr1> <nr2> - List between nr1 and nr2 (a 50-range limit is imposed.)

LL <nr>       - List Last <nr> of msgs

LT            - List all Traffic

L@ <bul>      - List At <bulletin designator or callsign>

L< <callsign> - List from callsign

L> <callsign> - List to callsign

LM            - List Mine (whether read or not)

LN            - List Mine (only new and unread msgs)



N <name>  - Update Name in User database.

NH <Call> - 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 <callsign> - Query User

QQ        - Query the QUEUE directory



R <msg#> - 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 <msg> - Allows the SysOp to edit certain field of a message.

F <msg> - 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-<days>   - List all msgs older than days.  No spaces.

L?<status> - List all msg with this status.

L?<type><status> - 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 <yourhostname> #<-- 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 <CR> 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

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