High Voltage Shareware

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

/ High Voltage Shareware / high1.zip / high1 / DIR4 / REF19.ZIP / REF.DOC < prev next >

Wrap

Text File | 1994-01-22 | 38KB | 733 lines

┌───────────────┐ │ The REF 1.9 │ └───────────────┘ "The Message Area Referee" Compliments of: The HOTware BBS Net/Node 064/003 * PLEASE DELETE ALL Version 1.5 ARCHIVES, Ver. 1.5 CONTAINS * * NUMEROUS PROBLEMS AND SHOULD NOT BE USED * ────────────────────────────────────────────────────────────── History ────────────────────────────────────────────────────────────── 11-02-92 Ver 1.0 Initial Release 11-12-92 Ver 1.1 Added /LOG command line parameter. /LOG will cause a REF.LOG to be kept in <GTPATH>\HOTWARE. 10-31-93 Ver 1.2 Added the REVIEW flag. This gives REF the ability to REVIEW messages from select users prior to bagging the message area. Added the /REGISTER feature to REF. Added /NLOG (new log) to REF. 11-04-93 Ver 1.3 Major Bug Fix! When using The REF on multiple message areas, the Name's list was not being purged correctly. The result, any names that were in previously processed message areas were again being processed, even if the names were not listed for that message area. Please delete version 1.2 of The Ref IMMEDIATELY if you are processing multiple message areas from one configuration file. 11-07-93 Ver 1.4 Added four new "FLAGS": REVIEW_BY_ORIGIN, MOVE_BY_ORIGIN, KILL_BY_ORIGIN, MARK_BY_ORIGIN. These new "FLAGS" allow you to specify a list of NET/NODE numbers for REF to look for rather than sender names on messages. When using these new "FLAGS" REF will dynamically build the name list and add any names that it finds in your message area that has any of NET/NODE numbers that you listed. See Discussion below for further information. 1-01-94 Ver 1.5 Added four new "FLAGS": REVIEW_BY_RECEIVER, MOVE_BY_RECEIVER, KILL_BY_RECEIVER, MARK_BY_RECEIVER. These new "FLAGS" allow you to specify a list of RECEIVE names for REF to look for rather than SENDER names on messages. When using these new "FLAGS" REF will now look at the message Receivers rather than the message Senders. Please read the documentation below for further information. 1-02-94 Ver 1.6 MAJOR BUG FIX RELEASE! DELETE VERSION 1.5 IMMEDIATELY! Version 1.5 was very overzealous with Deleting Moving and Marking messages and SHOULD NOT BE USED. Version 1.6 fixes the problems with Deleting Moving and Marking of messages that should not be operated on. This version also adds a much improved logging logging facility and improved screens. This version also repairs a problem with comparing one word names. Previous version were not working with single word names. 1-18-94 Ver 1.7 Added four new "FLAGS": REVIEW_BY_SUBJECT, MOVE_BY_SUBJECT, KILL_BY_SUBJECT, MARK_BY_SUBJECT. These new "FLAGS" allow you to specify a list of SUBJECTs for REF to look for rather than SENDER or RECEIVER names on messages. When using any of the SUBJECT flags, the Search text can also match substrings if the first character of the configured subject is a *. REF is now much more intelligent when using the ORIGIN parameter. Rather than building a name list as before, version 1.7 will look at the ORIGIN of each message prior to operating on it. The third improvement for this release is a configurable message header. You may now specify what you want REF to report as the reason for the moved message. Please see the documentation below for details on the above new features. 1-21-94 Ver 1.8 Added three modifiers to the "FLAGS" argument in REF.CNF. These modifiers add two major improvements. The REF can now RETURN messages to the sender, and The REF can now be told to only operate on INCOMING or OUTGOING messages specifically. These modifiers are invoked immediately following your FLAGS argument in REF.CNF in for form of /INBOUND /OUTBOUND /RETURN. See the documentation below for details on implementation. 1-22-94 Ver 1.9 REF will now indicate in the LOG File when a message has been RETURNED to the sender. ────────────────────────────────────────────────────────────── What is It? ────────────────────────────────────────────────────────────── What in the heck is The REF? The REF basically acts as a referee of a Echo Message Area. This utility has two modes of operation that you can use. Both of these modes are described below: 1: Creating a true READ-ONLY echo area. The REF will allow you to specify who IS authorized to post in a particular echo. Any messages that are found in a configured echo that were posted by an UNAUTHORIZED user will be "refereed". The sponsor of the echo has three option to penalize the offending user. The REF can either MOVE the message, KILL the message, or MARK the message as bagged so that it will not echo throughout the network. All three of these flags are classified under READ-ONLY echo mode, and are described under CONFIGURATION AND EXECUTION below. 2: REVIEW messages TO or FROM users, by SUBJECT, or by ORIGIN. The REF will allow you to specify who's messages you would like to REVIEW prior to letting them echo to the network. If you have had problems with a particular or several users entering messages that are either off topic, vulgar, or generally disruptive The REF can help. The REF can move messages that are TO or FROM a configured list of user names, SUBJECTS, or ORIGINS to an alternate message area for you, the sysop or echos sponsor, to REVIEW prior to allowing the message to echo. The REVIEW flags are classified under REVIEW echo mode, and are described under CONFIGURATION AND EXECUTION below. Not only can REF read a list of User Names that you supply, it can also check the ORIGIN Net/Node of messages. If you are afraid of users using alias's, you can provide REF a list of NET/NODE numbers. The REF will then look at the ORIGIN of each message and operate on them if applicable. The REF also has the capability to RETURN the messages to the offending user, see the discussion of the /RETURN modifier below for details. ────────────────────────────────────────────────────────────── Why Is It? ────────────────────────────────────────────────────────────── You may be asking about now, Why would you want to do this? It's simple. Prior to the birth of The REF there was no real way of truly forcing an echo to READ ONLY. Now The REF can monitor the actions of the players in a particular echo and throw flags to any unauthorized maneuvers. In real life The REF scans the message area looking for users that are Unauthorized and can take appropriate action on these messages prior to nightly bagging routines. Further expanding on The REF, you can also truly REVIEW messages by users that have a reputation of causing disruption in your echo areas. You can now automatically move messages to an alternate message area by user name, review the messages content, and them move them and allow them to continue on the echo path at your discretion. ────────────────────────────────────────────────────────────── Configuration and Execution ────────────────────────────────────────────────────────────── The REF reads a configuration file named REF.CNF from a directory off your GTPATH named HOTWARE. For example if your GTPATH is set to C:\GT, the REF.CNF must reside in C:\GT\HOTWARE. REF has two modes of operation READ-ONLY ECHO mode, and REVIEW mode. These two modes will be explained separately and then examples will be shown using the two modes in a single configuration file. ──────────────────────────────────────────── READ-ONLY ECHO Mode ──────────────────────────────────────────── The READ-ONLY ECHO Mode looks at a list of users that are classified as AUTHORIZED users. Any users that The REF see's that is NOT in the AUTHORIZED list will be penalized. Under READ-ONLY mode you decide whether the message is to be KILLed, MARKed bagged, or MOVEd to an alternate area. If you are afraid that some folks might try to use Alias's to get by The REF, you can alternately supply a list of NET/NODE numbers that are AUTHORIZED users. The REF will then look at the .ORIGIN of each message and only allow AUTHORIZED NET/NODES. This is done through the use of the following flags: KILL_BY_ORIGIN, MARK_BY_ORIGIN, MOVE_BY_ORIGIN. You may also look at the message RECEIVER or SUBJECT instead of the message SENDER or ORIGIN. These options will allow you to create a message area that contains only messages TO a particular party, or messages that are a on specific SUBJECT. This is done through the use of the following flags: KILL_BY_SUBJECT, MARK_BY_SUBJECT, MOVE_BY_SUBJECT, KILL_BY_RECEIVER, MARK_BY_RECEIVER, MOVE_BY_RECEIVER. These are the twelve available "flags" that are used in READ-ONLY mode, KILL, MARK, MOVE, KILL_BY_ORIGIN, MARK_BY_ORIGIN, MOVE_BY_ORIGIN, KILL_BY_SUBJECT, MARK_BY_SUBJECT, MOVE_BY_SUBJECT, KILL_BY_RECEIVER, MARK_BY_RECEIVER, MOVE_BY_RECEIVER ──────────────────────────────────────────── REVIEW Mode ──────────────────────────────────────────── The REVIEW Mode looks at a list of users that are classified as UN-AUTHORIZED users. Any users that The REF see's that IS in the UN-AUTHORIZED list will be reviewed. Under REVIEW mode the messages will be moved to an alternate area (destination echo as described below) for you to REVIEW. If you are afraid that some folks might try to use Alias's to get by The REF, you can alternately supply a list of NET/NODE numbers that are UN-AUTHORIZED users. The REF will then look at the .ORIGIN line of each message and classify any messages that match a NET/NODE from your list as UN-AUTHORIZED. This is done through the use of REVIEW_BY_ORIGIN. You may also look at the message RECEIVER or SUBJECT instead of the message SENDER or ORIGIN. These options will allow you to specify UN-AUTHORIZED SUBJECTS or RECEIVERS. In other words if the SUBJECT or RECEIVER is recognized, The REF will move the message to an alternate message area for you. This is done through the use of the following flags: REVIEW_BY_SUBJECT, REVIEW_BY_RECEIVER. These are the four available "flags" that are used in REVIEW mode, REVIEW, REVIEW_BY_SUBJECT, REVIEW_BY_ORIGIN, REVIEW_BY_RECEIVER. ──────────────────────────────────────────── A Brief Discussion of Each "FLAG" ──────────────────────────────────────────── MOVE MOVE messages that *ARE NOT* FROM a User. The MOVE Flag will read a list of USERS that you supply in your configuration file. After this list of USERS has been read, The REF will MOVE any messages that *ARE NOT* FROM a user in the list. MOVE_BY_RECEIVER MOVE messages that *ARE NOT* TO a User. The MOVE_BY_RECEIVER Flag will read a list USERS that you supply in your configuration file. This flag works very similar to the MOVE flag, except The REF will look at the message RECEIVER rather than the message SENDER. After this list of USERS have been read The REF will MOVE any messages that *ARE NOT* TO a user in the list. MOVE_BY_SUBJECT MOVE messages that *ARE NOT* a particular subject. The MOVE_BY_SUBJECT Flag will read a list SUBJECTS that you supply in your configuration file. This flag works very similar to the MOVE flag, except The REF will look at the message SUBJECT rather than the message SENDER. After this list of SUBJECTS have been read The REF will MOVE any messages that *ARE NOT* a particular subject. This flag in particular will recognize wildcards. If the first character of your listed SUBJECT is a *, REF will search for the listed subject as a substring of the actual message subject. For Example: Your Specified Subject = *ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject will be recognized as a match and WILL NOT be moved by the MOVE_BY_SUBJECT parameter. Example Without Wildcard: Your Specified Subject = ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject WILL NOT be recognized as a match and WILL be moved by the MOVE_BY_SUBJECT parameter. MOVE_BY_ORIGIN MOVE messages that *ARE NOT* FROM a Net/Node. The MOVE_BY_ORIGIN Flag will read a list of NET/NODEs that you supply in your configuration file. After this list of NET/NODEs have been read The REF will MOVE any messages that *ARE NOT* FROM a one of these NET/NODEs. If you select this FLAG, The REF will read each message and look at the .ORIGIN line, comparing them to the list of Net/Nodes you have supplied. Any messages that ARE NOT from one of the listed Net/Nodes will be moved to an alternate message area. MARK MARK messages that *ARE NOT* FROM a User. The MARK Flag will read a list of USERS that you supply in your configuration file. After this list of USERS has been read, The REF will MARK Bagged any messages that *ARE NOT* FROM a user in the list. This will prevent any messages that are UnAuthorized from being bagged. MARK_BY_RECEIVER MARK messages that *ARE NOT* TO a User. The MARK_BY_RECEIVER Flag will read a list of USERS that you supply in your configuration file. This flag works very similar to the MARK flag, except The REF will look at the message RECEIVER rather than the message SENDER. After this list of USERS have been read The REF will MARK Bagged any messages that *ARE NOT* TO a user in the list. This will prevent any messages that are UnAuthorized from being bagged. MARK_BY_SUBJECT MARK messages that *ARE NOT* a particular subject. The MARK_BY_SUBJECT Flag will read a list of SUBJECTS that you supply in your configuration file. This flag works very similar to the MARK flag, except The REF will look at the message SUBJECT rather than the message SENDER. After this list of SUBJECTS have been read The REF will MARK Bagged any messages that *ARE NOT* on a particular subject. This will prevent any messages that are UnAuthorized from being bagged. This flag in particular will recognize wildcards. If the first character of your listed SUBJECT is a *, REF will search for the listed subject as a substring of the actual message subject. For Example: Your Specified Subject = *ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject will be recognized as a match and WILL NOT be marked by the MARK_BY_SUBJECT parameter. Example Without Wildcard: Your Specified Subject = ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject WILL NOT be recognized as a match and WILL be marked by the MARK_BY_SUBJECT parameter. MARK_BY_ORIGIN MARK messages that *ARE NOT* FROM a Net/Node. The MARK_BY_ORIGIN Flag will read a list of NET/NODEs that you supply in your configuration file. After this list of NET/NODEs have been read The REF will MARK Bagged any messages that *ARE NOT* FROM a one of these NET/NODEs. This will prevent any messages that are UnAuthorized from being bagged. If you select this FLAG, The REF will read each message and build a list of names that are allowed to post in the message area. The REF will scan the the messages in the message area, and dynamically build this list by looking at the ORIGIN line of each message. KILL KILL messages that *ARE NOT* FROM a User. The KILL Flag will read a list of USERS that you supply in your configuration file. After this list of USERS has been read, The REF will KILL any messages that *ARE NOT* FROM a user in the list. KILL_BY_RECEIVER KILL messages that *ARE NOT* TO a User. The KILL_BY_RECEIVER Flag will read a list of USERS that you supply in your configuration file. This flag works very similar to the KILL flag, except The REF will look at the message RECEIVER rather than the message SENDER. After this list of USERS has been read The REF will KILL any messages that *ARE NOT* TO a user in the list. KILL_BY_SUBJECT KILL messages that *ARE NOT* a particular subject. The KILL_BY_SUBJECT Flag will read a list of USERS that you supply in your configuration file. This flag works very similar to the KILL flag, except The REF will look at the message SUBJECT rather than the message SENDER. After this list of SUBJECTS have been read The REF will KILL any messages that *ARE NOT* on a particular subject. This flag in particular will recognize wildcards. If the first character of your listed SUBJECT is a *, REF will search for the listed subject as a substring of the actual message subject. For Example: Your Specified Subject = *ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject will be recognized as a match and WILL NOT be killed by the KILL_BY_SUBJECT parameter. Example Without Wildcard: Your Specified Subject = ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject WILL NOT be recognized as a match and WILL be killed by the KILL_BY_SUBJECT parameter. KILL_BY_ORIGIN KILL messages that *ARE NOT* FROM a Net/Node. The KILL_BY_ORIGIN Flag will read a list of NET/NODEs that you supply in your configuration file. After this list of NET/NODEs have been read The REF will KILL any messages that *ARE NOT* FROM a one of these NET/NODEs. If you select this FLAG, The REF will read each message and build a list of names that are allowed to post in the message area. The REF will scan the the messages in the message area, and dynamically build this list by looking at the ORIGIN line of each message. REVIEW MOVE messages that *ARE* FROM a User. The REVIEW Flag will read a list of USERS that you supply in your configuration file. After this list of USERS has been read, The REF will MOVE any messages that *ARE* from a user in the list. REVIEW_BY_RECEIVER MOVE messages that *ARE* TO a User. The REVIEW_BY_RECEIVER Flag will read a list of USERS that you supply in your configuration file. This flag works very similar to the REVIEW flag, except The REF will look at the message RECEIVER rather than the message SENDER. After this list of USERS have been read The REF will MOVE any messages that *ARE* TO a user in the list. REVIEW_BY_SUBJECT MOVE messages that *ARE* a particular subject. The REVIEW_BY_SUBJECT Flag will read a list of SUBJECTS that you supply in your configuration file. This flag works very similar to the REVIEW flag, except The REF will look at the message SUBJECT rather than the message SENDER. After this list of SUBJECTS have been read The REF will MOVE any messages that *ARE* on a particular subject. This flag in particular will recognize wildcards. If the first character of your listed SUBJECT is a *, REF will search for the listed subject as a substring of the actual message subject. For Example: Your Specified Subject = *ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject will be recognized as a match and WILL be moved by the REVIEW_BY_SUBJECT parameter. Example Without Wildcard: Your Specified Subject = ECHOMAIL Actual Message Subject = 064/003 ECHOMAIL REPORT This Subject WILL NOT be recognized as a match and WILL NOT be moved by the REVIEW_BY_SUBJECT parameter. REVIEW_BY_ORIGIN MOVE messages that *ARE* FROM a Net/Node. The REVIEW_BY_ORIGIN Flag will read a list of NET/NODEs that you supply in your configuration file. After this list of NET/NODEs have been read The REF will MOVE any messages that *ARE* from a one of these NET/NODEs. If you select this FLAG, The REF will read each message and build a list of names that are allowed to post in the message area. The REF will scan the the messages in the message area, and dynamically build this list by looking at the ORIGIN line of each message. ──────────────────────────────────────────── Flag Modifiers ──────────────────────────────────────────── The REF will recognize three distinct modifiers for each of the FLAGS above. The three modifiers that are recognized are /INBOUND /OUTBOUND or /RETURN. Please note the /INBOUND and /OUTBOUND cannot be used simultaneously, but /RETURN may be used in combination with either of the other two modifiers. The purpose of the modifiers are as follows: /INBOUND Process ONLY Inbound messages. If the Incoming flag is not set and you are using this modifier this message will be ignored. /OUTBOUND Process ONLY Outbound messages. If the Incoming flag IS set and you are using this modifier this message will be ignored. /RETURN The RETURN modifier will cause any unauthorized messages to be RETURNED to the author of the message. The default for The REF when this modifier is not in use is to simply move the offending message to an alternate area leaving the message Sender and Receiver intact. When this modifier is used the message will be have The REF x.xx as the Sender and the original author as the Receiver. The Ref will also extract the .ORIGIN Net/Node address from the message and address it back to the sender. This allows you to configure your netmail message area in the Destination Message Area Path in your REF.CNF. ──────────────────────────────────────────── Example Single Section Configuration File: ──────────────────────────────────────────── E:\READONLY READ-ONLY Echo <- Echo Path and Name to Referee E:\DESTAREA Destination Echo <- Destination Path and Name for Moves MOVE /RETURN This Is A RO Echo <- Flag, Optional Modifier, and Optional Text Rob Roesch <- Jim Wilson <--User List To Search Jim Knight <- END <- END to specify END OF LIST The Configuration File is laid out in sections as shown above. The above seven lines show ONE section of a complete configuration files. You are allowed to have as many sections in your config file as you like, as long as each section ends with an END statement as shown above. Each section contains five individual components. Line 1-2: The first two lines of each section will contain a full path and name of two message areas, the search echo, and the destination echo for moves. Line 3: The third line of each section must start with one "flag", MOVE, KILL, MARK, or REVIEW, MOVE_BY_ORIGIN, KILL_BY_ORIGIN, MARK_BY_ORIGIN, REVIEW_BY_ORIGIN, MOVE_BY_RECEIVER, KILL_BY_RECEIVER, MARK_BY_RECEIVER, REVIEW_BY_RECEIVER, MOVE_BY_SUBJECT, KILL_BY_SUBJECT, MARK_BY_SUBJECT, REVIEW_BY_SUBJECT. In addition to the "flag" you may specify flag Modifiers to alter The REF's scrutiny. The available modifiers are /INBOUND /OUTBOUND or /RETURN. All three are detailed above. In addition to the "flag" and optional modifiers, you may create your own text for The REF to use in the Header that is applied when the message is moved to an alternate area. If you do not specify any text here, the default messages will be used. The default text that is used is as follows: DEFAULT REVIEW MODE TEXT: ──────── *** ──────── This Message Was Moved From Your Message Area Name For The Purpose of Sysop Examination By The REF x.x ──────── *** ──────── DEFAULT READ-ONLY MODE TEXT: ──────── *** ──────── This Message Was Moved From Your Message Area Name By The REF x.x ──────── *** ──────── If you specify text following the "flag" your message will be customized with your text. For example if you place MOVE BECAUSE YOU ARE UNAUTHORIZED on line 3, your text will look like the following: ──────── *** ──────── This Message Was Moved From Your Message Area Name BECAUSE YOU ARE UNAUTHORIZED By The REF x.x ──────── *** ──────── Line 4-?: Line four is the start of the "Users List" if you are using MOVE, KILL, MARK, REVIEW, MOVE_BY_RECEIVER, KILL_BY_RECEIVER, MARK_BY_RECEIVER, or REVIEW_BY_RECEIVER. Line four is the start of the "Net/Node List" if you are using MOVE_BY_ORIGIN, KILL_BY_ORIGIN, MARK_BY_ORIGIN, or REVIEW_BY_ORIGIN. You may have up to 1000 entries in this list. Line four is the start of the "Subject List" if you are using MOVE_BY_SUBJECT, KILL_BY_SUBJECT, MARK_BY_SUBJECT, or REVIEW_BY_SUBJECT. You may have up to 1000 entries in this list. Last Line: The last line of each section MUST be END. The REF will continue to read each line as a user name until it see's END. ──────────────────────────────────────────── Example Multiple Section Configuration File: ──────────────────────────────────────────── The following example uses five individual sections to create a multiple section configuration file. E:\READONLY My READ-ONLY Echo E:\DESTAREA My Destination Echo MOVE Because It Was From An Un-Authorized User Rob Roesch Jim Wilson Jim Knight END E:\GTDIGEST GT-ONE Digest Echo E:\GTPNSYSOP GT-ONE International Echo MOVE Perry Alexander Bob Butcher END E:\MYECHO My Fabulous Echo E:\NETMAIL My Netmail Message Area REVIEW_BY_ORIGIN /RETURN You Are Unauthorized To Use This Echo 064/001 032/001 END E:\MYNEWECHO My New Echo E:\NEWREVIEW My New Echo Review Area REVIEW Jim Knight Perry Alexander END E:\NETMAIL1 My Netmail #1 Area E:\NETMAIL2 My Netmail #2 Area REVIEW_BY_SUBJECT /INCOMING Because I Wanted To Get It Out Of The Way *ECHOMAIL REPORT RETURN RECEIPT END In the above example there are five individual echos that fall under the scrutiny of The REF. You will also notice that the first two sections are READ-ONLY sections and the third, fourth, and fifth are REVIEW sections. Also note the use of WildCards when using the REVIEW_BY_SUBJECT flag, and that INCOMING messages only will be moved. You may place as many individual echos into this config file as you find necessary. There is no limit other than available disk space. The REF will continue to process each file until the End of File is reached..... The above example shows two echos, but you can run it with 1 or 5000, it's up to you..... ────────────────────────────────────────────────────────────── Command Line Parameters ────────────────────────────────────────────────────────────── Currently there are three, /LOG /NLOG and /REGISTER. /LOG If you want REF to keep a log file for you put /LOG on the command line. REF will keep an ever growing log file in the HOTWARE directory off the GTPATH directory. /NLOG If you want REF to keep a log file for you, erasing any old log file that may be setting around, put /NLOG (new log) on the command line. REF will erase any old log files, and create a new log file in the HOTWARE directory off the GTPATH directory. /REGISTER Kill Protect will the proceed to send me a netmail message informing me that you are using the program. Please use this feature ONCE. ────────────────────────────────────────────────────────────── ErrorLevel Exits ────────────────────────────────────────────────────────────── Errorlevel 0: Good run, no Errors. Errorlevel 1: No GTPATH Environment Variable Set Errorlevel 2: Cannot open REF.CNF Errorlevel 3: Insufficient Memory ────────────────────────────────────────────────────────────── Registration ────────────────────────────────────────────────────────────── I am not requesting any money for this program, but I would not turn any down either <g>. If you want to slip $5.00 into and envelope I'll accept it. Although I don't require a registration fee I would appreciate knowing that you are using the program on a normal basis. Therefore I have provided a simple and easy way for you to register this program. From the DOS prompt type: REF /REGISTER The REF will the proceed to send me a netmail message informing me that you are using the program. Please use this feature ONCE. ────────────────────────────────────────────────────────────── Who Is Responsible for This? ────────────────────────────────────────────────────────────── Rob Roesch The HOTware BBS GT Power Net-Node 064/003 Rt 7 Box 566 Mocksville, NC 704-492-2081 (USR 16.8 DS) If you start using this utility, and get a chance, let me know (see above procedures. If you don't have any use for it, delete it for your total refund of all the disk space that it was occupying, assuming your operating system works right. This program comes with no warranty, no guarantee, and no promises. If it works GREAT, if not let me know and I will gladly take a look at it in my spare time. If you really really really like the program and want to make any donations, feel free, but it is not a requirement..... ────────────────────────────────────────────────────────────── Alternate Distribution Sites ────────────────────────────────────────────────────────────── The HOTware Utilities now have alternate Distribution Centers for your convenience. The following BBS always have the latest and greatest HOTware utilities online and available for download. BBS Name BBS Phone Location GT Net/Node Hours ┌──────────────────┬───────────────┬────────────────────┬───────┬──────────┐ │ Laboratory 386 │ 618-549-2322 │ Carbondale IL │064/400│ 10pm-8am │ └──────────────────┴───────────────┴────────────────────┴───────┴──────────┘