- List At L< - List from callsign L> - List to callsign LM - List Mine (whether read or not) LN - List Mine (only new and unread msgs) N - Update Name in User database. NH - Update Home BBS Call in User database. O - Over to the node (not available from MODEM). Q (or QS) - Query status of msg database. QL - Query Links QU - Query all users in the USER database QU - Query User QQ - Query the QUEUE directory R - Read msg# (can have up to eight on a line.) RM - Read Mine (whether new or not). RN - Read Mine, but only those I have not read yet. SP - Send Personal Message. SB - Send Bulletin Message. ST - Send NTS Traffic Message. S - (will be converted to SP) S ALL - (anything to ALL will be converted to SB) T - Talk to the SysOp U - Upload ASCII file Syntax: U AREA FILENAME.EXT V - Same as R but displays all the gory headers too. W - What areas are available. W area - What files are in that area. X - Toggle UserType eXpert to normal. The following commands are availble on the modem port only: SET ECHO - either ON or OFF SET PAGE - either ON or OFF @ - make me a SuperUser (will be password challanged) X - crossconnect me with the BPQ node (SuperUsers only) FTP - switch MODEM in an FTP Server for SLIP sessions. ***************************************************************** 3. Command Summary - SysOp Commands/Console Macros/Etc.: Extra Commands available from the CONSOLE window: E - Allows the SysOp to edit certain field of a message. F - forces RESOLVER to re-resolve that message. K- - Clean up the DV-MAIL.DAT LK - List Killed LH - List Held LX - List expired LU - List unresolved msg (personal and traffic only, bulletins are always supposed to resolve) L- - List all msgs older than days. No spaces. L? - List all msg with this status. L? - List this type of messages with this status. MT msg# filename - to copy just the text of msg# into filename. MM msg# filename - makes filename out of what you would normal see during a normal READ command. MV msg# filename - makes filename out of what you would normal see during a normal VERBOSE command. (all headers included) RH - Release Held bulletins (see end of Docs) RS - Release Stale Held only RB - Release BadBID Held only RU - Review and edit NonResolved mail ~r filename - to insert a prepared file into the message text. This will read filename.ext into the message. ------------------------------------------------------- Commands Available from the keyboard in a USER or MODEM window: F10 Key - Go into "chat mode" on user window. When a user uses their "T" command to get the SysOp's attention and the SysOp decides to be available, he/she switches to the user window and presses the F10 Key. To end a "chat mode" session all the SysOp has to do is enter F10 again. ***************************************************************** 4. File/Directory Ownership: a. Because this BBS is not only multi-connect, but multi- tasking also, file access conflicts can become a problem. To help keep things on the up-and-up, certain BBS windows "own" certain files and/or directories. If another window wants info from a resource it does not own, it must request the info from the owner, NOT go get it on its own. b. The following is a list of file/directories and their respective owners: File/Dir.: Owner (comments): DV-MAIL.DAT LISTER (read/write/create) \USER\*. LISTER (read/write/create) SEQUENCE.SEQ LISTER (read/write/create) SPAWN. LISTER (read only, during start-up) SWAP. RESOLVER (read only) FWD. RESOLVER (read only, copies to ramdisk for quicker searches) BIDOK. RESOLVER (read only) BULLETIN. RESOLVER (read only) \QUEUE\*. RESOLVER (read/write/create/destory) HEADERS.IMG HEADX (read/write/create) HADDR. HEADX (write/create), RESOLVER (read only) \LOG\*. RESOLVER (write/create) MOD. USER,MODEM (read only) MOUNT. PORTER (read only during RSRs) \HELP\*. USER,MODEM (read only) \PATHS\*. FWD (read only) \MSG\*. USER,FWD (read/write/create); LISTER (read only/destory) CONFIG.GTE ALL (read only) CHORE.* FWD (read only) PORTER.CNF PORTER (read only, during start-up) GR-PIF.DVP LISTER (read only, during start-up) GP-PIF.DVP LISTER (read only, during start-up) **-PIF.DVP PORTER (read only during a winodw opening) ***************************************************************** Section III - TCP/IP Support for GTEPMS/G8BPQ's TheNode: 1. There can only be one TELNET<->BBS pipe at a time. Second sessions to socket 30 will receive a busy notice. TELNET is handled by N2GTE's version of NET. It interfaces to BPQ thru TNC port COM=8. When a session is started, it tells BPQ to connect COM8 to any available BBS port (COM5 or COM6 or whatever you have setup). The BBS has no idea whatsoever that the connect was via telnet. The TCP/IP user will issue a connect using the following syntax: telnet n2gte 30 The IP user will be prompted for a callsign, then if there are any USER ports available, the first available one will pop up and the BBS itself will treat the connect as a normal AX.25 connect. 2. The following BPQCFG.TXT TNC Port Scripts deal directly with the TCP/IP interfacing with the BBS and the Node: a. The GTEPMS TELNET Port to Socket 30 via the Node allows TCP/IP Stations to make TELNET connections to the AX.25 BBS/Mailbox. TCP/IP TELNET sessions to the BBS are tied to Socket 30 AND to the node's COM 8. TNCPORT COM=8 APPLMASK=2 ENDPORT b. This is the first port defined in the AUTOEXEC.NET file as one of your radio ports and corresponds to it. In this case it just happens to be a UHF port and is given the device name "uhf" in the attach line of the AUTOEXEC.NET file. The device name "uhf" is arbitrary. TNCPORT COM=9 TYPE=KISS KISSMASK=1 ENDPORT TNCPORT COM=10 TYPE=KISS KISSMASK=2 ENDPORT c. This is the second port defined in the AUTOEXEC.NET file and corresponds to it. This one just happens to be a 2M port and is given the device name "vhf" in the attach line of the AUTOEX- EC.NET file. The device name "vhf" is arbitrary. ***************************************************************** 4. Information for the AUTOEXEC.NET File: a. Attaching the Shared Ports: attach asy 0 8 ax25 uhf 1024 230 4800 attach asy 0 9 ax25 vhf 1024 230 4800 the above lines equate to two radio ports, defined as PORTNUM=1 and PORTNUM=2 (441.000, 147.570 respectively) and equate to the BPQCFG.TXT TNCPORT's COM=9 and COM=10, respectively. Note: The "asy 0" refers to the G8BPQ Node Software or "io addr 0". If you run more than two ports, they will also have to be "attached" in like manner and the number in AUTOEXEC.NET will always be one less than the port number in BPQCFG.TXT. b. Starting the protocol that allows the TELNET sessions to the BBS: start bbs This is the protocol added by N2GTE, which allows "telnet" connects to the BBS from TCP/IP stations. Telnet ses- sions to the BBS are made to socket 30 (syntax: telnet n2gte 30) and the user will get the messages "SYN sent", "Established", then a prompt for your callsign. After you enter your call, you will get the notice "Ok" from the node. Next, you will be connected to the BBS, unless all the BBS ports are busy. After you are through, you may issue a disconnect with the "b" command or issue an "O" command to go to the Node before disconnecting. c. To have the _mailGaTE_ functions of the BBS working the correct way, one must add the following lines to your autoexec.net file. What these lines actually do is covered on the NET docs. smtp gateway #<-- for _mailGaTE_ smtp mode queue #<-- for _mailGaTE_ d. Remember, true hostnames are required for SMTP to work properly, so ensure that your HOSTS.NET is arranged properly. The proper placement in the HOSTS.NET file is as follows: IP.IP.IP.IP hostname alias alias alias alias... #comments where the "IP" denotes the digits of the IP Address. The first name after the IP is supposed to be the hostname of whatever the other operator calls his host. For Example: 44.0.60.34 ka3dxx.ampr.org ka3dxx # George Stickler ***************************************************************** Section IV - GTEPMS Features and Special Notes from the Author: 1. N2GTE Comments on Multiple Forward Windows a. Practical experience has shown me that about three connects per freq is max that one station can handle at 1200 baud. If multiFWD were used, the SysOp MUST ensure they use different freqs; i.e. force Lv2 connections with designated ports (C 1 SEVBBS-1, C 2 W3IWI, C 3 NATCAP-1, etc). This would spread out the freq loading. This would be a SysOp responsibility. Can you imagine what 441.000 would be like if N2GTE FWDed to KA3DXX, WB3V, WA7NTF, and N4QQ at the same time? b. MultiFWD may not be the best uses of computer resources. Every TNC set aside by BPQ needs about 2 to 3K memory. That's not too bad and can be considered insignificant part of a 4Mb RAM pool. But the FWD window needs about 100K. Allocating about 400K of the approximate two to four Mbytes you have available for new windows IS a significant chunk. If a system is "gang FWDing" there could be little memory left for user windows. The SysOp should decide which is more important; FWD useless bulletins or servicing his loyal Users? c. Not only is memory required, but consider the time slice allocation also. That is something most people forget. They remember RAM and freq loading, but what about uP loading. This factor does not exist in non-multitasking system. Many people think about RAM-hogs and disk-hogs, but us multi-taskers must also consider the time-hogs (or things that may degrade perform- ance). In DESQview, each window is given a slice of uP time. What that window does with it is up to the window. If there is nothing to do, it should give the remaining mseconds back to DV so DV can immediately switch to another window. All DV-friendly programs do this. ALL GTE programs do this also. In fact, LISTER and RESOLVER are truely DV-specific programs and actually STOP executing until DESQview wakes them up with something to do. SO while idle, LISTER and RESOLVER do not even get their time slice handed to them. ALL other windows have something to do with the COM ports (PORTER, USER and FWD). Thus they can not go to sleep. Each time DV gives them a time-slice, they make a quick check for incoming characters. If none are waiting, they give up the remainder of their time. But as long as there are characters coming in (or going out during FWDing) those windows want all the uP time DV will give them. It has to be that way. You only get one shot at pulling a character out of the comm ports. Once you miss a character, it is gone forever, because the TNC (or DRSI) has already sent its ACK saying it RXed all ok. It did. The program simply failed to suck the data out of the buffer before overflow. This will probably never happen on a 386@16MHz or above, but must be considered from a programmer's standpoint. That is the only reason I mention it here. d. As I coded it , a FWD window will sense that another FWD using the same chore file and will immediately shut down. I did that on purpose. If a long FWDing session takes over an hour to complete, there has to be a hook to keep another window from trying to FWD to the same stations next cycle. e. With multiFWD, the SysOp has the ability to be in a constant (or near constant) state of FWDing. This could give one the reputation of being a channel hog. f. The USER window will REVerseForWarD to a BBS, thus actually changing itself to a psuedo-FWD window upon the "F>" command. With that consideration in mind, does one really need so many other FWD windows open at once? Every USER window has the potential of being a FWDing window, depending on the type of connection. 2. Lifetimes for Bulletins, Mail, and NTS Traffic: a. Personal Mail (SP type) and NTS Traffic (ST type) NEVER goes stale. It would remain for years if the sysop lets it. b. The following data applies ONLY to bulletins: - Bulletins received from other BBS's that arrive at an N2GTEPMS System are immediately marked as stale if they are over 14 days old. - A bulletin created locally will be marked as stale once it has aged over 14 days. - Stale bulletins older than 14 days (whether created locally or received from another BBS) are marked as killed. c. Killed Messages (whether SB, SP, or ST) are deleted from the system about 3 days after they were killed. d. These times are hardwired into the code and are life- spans recommended by W3IWI. These lifespan time frames will always remain hardwired in the BBS code of the N2GTEPMS System to assist the SysOp in keeping stuff too old to be useful out of the network. If a particular SysOp has a beef about that, then N2GTE recommends the SysOp choose another BBS code to run. 3. The Remote Service Request (RSR) Feature: The RSR feature will let one GTEPMS system poll another one in an attempt to "resolve" mail. This feature in a given GTEPMS System will automagically interact with other GTEPMS stations so that they will have the ability to share one another's Message Switch files. If LISTER and RESOLVER on one system can't figure it out, they will check with another GTEPMS station to resolve problem mail. RSR is built-in. The RSR is one of the main "selling" features of the Message Switch System; its ablility to share another system's resources. 4. Associated with MODEM.EXE are two environment variables the user can set. They are ECHO and PAGE. To turn them on, the user would type "SET ECHO ON" or "SET PAGE ON" (without quotes, of course). Turning them off should be intuitive. Typing "SET" by itself will display the current environment. All new modem uses have both defaulted to ON. What ECHO does should be self-explainitory. PAGE will allow only about 20 lines of text to flow, then it will stop until the user send a to continue, or an "A" (must be capitol) to ABORT the current action. 5. LOG's: The BBS now Logs into a directory off of the BBS root called \LOG - All logs will end up there. They are updated every 15 minutes, so be advised not to have them open in to viewer/word processor during "BEACONING" time. 6. FWDing is done, ST first, then SP, then SB. All queues are FIFO. 7. You should create a file called \PASSWD. It should contain one line of text. Case of the letter WILL matter when responding to a password challenge. You will be challenge when your own call connects to the BBS or when giving the SuperUser command "@" in MODEM. If the PASSWD file does not exists, then there will be no challenge. The challenge is in the form of the BBS sending you five numbers. These number represent random position within the line of text in the PASSWD file. You must respond correctly with the appropriate charaters or get disconnected. Example: BBS sends -> 5 26 32 2 50 Your respond with -> Tw.hq (note puncuation characters are also valid) Note: Your own callsign will not be challenge if you have place in your CONFIG.GTE file the variable PASSME=NO. 8. From the MODEM, a user can gain access to the BPQ switch. First the user must become a SuperUser by issuing the "@" command. The after passing the password challenge, he issues an "X" command (for "Xlink"). He will then be connected to the BPQ node and may do statuses and node listing; even further connect out the node. ***************************************************************** Late updates. The \STOPBULL. file -- Due to recent FCC action, N2GTE has added a feature to RESOLVER which will allow SysOps to automatically place selected bulletin distributions on HOLD. These held bulletins can NOT be FWDed, nor even viewed by Users. The SysOp must manually release these bulletins. The STOPBULL file simply contains a list of @BBS designators of what bulletins are to be held. To release these, the SysOp (from the console window) types RH (Release Held). He/she will then get to view each bulletin in-turn and decide on its fate. To release STALE bulletins, you must now use RS (Release Stale) and for BADBIDs (RB). My personal STOPBULL contains this: USA STOPBULL only works on Bulletins, SP and ST mail are NOT effected. ***************************************************************** Late Late Update -- To make the above STOPBULL feature more flexable, I have added a new variable to the CONFIG.GTE file. It is called STOPBULL=x, where x is a bit-significant value to control how the \STOPBULL. file will be used. Here is how it is broken down: STOPBULL bit# 2 1 0 | | \- Hold bulls ORGINATING at my BBS. | \-------- Hold bulls FWDed to my BBS. \---------------- Hold SB, SP and ST to/from a certain call. Thus: STOPBULL=0 will cause no action. STOPBULL=1 will stop only bulls in \STOPBULL. that ORIGINATE from your BBS. STOPBULL=2 will stop only bulls in \STOPBULL. FWDed to your BBS. STOPBULL=3 will stop both ORG and FWDed. STOPBULL=4 will stop only SB, SP and ST TO/FROM callsigns listed in \STOPBULL. STOPBULL=7 will do it all. Example: The \STOPBULL. file has this: USA WA3QNS and the CONFIG.GTE has STOPBULL=5 Thus all @USA orginating from my BBS will be held, plus all mail, be it any @BULL, or SP/ST, to/from WA3QNS will be held. I, N2GTE, DO NOT LIKE HAVING THIS FEATURE. IT GRATES AGAINST MY FEELINGS. But, I have included it to allow the SysOp more control over what goes out of his transmitter. ************************************************************************ APPENDIX A List of Files from the GTEPMS System GTE12.ZIP CONS.EXE DV-MAIL.DAT FWD.EXE FWDMOD.EXE GTERM21.EXE HADDR HEADERS.IMG HEADX.EXE LISTER.EXE MAKEDIR.BAT MODEM.EXE PORTER.EXE RESOLVER.EXE SERVNET.EXE USER.EXE HELPFILE.ZIP @ B D E F FTP HELP I INFO J K L M N O Q R S SET T U V W X READ.ME MDMBIOS.ZIP GTE1BIOS.COM GTE2BIOS.COM GTE3BIOS.COM GTE4BIOS.COM DV-PIF.ZIP GC-PIF.DVP GF-PIF.DVP GL-PIF.DVP GM-PIF.DVP GP-PIF.DVP GR-PIF.DVP GT-PIF.DVP GU-PIF.DVP GZ-PIF.DVP SAMPLES.ZIP BIDOK BULLETIN CHORE.10 CHORE.MDM CONFIG.GTE FWD LINKS MOD MOUNT PASSWD PORTER.CNF SPAWN STOPBULL SWAP BPQ359.ZIP 220KISS APPLS.DOC BPQCFG.EXE BPQCFG.TXT BPQCODE.EXE BPQDUMP.COM BPQDUMP.DOC BPQNODES.COM BPQNODES.DOC CHANGES.BPQ COMMANDS.DOC CONFIG.DOC DRSI.CFG HOSTMODE.DOC INT14.DOC JKISS JKISSCW.DOC JKISSP KISS KISS.CFG KISS.DOC KISSMODE.DOC NODEDRV.COM NOSBPQ.DOC PAC2.COM PAC2.DOC PASSWORD.BPQ PATCHID.COM QUAD.CFG SAMPLE.C SWITCH.DOC SYSOP.COM SYSOP.DOC WISHLIST GTE-NET.ZIP ALIAS AUTOEXEC.NET BM.EXE BM.RC FTPUSERS HOSTS.NET IP-PIF.DVP MAKENET.BAT NET.EXE NET-DOCS.ZIP ADVANCE.DOC APPEND1.DOC APPEND2.DOC APPEND3.DOC BM.DOC COMMANDS.DOC NETROM.DOC README.DOC SETUP.DOC TCPIP.DOC TESTDRV.DOC END OF APPENDIX A List of Files from the GTEPMS System ************************************************************************
