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@
