Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / NET33.ZIP / WWIVNET.DOC < prev next >

Wrap

Text File | 1993-05-14 | 80.8 KB | 1,770 lines

WWIVnet Docs v2.33a by Wig De Moville <aka> Filo April 26, 1993 1. HISTORY The first version of WWIVnet Docs was written by Will Daystrom, also known as The Captain (1 @2370), who ran the White Star Line and who copyrighted the Documentation for WWIV v4.10 and WWIVnet Docs under White Star Line Software. His documentation was excellent and would not have needed to be rewritten if the WWIV BBS software and the networks associated with it were not growing and dynamic. However, v4.21a of WWIV introduced the ability for a BBS to be on more than one network, and with that ability many new networks were started. This documentation has been rewritten with those changes in mind, so that the current documentation will be useful regardless of which WWIV-based networks a board happens to belong to. The part of the documentation detailing the policies and procedures of WWIVnet has been moved to a separate document. This version of the WWIVnet Docs is written by Filo (1 @2050), and is deliberately not copyrighted in order that future versions can be built upon it without anyone's having to worry about copyright infringements. If additional changes in the documentation are necessary, I will offer them as v2.x if I am still involved with WWIVnet. If I am not, then the next author can decide whether to continue with 2.x or change to v3.x. I think that 3.x should be reserved for a major change in the working of the WWIV-based networks. 2. INTRODUCTION A network is a voluntary association of bulletin boards using WWIV software and participating in a network by calling one another to facilitate the transfer of electronic mail (email) and message bases (subs). At the current time, WWIV-based networks constitute the second largest network running on private computers in the United States. There are over 2000 systems located in the United States, Canada, England, Germany, Italy, Spain, Mexico and Japan. Through this network, a user of any of the bulletin boards that are members may send email to a user of any other board. A user may also post on a message base which may be read by the users of systems which subscribe to that message base; thus, many of the networked subs have international distribution. Because this system of communication is read by others and because it has an effect on systems other than the one on which it originates, a spirit of cooperation must prevail. Out of this spirit grows systems of organization and regulation which are known as networks and which are discussed in separate documents distributed by those networks. This document covers some of the aspects of the software which should be of interest to users and/or sysops regardless of the particular WWIV-based network(s) with which they are affiliated. WARNING: When you unzip the network software, you should see "- AV" on the line next to every filename. Furthermore, after the files have been extracted, you should see the message: Authentic files Verified! # XLD658 WWIV Software Services If you do not see the "-AV" and the above message (be sure the number is "XLD658"), then the files you have have been tampered with, and you should not use them. Since this software is used by several WWIV-based networks, the files herein should not be extracted and included in another network package. If you desire to distribute NETxx with another network software, you should include the NETxx.ZIP file in its entirety within the other network archive in order to preserve the AV codes. 3. REGISTRATION Up until net28, the WWIV network software has been distributed freely to everyone. Starting with net28, the net software is distributed much like the WWIV software itself. The WWIV BBS and network software is distributed as shareware, which means (in this case) that you can use the WWIV and WWIV network software for up to two months before deciding whether or not to register WWIV. If, at the end of the two month period, you decide to register WWIV, please see the 'read.me' file in the WWIV .ZIP file for information on how to register. If at the end of two months you decide NOT to register WWIV (and hence not use WWIV software for your BBS), you must stop using the WWIV and the network software. If/when you register WWIV (and receive a WWIV registration number), you have also registered the network software, and may use the bbs and network software on your system as you wish -- as a standalone BBS, or in a network. If you are running a BBS that is in no way based on WWIV software, but that uses the WWIV network software, then a similar registration procedure applies. You can use the network software for a two month trial period. If you decide to continue using the network software after the two month trial period, then you must register the network software for $20. If you do not register the network software at the end of the two month trial period, you must stop using it. Registration of the network software for those systems not running a BBS based on WWIV is done by following the instructions in the NETREG.FRM included with each NETxx.ZIP packet. Thus, there are two ways you can legally continue to use the network software after the two month trial period. Either register WWIV, or (if you are running BBS software that is in no way based on WWIV software), register the WWIV network software for $20. 4. ORGANIZATION WWIVnet originally began in 1988 with 25 charter members who helped Wayne Bell develop the network software and debug it. Since that time it has spread from a small Los Angeles-based system of local boards to several international networks. Currently, the three largest of these networks are WWIVnet, WWIVlink, and IceNET. The network software is in its 33rd version although there will undoubtedly be many future versions written as well. These versions are referred to as Net1, Net2,...Net20, etc. 5. WWIV Software WWIV v4.20e and up supports the automatic request for a sub and the automatic removal provided that each board has the network software to support the feature and provided that the sysop has configured his board to allow auto-requests. Beginning with NET32, the automatic request feature and an option for the description of the sub in the SUBS.LST is included in BOARDEDIT. This feature should facilitate a board's adding or dropping subs that are subscribed to. The network software includes the creation of informational files on each network system which reflects subs or messages received that have 'no place to go.' In effect that would mean that the receiving sysop has not created a message base for that sub or has deleted it but is still receiving mail for it. The sysop should check this file regularly and if he is receiving subs that he has not ordered or does not want, he should notify the sending host to please remove his system from the distribution list. This information and other information on network connections may be found in your GFILES directory in files named NETDAT0.LOG, NETDAT1.LOG and NETDAT2.LOG. The NETDAT0 is the newest log and NETDAT2 is the oldest log. These logs are only kept for a three day period unless you make other provisions to have them saved. They may provide useful information to you in terms of what you are/are not receiving and in terms of problems that may occur in your network connection. Under v4.22 of the BBS software the sysop can access these logs from the bulletin board by typing a comma at the main menu. The sysop should also occasionally review his DEAD.NET file which will be in DATA. Messages in this file are those which were bound for another system but which cannot be delivered after having arrived on your system. Often these are due to one of two factors. The first case might be due to a board's having subscribed to a sub and having been put on the distribution list for it before that board has been added to the bbslist. Thus the system does not know where to deliver it. If that is the case, the DEAD.NET should be left alone because once the system is added, the network software will deliver that mail to the new system. The second case would occur when a board has left the network or has been temporarily disconnected from the network. It may still be receiving mail because either the sysop failed to notify the host, mail was already in the system, or because the host sysop has failed to remove the board from the distribution list. In that case, the mail may be safely deleted. Before deleting the mail, you should check with the board's AC to be sure that the board is out of the network. In addition, the sysop should write the host of the sub whose mail is going to DEAD.NET and inform the host of which board is no longer on the network and request that host delete the board from the distribution list. NET32 and up also has a feature to report on undeliverable e-mail to another system in the form of a System Short Message (SSM). Sysops who receive subs from other systems have the responsibility to restrict access to the sub according to the rules of the host. For example, some subs may limit access to User Number 1, to users with 255 access, or some other requirements such as all posts must not have tag lines. The receiving sysop must also take steps to inform users of the rules applying to a particular sub. GFILES are often a good way of doing this. These guidelines for sysops are nothing more than common sense and normal courtesy which reflect the desire on the part of all to cooperate in order to make the network work properly and efficiently. One of the interesting features of the network is that it is a great leveler. No one (except possibly a few sysops) knows the age of the person making the post; therefore, people's impressions of the person who posts is made entirely based upon the language used and the thought expressed. As a consequence many a young user can convey the impression that he is much older and more mature, and some older users may convey the impression that they are irresponsible, illiterate users. One hopes that users will opt to convey the impression that they are mature, responsible human beings. Sysops may choose to promote responsible use of the network by asking users to make their network posts conform to certain suggested guidelines. For example, the Sysop may request that users: o Not Use Foul language on the network o Not make personal attacks against others o Not post a lot of one-line messages on the network o Learn the differences between using A, W, or P to respond to network messages. These are merely suggestions for responsible use of the network and are not requirements; however, some of those suggestions are also found in the rules of the hosts of many network subs. Where they reflect the host rules, they are generally considered network rules for that sub. The following information lets you see at a glance the type of message (ie where it originated) when reading message bases: [1] = messages posted by you <2> = messages posted by someone else remotely (3) = messages posted by someone else locally //BOARDEDIT now manages additional information for you, such as the host system #, whether a sub you host is auto-requestable, and whether the sub is automatically reported for SUBS.LST updates. This additional info is stored in the "SUBS.XTR" file in your data directory, but DO NOT MODIFY THAT FILE DIRECTLY. Use //BOARDEDIT all the time. If you're using net31 or earlier, you'll notice that your nnall.net, allow.net, and subs.pub files will automatically be updated for you. With net32 or later, the files will be deleted, as all the info is now in the SUBS.XTR FILE. You can now gate subboards among networks your system is a member of. This is done in //BOARDEDIT, simply by entering net info for multiple networks. In order to support sub gating, you need to be using net32 or later. Do not try listing different sub types in the same network, as it probably won't work. Gating DOES work with net-validation. You can gate subs as either the host or as a subscriber system, but please do not gate subs unless you really have a good reason, and know what you're doing. Additionally, you need the per- mission of the original sub host in order to gate messages. You can now net subboards by sub name (instead of just sub type). A sub name is 1-7 chars of upper-case letters and numbers, and doesn't start with a number. Note that in order to use sub-by-name, the host AND all subscribers need to be using v4.22 (or later) AND net32 (or later). Other than that, subs-by-name works the same as subs-by-type. Because of changes being made by the telephone companies (see Section 10 - Future Directions), it may soon be necessary to run v4.22 or better in order to be able to use the sub-by-name feature in almost all networks. There may even be a MANDATORY UPGRADE of both WWIV software and NET VERSION in the near future as a result of these changes. If you connect to the same system number in multiple networks, you can now force a callout to either one (you are prompted to select which one). Future versions of the network software will allow you to pick up all network messages for your system on one call to the same connecting system. You can now (correctly) forward mail between networks. If you're using net32 or later, if the person you forward the email to auto-replies, the reply will correctly go back to the original person who sent the email. 6. INSTALLATION This section of the WWIVnet Docs takes you step-by-step through the installation process involved in setting up the network executbles and other files necessary to the operation of a WWIV-based network. 6.1. Apply for Network Node Number The first step is to obtain a node number. The appropriate method for doing this varies from network to network and is covered in the documentation specific to the network that you are interested in. You may consult the NETWORKS.LST file included with this docu- mentation to determine if a "contact person" has been designated for the network you are interested in. The node number should be entered in INIT under Option 2 if you are on a single network; otherwise the information on each of your networks and network nodes is entered in INIT Option N. You may wish to enter information in INIT for a "Net low time" and "Net high time". If you do this, it means that beginning at the low time and ending with the high time, a user who attempts to log in will receive a message indicating that your board is only accepting network calls during that time period. For example, Net low time : 03:00 Net high time : 05:00 would indicate that the network time period is from 3am to 5am. Military times are used to indicate time periods in the network. Also, in INIT option 1, you should insure that your board name and telephone number are entered exactly as they are shown in the BBSLIST.### or the BBSLIST.NET file which are also discussed later. 6.2. CALLOUT.NET You will have a CALLOUT.NET file which should be placed in your DATA directory, or in the case of multiple-networks--in the date directory for each network, and which will show the systems that you connect with. This file is in the following format: @node [macro options] [transmit options] [callout options] [password] Each of these options is discussed in turn. The node is the node number of the board you are connecting with. 6.2.1. Macros: Macros are often used to achieve special purposes. These purposes include (a) connecting with another board in your area code where it is necessary to dial 1 before dialing the board number, (b) using a telephone service such as PcPursuit where special numbers, passwords, etc., must be sent, (c) connecting with another board that is running WWIV as some form of door (i.e., WWIV is not answering the phone--instead some other software answers). The macro to use is designated in the CALLOUT.NET by %x where x is an integer number. The macro should then be provided in the DATA directory under the name Mx.NET where x is the same number. For example, if you use PcPursuit to call St. Louis, Mo., and Phoenix, Az. you would need a macro for each city. The macro commands and a sample PcPursuit Macro are in Appendix B of this document. 6.2.2. Transmit Options: Transmit options are basically two. You may use the & parameter which means that files will be transferred each direction when a connection takes place. If the & is omitted then the transfer will be uni-directional; from you to the other board. In such a situation, you pay to send your files to the other board, and presumably, it will pay to send its files to you. This is not a very efficient arrangement and is basically discouraged. The other transmit option is for network compression. If you specify the ; parameter, then network traffic to be transmitted to that node will be compressed, using pkzip's compression techniques. PKzip or other compression programs are not needed, as the compression/decompression code is built into the network software (using the PkZip data compression library). You must ensure, however, that the system for which you specify compression is using net24 or higher; if they are using net23 or lower, all compressed data sent to that node will be lost. Please do not assume that compression should be used for all your net connections. Local connections and high speed connections that also use V.42bis are probably not good choices for using compression. Also, try to avoid using MNP5 on connections for which compressed data is sent. The packets that are created begin with z. For example, Z5252.NET would indicate a compressed net packet bound for node 5252. You should check with the Sysop of the other node before enabling compression between your system and the other. Some experimentation may be necessary to determine which connections benefit from compression. 6.2.3. Callout options: These options affect when your board will call the other board. /x Where x is an integer between one and 9. This means that the network will force a callout to that board every x days, even if there is no mail waiting to be sent to that system. This parameter is often set where one board does not often call the other. = This means to call during PcPursuit hours (6 pm to 6 am Monday thru Friday and anytime on weekends). These parameters are handy for those long distance connections utilizing PcPursuit. For a board to make use of PcPursuit for the network, a macro must be used (see appendix for a sample macro). - The minus parameter means to call during times when rates are cheapest (11 pm to 7 am and anytime on weekends). This parameter is recommended for long distance connections in order to minimize your phone bill. ! This limits the number of calls per day to 1. The board will attempt to call out starting 20 hours after the last successful connect. This feature only works with WWIV v4.12 or higher. !x Where x is an integer. This limits the number of calls per day to 20 divided by x. The board will attempt to call out every 20/x hours after the last connect. This feature only works with WWIV v4.12 or higher. + The plus parameter indicates that your board does not call the indicated node; instead, that node should be calling you. If both of you have the + parameter in CALLOUT.NET then no transfers will take place between you. ~ The tilde (~) means that your system will never call out to the other system, and that the other system will never call yours to pick up mail. The other system will only call yours to send data to you. ^ The caret (^) is used to enable the HSLINK protocol between your system and another. If present on both systems (and the HSLINK executable is found on both systems), the network will attempt to use HSLINK as the protocol instead of Zmodem (or ymodem). CAUTION: Be sure you do NOT have the -! modifier in your HSLINK.CFG file. NET32 now appends that modifier to the command line for outgoing Net calls. If the -! is present in the HSLINK.CFG file, it may cause conflicts that could prevent optimiun performance when recieving Net calls. See Appendix for details on setting up HS/Link for WWIV. Another set of parameters may be used to designate that the board should call between certain hours. These parameters are illustrated below: (3 )5 would mean that the board should call between 3 am and 5 am. Times are specified in 24 hour time. Midnight is specified as 0. These parameters are useful if you are having a connection with a board that runs a NET TIME PERIOD or to insure that local connections take place during non-busy hours. If none of these time delimiting parameters are used, your board will make the connection with the other anytime that there is mail to go out and the board is not busy. This is NOT recommended for long distance connections unless you are using a WATTS line or other system that makes long distance a fixed cost. It may be used for local connections if desired. 6.2.4. Passwords: You should not enter a password in your CALLOUT.NET. The network software will generate a password between the two systems once there is a successful connection. This is one way that you can tell whether or not your system has connected with the other. If there is a password present, there has been a connection. For more information on passwords, see the section on Trouble Shooting NetWork Connections. Also note that the password will be in quotation marks as the last item on each line of CALLOUT.NET. If you lose your password for some reason such as corrupt files or hard disk failure, you will need to contact the other sysop to have the password removed from his CALLOUT.NET file so that a new one may be established. 6.3. Network Software You should obtain the latest version of the Network software and place the files in the main directory of your BBS. That will be the directory where the BBS.EXE file resides. You may determine the latest version of the software, by asking your network contact person or other network official to supply you with a copy of it. You should remain alert for changes in the network version. Currently, it is NET33; however, future versions will be released as needed. It is your responsibility to obtain these versions once you are on a network. You may usually obtain them from Amber (Wayne Bell's board), from the WWIV Support Boards (you will get a list of these with the WWIV software, and the list is updated from time to time), or from one of your networks officials. 6.4. BBSLIST and CONNECT: There are basically two ways of using the network software. One of these ways is best suited for small networks and the other lends itself to larger networks. While both methods will work for small networks, the large method must be used when a network approaches 500 systems due to the way that some of the software functions. A small network will only need two of the files mentioned below (BBSLIST.NET and CONNECT.NET) and all nodes will have a listing in each. Large networks will use several BBSLIST and CONNECT files. All of these files should be placed in the DATA directory if your board is only on one network. If you are on more than one network, then the files for a particular network should be in its separate directory as you defined it in INIT option N. BBSLIST.NET - For a small network, this file can list all nodes participating in the network. The general format of this file is discussed in the appendices. A small network does not need any of the remaining BBSLIST.x files. In a large network, this file functions as a time/date stamp and will normally be two bytes long. If you did not get a file like this with your network data files and if things are not functioning properly, you may need to create this file. All that is necessary is to create a file name of BBSLIST.NET and put a single space inside of it and save it. BBSLIST.0 - This contains the numbers of valid groups in the network. It will look like an N*.NET file, sort of. All systems in the network will have a copy of this file. Let us say that a particular network has groups 1,2,3, and 60. In that event, the BBSLIST.0 file would appear as follows: ~754648789 A number such as the one given would appear on the first line following a tilde. This number is a time/date stamp and will change from time to time. :A This lets the software know that the information for each group will be found in separate files rather than in the BBSLIST.NET and CONNECT.NET. 1 2 3 60 Observe that the group numbers are shown one per line. BBSLIST.xxx - This file will have a number in the place of xxx. The number will be the group number and the file will have all of the BBSLIST.NET entries for that group. All systems will have a BBSLIST.1-255 for all groups listed in BBSLIST.0. However, the information in the file will pertain only to that group. You may note, at times, information in your network logs regarding bbslists ending in 5xx. Depending upon the type of software being used by your network for updates, these probably indicate that a "partial" update was received and processed. Normally after processing these files (the BBSLIST.5xx and CONNECT.5xx) are removed from the hard disk. CONNECT.NET -- For small networks, this file will reflect the connections of all nodes in the network. For a large network, this will be a time/date stamp type file similar to that discussed for the BBSLIST.NET. If things do not work right and the CONNECT.NET file is missing, try creating it with a space inside. CONNECT.0 - This file will exist on all systems for a large network and will show connections between systems in different groups. For example, if area codes 512 and 502 are part of the same group (group 4), a connection between boards in those groups is not between groups, even though it is long distance, and the connection would not be shown in the connect.0 file (it would be shown in the connect.4 file). However, a connection between 512 and 213 which are in different groups would be shown in the connect.0 file. Note that systems with connections listed in the connect.0 file will almost certainly also have connections listed in their local (group) connection file also. Some networks refer to groups as zones or regions so be alert for this difference in terminology in the respective network policy documents. CONNECT.xxx - This file will exist on all systems and will show connections between systems within that group. This will not show connections to systems in other groups. If your connection within the group will be calling you, then you need only wait until you receive the files. Thus, once this update arrives at the board which will be calling you, that board will callout to you and you will receive the necessary files. One exception to this is that some smaller networks use a different method of sending network updates. If you are on a small, private network, then you should check with your network administrator regarding what you should do (if anything) in order to receive updates. If you are to call the other board (and it does not call you), then you will need to keep in touch with that sysop so that you have an idea of when the network update comes in. If you obtain new network files via a download or some process other than receiving them through the network as an update, then you may need to force the network software to do an analysis. This may be done by using the following command at the DOS level. (Note: if you are on more than one network, you may need to use "dot commands" as discussed in the appendix. NETWORK3 That will run NETWORK3.EXE which analyzes your BBSLIST, CONNECT, and CALLOUT.NET files. If you add a Y after the command (ie space Y) then the network will send you a form letter as feedback letting you know the results of the analysis and sometimes identifying problems with your setup. Although it is natural for you to want to begin to subscribe to subs and so forth, you should exercise patience until you are 'officially' in the network. If you order subs before your board is official, then your system will show up as "unknown" and the mail will not reach you. Since many hosts of subs like to send new subscribers the rules regarding posting on that sub, the fact that you are an unknown system may result in a delay in your receiving the sub. If you wait until you are officially in the network, then these problems are avoided. If you are joining more than one network, it is important that you establish these connections ONE AT A TIME. The reason for this is simply that if you have several CALLOUT.NET files that have not established passwords and so forth for your connections, it is possible to have the passwords get confused (ie an incorrect association between network and password established). This may be avoided if you proceed in an orderly fashion and add one network at a time. 6.5. Information Needed for BBSLIST listings Your Board Name -- exactly as you want it to appear in the Network. You may wish to peruse a current listing of boards on the network in order to select a name that is unique. Your telephone -- this should include both area code and complete number. Maximum Baud -- this should be the maximum baud rate that you can support. If you are using a high speed modem capable of more than 2400 bps then you should indicate the rate that your serial port is locked at as the maximum baud rate or the maximum connect speed supported. You should check with the network administration for the conventions followed on the network that you are joining. The network software reports various information regarding hi-speed modems. These parameters are discussed in the appendices. Some networks will also want either your registration number (if you are registered). That information may (or may not) be reported in brackets in the BBSLIST information. The information above will be included in the BBSLIST.XXX for your group along with a group identification number. In that listing, some networks identify area coordinators (AC's) by a ^ next to the telephone number. Group or Zone Coordinators are often identified with a %. 6.6. Net Editor Black Dragon (1@3080 WWIVnet) developed the Net Editor to facilitate the updating of network files by sysops and Area Coordinators. That program is fully compatible with all network data structures since the beginning of WWIVNet to the present. You should check with your network administrators regarding whether or not updates in that format are acceptable to them. Some administrators will not be setup to receive them from netedit. 7. USING THE NETWORK Using the network is relatively simple. Sending netmail, subscribing to network subs and hosting network subs are discussed in this section. 7.1. Sending Netmail Netmail is like email on your local system. That is, users on your board may send email to one another by entering either the name or user number of the person that the mail is to be sent to. In netmail, you must also use the node number as part of the addressing scheme. Suppose that user number 5 on your system wishes to send netmail to user 2 (KatyDid) at 3451. In that case, the netmail could be addressed as follows: 2 @3451 -or- KATYDID @3451 Please note that this is merely an example; there is no user named KATYDID @3451. If the BBS is using NET32 or later and v4.22 or later, and that board is on multiple networks, the software will provide a listing of choices if the node number given is not unique (ie exists on more than one network to which the board is a member.) Such mail may be sent by the user in one of several ways. The user could simply use the E option to send email and then address it properly. The user might use the A response to send a private message to someone who has posted on a national message base, or the user might use either the A or S to respond to a message received privately from another system. Any of these methods will result in netmail being sent to another system. Mail may also be sent from one WWIV-based NetWork to another by using the following type of addressing: NETWORK NAME #UserNumber AT NodeNumber @XXXX where XXXX is the gateway node number. For example to send mail from WWIVlink to user #1 at node number 1 on WWIVnet, the mail would be addressed as follows: WWIVNET #1 AT 1 @2050 That is just an example. Any node that is running the NET32 software can function as a gateway node provided that it has connections in both networks. Addressing gateway mail by name is also permissable. For example, to address Wayne Bell by name in the previous example, you would use: WWIVNET RANDOM AT 1 @2050 For those who care, Random is Wayne Bell's handle. 7.2. Subscribing to a Netted Sub The method of subscribing to a networked message base depends upon the version of NETxx that you are using. To subscribe to a message base hosted by another system (i.e., a netted sub) while using NET30 or earlier, there are 3 things which you must do. First, you should send netmail to the host of the sub requesting that she place you on the distribution list for that sub. It is a good idea to name the sub and sub-type in that letter as many people host more than one netted sub and it will prevent them from getting confused. Second (for versions prior to NET32), you should enter your DATA directory and create a file. The name of the file should be NNsub-type.NET and it should have the host's node number in it. Although you can do this with an ascii text editor, it may be easiest to do this from the DOS level with the copy con command. To accomplish this, type in the following (note information beginning with -- is commentary and should not be typed) assuming that you are subscribing to the WWIV New Sysop's sub (sub-type 22050; hosted by 2050): copy con NN22050.NET --followed by an ENTER or RETURN 2050 F6 --the F6 means press Function key 6 or you can hold control down and press Z. A successful result will result in the message "One file copied" being seen on your screen. Please be sure to put two N's in the NNxxxx.net file. One N is used for a host system, so if you put a file with one N into your data directory, it will result in messages being doubled, most disconcerting to the host and other systems which subscribe to that sub. Starting with WWIV v4.20 rev D and ending with NET31, there is an alternative to having many little nn*.net files in your DATA directory. You can list all the subs you subscribe to in the file 'NNALL.NET' in your DATA directory. Each line in the NNALL.NET file contains the information for one subboard. The first number on the line is the sub type, and the second number is the host system. Anything after that is a comment. For example, you might have the following lines: 1701 1 Star Trek sub 10001 1 Politics sub 22050 2050 WWIV New Sysop's sub Note that you >MUST< be using WWIV v4.20 rev D or later for this to work. Starting with NET29, it was possible to auto-request a sub. This meant that if the sysop had listed the sub in a file called ALLOW.NET in DATA, then the subscriber/sysop could automatically request the sub. This method has been further refined under NET32 and v4.22 of WWIV so that the ALLOW.NET is not used and the NNALL.NET is not used either. SUBS.XTR contains all of the pertinent information regarding the sub and the networks that it is on. The third step is to either use B (for boardedit) when you are at W-F-C or type //boardedit when you are logged onto your BBS and then set up the message base. Be sure to indicate the sub-type number in the option for that: Completed result for the New Sysop's Sub might look like the following under v4.22 : A. Name : WWIV New Sysop's Forum B. Filename : NEWSYS C. Key : None D. Read SL : 60 E. Post SL : 60 F. Anony : No. G. Min. Age : 0 H. Max Msgs : 50 I. AR : C J. Net Info : Network Type Host Flags a) WWIVNet 22050 2050 K. Storage typ: 2 L. NetValidate: No M. Require Ansi: No N. Disable Tag: No O. Description: WWIV New Sysop's Forum for Help & Advice on WWIV Since the host of New Sysop's Forum permits visiting sysops to read and post and since the sysop of this board assigns an SL of 60 and an AR of C to visiting WWIV sysops, he can be sure that the host's requirements are met. Although you are not required to do so, it is a good idea to send a short thank you or other acknowledgement to the host to let him know when you begin to successfully receive messages on the sub. If the host has special rules and regulations that you need to inform your users of, you may do this in several ways. You could include such information in a form message (i.e., a message named FORMxx.MSG where the xx may be either integers or letters) which you send to all users. You also might make the first message on the message base contain the rules and then make it a permanent message. If you choose this form, be sure to make such a message before you get hooked up to receive the messages, else your message will go out on the network. Finally, you could put a synopsis of special rules in the GFILES area and direct your users to read that. 7.3. Hosting a Netted Sub As part of some networks, you will receive SUBS.LST, a listing to be found in your network dATA directory regarding the various networked subs that are available for you to subscribe to. At some point, you may wish to host a netted sub yourself. If you do, you should first make sure that there is not another sub already out there serving the same need. If there is, then you should only host a sub on the same topic because you think that you can do it better or because yours will have a special slant. On the other hand, you may have expertise in an area or information on a subject which is not being currently addressed on your network and for which you think that there might be a demand. In that case, you could decide to host such a sub. To host a sub, you must create an Nsub-type.NET file in DATA and in it, you should keep a list of the systems which subscribe. The list may be vertical or horizontal as long as there is a space between numbers when they are placed horizontally. Personally, I recommend a vertical listing from lowest to highest; that way you can easily tell when a sub has already subscribed. The traditional numbering of subs would start with your node number. For example, assume that you were node 5290, then your logical sub numbers would be: Hosted Sub Sub-type Host First 5290 5290 Second 15290 5290 Third 25290 5290 Fourth 35290 5290 Fifth 45290 5290 Sixth 55290 5290 You may observe, however, that not all subs in a network are numbered this way. This is because of two occurrences. First, many boards hosted subs before this numbering system was developed. Secondly, sometimes the original host ceases to sponsor a sub and another sysop takes it over but maintains the original numbering scheme. For example, Sub-type 2370 is the number of the WWIV Modifications Net Sub which started in 1988 at the White Star Line. After Will Daystrom, the originator, no longer could host the sub, it was passed to others. Although the host number changed, the sub-type originally used continued to be used in some networks. Net32 and V4.22 of WWIV support a Sub-by-Name concept which means that you may use any legal 7 letters or characters as a SubType. This numbering convention will enable boards to handle more subs than was possible before under the sub-as-integer concept. NOTE that future changes (see Section 10 Future Directions) may effectively necesitate your being able to use the sub-by-name approach. Thus if you have not upgraded your WWIV version, you should give some thought to doing so soon. You may want to develop a form message to send to those sysops who subscribe to your sub. Such a message should remind them of the name, sub-type, and host and it should provide any rules that you may have regarding who may access the sub or who may read/post there. Also you should get in the habit of reading your mail regularly and responding quickly to requests for the sub. If you have indicated (under NET32 and version 4.22) that the sub may be auto-requested, then if you have a file called SA......NET in GFILES, and if the dots are replaced with either the subtype number of the first 6 letters of the sub-by-name, then that letter will automatically be sent to those who subscribe to the sub with the autorequest function. You may wish to advertise your sub. There are some National netted subs which have been developed just for that purpose and you should use them if you can. The host has the right to run his sub as he sees fit and may establish any rules he wishes. The only restriction on sub topics is that they be legal. If a host chooses to 'throw' someone off of a sub, the individual has no recourse. Of course someone may start her own sub if she wishes. These rules are followed on most networks, however, you should refer to the documentation for the particular networks you are a member of to see if that network has different rules for sub hosts. WWIV v4.12 and following introduced a feature known as Net Validation. This feature may be toggled on or off in BOARDEDIT. When it is toggled on, messages will not leave your system until they have been validated. A host, when reading new messages on a sub, may press X to prevent a message from being sent out. After reading the messages, she will be asked, "Net Validate these Messages?" A Y response will result in all messages being sent out except those where an X was pressed. After all messages have been read, pressing X will cause them to be sent again. NOTE: This should not be done for it may result in sending out duplicate messages across the network. 8. NETWORK FILES 8.A FILES in same directory as BBS.EXE The files discussed below are the Network executable files which should be placed in the same directory as your BBS.EXE file. The files which belong in your DATA directory are discussed under 8.B. 1) NETWORK.EXE - This file is run when a BBS is calling another board through the network. This program handles the modem and the network security. 2) NETWORK1.EXE - This program analyzes P*.NET files to determine which are for local distribution and which are to be sent to boards that you connect with. The latter files will be stored in DATA in Sxxxx.NET files where xxxx is the node number of the receiving board, or in Zxxxx.NET files if the packet is compressed. 3) NETWORK2.EXE - This program analyzes local mail and distributes it to the proper message sub or to email. 4) NETWORK3.EXE - This program analyzes CONNECT.NET and BBSLIST.NET. The analysis may cause the network software to leave you messages. The sysop should read these messages and respond to them ASAP. These messages are discussed in the Appendix. 5) LNET.EXE - This program allows the deletion of corrupted messages prior to their being sent over the network. It can also be used to delete a message which the Sysop does not want to go out over the network....such as one which violates the spirit or rules of a Sub. As a general rule, a Sysop should not use LNET to read outgoing messages. One exception to this is to use LNET to read the messages in DEAD.NET. LNET cannot read mail in packets which have been compressed. DEAD.NET is a file to be found in DATA for messages that could not be delivered because the system and/or routing was in error. The header for these messages in DEAD.NET indicates the systems which it is for and the number of days since it was written. Sometimes messages go there because a new board has not gotten set up yet; but often they go there because one or more of the destination boards have gone down. If these messages are several weeks old, there is probably no harm in deleting the DEAD.NET. 6) DE1.EXE - This program analyzes net packets to make certain that it is authentic. Such packets are referred to as Source Verified messages. This file is NOT used by all networks. Since it is network specific, if you are a member of more than one network, you should place this file in the network data directory. 7) DExxx.EXE - This program authenticates updates received from the group coordinator. Again, this files is not used by all networks and it is network specific. If you are on several networks, put these files in the network data directory for each separate network. 8) NETINIT.C - This file needs to be used only if you have registered WWIV and have modified the structure or size of the userrec structure. If you have modified it, compile and run NETINIT and it will store information necessary for the network in the CONFIG.DAT file. 9) REQ.EXE - This file is provided to allow those systems that do not run WWIV BBS software a means of auto-requesting subs. Additional files may be added to the network as the development progresses or some of the existing files may be changed and/or eliminated. 8.B Files in your Network Data Directory The files that belong in your network data directory will vary somewhat from network to network depending upon whether the "large" or "small" form or file organization is being used and upon whether or not the network employs group or zone coordinators who send out updates. As mentioned earlier, those executables (like DEx.EXE type files) belong in the network data directory. In addition, the BBSLIST.NET and possibly BBSLIST.1, BBSLIST.2, etc., the CONNECT.NET and possibly CONNECT.1, CONNECT.2, etc. and the CALLOUT.NET files must be present in order for the network to function properly. When the network analysis is performed by NETWORK3.EXE, additional binary data files will be created such as CONTACT.NET, BBSDATA.*, etc. You may also find FBACKHDR.NET (an information file distributed by the net coordinator for the network), SUBS.LST and perhaps SUBS.1, SUBS.2, etc which provide information on the subs available in the network. CATEG.NET, an information file that permits sub hosts to categorize their subs so that they automatically show up in SUBS.LST according to the proper category. NETWORKS.LST, a file showing the various WWIV networks and whom to contact for additional information on that network as well as information on the coordinator of that list so that persons creating a network will know whom to contact to get their network on the listing. 8.C "Dot Commands" Beginning with NET32, it is possible to use "dot commands" when it is desireable to force a network executable to work with a specific network. If no "dot command" is used, the program defaults to using the network executable with data in the DATA directory. On the other hand, if you are on more than one network, Option N in INIT will create a file called NETWORKS.DAT in the DATA directory. Dot commands work by using data from the networks in the order listed in the NETWORKS.DAT file which is the same order that you see when you use option N in INIT. The first network listed is associated with .0; the second with .1, etc. For example, to force LNET to run on the DEAD.NET file in the second network listed, you would use LNET .1. To force a network analysis on the third network listed, you would use NETWORK3 Y .2. Under NET31, it was necessary to set environmental variables to make these commands work. These environmental variables are no longer needed under NET32 and should NOT be used. 9. TROUBLE-SHOOTING NETWORK CONNECTIONS Utilizing the NETWORK is really very simple. If you have tried everything you can think of to remedy a problem and are unable to do so, contact one of the Sysops of a SUPPORT Board and enlist aid. Do not contact WAYNE BELL except as a last resort. Sometimes there are problems with the code and/or its compatibility with different modems; however, those type of problems can only be addressed after all other avenues have been thoroughly explored, and even then that may not be the solution. For example, many WWIV Sysops have registered the WWIV software, obtained the source code and made extensive modifications to the BBS.EXE. In that event, it may be a modification that is causing the problem rather than the network software. When seeking help, be prepared to provide information on your system, your modem, the error messages you get and so forth. Debugging network problems is usually a process of eliminating the various possible sources of problems one by one. Any information which you can provide to speed this process makes it easier on all concerned. A few common problems, and their solutions, are described next. 9.1. You force callout and the cursor returns to WFC First, be sure that you are attempting to force the call during any agreed upon hours. If it is not during the agreed upon hours, the network software will prompt you "Are you sure?" An affirmative response will allow the call to proceed. If the call does not connect, you should double check the CALLOUT.NET, CONNECT.0, and BBSLIST.x to be sure that no typographical errors were made. Zeros cannot be o's, group designators must be correct, etc. Also, under Net20 and later you should ensure that all files in your network dATA directory are correct as they affect your board and the board that you connect with. For example, a failure to show your connection will cause an error. If no typographical errors were made, run network3.exe from DOS level and force a reanalysis. If after doing all of these things, the board will still not call out, go to your network data and delete BBSDATA.NET, BBSDATA.IND, and BBSDATA.ROU as well as CONTACT.NET and rerun the NETWORK3 program which will force the reestablishment of the deleted files. This will often cure the problem. If it does not, first check your NETDAT0.LOG in GFILES to see if it provides any clue as to the nature of the problem. If not, you should then contact one of the support boards and explain your problem in full detail. The command line NETWORK3 Y will force local feedback to be sent to you from the network software. The resulting information may be useful in determining problems in your network setup. 9.2. Your board calls out and gets a "Bad PW" message The "Bad Password" message will show up in your net log which is readable from WFC by pressing N. If that is the case and a successful connection has never been made, then the remote sysop should ascertain that the CALLOUT.NET is correct. If so, then check the CONNECT.x and BBSLIST.x. If a successful connection has been made in the past and a password between the two boards has been established, then try again as line noise may be the culprit. If the "Wrong Password" persists over several tries, then it is possible that a file has become corrupted. In this event, both you and the remote sysop need to delete the password which was generated by the network and let the net software reestablish the password. If you have never successfully connected with the other board, then the error may be due to the other sysop's not having setup for the connection. You should contact him and ascertain whether or not the connection if reflected in his CONNECT.xxx file or CALLOUT.NET file. It may also be that a faulty connection caused his board to create a password whereas yours did not. 9.3. Your board calls and gets a "NO NET" message This occurs when an unsuccessful connection occurred. Often it is only because the other board is busy. The remedy is to try again. If the board is a new board and you know it is not busy, then both you and the other sysop should make certain that all files are in the proper places. There are several Binary files created by the network. These are CONTACT.NET and BBSDATA.*. Sometimes these files will become corrupted and this may be the cause of a failure to establish a connection. You may delete these two files from the DATA directory and then run NETWORK3.EXE again. This re-analysis will recreate those two files and may cure the problem. This problem (no net) may also occur when the modems have connected but are not recognizing each other's signal. It may be that one modem thinks the connection is at 14.4k whereas the other thinks it is at 12k or something else. 10. FUTURE DIRECTIONS In the near future, WWIV BBS software is likely to include some of the following features: REMOTE access by boards or users as a Sysop Selectable option. This feature would be similar to the SNARF software sometimes used as an external utility on WWIV boards. This option is currently under development and will support direct calls from your board to others in multiple networks using Zmodem and/or HSLINK and using PcPursuit or normal connections. It will be capable of utilizing the WWIV macro commands, will provide logging features, and will provide the ability to send or receive specified files. OFF-LINE READER(s) for users to download message bases, read and reply while off-line and then upload responses. This feature seems to be well-developed and is available through 3 QWK mail readers and the WOMR for WWIV systems only. Increased INTER-NetWorking among established networks. Although this currently occurs under NET32 and v4.22 with WWIV-based networks, this inter-networking is likely to be extended to other networks such as FidoNet and/or UUCP net. A change in the method of assigning node numbers. WWIV-based networks have generally assigned node numbers that took advantage of the fact that all US area codes had either 0 or 1 as a middle digit. Thus, nodes 00 - 49 were indicated by using the first and last digit of the area code as the first two digits of the node numbered followed by 00-49 if the area code had a middle digit of zero and by 50-99 if the area code had a middle digit of one. Growth in the number of US phones as well as a desire to maintain compatibility with some international phone companies has led the phone companies of the USA to announce that they will begin assigning area codes having neither zero or one as the middle digit. Different networks may handle this in different ways. WWIVnet has decided to handle this by using a node numbering system whereby the group that a 4 digit node is in is represented by the first digit of the node number. A 5 digit node number will have the group as the first 2 digits. Node numbers will no longer reference the area code. Each group will have a maximum limit of 1000 nodes. One aspect of this future renumbering will be that the traditional means of indicating the sub numbers available for a board to use ( see Section 7.3) will no longer work well. This change will probably mean that either some person(s) within each net must be made responsible for subtype numbers or that widespread use of the sub-by-name concept must be applied. Network coordinators and network administrators are strongly encouraged to give this matter serious consideration and sysops are alerted to the fact than a mandatory upgrade in WWIV and network software may occur as a result. Some of these developments will be due to the direct efforts of Wayne Bell and others will be due to the efforts of programmers and others who are dedicated to making WWIV the finest software available. If you have questions about anything in these documents, you should first ask your network administration for explanation or help. If they do not know the answers, then contact Filo (1 @2050 WWIVnet, WWIVlink, IceNET), and only as a last resort contact Wayne Bell (1 @1 WWIVnet or 1@3050 IceNET). Because WWIV BBS software and network software are dynamic, growing, and constantly improving, these docs will be updated from time to time. 11. APPENDICES 11.1 Appendix A - Macro Language A macro is not normally needed for calling another BBS with the network software. However, when it is needed for reasons discussed in the body of the documentation, then it should be used. Use of a macro is indicated by using a %x in the CALLOUT.NET with at least one space following the node number and before the % sign. The x should be an integer. In the network data directory, a file called Mx.NET should be created which contains the macro. The x should be the same integer as that used in the CALLOUT.NET. You may have several different macros where they are necessary. The network macros should have one of the COMMAND words listed below on the left margin of the macro, followed by additional information within quotes following the command line. See appendix B for an example for a macro that might be used for a PcPursuit connection. The commands supported are listed below in alphabetical order. It is common to have DEBUG as the first line of the macro. DEBUG -- This command should start the macro and should be followed by an open and close quote (""). This will cause results to be echoed to the screen. DIAL -- This command causes the modem to dial whatever number that you put there. (For example, DIAL "631-5841"). You can also use two replaceable parameters with this command, %1 for area code and %2 for the 7 digit phone number shown in BBSLIST.x. FAILURE -- This command allows you to define a failure condition. Typically the failure is "BUSY". PARITY -- This command allows you to set the parity at something other than 8N1. SEND -- This command causes whatever is in quotation marks to be sent via the modem. The information in quotes must end with a left brace ({) which in the macro language indicates a carriage return. You can also use the send command to dial the phone if yout put everything that must be provided to the modem (for example, SEND "ATDT631-5841{" would cause the modem to dial the number indicated. SETBAUD -- This command allows you to set the baud rate for the call. SPEED -- This command allows you to set the comport speed for the call. SUCCESS -- This command allows you to define a success string. TIMEOUT -- This command will cause the modem to pause for the number of seconds indicated or until a WAITFOR condition has been met, whichever comes first. WAIT -- This command is similar to the TIMEOUT command except that the modem or macro will wait the number of seconds indicated regardless of any following WAITFOR condition. WAITFOR -- Anything in quotes following this command will be the condition that the macro waits for before continuing. 11.2. Appendix B - PcPursuit Macro DEBUG "" {enables you to see what happens} SPEED "2400" {speed you are calling at DIAL "686-2452" {put your local PcPursuit Access # TIMEOUT "7" SEND "~@~D~{~D3{" WAITFOR "@" send "~D~{" waitfor "NOT" send "~D~{" waitfor "NOT" SEND "~C D/MOSLO/24,password,idnum{" {each city has its own code TIMEOUT "7" FAILURE "D/MOSLO/24 BUSY" SUCCESS "ANSWER TONE" WAITFOR "D/MOSLO/24 CONNECT" SEND "~I{" SEND "~ATZ{" WAITFOR "OK" SEND "ALT 5{" {see comment below WAITFOR "HELLO" TIMEOUT "30" DEBUG "" SEND "D%2{" WAITFOR "DIALING" FAILURE "BUSY" WAITFOR "ANSWER" The ALT 5 character referred to above can be made with an ascii editor capable of using extended ascii symbols. The actual symbol looks like the Club suit in a deck of cards, "the puppy track". You can make this character by holding the alt key down, pressing a 5 on the number pad and releasing the ALT key. The macro above has been used successfully for PcPursuit connections. The comments on the right side after the left brace ({) should not be typed; they are only partial explanations to help you understand what the macro is doing. Note that each SEND line ends with a left brace. In the MACRO script language this signals a carriage return. In PcPursuit, each pursuitable city has a city code. In the example above, MOSLOW is St. Louis, Missouri. You would need a macro for each city that you call. The %2 in SEND "ATDT%2" is the 7 digit phone number which the macro will take from the BBSLIST data. In conjunction with DIAL or SEND, you may use %1 for the area code and %2 for the 7 digit telephone number. If you use DIAL, you do not need to use the ATDT command; but with SEND you need it. Using the simple script language contained above, you can develop elaborate scripts. In our area, we have written scripts that logged the network onto QBBS and RBBS boards and selected Door programs which were WWIV setups which in turn ran the network. If you have trouble developing the scripts to use for a particular application, you should be able to get help from any Support Board. You will need a text file taken from a screen capture of what you are logging into. Then the support board should be able to help you develop the appropriate script for you to use. 11.3. Appendix C - Network message types The network recognizes various types of major and minor type messages, and these are often reflected during the analysis which takes place after a network message is received. The information which follows briefly explains each of these message types. These types may be expanded in the future. main type 1 - net info (all type 1 msgs must be use method==1) 0 - feedback to sysop 1 - bbslist.net 2 - connect.net 3 - subs.lst 4 - wwivnews.net 5 - fbackhdr.net 6 - Additional wwivnews.net text 7 - categ.net 8 - networks.lst main type 2 - email (no method requirements) minor type not used main type 3 - post (from host to subscriber. numeric sub types only) (no method requirements) minor type is sub type main type 4 - UNUSED main type 5 - pre-post (from subscriber to host. numeric sub types only) (no method requirements) minor type is sub type main type 6 - external msgs (no method requirements) minor type is external message type main type 7 - email by name (no method requirements) minor type not used (name of destination user at start of msg text) main type 8 - net edit msgs (email 1@3080 WWIVnet for a list of these) main type 9 - subs.lst 0 - subs.lst 1 - subs.1 2 - subs.2 ... main type 10 - UNUSED main type 11 - bbslist.* (method must be 1 or ((minor_type % 256)+256)) 0..255 - bbslist.<minor-type> - full bbslist update NC-net 257..511 - bbslist.a<minor-less-256-in-hex> - full bbslist update GC-NC 513..767 - bbslist.<minor-type> - partial bbslist up NC-net main type 12 - connect.* (method must be 1 or ((minor_type % 256)+256)) 0..255 - bbslist.<minor-type> - full connect update NC-net 257..511 - bbslist.a<minor-less-256-in-hex> - full connect update GC-NC main type 13 - unused main type 14 - group info (from GC) (method must be 257..511) 0 - email to sysop main type 15 - ssm (no method requirement) minor type unused main type 16 - sub add request (no method requirement) 0 - sub by name, sub name first part of text other - minor-type is sub-type main type 17 - sub drop request (same desc as 16) main type 18 - sub add response (same desc as 16 plus..) first byte of text (after sub name, if any) is status of request main type 19 - sub drop response (same desc as 18) statuses for 18&19: 0 - ok 1 - not host 2 - not there (can't drop you) 3 - not allowed to add/drop this sub 4 - already there (can't add you again) main type 26 - post by name (no method requirements) minor type unused sub type is first part of msg text this is from subscriber to host, and from host to net main type 27 - new external (no method requirements) minor type is external type (see section <whatever>) NOTE: all major type 1, 11, 12, and 14 messages are appropriately source-verified. Information for this appendix supplied by Wayne Bell, Random, 1@1 WWIVnet. 11.4. Appendix D - Identifiers Used in BBSLIST < USRobotics HST protocol > Hayes V-series protocol | Telebit PEP protocol ! V.32 protocol $ V.32bis protocol / Compucom 9600 protocol ? Fax modem ^ Area code coordinator % Group coordinator & Network Coordinator + Network Server = PCPursuit connection(s) \ FidoNet front-end _ Dead-end node. The identifiers above may be stacked together. For example, "<!$" would indicate a U.S. Robotics modem that is v.32 and HST compatible and supporting v.32bis. This list will be expanded from time to time as other hi-speed modems enter the network. The identifier for dead-end node should not be used except in emergencies. It is a means to force the network to treat a node that would NOT normally be a dead end node as if it were one in order to facilitate temporary re-routing of messages. 11.5. Appendix E - Using the Net Software for Private Networks The network software may be used for any legitimate private network as long as the user understands that the author is under no obligation to provide the software which distributes network updates and as long as the functioning of the private network does not interfere in any way with the functioning of other WWIV-based networks. The author will assume no responsibility for insuring the operation of any private networks or any other network utilizing WWIVnet or WWIV software. Further, the WWIV support board Sysops are under no obligation to explain how to set up and/or operate a private network. Of course, even for private networks, in order to continue using the WWIV network software past the two month trial period, you must have either registered WWIV, or (for BBS software that is in no way based on WWIV software) registered the WWIVnet software. The NETUP software developed by Wayne Bell and used by some networks for updating their network files may be purchased for $300 by contacting 1@1 WWIVnet or WWIV Software Services. 11.6. Appendix F - Automated subboard requests Net29 and above support automated subboard subscriptions. In order for this to work, BOTH systems (the host and the subscriber) must be running Net29 or later. The program 'REQ.EXE' can be used to subscribe or drop subboards. There are some files associated with automated subscription under Net29, Net30, and Net 31: ALLOW.NET (in the DATA directory) - lists subboard types that are under automated control. If you host sub type 1701, and you want systems to be able to automatically subscribe to it, you would have the number 1701 in the ALLOW.NET file. If a sub type is not listed in the file, or the file does not exist, then sysops will not be able to automatically subscribe to the subboard. DISALLOW.NET (in the DATA directory) - lists system numbers that are NOT allowed to automatically subscribe/drop subboards. If you want to keep a certain system from subscribing to any of your subs, place their system number in the DISALLOW.NET file. SA*.NET (in GFILES directory) - This is a text file that is sent, as part of a pseudo-email, to a sysop when they are added to a sub. If you host sub 1701, then the file 'SA1701.NET' would be appended as part of a piece of mail to the sysop that is subscribed to the sub. It can give any rules of the sub, etc. The DISALLOW.NET file may still be used with NET32 and higher. SR*.NET (in GFILES directory) - If a system is not allowed to automatically subscribe to a sub (if the sub isn't listed in the ALLOW.NET, for example), then this piece of mail is appended to a message informing the sysop that he cannot be automatically added to the sub. The file should list why it isn't under automated control, and if it would be worth the effort to email the sysop and ask for it. This option also works with NET32 and higher. The REQ.EXE program is very simple to use. You need to know only if you want to add or drop the subboard, the sub type, and the host. You then put all this info on a command-line, such as: REQ A 1701 1 To REQuest an Add to type 1701 hosted by @1. To drop the sub, you'd say: REQ D 1701 1 You should get email back from the system when you are automatically added/dropped from a subboard. You will get no mail back, and nothing will happen, if the remote system isn't running net29 or later. If you request to be added to a subboard that you don't have configured into your system (in //boardedit), then when the response comes back indicating you were added, the network will automatically request that you be dropped from the subboard (since there is nowhere for the messages to go), and you will NOT get an indication in feedback. 11.7 Appendix G - Multi-Networking with NET 31 and v4.21a Beginning with NET31 and v4.21a of WWIV it is possible to network among WWIV-based networks rather easily. The methodology for doing this is discussed more thoroughly in the documentation for WWIV v4.22. 11.8 -Appendix H - USING HS/LINK WITH WWIV & NET32+ HS/Link WILL work properly on most WWIV systems using its DEFAULT settings (NO HSLINK.CFG file). Put HSLINK.EXE in your main BBS directory. Add a caret (^) to the desired lines in CALLOUT.NET and have the systems you connect do the same (it must be present at BOTH ends). Once this is down, if you have 103k free when the system attempts a NET callout and HST protocol is NOT in use, it will use HS/Link for the NET transfer. This probably will NOT work if you are using PC Pursuit. (see below) For more information on using and optimizing HS/Link for WWIV, download and read WWIVHSLK.ZIP which can be found on most Source Distribution Systems, and many others. It may also appear under the filename of HSLKWWIV.ZIP === Info for PC Pursuit users === The problem with PCP is that being a timeshare net, it does not transmit data continuously, especially during busy times. There may be delays in data transmission. If the HS/Link default block size of 1024, or 4096 is used, and the default window of 8 is in effect, HS/link will send 8 of these blocks before stopping for an acknowledgment. If PCP is busy, this may be more data than it can "swallow" in one gulp. Once PCP gets behind, it may have problems recovering, in which case the data may or may not get thru. Even if it does, the ACK may not get back to the sending end, in which case HS/Link waits for it's internal timeout, before trying again. Often PCP cannot recover at all, and HS/Link will finally abort the transfer. This problem can be resolved by using smaller blocks, and smaller windows. A setting of 512 or smaller for the block size is recommended, and a window of 4 should work fine. This will give PCP smaller blocks of data, and HS/Link will stop more often to check that the data has been received. You can force these settings by creating a file called HSLINK.CFG with your ASCII editor. It should contain only the following two lines, and should be in the same directory as HSLINK.EXE: -S512 -W4 CURRENT HS/LINK VERSION : Be sure to use the LATEST release of HS/Link. While the current version is always compatible with older versions, you will not get the benefit of the latest enhancements and fixes if you are using an old version. LOG FILE Starting with v1.13D0, HS/Link will create a logfile if the environment variable HSERR is defined. To create a logfile called HSLOG.TXT on your C drive in your Gfiles directory, just add this line to your autoexec.bat file. SET HSERR=C:\GFILES\HSLOG.TXT HS/Link will keep appending to this file, so you will want to provide some means of erasing, renaming, and or zipping it in your nightly event. === CAUTIONS if using a CONFIG file === DOWNLOAD DIRECTORY (-U) : This option controls the destination directory for incoming files. By default, HS/Link will put incoming files into the "current" directory. This is where WWIV is expecting to find them. WWIV changes to the 'TEMP' directory before receiving files. The BBS will move the files to where they belong, so the -U OPTION SHOULD NOT BE USED for the BBS. FORCE REMOTE TO USE LOCAL OPTIONS (-!) This option causes the remote (called) end to use some of the options specified by the calling end. This does NOT affect any of the options having to do with security, such as the upload path, or the overwrite option. It does affect block size (-s), xon/xoff (-hx), and windows (-w). NET32 will append the -! option to the HS/Link command line for outgoing calls, thus forcing the remote to use these settings for NET transfers. Since it is not present on the command line for incoming NET calls, the calling system will be able to use the settings that are best for his phone lines. It SHOULD NEVER BE PRESENT IN THE CFG FILE THE BBS WILL BE USING! MINIMUM BLOCKS (-nm) : Removes block numbers from each block, thus saving a few bytes. No improvement in performance has been measured. It's effect is similar to that of Ymodem-G, and the results can be catastrophic if an error does creep in. This option SHOULD NEVER BE USED! SLOW HANDSHAKE (-hs) : Sends Xoff or lowers RTS during disk I/O. This causes the computer to signal the modem not to send any data during disk I/O. It is available for systems with slow disk access. It may help if you get frequent CRC errors or COM overruns on clean lines. Be sure NOT TO DISABLE Xon/Xoff HANDSHAKING IF THIS OPTION IS USED. Information for this appendix supplied by : Lance Halle 1@6211 WWIVnet MOON VALLEY TRIANGLE Phoenix, Az. 602-942-9228 24 hrs 11.9 Appendix I -- Meaning of symbols in SUBS.XTR 11.9.1 You are reminded that you should not modify these directly. Always use BOARDEDIT when making changes to this file. 11.9.2 Meaning of symbols A typical entry in SUBS.XTR might look like this: !8 @Novice & Veteran Sysops Helping Each other with WWIV #0 $WWIVnet 22050 3 0 !x = The number of the Sub on the board (ie the sub index in BOARDEDIT. @ = The long description for the sub (for auto-subs-info) #0 = Flags (currently not used but for future expansion) $NETWORK SubType Flags Host Category Flags are 1 for auto-addrop, 2 for auto-info (3 for both). Host is 0 if you are the host (you host it), otherwise the host system #. Category will be an option that will permit the sysop to self-classify a sub according to pre-defined categories, thus facilitating the maintenance of network wide SUBS.LST type files. The categories will be listed in CATEG.NET which will be found in the network data directory. 11.10 -- Technical Information regarding use of external message Interface Net33 (and later versions) will include a method whereby messages for external programs can be transferred through the network. This does not describe how to read network data files, or how to write net packets, only how to integrate a program that does those things with the network. (see the WWIV source code, or WWIVnet technical docs, for info on that.) All received message packets that are destined for the local system are stored into "LOCAL.NET" in your network data directory. The network2.exe program is then run to process the messages. If any messages are of the "new external" type (main_type_new_extern, 0x001b), then they may be saved for processing by an external net program. Each external network program requires a program (.exe or .com, NOT .bat), which will take as parameters a filename of a network file (p*.net format), and a network number identifier (.net_num). Each external network program can take as input a contiguous range of minor_type's. External network programs are described in the 'EPROGS.NET' which (optionally) exists in the network data directory. The eprogs.net file is a text file, and has a line describing one external net program per line. Each line has three pieces of information: the program name (1-8 chars), the starting minor_type, and the stopping minor_type. So, for example, if an external net program 'netprog.exe' is to handle main_type 0x1b, minor types 100-103, then the line in the eprogs.net file for that processor would be: netprog 100 103 (If the program handles only one minor_type, then the starting and stopping minor_types should both be the same, and equal to the minor_type to be processed.) As local.net is processed, any main_type_new_extern messages encountered cause network2 to search the eprogs.net file to see if any external net programs are set up to handle that minor_type. If none are found, the net message is thrown away. If there are two or more programs listed to process that minor_type, only the first receives the message. Net messages accepted for an external net program are stored to a temporary file while local.net has been processed. After local.net has been completely processed, and deleted, network2 runs the external net programs, in order, passing them the filename of the temporary net file for that program, and an indication of which network is being processed. After the program exits, the temporary net file is deleted. Note that it IS allowable for an external net program to create a p*.net file for outgoing messages, OR to put net messages to the local.net file which will be immediately re-processed by the BBS. Please do not blindly grab minor_types. If you need a lot of separate message types, the message type can be stored in the text part of the message and a single minor_type used instead. There are also local.net pre-processors allowed in net32. The preprocessors are listed in the 'epreproc.net' file in the network data directory, one per line. BEFORE network2 processes ANY of local.net, each preprocessor is run, in order, passing each the ".net_num" parameter to indicate which network is being processed. The pre-processor may then scan through local.net, and mark as deleted (main_type=65535) any message processed by that preprocessor. The preprocessor may even append additional messages to the local.net file, if that is desired. Information for this appendix supplied by Wayne Bell (Random), 1@1 WWIVnet.