synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / modem.madness / SMMNETML / CN311-SW.ZIP / CIRCUIT.DOC < prev next >

Wrap

Text File | 1992-05-28 | 114.3 KB | 2,124 lines

Circuit Net Version 3.11 The Best Electronic - Net-Mail System For the Spitfire Bulletin Board System Version 3.11 T A B L E O F C O N T E N T S ------------------------------------------------------------------------ TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . 2 CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . 4 System Requirements . . . . . . . . . . . . . . . . . . . . 4 Setting Up Made easy . . . . . . . . . . . . . . . . . . . . 4 Configuration . . . . . . . . . . . . . . . . . . . . . . 4 Batch files . . . . . . . . . . . . . . . . . . . . . . . 6 Starting from scratch . . . . . . . . . . . . . . . . . . . 7 First things first . . . . . . . . . . . . . . . . . . . . 7 Configuration . . . . . . . . . . . . . . . . . . . . . . 8 Batch files . . . . . . . . . . . . . . . . . . . . . . . 11 Changing from node to host . . . . . . . . . . . . . . . . 14 Configuration . . . . . . . . . . . . . . . . . . . . . . 14 Batch files . . . . . . . . . . . . . . . . . . . . . . . 15 SYSTEM OPERATIONS . . . . . . . . . . . . . . . . . . . . . . 19 The Network . . . . . . . . . . . . . . . . . . . . . . . . 19 Processing Mail . . . . . . . . . . . . . . . . . . . . . . 19 Batch files . . . . . . . . . . . . . . . . . . . . . . . . 20 Mail transfers . . . . . . . . . . . . . . . . . . . . . . . 20 Communications programs . . . . . . . . . . . . . . . . . . 21 FILE EXPLANATIONS . . . . . . . . . . . . . . . . . . . . . . 22 Directories . . . . . . . . . . . . . . . . . . . . . . . . 22 CircuitNET directories . . . . . . . . . . . . . . . . . . 22 Mail Directory . . . . . . . . . . . . . . . . . . . . . . 22 Work Directory . . . . . . . . . . . . . . . . . . . . . . 22 System Directory . . . . . . . . . . . . . . . . . . . . . 22 SpitFire Directories . . . . . . . . . . . . . . . . . . . 22 System Directory . . . . . . . . . . . . . . . . . . . . . 23 Work Directory . . . . . . . . . . . . . . . . . . . . . . 23 Message directory . . . . . . . . . . . . . . . . . . . . 23 Work Files . . . . . . . . . . . . . . . . . . . . . . . . . 24 Mail Packets . . . . . . . . . . . . . . . . . . . . . . . . 24 Dossier Files . . . . . . . . . . . . . . . . . . . . . . . 25 CONFIG.EXE . . . . . . . . . . . . . . . . . . . . . . . . . 26 NODES File . . . . . . . . . . . . . . . . . . . . . . . . . 33 Packet compression . . . . . . . . . . . . . . . . . . . . . 33 PRIMER.EXE . . . . . . . . . . . . . . . . . . . . . . . . . 34 EXTRACT.EXE . . . . . . . . . . . . . . . . . . . . . . . . 34 IMPORT.EXE . . . . . . . . . . . . . . . . . . . . . . . . . 35 MAILCALL.EXE . . . . . . . . . . . . . . . . . . . . . . . . 35 APPENDIX A . . . . . . . . . . . . . . . . . . . . . . . . . 36 LICENSE AGREEMENTS . . . . . . . . . . . . . . . . . . . . . 36 STANDARD DISCLAIMER . . . . . . . . . . . . . . . . . . . . . 38 COPYRIGHT NOTICES . . . . . . . . . . . . . . . . . . . . . . 39 THE ANATOMY OF A MESSAGE . . . . . . . . . . . . . . . . . . 40 SpitFire Messages . . . . . . . . . . . . . . . . . . . . . 40 Circuit Net Messages . . . . . . . . . . . . . . . . . . . 40 APPENDIX B . . . . . . . . . . . . . . . . . . . . . . . . . 44 BASIC CONCEPTS . . . . . . . . . . . . . . . . . . . . . . . 44 APPENDIX C . . . . . . . . . . . . . . . . . . . . . . . . . 46 Source Code and Record Structures . . . . . . . . . . . . . 46 APPENDIX D . . . . . . . . . . . . . . . . . . . . . . . . . 47 Circuit Net Revision history . . . . . . . . . . . . . . . . 47 APPENDIX E . . . . . . . . . . . . . . . . . . . . . . . . . 48 APPENDIX F . . . . . . . . . . . . . . . . . . . . . . . . . 53 REGISTRATION INFORMATION . . . . . . . . . . . . . . . . . . 54 Circuit Net Upgrades . . . . . . . . . . . . . . . . . . . . 55 Registration Form . . . . . . . . . . . . . . . . . . . . . 56 END OF DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . 57 CONFIGURATION Configuring CircuitNET v3.11 has been made as simple as possible. CONFIG.EXE will allow you to setup not only CircuitNET files, but also make any necessary changes to the configuration of your Spitfire setup. System Requirements In addition to the obvious requirement of having an MSDOS or Os/2 v2.0+ based computer and a modem, you must also have Spitfire BBS software version 3.x, and some free space on your hard drive. The amount of free space depends upon the message traffic in the network you will be participating in. 10 Meg of free disk space should be more than sufficient to start with. As you get familiar with the volume of message traffic, the disk space requirements for your particular situation may turn out to be more or less than initially allocated. Setting Up Made easy: **** IMPORTANT NOTE ***** The following sections are divided into two areas that contain instructions for specific situations. The instructions are written in checklist form and should be folloId step by step. ********************** Step one: Choose the ONE of the following sections that applies to your situation, and follow the instructions step by step. *** IMPORTANT NOTE *** SEEDING of conferences is NOT NECESSARY, and only clutters the network with meaningless messages. CONFIG.EXE will seed any conferences created with non-net-mail messages. ********************** Starting from scratch This section is for those setting up CircuitNET for the First time. If you are setting up a second CircuitNET based Network, refer to the section on multiple copies first. First things first **** IMPORTANT NOTE *** CircuitNET Software is intended for use with an established network. The BBS from which you obtained the original information should be able to provide you with the information you will need to properly install the software. If the BBS that provided you with the software cannot help you, then contact any node of the network you wish to participate in for the name of that network's secretary, and contact the network secretary to get assigned to a host whose job it will be to provide you with the necessary information. If you intend to start a new network, then contact Dave Stahl at the address or number given in the registration information appendix. ********************** Before setting up CircuitNET Software, you will need the following information and files from your host: 1) A Node Id. This is a 1 to 8 Alpha-Numeric designation by which your BBS will be identified to the software, and to the network. 2) HOST Node Id. You will need this to tell the software what to name your outgoing mail packets. 3) A current list of conferences available and/or required for you to carry. 4) A copy of the Network Charter, Bylaws, or Rules for the network you are joining. 5) Instructions on how and when to make your mail transfers. In most cases, this will include a special logon account for your BBS to use when calling for mail. 6) Sample scripts for unattended transfers. Or the information required for building a suitable script. (Some sample scripts are included in the CircuitNET distribution packet, but I make no guarantee as to their suitability for any specific host.) Configuration Now that you have the information you need from your host, you are ready to start the installation. You may now turn the page and begin. 1) Using DOS or your favorite disk management utility, create a directory named CIRCUIT. Normally this would be a sub- directory of your Spitfire System directory, but it need not be. If you plan to dedicate a drive to CircuitNET operations, you can use the root directory as your CIRCUIT directory. (If you choose a directory that is not a sub- directory of your Spitfire System Directory, you will be prompted for the path to an SFNODES.DAT file.) 2) Unzip *.EXE from your CircuitNET distribution file into your CIRCUIT directory. If you have not already done so to unzip the files, make your CIRCUIT directory the current DOS directory. 3) Enter CONFIG or CONFIG COLOR to invoke the CircuitNET Configuration Utility. You will be presented with a series of questions before you reach the main menu, and will be told that several directories Ire not found. You either need to tell the program to (M)ake them, or (R)e-enter the name of an existing directory. The default names will identify the purpose of the directory that could not be found. At a minimum, the Circuit\Work, and Circuit\Mail directories should need to be created. (Note: Config cannot (M)ake two directories at once. If a two deep directory is required to be created, you will have to (M)ake only the first at this point, and change the path later in the configuration process.) 3a) Are you a HOST Node (Y/N) N Press Enter to accept the Default of NO. (You should not be in this section if you are a host node. If you are one of those rare cases of a a node joining the net and hosting another new node, then you have my sympathy, and should ansIr Yes, and then skip the CONFIG portion of "Converting from a node to a host.) 3b) Do you want Primer to mark old messages for deletion? Y Press return to accept the default of Yes. This will cause Primer to check for messages older than the old message value configured for each conference as it searches for Net-Mail messages to send. If any are found, they will be explicitly marked as deleted, just as if you had deleted them from within Spitfire, so that the next purge of the message base will purge them. AnsIring No to this prompt will cause Primer to ignore old messages, and only consider the net-mail status as it scans each message conference. 3c) Keep History for how many MSG/Conf (512..2048) 1024 Press enter for the default history size of 1024. You will be able to change this value later if you develop problems with duplicates or incomplete threading, or have consistent out of memory problems with IMPORT. Read the section on system operation for details on when it should be changed, and what effects changing it will have. 3d) Enter BBS Phone number This entry is used to display your phone number in the tagline of messages originating on your BBS. (It is prefixed by the word 'Phone: ' when the tagline is built.) 3e) Enter BBS Name This entry is also used to build the taglines for messages originating from your BBS. It is intended to provide the network users with some idea of where in the world each message came from. (Consult the network rules provided by your host to see if the network you are joining has some rule concerning the information to be put in this field.) 3f) (REGISTERED COPIES ONLY) Enter Your Location or Motto This is also used to build the tagline, but is only displayed in registered versions. The shareware version uses this field to identify unregistered nodes. 4) You should now be presented with the Main Menu for CONFIG. Select (M) to configure the message conferences. This will link the names from the Conference list provided by your host with specific Spitfire conferences. All of the information displayed, save the conference codename, is taken from your SpitFire SFMCONF.DAT, and will Update Spitfire's configuration when you (Q)uit this menu and select (Y)es when asked to save the changes. The Conference Codename field will be written to a file named CNCONFS.CFG in Your CIRCUIT Directory. When the conferences are saved, all conferences are automatically seeded with a non-net-mail message, and the SFMSGxx.LMR files are updated to SpitFire 3.2 standards. (Spitfire 3.1 has no problems with this.) 4a) You are presented with the display for Conference Number 1 of nn, where 'nn' is the total number of conferences configured. Using the '+' and '-' keys you can step through the conferences and set those that will be assigned network codenames to "Net-Mail conference = TRUE". As you change the net-mail status to TRUE, select (C)odename and enter the network conference name that is to be associated with the conference. All of the fields, EXCEPT the Codename field are explained in the Spitfire documentation. All of the fields are covered in the section on CONFIG.EXE also. Conference codenames are explained in detail in the System Operations section under "the Network". 4b) ADDING Conferences: When you have exhausted the conferences which Ire originally configured in SpitFire, you can add more as required, up Spitfire's maximum of 255. Conferences are always added as the LAST conference. The new conference is automatically identified as a net-mail conference, and needs only a CodeName to be completely configured as a network conference. 4c) DELETING Conferences: When you select (D)elete a conference, the LAST conference will be displayed, and you will be asked if you wish to delete it. CONFIG will only delete the last conference, and it DOES NOT delete the SFMSGxx.* Files associated with the conference being deleted. Deletion of the files must be done at the DOS level. 5) Select (Q)uit when you have configured the conferences you wish to echo with the network, and hit enter to save the changes to BOTH Spitfire and CNCONFS.CFG. *** MULTIPLE NODES TAKE NOTE *** The SFMCONF.DAT file is only updated for the node which CircuitNET uses for finding the Spitfire information it needs. If you have multiple nodes that share a message directory, you will need to copy the modified SFMCONF.DAT to the other nodes if you wish them to have access to any added conferences, and any changed descriptions. ******************************** AT this point, CircuitNET and SpitFire are configured for echoing messages to and from the network manually. Meaning that you can now use Primer, Extract and Import from the DOS command line to build and process mail packets. A rather cumbersome and usually erratic means of day to day net-mailing. So you need to automate the process through batch files. Batch files In order to automate your mail transfer, you will need to configure a scheduled event to invoke Primer and Extract, invoke a communications program to exchange mail packets with your host, and then invoke Import. The sample batch file NODEVENT.BAT included in the documentation package contains all of the required commands to automate your mail transfers. Your host should be able to tell you what modifications need to be made to the script files to log on to his system. ***** NOTE ***** The examples and explanations below use TELIX only as an example because that is the communications program *I* use, and am familiar with. Any communications program that can be invoked in a batch file and run a script unattended can be used. Sample scripts contributed by various nodes in CircuitNET International are included for other communications programs. 1) Choose an event in the SF.BAT file that controls the node CircuitNET is configured on. (If your system is controlled by a front door program, you can configure CircuitNET as an External event for the front door program.) :EVENT_A is chosen for this explanation. 2) Using an ASCII Text editor, read in the file NODEVENT.BAT betIen the :EVENT_A label, and the GOTO LOOP command, and edit the paths to conform to how your system is configured. (If you aren't using TELIX, you will need to replace the lines that call TELIX with the appropriate commands for your communications program.) 3) Configure your communications program to upload and download from the CIRCUIT\MAIL directory. In Telix, make a dialing directory entry for your host's BBS. The script to link is CNMAIL, and the password must be entered. (The sample Telix script obtains the password from this entry.) 4) Enable the event chosen to run at the time your host has scheduled your mail run. *** NOTE *** If you are going to use a two call system, then the event needs to be broken into 'send' and 'receive' events. The line by line explanation of NODEVENT.BAT below identifies where the break would need to be made. Separate scripts would be used for the send and receive calls to the communications program, and in Telix two dialing directory entries would be needed. The NODEVENT.BAT Explained: :EVENT_A ECHO OFF C: CD \SF\CIRCUIT\MAIL REM Change to mail drive and directory to keep filenames REM shorter on the command lines. IF EXIST HOSTNODE.ZIP PKUNZIP HOSTNODE REM If the file hasn't been renamed later in this event, REM it wasn't sent. so unzip it to append the new mail to REM the existing packet. C: CD \SF\CIRCUIT REM change to the drive and directory where CIRCUIT.CFG is. PRIMER REM Primer does NOT have to reside in the current directory. REM It may be in the PATH, or invoked with a full pathname. REM this applies to all of the CircuitNET programs. EXTRACT /Node=HOSTNODE REM This command line format extracts to a single node, and REM bypasses the NODES file. *** NOTE *** From this point to the GOTO LOOP would be included in the Receive Mail event for a two call system. The dialing script would be changed to DIAL2.SLC to dial the entry with the download mail script in place of the upload mail script. ************ C: CD \TELIX REM Change to the drive and directory of your comm program. REM Telix is configured to upload and download from the REM CIRCUIT\MAIL directory so moving files is not required. REM If your communications program is NOT configured to REM upload and download directly from the CIRCUIT\MAIL REM directory, then HOSTNODE.ZIP needs to be copied to the REM appropriate directory. TELIX /SDIAL1 REM This line tells Telix to start up and run the script REM 'DIAL1.SLC'. The script dials entry number 1 in Telix's REM dialing directory, and turns over control to the script REM linked to that entry when a connection is made. The REM DIAL1 script provided redials indefinitely, but can be REM configured to try a limited number of times if desired. C: CD \SF\CIRCUIT\MAIL REM Change back to the mail directory to shorten pathnames. IF ERROR LEVEL 1 GOTO NOT_SENT COPY HOSTNODE.ZIP HOSTNODE.DB4 DEL HOSTNODE.ZIP :NOT_SENT REM This error trap will rename the file to indicate that REM your comm program did not encounter an error sending the REM file. Save the file rather than killing it long enough REM to give your host a chance to request a resend if needed *** NOTE *** At this point, a GOTO LOOP would be inserted to end the send mail event for a two call system. The receive mail event would start at the preceding note, and include the following commands. ************ C: CD \SF\CIRCUIT REM Change back to the drive and directory where CIRCUIT.CFG REM is located. IMPORT REM Import the mail downloaded from your host. If there was REM no mail, Import will detect that, and log the REM information in the status report, and the log file. GOTO LOOP There is nothing that prohibits other commands from being included in the event such as bulletin generators to notify your users when the new mail has arrived, or prohibits removing redundant commands (such as changing drives if you have everything on the same drive.) This is simply a *generic* event for you to build upon. If you wish to link your mail event to the internal message packing event, you would put these commands in SFMSGPAK.BAT which executes following Event M if it exists. Changing from node to host Configuration There is one change needed in your CircuitNET configuration for hosting from a single node, and one additional text file named NODES, and one additional program that requires configuration. i.e. MAILCALL If you have multiple nodes, refer to the section on Multi Node operations. 1) Invoke CONFIG, and go to the sub-menu for (B)BBS info, and change the HOST BBS flag to TRUE. And save the changes. 2) In the CircuitNET system directory, create a text file named NODES, which contains the node id's of your dependent node(s). 3) Change to the CircuitNET system directory and invoke MAILCALL EDIT. (A)dd records for each of your dependent nodes using the name they will be logging on under, and the full name of the packet file to send to them. Refer to Mailcall.Doc for more about editing MAILCALL.DAT. Batch files There are Two additional batch files, and two changes to your existing event required to host another node. 1) Changes to your existing event: a) Following the IMPORT command line add the following commands: EXTRACT LOCK REM The LOCK parameter is required on the last EXTRACT REM of the event as it it not automatically selected as REM it is when HOST is configured as FALSE. IF ERROR LEVEL 133 GOTO SINGLES REM Error level 133 is returned if EXTRACT does not find REM enough disk space to extract for all of the nodes REM listed in the NODES file. If Error 133 is REM encountered when extracting for a single node, REM files will need to be deleted to make room. See REM the troubleshooting section for more info. :RESUME REM The Resume label is only needed if there Ire REM existing commands betIen the IMPORT and GOTO LOOP GOTO LOOP :SINGLES EXTRACT /Node=firstnode EXTRACT /Node=secondnode EXTRACT LOCK /Node=LastNode REM Replace "firstnode", "secondnode", "lastnode" with REM the nodes listed in the NODES file. Each node REM added later to the nodes file, would require a REM corresponding command line under the :SINGLES label. GOTO RESUME REM Could be GOTO LOOP if :RESUME wasn't needed. b) Following the IF EXIST HOSTNODE.ZIP ... Statement at the beginning of the NODEVENT.BAT commands, add corresponding IF EXIST NODEID.ZIP PKUNZIP NODEID commands for each node id in the NODES file. The batch file(s) that send the packets will be responsible for renaming the packets if successfully sent. 2) SFINIT.BAT file: This Batch file executes before Spitfire resets for the next caller. The following commands need to be added to check for an uploaded mail packet from a dependent node, and import it. IF NOT EXIST C:\SF\CIRCUIT\MAIL\YOURNODE.ZIP GOTO NOMAIL REM Skip over the import command is there's no mail C: CD \SF\CIRCUIT REM Go to the directory with CIRCUIT.CFG IMPORT REM Import the mail Refer to the Troubleshooting section for REM details on error levels returned for error trapping if REM desired. :NOMAIL REM continue with your existing SFINIT.BAT file, or return REM control to Spitfire. 3) SFSECxx.BAT file: This batch file executes as soon as a user with a security of 'xx' logs on. Most hosts have a specific security level for their dependents nodes when the call for mail. (The dependent BBS's have a separate user account from their sysop's account under their node ID.) This makes SFSECxx.BAT the ideal place for mail pickups. This is by no means the ONLY setup for distributing the mail to your dependents. SFMESS.BAT, SFMAIN.BAT, SFFILE.BAT, an unused :DOOR_x label in SF.BAT, or a frontdoor program can all be used to accomplish the goal of sending the right packet to the right node. The simplest method would be to simply configure the CIRCUIT\MAIL directory as one of Spitfire's file areas, and let the nodes download and upload their packets as they would any other file. ECHO OFF COPY SFDOORS.DAT C:\SF\SFEXTEND\SFDOORS.DAT :LOOP C: CD C:\SF\SFEXTEND SFMNUEXT IF ERROR LEVEL 48 GOTO EXTENDZ ... REM Most of the IF ERROR LEVEL statements removed to save REM space as only 0, 1, 2, & 4 are used for mail REM transfers. Refer to SFEXTEND documentation for REM information on setting up extension A for downloading REM mail, and Extension B for uploading mail. IF ERROR LEVEL 6 GOTO EXTENDC IF ERROR LEVEL 4 GOTO EXTENDB IF ERROR LEVEL 2 GOTO EXTENDA IF ERROR LEVEL 1 GOTO LOOP IF ERROR LEVEL 0 GOTO END :EXTENDA MAILCALL C:\SF\EXTERNAL\SFEXTDNA.BAT REM The batchfile specified on the command line does not REM need to be one that Spitfire normally uses for external REM transfer protocols, only one that can make use of the REM same parameters as Spitfire passes to it's external REM protocol batch files. The batch file used should check REM for a successful transfer, and rename the packet to REM indicate it was picked up. Refer to MAILCALL.DOC for a REM more detailed explanation. IF ERROR LEVEL 250 GOTO FATAL_A IF ERROR LEVEL 2 GOTO LOOP IF ERROR LEVEL 1 GOTO NOMAIL REM Refer to MAILCALL.DOC for details on these and other REM error levels it returns. Suffice it to say that all REM fatal errors are greater than 250, error 2 is "User not REM in Mailcall.dat", and Error 1 is "Mail packet not found REM to send." GOTO LOOP REM Fall through to here is packet was sent successfully. :NOMAIL C:\SF\EXTERNAL\DSZ port 2 sz -mrr NOMAIL.ZIP GOTO LOOP REM This sends a very small file named NOMAIL.ZIP to REM indicate that the lack of mail was not a failure of the REM dependent's event, but rather there was no packet built REM for that day. :EXTENDB CD C:\SF\CIRCUIT\MAIL C:\SF\EXTERNAL\DSZ port 1 rz -mrr GOTO LOOP REM Receive file directly into The CIRCUIT\MAIL directory. REM You may wish to add commands to make a copy in a safe REM place if you are of the paranoid persuasion. :END *** NOTE *** In addition to setting up your system to function as a HOST you must also assist your dependent nodes with Scripts, conference listings, network rules, and provide any other information they may need to reliably echo mail from your board. Echoing from your system will be subtly different from echoing with any other Host, and this documentation cannot anticipate your unique situation. ************ SYSTEM OPERATIONS This section is an overview of various aspects of CircuitNET software operations. The appendix on Basic Concepts is a detailed discussion of netmailing in general, and CircuitNET software based networks in particular. The Network A CircuitNET Software based Net-Work is inherently a tree structured system. The software assumes that there is one and only one path to any other node in the network. The structure consists of one ROOT node, (Generally referred to as the "National Host" or "National Hub"), Several HOST nodes, and END nodes. The ROOT and HOST nodes are "way-stations", or "switching stations" for network messages, and store messages that are "in transit" and distribute them to more than one other node. END nodes only exchange messages with their HOST. In addition to the technical limitations that mandate a tree structure, the administrative body of each network may have other requirements that affect the network structure, and where your BBS fits into that structure. Processing Mail There are three stages of processing involved in CircuitNET software. Conversion from the BBS's message format to CircuitNET format, Sorting of messages in CircuitNET format into transfer packets, and converting messages from CircuitNET format back into the BBS's message format. These functions are performed by PRIMER.EXE, EXTRACT.EXE, And IMPORT.EXE respectively. PRIMER: Primer's function is to identify messages flagged as net-mail in the BBS's message area, and convert ones that haven't already been sent into CircuitNET format. It checks each message for routing information in the subject field, and determines if the message is routable. If the message can be sent, Primer assigns it a unique network number, identifies the thread it is part of, (if applicable), and adds the node of origin and destination (if routed). The message is then added to any other "in-transit" messages in the work directory to be processed by EXTRACT. Once PRIMER has converted a message to CircuitNET's format, CircuitNET considers it to be "In-transit" until it reaches an end node, or it's destination. EXTRACT: Extract selects messages from the "in-transit" holding area, and builds one or more transfer packets. It performs several tests on each message to determine if it should be included in a specific packet. The tests include checking to see if the origin or last seen nodes are among the nodes accessible through the node the packet is for, checking to see if it is routed to a node accessible through the node the packet is for, and checking that node wants the conference the message is for. If the message passes all of the tests, then it is included in the packet. If it fails anyone of them, it is ignored. IMPORT: Import checks each message it processes against a history file to reject any duplicate messages. It also determines which BBS message conference the message belongs in, and assigns the message to one of three categories. The message has reached it's final destination, it is "just passing through", or It's both. In the case of an end node, There is nowhere to pass a message on to, so import ignores messages that would otherwise be "just passing through". For Host nodes, messages which haven't reached their final destination, are added to those in the holding area, and messages which pass the tests for being converted to the BBS's message format are added to the appropriate BBS message area. Batch files CircuitNET software is designed to work in and in conjunction with batch files. This gives a great deal of latitude in the way CircuitNET works on any particular BBS. Very basic batch files are provided as samples, but CircuitNET also provides a multitude of Error level exit codes that can be tested in batch files. I leave it up to your imagination and the list of exit codes as to how you make use of them. Mail transfers CircuitNET Software does NOT contain any communications routines, and does not concern itself with how the transfer packets are moved from one node to another. The utility MAILCALL.EXE is provided as a means of matching a caller with a packet file, but even there, the actual file transfer is accomplished by a batch file based on Spitfire's External protocol batch files. Sample batchfiles, and sample scripts for some of the more common communications programs are provided to assist you in transferring the mail, but are not the only way the transfers can be accomplished. The means of transferring the mail packets must be co-ordinated with your host, and any means that can be agreed upon is the means that should be used. Communications programs CircuitNET software does NOT contain any communications routines. It relies upon your choice of communications program to transfer the files from one node to another. As of this writing, the three most common programs used to transfer mail packets are Telix, Qmodem, and DSZ.COM. DSZ is generally used in conjunction with Mailcall in a host configuration where a phone call is ansIred, while Telix, QModem and other terminal packages are generally used where a phone call must be made. Some Hosts have Front End programs which allow "FREQ'ing" a mail packet if you have that capability, but a front end is NOT required for CircuitNET. Any Communications program that is capable of making an unattended phone call from a batch file will do. The fact that the Author of this document uses Telix in the examples is not to be construed as an endorsement of Telix as the preferred means of transferring the packets. It is merely the program with which the author is most familiar. FILE EXPLANATIONS Directories CircuitNET Software needs to know where certain files are located, and expects certain files to be in certain directories. The following is a discussion of what directories CircuitNET Software utilizes, and what each directory is utilized for. CircuitNET directories These are the directories that are peculiar to CircuitNET. Mail Directory The MAIL directory is where EXTRACT.EXE builds the message packet(s). It is also where MAILCALL.EXE will look for the filename you specify to be sent to a specific username. Normally you will see only files with a Node Id for a name and the extension '.ZIP', but during execution of EXTRACT.EXE a .CND and a .CNP file will be built for each node being extracted for, plus PKZIP will normally use this directory for it's temporary file while zipping the packet. A good estimate of the amount of space required in this directory, is to multiply the file sizes of the finished packet(s) by 3 to get the amount of space that needs to be free in this directory for EXTRACT to do it's job. Work Directory The WORK directory is where "Messages In-Transit" are held, and where IMPORT.EXE unzips incoming packets to. For a Host node, there will normally be two files in this directory named MESSAGES.CND and MESSAGES.CND. For an end node, the files only exist from the time that PRIMER.EXE runs until EXTRACT.EXE is done building the packet for the host. While IMPORT.EXE is importing messages, there will also be a CND and CNP file with your Node Id as a filename. Import deletes then when it is done with them. System Directory The CIRCUIT or System directory, is where the Dossier Files, outbound history files, CNCONFS.CFG, and CNROUTES.LST are stored. It is normally also where CIRCUIT.CFG and the executable files are kept, but it is not absolutely necessary that they be kept there. The CIRCUIT.CFG file in the current DOS directory will be used when each module is invoked, and the directories defined in the CIRCUIT.CFG file will be used. SpitFire Directories Since CircuitNET is designed to work directly with the Spitfire message base, it needs to know where some of Spitfire's files are to be found. System Directory CircuitNET uses Three (3) files in the Spitfire system directory. SFMCONF.DAT, SFNODE.DAT, and SFDOOR.DAT (or equivalent). SFMCONF.DAT and SFNODE.DAT are used by CONFIG.EXE which also uses the SpitFire WORK path from SFNODE.DAT to find SFSYSTEM.DAT in order to initialize the Sysop names, and obtain the number of users alloId. SFMCONF.DAT is updated by CONFIG.EXE with any changes made in the message conference configuration menu. PRIMER.EXE uses SFMCONF.DAT to get the old message purge date for each net-mail conference if PRIMER is to kill old messages. PRIMER ignores SFMCONF.DAT if the kill old message feature is turned off. SFDOOR.DAT or one of the equivalent files is used by MAILCALL.EXE to select the mail packet to be sent, and find the parameters needed to be passed to the batch file which does the actual transfer of the file. Work Directory As stated above, this directory is only used by CONFIG.EXE, and is obtained from SFNODE.DAT. Message directory Spitfire's message directory needs to be know for obvious reasons. Other than messages, PRIMER and IMPORT both 'lock' this directory by creating a file named WORKING.CN while they are processing messages. The file should only exist while PRIMER or IMPORT is running, and should be removed when they are complete. Both PRIMER and IMPORT work with a history file for each CircuitNET conference with the extension '.HST', plus SFMSG00.HST for "other" conferences. Work Files The two files named MESSAGES.CNP and MESSAGES.CND in the CircuitNET WORK directory are a holding area for "Messages In- Transit". A message is considered In-Transit from the time that PRIMER converts it to CircuitNET format, until it reaches it's final destination. Each node it passes through, (including the node it originated on), collects one mail cycle's worth of messages in the work files, until EXTRACT has processed them to all nodes being serviced. For an End node, only the messages that PRIMER copies from the Spitfire message base are involved, and only for as long as it takes for EXTRACT to process them. For a Host node, the work files are a little more important. As the messages from each dependent node are imported, any have not reached their final destination, (i.e. messages routed TO: the host node), and are not rejected as being duplicates, are added to the work files. PRIMER adds any messages entered locally, and then EXTRACT builds outgoing mail packets from the work files. When the last packet in the mail cycle has been built, EXTRACT deletes the work files so the cycle can begin again. Mail Packets A Mail packet is essentially a "copy" of the work files with unwanted conferences, and duplicate messages purged out. Each packet is a compressed file containing a .CND file, and a .CNP file. CircuitNET Software is constructed to use PKWare compression utilities, although it is possible to use other compression utilities by use of batch files named PKZIP.BAT and PKUNZIP.BAT provided the extension '.ZIP' is used so IMPORT.EXE will recognize the presence of a packet. History Files CircuitNET 3.11 changes the duplicate rejection scheme from prior releases. The change involves the use of history files which have the extension of '.HST'. There are Three different history files used, of two different types. There are the conference history files, and the node history files. The Conference History files are kept in the SpitFire message directory. There is one for each conference used by CircuitNET, and one for all conferences that are NOT carried by the node. SFMSG00.HST is the name used for the "all others" history, and SFMSGxx.HST is matched to the rest of the SFMSGxx.* files for the conferences carried by the BBS. The conference History file size is controlled by the "Max History per Conference" value configured in CIRCUIT.CFG. Once the maximum number of history entries for each conference is reached, (Or double the Maximum for SFMSG00.HST), each new message Primed or Imported replaces the oldest history record in the file. Primer does NOT do any duplicate rejection on outbound messages, and only records the history information for threading purposes. Import checks each incoming message against the appropriate history file and rejects duplicates and links threads based on the information therein. Obviously the more history kept, the better the duplicate rejection, and the more complete the threading. On the down side hoIver, the larger the history file, the sloIr Import runs, because of decreased memory available for processing large blocks of incoming messages at one time. The NODE history files are used for outbound duplicate rejection. One is created for each node extract builds a packet for, and kept in the CircuitNET System directory. The file Size is not as rigidly controlled as the conference histories, and purging of old history records is based on the number of days since the message was sent. The number of days history to keep is derived from the Maximum History value that controls the size of the conference history files. The Maximum History value is divided by 64 to give a minimum of 8 days history, and a maximum of 32 days. (The number of days is rounded down to the nearest integer value.) Only messages which pass all other tests for inclusion in a mail packet are checked against the node history file to see if it has already been sent to that node. Then all messages are added to the history file with the date they Ire sent. (Rejected messages get added with a new date to prevent problem messages from ever being resent.) (Note: Incoming messages from a node are NOT included in the node history file as they should never pass the tests for inclusion in the packet in the first place.) Dossier Files Each node messages are extracted for needs a dossier file in the CircuitNET System directory with the conferences that are to be echoed to that node. IMPORT.EXE will add any new conferences it sees to the Dossier file for the node that built the packet, and EXTRACT.EXE will add conferences if it finds a message routed through a node that doesn't already have that conference in it's Dossier. Import will also delete conferences from a Dossier file if it encounters a message that requests such deletion. Extract never deletes conferences from dossier files. WORKING.CN Both Primer and Import manipulate the conference history files by reading them into memory, and then re-writing the entire file when done with it. In order to prevent multiple copies of Import from trying to update the same history file or Import and Primer from writing contradictory changes to the same file, a 'key' file is used to lock the entire Spitfire message directory from use by more than one CircuitNET module at a time. The File is named WORKING.CN, and Primer and Import both will look for the file before they begin processing. If it doesn't exist it is created to lock out another module from starting, and if it does exist, the program will pause in a loop for 10-15 minutes checking for the file every few seconds. If the file is removed before time runs out, then the program replaces it to claim the message directory and proceeds with processing, or it puts a notice in the status message that it encountered the key file which didn't clear in the allotted time. CNROUTES.LST CircuitNET provides the capability to 'route' messages to a specific node. In order to know which packet a routed message should be included in, it refers to CNROUTES.LST. This file is a pure ASCII text file, with <Destination>,<node_to_Route_through> on each line. IMPORT.EXE builds this list by looking at the true origin, and last node to process each incoming message. Every packet imported is used to build a new list in memory, and when the entire packet has been processed, any existing routing list is compared to the new list in memory, and Destinations not represented in the packet processed are added to the new list in memory. Once the new information and the old (unchanged) information is combined in memory, the entire file is over- written with the new list. IMPORT has no way of knowing how long it has been since a message was received from a specific destination, and whether none have been received because the node is no longer active or just didn't have any message traffic for that day, so it NEVER deletes a destination once it has been added. Deletions must be done manually with a ASCII text editor periodically as node numbers are changed because of registrations or moves, or for nodes that drop out of the network. Inactive nodes present no particular problem other than taking up space. CONFIG.EXE Config is how you maintain CircuitNET's configuration file. Config defaults to a White on Black color scheme, but will accept the command line parameter 'COLOR' to switch to a White on Blue color scheme for those who prefer less contrast. Config automatically selects one of four possible operating modes, based on what files it can find when invoked. Config first looks for an existing file named CIRCUIT.CFG in the current DOS directory. If the file is a version 3.0x format file, config automatically converts the file to 3.1x format, and asks for the additional information needed. Otherwise it goes directly to the main menu. If config doesn't find CIRCUIT.CFG it looks in the parent directory of the current DOS directory for SFNODE.DAT. If it is not found, Config will ask where SFNODE.DAT can be found. Once it finds SFNODE.DAT, it looks for SFSYSTEM.DAT and asks for directions if it cannot be found. Using the information from SFNODE.DAT, and SFSYTEM.DAT and some default directory names, CONFIG will ask if you want each directory it can't find Made or Re-entered, or if you want to abort Config. It will then ask several questions, (with suggested responses for everything except Node Id), and eventually deliver you to the main config menu. The Main Menu: Since all possibilities eventually lead here, I guess I should explain what's going on here. The main menu presents you with 4 choices: [C] - Configure CircuitNET Information. [M] - Configure/Add Message Conferences. [S] - Configure Spitfire (Sysop Names/net-mail Toggle) [Q] - End the Program The Quit option should be pretty much self explanatory, so I'm just going to ignore that one, but since I'm at the bottom of the list I'll go backwards. [S] This will take you to another menu with 6 choices: [R] - Sysop Real Name: The name you put here, (and save to CircuitNET), is the name which will appear on your messages in the network. It is also the name that IMPORT.EXE will look for and swap back to your sysop logon name. [U] - Sysop User Name: The name that appears here, is the name that Primer will look for and change to the name above on messages it puts into the network. This is also the name that "Sysop ALL", "Sysop <NodeId>", and the name above will be converted to by IMPORT.EXE. It should therefore be the name you normally log on to the BBS with, (or your mail door uses to determine which messages are TO: You) [N] - net-mail will be used: Should be True if you want people to be able to tag messages for net-mail. If it's False, you will be able to import network messages, but won't be able to send any. [S] - Save Changes to Spitfire Only SFSYSTEM.DAT will be updated to the values shown. CIRCUIT.CFG will remain unchanged (Unless saved later from the [C] - Configure CircuitNET Info menu. This should therefore be the LAST changes you make if you do not want Spitfire and CircuitNET to agree on the Sysop's Real Name. See note to SFMail users below) [C] - Save changes to CircuitNET The Sysop Names displayed will be saved into CIRCUIT.CFG only without changing the values used by Spitfire. (See the note below if you use SFMail.) [B] - Save changes to both SpitFire and CircuitNET The values displayed will be written to both CIRCUIT.CFG and to SFSYSTEM.DAT. NOTE to SFMail users. The author of SFMail keys the registration to the "Sysop Real Name" saved to SFSYSTEM.DAT. If you wish to be known by an alias in the network, and log on the the BBS as "Sysop", (or a different alias than you want shown in the network), then you need to NOT use the [S] option or the [B] option, and only save changes to CircuitNET. Doing otherwise will either cause SFMail to crash, or cause the name you registered SFMail under to be used on the network. To return to the Main Menu select Q for Quit. [M] - Configure/Add Message Conferences The menu displayed when you select this option is basically the same as that displayed by ALT-R from the spitfire "Ready for use" prompt. Therefore I will only cover four of the options which either don't exist, or function differently than the SpitFire ALT-R menu. [#] - Conf Access Type: The only difference here is the notation. SpitFire Spells out "Equal to user security", and "Equal To Or Greater Than User Security", while Config uses Either the mathematical symbols '=' or '>=' for "Equal to" and "Greater Than or Equal To". The function is the same, but the symbols Ire used to save space on the display. [A] - ADD a conference [D] - DELETE a conference. Both the Add and Delete Functions only work on the highest numbered conference. Inserting a conference or removing a conference from the middle of the file is not supported. With large numbers of conferences, properly inserting a conference, or removing one from the middle involves a great deal of time in moving files to keep them in synch with the conference descriptions. Config will automatically seed new conferences, and update all .LMR files to match the SpitFire 3.2 standard. It does NOT hoIver do the reverse, and delete the conference files along with the conference description. The files are left intact so that they can be renamed to a new conference number if the description they match was moved to a new record. Deleting and re-adding a conference will therefore NOT remove messages which do not match the new description. *** IMPORTANT NOTE *** DO NOT, repeat DO NOT insert or delete conferences through Spitfire! Doing so will cause the conference codenames to be shifted away from the matching descriptions. The codenames are stored in a parallel file which matches SFMCONF.DAT record for record. If you need more conferences added to Spitfire, CONFIG can add non-CircuitNET conferences simply by leaving the Conf. Codename field blank. ********************** [C] - Conf. Codename: This option updates a separate file from all of the other fields shown on the Conference Configuration menu. CNCONFS.CFG is kept in the CircuitNET System directory, and matches the SFMCONF.DAT record for record. If this field is 'NC' (meaning 'Not Configured'), or Blank, then CircuitNET ignores the conference. Any other Alpha-Numeric entry will be treated as a network conference codename. (The name by which the conference is known to the software.) As only upper case information is accepted, case is not critical. and spaces will be stripped out. Spelling hoIver is important! If you mis-spell the codename assigned to a conference, then you have effectively created a conference that only you carry, and one BBS is not much of a network. When you have made all necessary changes to your message conferences, press Q to quit, and you will be asked if you want to save the changes. 'Y' or <Enter> will write all changes to SFMCONF.DAT, and to CNCONFS.CFG, and check each conference to see if it requires seeding, or if the .LMR file requires updating to SF 3.2 specifications. A non-net-mail seed message will be written to each conference that has no messages already, and empty last read pointers will be appended to any .LMR file that has feIr records than the maximum number of users alloId. (SpitFire 3.2 pre-builds .LMR records for all allowable users. The larger .LMR files do not affect the operation of earlier Versions of Spitfire 3.x. Existing last read pointers are not changed by Config.) [C] - Configure CircuitNET Information This choice from the Main Menu takes you to a menu with Two Choices: [P] - CircuitNET Paths and FileNames The paths Ire discussed above, and The activity and error logs can be any valid filename. It is not recommended that they be the same file, although it is permitted. Many nodes use SpitFire's HEYSYSOP.LOG so activity reporting is accessible remotely. (The minimum logging is a status report as a private message in conference #1 addressed to the Sysop User Name in CIRCUIT.CFG, so remote access to information logged to the files is not generally needed.) New entries are checked for validity before being accepted. [B] - BBS Information (Node ID) This choice takes you to the BBS Information Configuration Menu. This menu is the only one isn't relatively self explanatory. [N] - Node ID The Node ID field is where you tell the software several things. Where messages entered on your BBS come from, What file name IMPORT.EXE should look for, and which routed messages and "Sysop WildCard" format messages are meant for you to read. The Node ID is assigned by the network you are joining, and should be obtained from your host. The node ID is used for several filenames through out the network, so it is limited to the characters alloId by DOS in an unambiguous filename. (i.e. no '*','?','/','\','<','>' characters.) what you enter will be converted to upper case, and have any spaces stripped out before it is saved. [#] - Msgs/Conf to keep a history on = This field has several effects on the operation of the software. It controls both the maximum size of the conference history files, (File size = MaxHist * 8 Bytes), the number of days to keep outbound histories for each node extracted to, ( Days = MaxHist DIV 64), and how effective net-wide threading is, ( at least one thread element must be represented in the history file for the thread to be linkable). A minimum of 512 messages (8 Days) and a maximum of 2048 messages (32 Days) are permitted. Any value betIen those two is acceptable. The default is 1024 (16 Days). Since both Primer and Import read the entire conference history files into memory, the larger this value, the less memory they have available for manipulating more than one message at a time, so they have to read in and process smaller blocks of messages for processing. This will affect processing speed on importing of large packets with messages for many conferences, more than it will Priming, or packets with few conferences represented. If you are concerned about processing times, you will need to find the optimum value for your system that handles rejection of duplicates and threading adequately, without increasing processing time beyond what you consider acceptable. [K] - Kill Old Msgs When Priming This feature exists because some of the message packing facilities do NOT kill old messages, and old message thread elements properly. Since Primer reads every message in each net-mail conference anyway to find un- sent messages, you can have it also check the message date against the Old Message Purge Days you have configured in SFMCONF.DAT. If this is set to TRUE, Primer will flag ALL old messages as being explicitly deleted, and disconnect each message from it's thread, and flag it has having been received. This will force any message packer to remove the message unless it is the sole survivor in a conference. Primer will recognize purge dates as low as one day, while The internal SpitFire message packer will treat any value of less than 5 as 120 days. Having this feature turned on gives Primer more work to do, and slows it down marginally. Turning this feature to FALSE will speed Primer up some if you are happy with the way the message base packer you use handles old messages. [H] - This BBS is a HOST This flag changes how IMPORT and EXTRACT deal with the work files. If you are not hosting other nodes. (i.e. building packets for more than one other node.) then this should be set to FALSE, so that IMPORT.EXE will not waste time or disk space writing copies of the incoming messages to the work files only to have them bypassed by EXTRACT.EXE and deleted. This causes Extract to default as if you specified 'LOCK' on the command line to delete the work files when it is done. Setting this field to TRUE causes IMPORT to write messages to the work files, and EXTRACT to leave those files intact when it is done, so that mail from dependent nodes can be combined with mail from the host node and distributed to all of the nodes you are linked with. YOU are then responsible for specifying the 'LOCK' parameter on the command line for the last extract of the day to dispose of the files, or to manually dispose of them at the appropriate time. [P] - BBS Phone number [B] - BBS Name (and on registered copies) [M] - City/State/Motto or Whatever These three fields are combined by Primer to build an identifying tagline for all messages that originate on your BBS. All will accept any Alpha-Numeric ASCII ('True' ASCII, NOT the full IBM Extended Character set, or Control characters.) The two lines below are an example of how the tagline is built: CircuitNET 3.11: Node: <NODEID> Phone <BBS Phone> <BBS Name field> <BBS Motto Field on registered versions> Once you have made changes on the sub-menus of the Configure CircuitNET information menu, and select Q to return to the Main Menu, you will be asked if you want to save any changes made. 'Y' or <Enter> will re-write CIRCUIT.CFG with any changes made. *** NOTE *** The information changed includes the Sysop Names displayed on the Configure Spitfire (Sysop Names) option from the main menu. Any time changes are save to CircuitNET, the Entire Configuration file is re-written with whatever is in memory, and NOT just the changes that Ire made on a specific menu. ************ NODES File The NODES file is where Extract looks for the node(s) it is to build (a) mail packet(s) for. If Extract doesn't find a /NODE= command line parameter, it looks for an ASCII text file named NODES in the CircuitNET System Directory. In the file it expects to find a list of Node ID's separated by carriage returns. (i.e. one node ID per line.) Extract Builds a mail packet for each node it finds in the file. (Note: Each additional node listed increases EXTRACT.EXE's disk space requirement in the CircuitNET MAIL directory by the size of the work files. Too many nodes will cause Extract to abort with an error level of 133.) If Extract finds a /NODE= command line parameter, it bypasses the NODES file and builds only the packet for the node ID specified on the command line. Packet compression CircuitNET Software expects to find PKZIP.EXE and PKUNZIP.EXE in the DOS search path. Because of the method used to shell out for packet compression, if PKZIP.BAT or PKUNZIP.BAT are found before the .EXE file is, then the batch file will be executed in it's place. EXTRACT.EXE does not check for an existing packet before shelling out, but IMPORT does. If you wish to modify the way the packets are compressed or uncompressed, you need only create a batch file with the appropriate name and place it where it will be found and executed before the corresponding .EXE file. In order to get Import to shell out, a file with your node Id and the extension '.ZIP' needs to be placed in the CircuitNET MAIL Directory. The following command line parameters would be passed to the batch files. From EXTRACT.EXE to PKZIP.BAT: %1 = -m %2 = <CircuitNET MAIL Dir><NodeID of packet to Compress> %3 = '@'<CircuitNET Mail Dir><NodeID of packet to compress>'.CMD' (Note: Extract appends to any existing .CMD file found to allow inclusion of other files in the mail packets.) From IMPORT.EXE to PKUNZIP.BAT: %1 = -o %2 = <CircuitNET MAIL Dir><Your Node Id> %3 = <CircuitNET WORK Dir> (Note: Import expects to find the .CND &.CNP files to process in the CircuitNET WORK directory when the shell returns control.) It should be noted that any changes in the compression utility used to build the packet needs to be co-ordinated with the other nodes involved. You cannot simply choose to send a packet in a non-Zip format to a node that is not setup to process it. How you deal with converting the command line information and determining the format of incoming packets, and select alternate compression formats is entirely up to your imagination and Skill in batch file construction. PRIMER.EXE Primer is used to convert messages from Spitfire format to CircuitNET format. In the process of finding and converting net-mail messages, primer marks each message as having been sent in the Spitfire message files, swap the name from the sysop's logon name to the sysop's real name, and parses the subject field for routing and conference management codes. If a routing code is found Primer checks the routing list to insure that it is routed to valid destination. Primer assigns each message a unique message number and a unique thread identifier and marks the message with it's true origin. Primer also updates the conference history file with the Unique number it assigned to the message matched to the messages internal Spitfire message number so that replies to the message from the network can be threaded to it. EXTRACT.EXE Extract is basically a message sorter. It checks each message in the work files against the dossier files, node history files, and routing list to determine if the message should be included in each nodes mail packet. Extract's most important function for end nodes is to Ied out duplicate messages that result from repeated uploads of the same reply packet from offline mail readers. For host nodes, the routing and selection functions gain in importance. IMPORT.EXE Import converts messages back into Spitfire format, and determines which messages are to be passed on to other nodes. Import is responsible for changing the Sysop's real name back to the Sysop's logon name, and will recognize several variations of messages addressed to "Sysop xxx" as being the equivalent of being addressed to the sysop's real name. The special formats are "Sysop" and either the keyword "ALL" or a node ID specification. The node Id Specification can be either an explicit node ID, or a DOS style wildcard. "Sysop All" will always convert to the sysop's log-on name, and be imported. Import will by-pass other Sysop messages if they do not match your node ID, and pass them on to the work files so they can be relayed to other nodes. (NOTE: If you are NOT configured as a host, then Import will not write ANY messages to the work files.) Import does one more thing with messages that will convert to the Sysop's logon name. I will "rescue" messages that are in conferences that are not normally imported by importing them as "comments to the sysop" in conference #1. If a message reaches your board, and is intended for you to read, then you will see it, even if you do not normally import that conference. MAILCALL.EXE Mailcall is a utility for host nodes to distribute mail packets to the proper nodes. It is covered in full in the separate file MAILCALL.DOC. It is NOT required for end nodes. APPENDIX A L I C E N S E A G R E E M E N T Shareware Version -------------------------------------------------------------------------- CircuitNET is not a Public Domain program and is not free. Non-registered users of CircuitNET are granted a 30 Day limited license to evaluate the suitability of CircuitNET for their particular requirements. Any usage of CircuitNET beyond the evaluation time period requires registration of each copy of CircuitNET used, according to the multi-net usage agreement. Use of non-registered copies of CircuitNET beyond the original evaluation period is prohibited. CircuitNET and its accompanying programs may NOT be modified in any respect, for any reason, including but not limited to, de- compiling, disassembling, reverse engineering, or editing of the EXE. This documentation may not be reproduced, transmitted, transcribed, or translated into any language, computer or otherwise, without the express written consent of Dave Stahl. You are free to distribute the PUBLICLY AVAILABLE shareware version of CircuitNET to others subject to the above restrictions and also the following: A. No fee is charged for its use. B. No remuneration may be accepted for CircuitNET. This does not apply to computer access charges the system operators ( Sysops ) of or organizations owning bulletin board systems, online services, etc. may charge subscribers. C. CircuitNET must be copied in unaltered form, complete with files containing license information, the FULL documentation and all accompanying files. D. License to distribute this program is granted to Shareware Houses & Disk Vendors, with the following conditions: ■ The files distributed MUST be the latest available, preferably from a CircuitNET distribution BBS. ■ The CircuitNET archive must be complete, and MUST be named with the author's ( Dave Stahl ) naming conventions. Commercial distributors of "Public Domain", "Shareware", and/or User Supported software may distribute CircuitNET subject to the above conditions only after obtaining WRITTEN permission from Dave Stahl. This condition statement supersedes all previous agreements. Please refer to registration/ordering section for additional information on registration, corporate site-licensing and related topics. -------------------------------------------------------------------------- L I C E N S E A G R E E M E N T Registered Version -------------------------------------------------------------------------- CircuitNET and its accompanying programs may NOT be Modified in any respect - for any reason - including, but not limited to: ■ Decompiling. ■ Disassembling. ■ Reverse Engineering. ■ "Editing" Of Compiled EXE. The documentation for CircuitNET may be translated into foreign languages ONLY with permission from Dave Stahl. The SHAREWARE license statement does not apply to the REGISTERED version of CircuitNET. The registered software of Dave Stahl is protected under United States Copyright and Trademark Laws. It must be treated just like a book with certain exceptions ( Below ) A. Dave Stahl authorizes the making of archival copies of the registered software for the sole purpose of backing-up your software and protecting your investment from possible loss. B. The medium on which the registered software is recorded is transferred to the customer, but not the title to the software. C. The Licensee may resell or transfer unmodified copies of the registered software provided the customer has registered from Dave Stahl one copy of the registered software for each one sold or distributed. The provisions of this software license shall also be applicable to third parties receiving copies of the registered software from the customer. The resale price of CircuitNET is not to exceed the price paid originally. D. Multi-Net usage Agreement: Each registered copy of CircuitNET can be used on up to 2 ( Two ) Bulletin Board Systems owned by you, regardless of the number of networks you run. This does not apply to Multi-Node BBS's, Nor to Subboards off the same BBS. Should you require a second registration, please see the registration form for details. E. Dave Stahl reserves the right to cancel your registration of CircuitNET upon proof of any aberration of the above outlined terms, particularlly those dealing with modifications. F. You MAY NOT form new network using CircuitNET software without CONSENT from Dave Stahl. This applies to local networks, as well as national or international networks. S T A N D A R D D I S C L A I M E R -------------------------------------------------------------------------- CircuitNET is provided AS IS without any warranty, expressed or implied. This includes without limitation the fitness to a particular purpose or application and any warranties of merchantability. While I tried to be as through as possible while debugging CircuitNET, Dave Stahl shall not be liable for any damages, whether direct, indirect, special, or consequential arising from a failure of this program or accompanying files to operate in a manner desired by the user. Dave Stahl shall not be liable for any damage to data or property which may be caused directly or indirectly by use of this program. In no event will Dave Stahl be liable to you for any damages, including any lost profits, lost savings or other incidental or consequential damages arising out of your use or inability to use the program, or for any claim by any other party. If you have a problem with CircuitNET please notify Dave Stahl, describing the situation & revision number/date. Registered users, please include the serial number found on your registered programs. -------------------------------------------------------------------------- THE ANATOMY OF A MESSAGE SpitFire Messages Spitfire maintains and manipulates messages with a system of parallel files. It maintains .PTR, .DAT, .IDX, and .LMR files for each conference. All of the files have a common file name consisting of SFMSG folloId by the number of the conference. CircuitNET deals only with the first three files. (CONFIG.EXE does create the .LMR file for new conferences but doesn't manipulate it in any way.) The .PTR file: Spitfire messages are separated into the header or pointer record, and the data records or message body. The .PTR file is where the header records for each conference is stored. The header record contains the information on who the message is to and from, when it was entered, the location and number of data records, an internal message number, and thread identification. It also contains a set of Flags that indicate whether the message is deleted, net-mail, received, or part of a thread. Essentially everything Spitfire needs to know about each message except what it actually says. The .DAT file: The SpitFire message Data File stores the text of the message in 128 byte blocks. EAch message is "rounded up" to the next multiple of 128 bytes. The .IDX file: Spitfire uses an index file to speed searches through the message directory. Each index record contains a code identifying who the message is to, who the message is from, and the message number and thread identification number. The to and from codes are simply 32 bit CRC's of the text in the to and from fields of the pointer record for the matching message. The .LMR file: Spitfire maintains one record in each .LMR file with the internal message number of the last message read by each user in each conference. ( With Spitfire 3.2 there is a record for each user allowed rather than for each active user. ) Circuit Net Messages CircuitNET uses a similar system to Spitfire's with the difference that CircuitNET doesn't require the index and last read files. It does need to keep track of a history of which messages have been moved in and out of each of Spitfire's message conferences. So CircuitNET adds one file to SpitFire's files with the extension .HST to keep the historical data in. CircuitNET uses the extension .CNP for it's pointer files, and the extension .CND for it's data files. The .CNP File: Like Spitfire, CircuitNET keeps the data in a separate file from the header records. CircuitNET uses much of the information from the Spitfire .PTR file to build it's pointer records, but there is information in the Spitfire record that CircuitNET doesn't need, and there is information that CircuitNET needs that is not in the Spitfire records. Also, some of the information that CircuitNET does get from the Spitfire record isn't as compact as it could be. So CircuitNET builds a record that contains everything it needs to re-construct a Spitfire message header, plus everything it needs to control the messages travels through the network, and at the same time is a small as possible. The end result is that SpitFire's pointer record is 64 bytes larger than CircuitNET's. The .CND file: CircuitNET's Data file is not organized in blocks, but in single bytes. Strings of repeated characters in the Spitfire data records are stored as three bytes, and trailing spaces are stripped out. (Repeated characters are represented as a identification mark, number of characters, and the character to repeat.) Short of an actual compression, as is done by archiving programs, this transfers the message text in as few characters as possible. M E S S A G E C O N T R O L C O D E S -------------------------------------------------------------------------- CircuitNET Message Control codes (MCCs). MCCs allow you or any user of your system to route messages to a specific node. In addition, the Sysop may REMOTELY modify his or her Dossier File on another system. ROUTING MESSAGES In order to route a message to a specific node, a user must enter the Route Specifier, which consists of TWO greater-than signs (>>) immediately folloId by the node number of the system that message is to be routed to, in the SUBJECT of the message. The Route Specifier, together with the destination node, comprise the Route MCC. Thus, if a user wanted to route a message to another user on node 801000, he or she would enter the message as normal, but would place the following in the subject of the message: Message to: Joe Blow Message From: Joe User Message subject: Hi Joe! >>801000 | | | +-- Node to Route message to. + ----- Route Specifier *NOTE: The FIRST character of the subject MUST be a letter. The rest of the message would contain the actual text of the message. Thus, the entire message would appear as below, and would be sent to all of your linked nodes, but would only be imported into node 801000: Message To: Joe Blow Message From: Joe User Message Subject: Hi Joe! >>801000 1: This is a routed message to node 801000. 2: 3: Sincerely, 4: 5: Joe User DOSSIER FILE MODIFICATION A Sysop of a CircuitNET system may REMOTELY modify his or her Dossier File on another system by using the Add and Delete MCCs. A CircuitNET Sysop may both add and delete conferences from his or her Dossier File. Adding a conference: Adding a conference simply requires sending a routed message IN that conference. Assign the desired codename to a Spitfire Conference, and then enter a routed message in that conference to be sent net-mail. Route the message to any node you know already echoes that conference. (Usually routing to your host is sufficient.) Address the message TO: Sysop <NodeId> of the node you route the message to. WildCard routing and Sysop specifiers are permissible. The desired conference will be added to ALL dossier files required for you to echo the conference betIen your node and the node the message is routed to. Deleting a conference: Remote deletion of conferences is more tightly restricted. 1: You can only delete conferences from the Dossier file for YOUR node on systems you echo directly to. You CANNOT delete conferences in nodes you do not build packets for. 2: The message must be FROM: the name given as Sysop User Name in Config. A message from any other name will produce an error message from Primer in both the Activity and Error log files alerting you to an "Unauthorized attempt to delete a conference", and the message will NOT be processed. The warning message will be repeated each time primer is run until the offending message is deleted, or until the Sysop User Name is changed to match the From: field in the message. 3: The Subject: filed must contain a routing specifier AND a deletion command. non-routed attempts to delete a message will be processed as a normal message and sent into the network, but will have NO effect on the dossier files. (i.e. SUBJ: >>MYHOST--BANANAS) 4: The last character of the codename to delete must be folloId by a space, or be the last character in the subject. Imbedded spaces are ignored. any text following the '>>' marker, (including the marker), will be removed once Primer parses the information so any text following the codename will be lost. 5: On the recieving end, the name of the Dossier file to modify must match the node ID of the true origin of the message. In other words, you cannot modify any dossier file except the one for YOUR node on a system that builds packets FOR you. (i.e. your host, or a direct dependent of your node.) NOTE: All traffic in the conference must cease, or the automatic update feature of IMPORT will re-add the conference. All message in the packet containing the deletion command will Import normally before the deletion is made, so the command can delete the conference it is sent in, but it must be manually removed from the affected dossier file on your end. (After the delete command is sent if it is in the affected conference. Any time if in another conference.) A P P E N D I X B B a s i c N e t m a i l C o n c e p t s -------------------------------------------------------------------------- NODE NUMBERING In order to maintain organization throughout ANY network, a system must have an address, or a unique identifier that distinguishes that system from another. In CircuitNET, this addressing technique is called Node Numbering. Each system using CircuitNET will have a node number. In the CircuitNET International Network, node numbers are assigned as follows: - Node numbers consist of the area code of the system's location, followed by a three-digit number denoting the number of the system. Thus, the first system in area code 801 would be assigned the node number 801001. - Any CircuitNET system which performs host duties is assigned a 000 number to their node number. Thus, the host system for the 801 area code is designated as 801000. Host Systems are usually the first registered CircuitNET systems in an area. CONFERENCE IDENTIFICATION Each conference used by CircuitNET must have a codename. This codename is used to match up conferences on different system whose conference configuration are not identical. For example, if System A has the CircuitNET Support Conference as Spitfire conference number one, and System B has it as Spitfire conference number nine, then there needs to be some way for CircuitNET to make sure that the mail from System A's conference number one is imported into System B's conference nine, and vice-versa. This is where CODENAMEs come in. Conference CODENAMEs are eight-letter mnemonics used to represent the name of a conference. By using a conference codename, conferences are more accurately represented on a system. Instead of having to maintain a database that represents each system's unique configuration, a more static method is provided by assigning each conference a codename that is used to denote which conferences are to be linked together. Thus, CircuitNET doesn't worry about matching conference number up, but rather concentrates its effort in getting the mail from one conference into another conference with the same CODENAME. DUPLICATE MESSAGES Duplicate messages occur when there are two or more messages which are exactly the same in any given conference. IMPORT compares each message being imported to those already in the software message conference and rejects any that would be duplicates. If there is no matching message in the spitfire message base then the message is imported. This may result in a resent message which is a message that was on a given board then deleted and then re-imported into that boards message base and then sent back out on the net. APPENDIX C This appendix is provided to those of you who like the technical aspects of CircuitNET. If you have any questions concerning topics above and beyond those covered in this manual, contact Dave Stahl and I will help you out in any way I can. SOURCE CODE AND RECORD STRUCTURES There are no plans to release the source code to CircuitNET to anyone. The record structures, however, will be released on a case by case basis to those who wish to write utilities to function with any of the Circuit Net files. APPENDIX D REVISION HISTORY -------------------------------------------------------------------------- April, 1992 - Copyright purchased from Gorilla Brothers Software by Dave Stahl Jan 1992 - Release Ver 3.11 - Rewrite of CircuitNET mail packet structure, duplicate rejection sceme reworked for better results, Node ID increased to 8, addition of .HST files for duplicate rejection, Outbound duplicate rejection added, NET wide message threading added, message routing expanded to now include wildcard message routing, SYSOP ALL message routing now added. Dec 1990 - Copyright purchased from Sean C. Burbidge by Gorilla Brothers Software. Release 3.04 - Fixed memory allocation problems and message conference size limitations introduced in release 3.01 of import, also enabled transparent conference routing and automatic dossier file updates. Release 3.01 - Added Duplicated Rejection facilities to IMPORT.EXE -------------------------------------------------------------------------- APPENDIX E Command lines, Exit Codes, and Troubleshooting PRIMER.EXE only recognizes three command line parameters: NOLOG: Reduces logging to the status message, and start/stop times in the activity log. Errors will be reported to the Error log with only a reduction in detail. BRIEF: The default logging level with the status report message copied to the log files. VERBOSE: For Primer only notification of errors is added to the default brief logging. EXTRACT.EXE Recognizes the same three logging level commands as does Primer plus three additional command line parameters: Nolog, Brief, and Verbose function basically the same as for Primer, with the exception of the verbose mode. For Extract verbose logging adds detail to reject notices, but extract does NOT notify you that it has rejected any messages. the only trace of outbound rejections is the error log entries. /Node=xxxxxxxx This command line causes Extract to bypass the NODES file, and only build one packet. Only the first occurrence of this parameter is recognized. LOCK This parameter tells extract that the mail cycle is complete, and that the work files are no longer needed. The work files will be deleted when extract is finished building the packet(s). If Extract encounters a fatal error, this parameter is ignored. If the BBS is configured as a HOST this parameter must be used. If the BBS is configured as an end node (i.e. "This BBS is a host = FALSE) this parameter is automatically set. HOST This parameter overrides the configuration host mode variable and preserves the work files. It is the functional opposite of LOCK. IMPORT.EXE Recognizes the three logging levels, plus one other command line parameter: NOLOG Import reduces the information in the status report message, as Ill as reducing the Activity log to start/stop times. Import will also stop reporting of which messages Ire rejected to the error log. BRIEF: In the default mode of Brief logging, Import reports the numbers imported by conference in addition to the totals reported in NOLOG mode. It also copies the same information to the Activity log. Minimal information is reported to the error log for rejected messages. VERBOSE: Import Adds information on each message imported to the Activity log, and expands the information on rejected messages in the Error log. (The format of the verbose activity log is compatible with NETBULL.EXE by Kenneth Rucker which generates a bulletin for your users.) HOST: Import does not write messages to the work files unless it is in host mode. Import uses the HOST variable in the CIRCUIT.CFG file as the default. This parameter can be used to force Import to write to the work files, although no command line facility has been provided to prevent it from writing to the work files if the BBS is configured as a host. Error Levels and trouble shooting: Primer.exe: Prime has two error exit levels 128 : CIRCUIT.CFG not found or unreadable. There are two possible causes for this error. Either Primer was invoked with the current DOS directory other than the one that contains CIRCUIT.CFG, or the CIRCUIT.CFG file as not compatible with version 3.11 of CircuitNET. (Either corrupted, or from an older version of CircuitNET.) Insure that your batch file changes to the directory that contains CIRCUIT.CFG, and if that doesn't correct the problem, you will need to re-build CIRCUIT.CFG with CONFIG.EXE 135 : Message base locked by WORKING.CN. Both Import and Primer use a file named WORKING.CN to "lock" the SpitFire message Directory. If you suffer a poIr failure or have to re-boot the system while Import or Primer is working, this file is not deleted as it should be. Primer and Import will loop until this file is deleted, or 10-15 minutes, or until any key is pressed. If the file is removed while they are looping they go ahead and execute, other wise they exit with a notice to the the status message and log files, and this error level. Normally this error level indicates that a run-time error or other program interruption cause the key file to be left behind. If WORKING.CN exists when neither Import or Primer is running, then it should be deleted. (Your batch file can delete the working file when the main Spitfire node is booted, but care should be used to prevent the file from being deleted when a module is actually working.) Another situation that can cause this error level is when the module that has the message area locked does in fact take more than 15 minutes to complete it's processing. Primer's processing time is much longer than the time Import will wait if you have many conferences and/or several conferences with great numbers of messages. For a 286/12 machine over 100 conferences, or over 10,000 messages total will push Primer's processing time beyond the time limit to wait for the Key file to clear. EXTRACT.EXE Extract only exits with an error level of 0, 128, or 133. 128 is generated when Extract cannot open or read any of the files it requires. The error log is used to report which file caused the problem. 133 is generated when Extract cannot find enough disk space to build the mail packets. If this occurs when extracting for a single node, files will need to be deleted or moved to make room in the CircuitNET Mail directory. If it occurs when extracting for multiple nodes then usually extracting for each node singly with the /NODE= command line option will be successful. IMPORT.EXE Import has the most extensive error exit reporting. 1 : Error level 1 is generated when there is no mail packet found to process. Import checks in the CircuitNET Mail directory for <nodeid>.ZIP before doing any processing. 2 : Error level 2 is generated if either the .CND or .CNP file from the mail packet are not found in the CircuitNET Work directory after returning from the shell to PKUNZIP. The most probable cause for this error is that the mail packet contained Zero byte files. Other possible causes include an error unzipping the packet, and insufficient disk space in the Work directory. 128 : Import could not find CIRCUIT.CFG or could not read it. 129 : Import could not find CNCONFS.CFG in the CircuitNET system directory, or could not read it. 131 : Import did not find enough memory to process the packet. Import requires approximately 256K to load, and then checks to insure it has enough memory available to read in the files it needs to process the message packet. 133 : Not enough space on work drive to run. Import did not find enough disk space on the drive that contains the CircuitNET Work directory to process the mail packet. 134 : Not enough memory to continue. Import ran out of available memory. This indicates that the mail packet contained information that caused it to build bigger lists in memory than it predicted it would need. Import leaves the .CND and .CNP file in the work directory in this case, and often simply re-zipping them and re-importing the packet will recover missed mail. (The rejection of the previously processed messages consumes less memory than processing them the first time did.) If that fails, removing TSR's and device drivers from memory is required to provide more memory for import to work with. 135 : Message base locked by WORKING.CN. See the comments under Primer for more information on this error. Import is susceptible to some of the same factors that would cause Primer to run longer than the time limit. i.e. large numbers of conferences, or a very large packet with messages to many different conferences. On a 286/12 machine a packet with over 2000 messages to 100 different conferences was required to cause import to run longer than the time another module would wait. 136 : Unable to Open/Create MESSAGES.CN? If host mode is active, and Import cannot open or create the work files, it will abort without processing any messages, and leave the packet .CNP/CND files in the work directory so that they can be re-zipped after the problem is corrected. Most probable cause of this error is Extract having the files open longer than Import's sharing code will re-try, or an orphaned file lock in the tables maintained by SHARE.COM. Re-zipping the packet and re-trying should correct the problem. R E G I S T R A T I O N I N F O R M A T I O N -------------------------------------------------------------------------- Once a registered user of CircuitNET, you are free to utilize the program as often as you wish. You will also be notified when a significant enhancement has been made to CircuitNET. Once registered, all upgrades are available for free. Upon the receipt of your registration you will be provided with your registered copy of CircuitNet which will allow you full access to all of the current net mail conferences. There are two ways to register. The first is by sending $20.00 (US) to Dave Stahl along with a registration form. You may then download your registered version from Quantum Leap! @ (408) 267-0631. Or, for an additional $5.00 (US), I will send you the latest shareware and registered versions of CircuitNET on disk along with documentation (on disk) w/Utilities. CircuitNET UPGRADES Once you have registered CircuitNET, future upgrades are free. Registered users desiring an upgrade may either download the new version from the CircuitNET Support BBS, or may opt to receive the new version on diskette. In such case, please send $5.00 (US) to Dave Stahl for handling costs. APPENDIX F: REGISTRATION FORM Remit Registration To: Dave Stahl 3158 Ross Ave San Jose, Ca, 95124 Qty. Description Each Total -------------------------------------------------------------------------- ____ CircuitNET Upgrade to version 3.11 on disk $5.00 _______ ____ CircuitNET Registration $20.00 _______ ____ CircuitNET Registration ( 360K 5.25" ) $25.00 _______ ____ CircuitNET Registration ( 720K 3.5" ) $25.00 _______ ____ CircuitNET Second Registration $10.00 _______ ____ CircuitNET Second Registration ( 360K 5.25" ) $15.00 _______ ____ CircuitNET Second Registration ( 720K 3.5" ) $15.00 _______ --------------------------------------------------- Subtotal _______ All orders outside US & Canada add $5 Shipping Shipping _______ Add $5 for Currency Exchange *SEE ABOVE Misc. Charges _______ CA residents please add 8.25% sales tax Tax _______ ------------------------------------------------------ TOTAL $_______ Name: ________________________________________________________________ Company: _____________________________________________________________ Address: _____________________________________________________________ City: _________________________ State: _______ ZIP: _________-______ Data Phone #1: _______________________ Home Phone:___________________ Data Phone #2: _______________________ BBS Bps: _____________________ BBS Name: ____________________________________________________________ BBS Hours: _____________ Password For Quantum Leap!:_________________ If you are not already logged into Quantum Leap!, please give me a password to set up your account with. All checks must be drawn on US funds in US Dollars. Sorry, No COD orders will be accepted. -------------------------------------------------------------------------- C O P Y R I G H T N O T I C E S -------------------------------------------------------------------------- CircuitNET is Copyright (c) 1992 by Dave Stahl Spitfire is Copyright (c) 1987,1992 by Buffalo Creek Software. PKZIP and PKUNZIP are Copyright (c) 1990 by PKWare, Incorporated. Turbo Pascal is Copyright (c) 1989,1992 by Borland International. Turbo Pascal Reg. U.S. Pat. & Tm. Off. -------------------------------------------------------------------------- I would like to thank the following people who have helped in the making of this project. Bill Arlofski Steve Newman Wayne Letalien Bill Gray Glenn Lewis Lonnie Odom Michael Benedict Mike Ist Steve Palmer Lynn Hochwitz Sean Burbidge Mark Eastman Jere Issel What are you looking down here for? Get netmailing!