DP Tool Club 8

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

/ DP Tool Club 8 / CDASC08.ISO / VRAC / FAN_200.ZIP / FAN.DOC < prev next >

Wrap

Text File | 1993-09-12 | 75.8 KB | 1,849 lines

FAN File Announcement Utility, version 2.00 Manual Copyright 1992, 1993 by David G. Fisher. All rights reserved. Introduction What is FAN?..........................................4 Disclaimer............................................5 Documentation/Credits.................................6 Registering FAN.......................................7 Submitting Bug Reports................................8 Using FAN The Basic Philosophy..................................9 Description of Syntax................................10 Defining Month Names.................................12 Message Area Formats......................................13 Format - Packet (*.PKT)..............................13 Format - *.MSG.......................................13 Format - Squish......................................13 Format - ASCII Text File.............................13 Announcing messages to ASCII text files..............14 Announcing messages to NetMail.......................15 Announcing messages to local message bases...........16 Defining Announcement Areas..........................17 Description of Announcement Area Components MsgAreaName..........................................18 MsgAreaType..........................................18 MsgAreaPath..........................................18 From.................................................19 To...................................................19 Subj.................................................19 Attributes...........................................19 AddressFrom..........................................19 AddressTo............................................19 MonthIndex...........................................20 Announce.............................................20 Exclude..............................................20 Message Construction Templates............................................21 Valid Template Macros................................22 Sorting and Grouping File Announcements..............25 Testing Your Templates and Message Formats...........26 Defining a FILES.BBS Announcement Area....................27 Maximus CBCS and Opus Alternatives...................27 MaximusFileAreaFileName <file name>.............27 MaximusFileArea <area name> <FAN announce name>.27 Using the File Logging Feature............................29 AnnounceLogFile......................................29 AnnounceLogTemplate..................................29 AnnounceLogMonthIndex................................29 Special Tick Considerations Reading Tick's Configuration File....................30 Bad Tick Files.......................................30 Announcing Locally "Hatched" Files...................30 Using SEAL's FileDesc Statement......................30 Unresolved (Unresolvable?) Bugs...........................31 Using FAN with ZMail under DOS.......................31 Using FAN with AutoBoot 2.00 and Opus under DOS......31 Future Possible Features/Enhancements.....................32 Appendices Appendix A - Example REXX procedure calling FAN......33 Appendix B - Example DOS procedures calling FAN......35 Appendix C - Examples that place BBS caller information in DOS Environment Variables.............38 FAN Users Manual Page 4 ---------------------------------------------------------------------- What is FAN? FAN creates message announcements to announce new file arrivals by scanning - either or both - standard FILES.BBS files and .TIC files generated by file distribution systems running Barry Geller's TICK utility, or .TIC clone programs such as AllFix. FAN was originally inspired by Doug Belkofer's RFD [R]eceived [F]or [D]istribution, an MS-DOS program that works beautifully on .TIC processed files, but lacked other features I desired, such as support for long file descriptions, FILES.BBS files, or would run under OS/2. After many versions, FAN has evolved into an incredibly different and more advanced program than RFD. FAN can be configured to announce files in a variety of customized formats. The following is an example of FAN's potential: From: Dave Fisher of 1:170/110@fidonet.org To: All Subj: New Arrival(s) on LiveNet Attr: Arrivals ____________________________________________________ 1:170/110 The following file(s) were received here for distribution on 11 Sep 92 at 02:07:52: FAN_121.ZIP 115876 10-Sep-92 File announcement utility (DOS and OS/2). Scans inbound .TICs and/or FILES.BBS for new uploads. Enhanced formatting for long, justified descriptions... Just like this one! Distributed via FWCOMM from 1:170/110. --- FAN 1.21/beta * Origin: LiveNet! Tulsa's OS/2 Warehouse. 918-481-5715 (1:170/110) FAN custom formats file descriptions up to 1024 characters in length, creating announcements that can also include information such as the following: File Name Size in Bytes or Kilobytes Distribution Area Tag Name Originating Address, File Date (expressed in many different ways), Name of FDN area, etc. File announcments can be grouped and sorted in a variety of ways, and be written to *.PKT, *.MSG, Ascii Text, or Squish formatted message bases. FAN is a bound program (which means it will run under OS/2 or DOS). FAN Users Manual Page 5 ---------------------------------------------------------------------- Disclaimer This program is shareware. There is absolutely no warranty for this program or guarantee it will work. The user of this program assumes all risk. While I feel confident this program will not harm your system in any way, by using this program, you agree to assume full responsibility for any adverse effect to your system. Where applicable, all trademarks referred to here are the property of their owners. FAN Users Manual Page 6 ---------------------------------------------------------------------- Documentation/Credits There are four document files that describe FAN. FAN.DOC The file you are reading is a basic description and introduction to FAN. Many thanks to Bill Whitehouse and Raymond Beriau for their helpful, editorial comments, and contributions to this document! HISTORY.DOC History of changes to FAN should serve as a good reference to track new FAN enhancements as they are added. CONTENTS.DOC Content listing of all the files that are distributed with FAN and a brief description of each one. FAN.CFG The accompanying FAN.CFG configuration file is heavily documented and demonstrates how I use FAN on my system. It is a companion to this document, included to illustrate how FAN's default settings are modified and how Announcement Areas are defined. FAN Users Manual Page 7 ---------------------------------------------------------------------- Registering FAN FAN is probably one of the most easy programs to register. Once you configure the enclosed FAN.CFG configuration file, simply run the program REGISTER. This program will read your configuration file and generate a netmail message which will be addressed to FAN on my system. My system will then read this message and automatically reply to you with your registration key. It's that simple! No forms, no envelopes, no hassles. Once you receive your reply, change your FAN configuration to use your personalized registration key by altering the RegistrationKey statement. Please note: once you have a registration key, changing the PrimaryAddress, SystemName, or Sysopname will invalidate that key. You will have to run REGISTER again with the new information to obtain a new registration key. When you are registered, your ^aPID kludge line (if enabled) will read x.xx Reg instead of x.xx Eval. Currently, registrations using the REGISTER program can only be sent via FidoNet, ibmNET, or OS2NET. Please register FAN! Knowing how many sysops are using fan will help me determine how much time and resources to allocate to future development and enhancements. All registered users will automatically receive notice of new beta releases. If you do not wish to be notified, please netmail me with your request to be removed from the beta team distribution list. While I don't demand a contribution, if you find this program useful and would like to contribute to ongoing shareware development, please send a contribution of $10 or more to: Dave Fisher 5131 East 88th Court Tulsa, Oklahoma 74137 USA The most recent FAN release is always available here with the magic File Request name of "FAN" (without the quotes). FAN Users Manual Page 8 ---------------------------------------------------------------------- Submitting Bug Reports When submitting a bug report, please read the following guidelines. Invaritably when someone reports a bug in FAN, I will have to write back asking for one or more of the following items. Performing these tasks first will ensure that I will be able to identify the problem quickly. 1. Write a brief description of the problem. 2. Run FAN using the undocumented qualifier /debug=<level>. I guess this qualifier isn't so `undocumented' now. :) Adding this qualifier to the command line will make FAN write quite a bit of information to STDOUT (normally the screen). Redirect this to a file (say called DEBUG.OUT) and send it to me with your bug report. For example: FAN /debug=5 [...] > DEBUG.OUT Debug levels range from 1 to 5. Please run at debug level 5 when submitting a bug report. This will give me the most detailed information concerning the internal processing of FAN. 3. Include any relevant output files. This could include *.PKT files, log files, ASCII formatted message files --whatever-- you feel would help shed some light on FAN's abnormal behavior. 4. Include a copy of your configuration file. This is important! Many times the bug may be due to a configuration error, in which case I need to make FAN more intelligent concerning the processing of the configuration file, or more clear concerning the instructions when configuring FAN. Bug reports may be submitted to me at any of the following addresses: Dave Fisher LiveNet OS/2 BBS 1:170/110@fidonet.org 40:4372/0 (ibmNET) 81:202/201 (OS2NET) Also, please don't hesitate to send enhancement suggestions. FAN wouldn't be what it is today without your thoughtful recommendations. FAN Users Manual Page 9 ---------------------------------------------------------------------- The Basic Philosophy FAN is designed to run on two separate occasions: 1. After your mailer receives *.TIC files but before they are processed by TICK. And... 2. After new files are uploaded to file areas you want FAN to monitor (i.e., FILES.BBS files). I run FAN on my own system only when the mailer exits to process mail and *.TIC files are found in the Inbound Directory. This a matter of personal preference; FAN will announce any new arrivals since its last run. If you want announcements to identify BBS uploaders by name you should run FAN whenever new uploads are detected at caller log-off. See Appendix A for an OS/2 REXX example that processes my incoming *.TIC files. See Appendix B for three DOS batch file examples. The first two examples processes *.TIC files, and the third demonstates how to use DOS's ATTRIB.EXE and a choice of two other shareware utilities to detect new BBS uploads and prompt FAN announcements. See Appendix C and the accompanying FAN.CFG and file templates for examples that place BBS caller information in environment variables FAN can use in its announcements. Once FAN identifies file(s) to announce, it checks its configuration file for each "Announcement Area" you have defined. When received files match an Announcement Area, FAN creates the announcment in the file format you have chosen (*.PKT, *.MSG, etc.). *.PKT files created by FAN are suitable for mail processing software, such as Squish or oMMM. FAN's *.PKT file adheres to FTS-0001 Fidonet mail packet standards. Simply execute your mail processing software to import echomail once these packets are created. FAN Users Manual Page 10 ---------------------------------------------------------------------- Description of Syntax FAN /Config = <path+file name> default: FAN.CFG /[no]Log default: NoLog /LogFile = <path+file name> default: None /LogLevel = <1..4> default: 4 /[no]LogWarnings default: LogWarnings /[no]Quiet default: NoQuiet /TossLogFile = <path+file name> default: None /FileArea = ( Areaname1, ... ) default: All Areas /TestMode default: NoTestMode /Debug=<0..5> default: 0 (no debug) Notes on the syntax: Qualifiers can appear in any order, in any case, and are only significant to four characters. /TossLogFile, for instance, is the same as /toss. Qualifiers /Config = <path+file name> This is the name of the configuration file. The default is FAN.CFG in the current directory. If you prefer, you can define an environment variable using the DOS SET command instead, with the following syntax: Set FAN_CONFIG=<path+filename> /[no]Log This qualifier will turn the logging function on and off. Default is NoLog. /LogFile = <path+file name> This qualifier defines the name of the log file. /LogLevel = <1..4> This qualifier defines the level of log file detail. Level 1 is the least detailed, while Level 4 is the most verbose. The levels indicate the 'importance' of a message, where Level 1 is the most important (usually error messages). /[no]LogWarnings This qualifier will run instruct FAN is print or not print warning messages. Warning messages simply point out possible inconsistencies in your configuration of FAN. They do not suppress messages of a more serious nature. For example, you may be running FAN using a TIC configuration file, and neglected to announce a couple of the areas in this file. FAN will issue a warning indicating the area does not appear in any Announcement Definitions. However, it may also be you do FAN Users Manual Page 11 ---------------------------------------------------------------------- NOT wish to announce those areas, thus the warning messages would be unwanted. I would suggest to let FAN run the first few times for all warning messages, until you feel things are running smoothly. Then add the /NoLogWarn qualifier to FAN command line (or state NoLogWarnings in the configuration file) after several actual runs. /[no]Quiet This qualifier controls whether FAN should print detailed output to the "standard output device", which is normally the screen. Set it to /Quiet and all you see are the program copyright line and any error messages. The default is /NoQuiet. /TossLogFile This qualifier instructs FAN to write the message area names it processes to a specific file, enabling your tosser/scanner (such as Squish or oMMM) to limit its processing to those listed areas. /FileAreas = ( Areaname1, Areaname2, ... ) This qualifier will allow you to run FAN and restrict the announcements to occur ONLY within the list *.TIC/File areas. The area names used are the TIC file area names (such as SDSMAX), or the area names you have defined in the FAN configuration file using the FILESBBS statements. This qualifier is especially convenient if you want to announce files that a particular user uploaded to a particular file area, and want to use environment variables to indicate his/her name as the author of the upload. By restricting the announcements to ONLY that file area, you limit the risk of announcing other new file arrivals erroneously with the uploader's name. /[no]TestMode This qualifier will run FAN in its test mode. For a description of this test mode, please refer to the section entitled "Testing Your Messages and Message Formats". /Debug=<0..5> This qualifier will instruct FAN to print internal processing information to STDOUT. This qualifier is useful when submitting bug reports, or trying to solve a problem in the configuration. At the highest debug level (5), quite a bit of information will displayed. FAN Users Manual Page 12 ---------------------------------------------------------------------- Defining Month Names In order to accomodate multiple languages, as well as different month name formats, different "month lists" can be defined in the FAN configuration file. Each list of month names has an index number associated with it. This number can be specified in each Announcement Area Definition. If it is not specifically specified in an Announcement Area Definition, Month List 1 will be used. A Month List has the following format: Months [index number] [month names] There can be up to 9 different month lists (index numbers 1-9), each starting with the keyword 'Months'. The month names can be separated by spaces or commas, and must all be listed on the same line. Month lists can be referenced within a message by either using the MonthIndex keyword in the Announcement Area Definition, or using the tokens [filemonthname1] to [filemonthname9] in the message template files. By using the month token [filemonthname] in the template files, it is possible to mix different month name formats within one single message. FAN Users Manual Page 13 ---------------------------------------------------------------------- Message Area Formats FAN will create announcement messages in a variety of message formats. These formats are as follows: Format - Packet (*.PKT) Packet, or *.PKT, files are normally received by network front-end mailers such as BinkleyTerm and FrontDoor. These files are then processed by your tossing/scanning software and entered into the appropriate message area, whether that be echomail or netmail. If your message base is not supported by FAN, you would use this option and define your DefaultMsgType as "Packet". Format - *.MSG *.MSG formatted message bases are the defacto FidoNet standard. However, more efficient message base formats are becoming more popular, such as Squish. Format - Squish Squish formatted message bases area created and maintained by the SQUISH software created by Scott Dudley. Each message base is stored in one file with a companion index file for efficient searches and quick access. Format - ASCII Text File FAN recognizes a special message area type which does not really relate to FidoNet at all. Instead of sending messages to a special formatted file such as Squish or *.PKT files, FAN can write messages to a flat ASCII text file. This makes extremely flexible since the format of this file is up to you when you design the message template files. FAN Users Manual Page 14 ---------------------------------------------------------------------- Announcing messages to ASCII text files One powerful feature of FAN is the ability to announce messages to a variety of ASCII text files in a variety of formats. These text files can be used as input to virus scanning software or news items for QWK downloaders. This feature is similar to the AnnounceLogFile, but much, much more flexible. There is no limit to the number of ASCII Announce Areas that can be defined. Please note! FAN will append to the ASCII text file if it already exists. Thus, if you intend the ASCII text file for a temporary use (such as input for virus scanning), be sure to delete it after you are done. In order to define ASCII text files, simply create an Announcement Definition with the special keyword "ASCII", a message type (MsgAreaType) of "ASCII", and include the statement "MsgAreaPath". For example: MsgAreaName ASCII MsgAreaType ASCII MsgAreaPath c:\bbs\fan\allfiles.txt MonthIndex 2 PrefixTemplate c:\bbs\fan\pascii.tpl FileTemplate c:\bbs\fan\local.tpl SuffixTemplate c:\bbs\fan\sascii.tpl Announce * For example, the above can be used to create nicely formatted messages as news items to QWK downloaders. All file areas will be announced (since a wildcard match of "*" is used in the Announce statement) using the specified templates. Notice that it is not necessary to specify "From", "To", "Subj", and/or "Attributes" statements since these are not used within creation of the messages. If you wish to include this information in the annoncement, simply include it within one of the prefix or suffix templates. MsgAreaName ASCII MsgAreaType ASCII MsgAreaPath c:\bbs\fan\ibmnet.txt PrefixTemplate None SuffixTemplate None FileTemplate c:\bbs\fan\fascii.tpl Announce IBMOS2FX IBMDOSFX IBMEWS IBMINFO IBMTCPIP The above example illustrates the use of an ASCII area creating a "raw" text file which can be used as input into another software package. Notice the prefix and suffix templates have been disabled. This is necessary if default prefix and suffix templates have been defined earlier in FAN. FAN Users Manual Page 15 ---------------------------------------------------------------------- Announcing messages to NetMail If you wish to send an announcement to a particular person via netmail, create the Announcment Definition in the usual manner with the following exceptions: 1. Define the MsgAreaName as 'NETMAIL', and 2. Include the keyword 'AddressTo'. For example: MsgAreaName NETMAIL AddressFrom 1:170/110 AddressTo 1:170/110.7 From Dave Fisher To Mark Barbee Subj New OS/2 files received via ibmNET Attributes LP FileTemplate c:\bbs\fan\local.tpl Announce IBMOS2FX The message area name 'NETMAIL' will instruct FAN to format the message for NetMail, and not EchoMail, which simply means there will be no ^aAREA control line, no tag/origin line, no ^aPATH or ^aSEEN-BY control lines, etc. The addresses can be full 4D format of <zone>:<net>/<node>.<point>. FAN Users Manual Page 16 ---------------------------------------------------------------------- Announcing messages to local message bases If you instruct FAN to write a message in *.PKT format to a local message base, special consideration must be given to these message bases since they are not set up for incoming/outgoing echomail. In other words, these message bases are local to your system, and messages are never scanned out to other systems. Normally, you do not have to define these message bases in your tossing/scanning software. However, since you have instructed FAN to create *.PKT messages, you will have to define these local areas for your particular tossing/scanning software. For example, for Squish, you simply define the area by creating an echo tag name and use your address as the origination node: EchoArea LOCAL c:\max\msg\local -$ 170/110 In this example, the MsgAreaName used in FAN will be "LOCAL" and the origination node for the messages is my FidoNet node number, 170/110 (your own address would go here). For Opus, you would add the lines ECHOMAIL and SCAN to you local message area and scan it to your address as follows: AREA 0007 SDS NAME SDS/SDN_In PUBLIC MESSAGES ONLY ACCESS PRIV Disgrace EDIT PRIV Sysop PEEK PRIV Sysop PATH E:\MSG\SDS_IN\ TITLE Incoming Software Distribution Files MAXLINES 60 ECHOMAIL FILESIN SCAN 129/112 END AREA In the above example, you would identify the MsgAreaName in FAN as "FILESIN". The address after "SCAN" would be your own. FAN Users Manual Page 17 ---------------------------------------------------------------------- Defining Announcement Areas Announcement Areas are central to defining FAN's operation. They include all the information FAN needs to create messages destined for echomail, netmail, or a message area/base. Announcement areas are defined in the configuration file, each beginning with the keyword 'MsgAreaName'. It is important to note that this area name is the "message area tag name" of the echo for announcements, NOT the tag name of the File Distribution Area (used in Tick and FILESBSS definitions). Each announcement area has the following 3 basic parts: 1. The Echo Tag Name (keyword 'MsgAreaName') 2. Message Header Specific Information (keywords, 'From', 'To', 'Subj', etc.) 3. FDN Tag Names to announce (keyword 'Announce') or exclude (keyword 'Exclude') Each announcement area is fully self-contained, and does not effect any other announcement area definitions. FAN Users Manual Page 18 ---------------------------------------------------------------------- MsgAreaName The MsgAreaName is the name echo tag name of the message base. All files received which are part of the groups in the Announce lines will have announcement messages created for this message base. MsgAreaType Each announcement definition can create the announcement message in a variety of formats. These formats range from FTS-0001 *.PKT files which will be placed in your incoming mail directory to actual message bases (such as Squish formatted bases). Keywords for the different area types are Packet, *.MSG, Squish, or ASCII. Please see the section "Message Area Formats" for a list and description of each area type available. Please note: If the message area is formatted as *.MSG or Squish message base, enable one or more of the FAN configuration statements MaximusMsgAreaFileName, SquishCfgFileName, or AreasBBSFileName. This will cause FAN to fill in the MsgAreaType and MsgAreaPath for you, and reduce the amount of work it would take for you to maintain the FAN configuration file. Also, if you choose a default message type of *.PKT (DefaultMsgAreaType), and define one of the above Maximus/Squish control files, THE DEFAULT MESSAGE TYPE MAY BE OVERRIDDEN for any given message area. For example, if you announce to a message area called NEWFILES and FAN finds this definition in the Squish (or other) configuration file, then FAN will automatically override the default message type for that area (NEWFILES in this case) and set it to the type of message area found in the configuration file. If a message area is defined in a configuration file and you want to force a specific message type, simply use the keyword MsgAreaType within the Announcement Definition itself. MsgAreaPath This configuration statement has different meanings based on the MsgAreaType. They are as follows: MsgAreaType Packet MsgAreaPath is not used for *.PKT messages. The configuration statement PacketPath will be used for the message path. MsgAreaType *.MSG MsgAreaPath is the directory name of the *.MSG message base. If you have configured FAN to read your Maximus, Squish, or AREAS.BBS configuration file, you will not have to define MsgAreaPath. MsgAreaType Squish MsgAreaPath is the directory plus base name of the Squish message base. If you have configured FAN to read your Maximus, Squish, or AREAS.BBS configuration file, you will not have to define MsgAreaPath. FAN Users Manual Page 19 ---------------------------------------------------------------------- MsgAreaType Ascii MsgAreaPath is the full path and filename of the ascii file to create. From This is the name of the "person" that is credited as sending the announcement. You can even user YOUR name here! The default is "File Announcer". To This is the name of the "person" to whom the message is written. The default is "All". Subj This is the subject line of the message. The default is "Files received for distribution". Attributes These are one letter keywords toggling FAN message attributes. P = Private C = Crash H = Hold K = Kill/Sent L = Local F = Forward R = Read/Received S = Sent X = Scanned (Squish only) Many mail processing software packages will need the Local flag set on the message ('L'). One or more of the following attributes can be combined on the same line, with no intervening spaces. For example, to mark a message as Private and Local, either "LP" or "PL" would be acceptable (without the quote marks). AddressFrom This is the address to use for the newly created message packet. Normally, FAN will use the default address defined at the top of the configuration file. However, it is possible to create annoucements for other networks using an alternate address by specifying 'AddressFrom' within the announcement definition. AddressTo When sending messages via NetMail (instead of being destined to an EchoMail message base), 'AddressTo' will define the node address of the receiving party. MonthIndex FAN Users Manual Page 20 ---------------------------------------------------------------------- If a 'MonthIndex' is not specified, the Month List defined as Index 1 will be used. Otherwise, 'MonthIndex' will define a different month list. Whenever the template token [filemonthname] or [curmonthname] is encountered, the default Month List for the Announcement Area will be used. Announce These are the names of the File Distribution Areas for which you wish to create announcement messages. You can have one or more lines using the keyword 'Announce'. One or more Tick File Areas can be defined can be defined on each 'Announce' line. Simply separate each Tick File Area name with a space. You may also specify wildcarded File Distribution Areas in the Announce statement. Valid wildcards are the asterick and the question mark. An asterick matches to one or more characters, while the question mark matches only one character. For example, an Announce name of "IBMO??FX" would match to IBMOS2FX, but not IBMDOSFX. An Announce name of IBM*FX would match to both of the above example File Distribution Areas. Exclude Since Announce areas can contain wildcards, it may be necessary to restrict some areas from being caught in the wildcarded match. For example, if you want to announce most of your File Distribution Areas, except for a select few (such as private or beta File Distribution Areas), the Exclude statement can be used. For example, if you wish to include all ibmNET FDN areas, except the private sysop area, you would specify: Announce IBM* Exclude IBMNET The format of the Exclude statement is identical to the Announce statement explained above. FAN Users Manual Page 21 ---------------------------------------------------------------------- Templates FAN composes the body of each message with three templates. "FileTemplate" determines the form and content of each file announcement. "PrefixTemplate" and "SuffixTemplate" assign any opening and closing remarks you choose to run at the top and bottom of each message. "GroupTemplate" will be used when sorting is active, and will appear at the beginning of each "group" of files. PrefixTemplate usually consists of a short sentence describing the purpose of the message, along with the time and date the announced files were received on your system. SuffixTemplate might include other systems you distribute the files announced here to, File Request limitations, etc. The GroupTemplate normally includes some type of group header/divider information, such as the TIC/FILESBBS group description, etc. If PrefixTemplate, FileTemplate, or SuffixTemplate are not part of an Announcement Definition (i.e., they are defined BEFORE any Announcement Definitions), then that template will pertain to all Announcement Definitions. This default behavior can be overridden by defining the template within the Announcement Definition itself. Please see the example FAN.CFG enclosed in the FAN distribution archive for examples. For example, if the following were defined within your FAN configuration file: FileTemplate DEF_FILE.TPL MsgAreaName MESSAGE_BASE_1 From .... To .... MsgAreaName MESSAGE_BASE_2 From .... To .... FileTemplate LOCAL.TPL MsgAreaName MESSAGE_BASE_3 From .... To .... The file template DEF_FILE.TPL will be used for MESSAGE_BASE_1 and MESSAGE_BASE_3, while the file template LOCAL.TPL will be used for MESSAGE_BASE_2. FAN Users Manual Page 22 ---------------------------------------------------------------------- Valid Template Macros All FAN macros, or tokens, are expanded as the message is created. They are not case sensative (i.e., they can be in upper or lower case). The basic syntax of a macro is as follows: [ macroname, macro options, ... ] A macro is enclosed within brackets, and can include one or more macro options which effect the appearance of the final formatted text. The order of the macro options are not significant. Macro options are only significant to 4 characters. Thus, "TRUNCATE" is the same as "TRUN" or "TRUNC". See below for a list of macro options. The following macros are valid within ANY of the templates, as well as specified To:, From:, and Subj: fields in FAN's configuration file. The following macros expand various aspects of the current date of the announcement: [curdate] Current date in "DD [month name] YY" format [curtime] Current time in "HH:MM:SS" format [curmonthname] Current month name (using DefaultMonthIndex) [curmonthname1..9] Current month name using index N (1-9) [curmonth] Current month number (01-12) [curday] Current day number (01-31) [curyear] Current year number (i.e., "93") [curyear4] Current year number (i.e., "1993") Miscellaneous macros: [totalsize] The total size of all files announced in the message, in bytes [totalsizeKB] The total size of all files announced in the message, in kilobytes (rounded to one decimal place, i.e., 130.8 kilobytes). [env:varname] A valid DOS environment variable "VARNAME". For example, if the user's name who uploaded a file is in the environment variable ULNAME, then this macro would be expressed as [env:ULNAME]. [text,"???"] Normally, text is simply written within the template file without any translation. However, it is possible to have FAN perform the same formatting functions on miscellaneous text as it does on macro tokens. For example, if you wanted a portion of text to be a continuation of the previous margined paragraph, specify something liek [text,"Uploaded by ",MARGINS:30:78] instead of simply writing "Uploaded by " directly into the template file. The following macros are valid ONLY within the FileTemplate or GroupTemplate: FAN Users Manual Page 23 ---------------------------------------------------------------------- [filepath] The full path name of the file received. This is the physical directory location of the file on your machine. [filename] The name of the file received [filefullname] The full path and file name ([filepath] + [filename]) [filebasename] The base filename without extension (i.e., "TEST") [fileext] The file extension (i.e., "ZIP") [filesize] The size of the file in bytes [filesizeKB] The size of the file in Kilobytes [areatagname] The TICK/FILESBBS file distribution area tag name [fileareadesc] The TICK/FILESBBS file distribution area description [fileorigin] The address where the file originated [filedesc] The complete description of the file (up to 1024 characters) [fileyear] The file date year, expressed as two digits (i.e., "93") [fileyear4] The file date year, expressed as four digits (i.e., "1993") [filemonthname1..9] The file date month, expressed as text as defined in the configuration file (using the 'Months' keyword). If a number does not follow [filemonthname], then the default Month List will be used. Otherwise, specific month lists can be specified by using [filemonthname1], [filemonthname2], ... [filemonthname9], where the number is the Index Number of the Month List. [filemonth] The file date month, expressed as two digits [fileday] The file date day, expressed as two digits Any macro can also include any the following format options: Number A number after the macro name will force the expanded text to the indicated field length. The actual text will not be truncated. Thus, if the actual length of the expanded text is greater than "Number", then the output will be greater than "Number". If the actual length of the expanded text is less than "Number", spaces will be padded until the length is "Number". For example, if you want a 12 character fixed length field for the file/TIC area tag name, specify [areatagname,12]. TRUNCATE Only applicable if a field length is specified. If the actual length of the expanded text is greater than the field length indicated, the text will be truncated to the specified field length. For example, if you only want up to 25 characters of the file description text, specify [filedesc,TRUNCATE,25]. RIGHT FAN Users Manual Page 24 ---------------------------------------------------------------------- Only applicable if a field length is specified. This macro option will right justify the text. For example, if you wish to have the file size right justified within a 10 character field, the syntax would be: [filesize,RIGHT,10]. MARGINS:left:right One powerful feature of FAN is the ability to left and right justify text. This is extremely handy if you want to format long file description lines, or create paragraph-like output. It is important to note that when MARGINS are spcified and FAN writes to a line of formatted text, it will NOT overwright previous text. Thus, if your output line is already 50 characters in length, and you specify a left margin of "30", FAN will append to the line until it hits the right margin. When a new line is created, FAN will move to the left margin and begin writing again. In this way, it is possible to create "paragraphs" if you specify the same left and right margins for the output text. For example, if you wish to create a paragraph that begins with the file description and ends with the name of the TIC area tag and origin address of the file, you would specify: Desc: [filedesc,MARGINS:6:45] - [text,"Distributed via ", MARGINS:6:45][areatagname,MARGINS:6:45][text, " from ",MARGINS:6:45][fileorigin,MARGINS:6:45] The above should all be one line, it was broken ino three lines for readability. It would produce output similar to: Desc: Listing of files available on the IBM Canada BBS systems - Distributed via IBMNET from 40:649/312 The left and right margins start at the count of zero, not one. Thus, MARGINS:0:79 is a full 80 character line, from 0 to 79. See the accompanying .TPL files for examples of actual usage. FAN Users Manual Page 25 ---------------------------------------------------------------------- Sorting and Grouping File Announcements FAN can sort and/or group file announcements in the order they were received, or alphabetically by filename and/or TIC/FILESBBS tag name. Sort methods available are: None : No sort. Files will be announced in the order they are processed. Alpha : Files will be sorted alphabetically by filename. Group : Files will be sorted by group (TIC/FILESBBS) name, tag and then alphabetically by filename within the group. The sort method can also be Announcement Definition specific. Thus, you can have different sorting/presentation strategies for different message areas. If defined outside any Announcement Definition, this will become the default for any areas in which a SortMethod is not specified. When choosing a sort method Alpha or Group, the GroupTemplate, if defined, will be used. FAN Users Manual Page 26 ---------------------------------------------------------------------- Testing Your Templates and Message Formats In order to experiment and refine the format of your messages, FAN has a "test" mode. This test mode will enable you to test FAN without actually creating *.PKT's in your mailer's inbound directory, and possibly toss those messages by mistake. In this mode, the following conditions apply: 1. All messages intended for a *.PKT will instead be written to an ascii text file. This file will be the name of the echo area (MsgAreaName) meant to receive the message with an extension of *.TST, or if the MsgAreaName is ASCII, then MsgAreaPath will be used (the path will be stripped from the filename first). If the name of the echo area exceeds 8 characters, only the first 8 characters of the echo area name will be used. Thus, if the echo area name is "LOCAL", the name of the file will be "LOCAL.TST". These files will be created in the current directory. 2. The log file name, if specified, will be overridden. The new log file name will be "TEST.LOG" and will be created in the current directory. 3. No entries will be written to AnnounceList. 4. No entries will be written to AnnounceLogFile. 5. *.RAD files for locally hatched files using TIC will NOT be deleted. 6. FAN will look in the current directory for *.TIC or FILES.BBS files to create announcements. 7. Path names will be stripped from the template files defined in FAN.CFG. FAN will look for these template files in the current directory. To invoke FAN in test mode, simply use the qualifier "/TestMode", or simply "/Test". For example: FAN /test [...] A quick, easy way to test your templates is to create a test directory and either save a few of your *.TIC files, or if you do not receive *.TIC files, create a test FILES.BBS file with a few entries. Since FAN looks in the current directory for these files while in test mode, nothing in your "live", active directories will change. FAN Users Manual Page 27 ---------------------------------------------------------------------- Defining a FILES.BBS Announcement Area It is possible to have FAN announce new files that are uploaded to your system by having it monitor one or more FILES.BBS files. FAN keeps a database of files that have already been announced. In this way, FAN can identify new FILES.BBS entries (see keyword 'AnnounceList' in the configuration file). There are four parts to the FILES.BBS definition: FILESBBS_FileName [filename] This is the full path and file name of the FILES.BBS file. On most systems, this will be [path]\FILES.BBS. Some systems, however, use different file names. FILESBBS_Files [pathname] This is the path where the actual files listed in the FILES.BBS file reside. Some systems keep all their downloadable files in one directory, which are referenced by different FILES.BBS files. FILESBBS_AnnounceName [name] When you are writing the Announcement Definition in the FAN configuration file, the TIC area tag name is specified on the 'Announce' line. Since there is no TIC area tag name associated with your FILESBBS file area, FILESBBS_AnnounceName is used to create a "dummy" TIC tag name to use on the 'Announce' line. FILESBBS_Description [description] This is the description of the FILESBBS area. It will be used when expanding the template macro [fileareadesc]. All the above keywords MUST be used in the order that they are describe above (i.e., FILESBBS_FileName, FILESBBS_Files, FILESBBS_AnnounceName, and then FILESBBS_Description). Maximus CBCS and Opus Alternatives If you are running Maximus or Opus, FAN can read the path information directly from your file area control file. Simply use the keywords MaximusFileAreaFileName and MaximusFileArea. If you specify the FILES.BBS areas here, you do not have to define them using the FILESBBS FAN keywords. MaximusFileAreaFileName <file name> This keyword specifies the name of the control file which contains all the downloadable directory information for file sections on your BBS. MaximusFileArea <area name> <FAN announce name> This keyword attaches a specific "announce name" to each file area you wish FAN to monitor. The announce name can be the same for every FAN Users Manual Page 28 ---------------------------------------------------------------------- area, or different. It is usually helpful to use different announce names for each area, since this announce name can be included in the text of the announcement message itself using the [areatagname] token (see section Message Construction). For example, if you had the following areas: MaximusFileArea 98 NEWOS2FILES MaximusFileArea 99 NEWGENFILES MaximusFileArea 20 OS2UTILS MaximusFileArea 21 OS2GAMES MaximusFileArea 50 OPUSBBSFILES MaximusFileArea S01 SYSOPFILES You could then choose to announce all those areas to specific message bases in a variety of ways. For example, if you wanted to publically announce the arrival of files in all the areas above except S01, which should be private to the Sysop only, the following Announcement Definitions could be constructed: MsgAreaName LOCAL From Dave Fisher To All Subj New files received Attributes L Announce NEWOS2FILES NEWGENFILES OS2UTILS OS2GAMES Announce OPUSBBSFILES MsgAreaName LOCAL From Dave Fisher To Dave Fisher Subj New private sysop files received Attributes LP Announce SYSOPFILES FAN Users Manual Page 29 ---------------------------------------------------------------------- Using the File Logging Feature FAN can create a log of all files found for announcement. This log can be used for a variety of purposes. It can be used as input for virus scanners, download/upload tracking programs, or simply as a historical reference of all files that have been received via TIC or user upload. The format of the log file is user-definable. The same file macros that are available for announcements are also available here. Please note: you may find that creating an ASCII formatted announcement area will better suit your needs. The ASCII format was a later enhancement, and is more flexible than the file logging feature since you can have multiple ASCII formatted announcement areas (and consequently multiple "log" files) and also have the ability to define which file distribution areas will be included or excluded. AnnounceLogFile This keyword defines the actual file name of the log file. This log file will be appended to each time FAN finds new files to announce. AnnounceLogTemplate This keyword defines the format of each file entry in the 'AnnounceLogFile'. If 'AnnounceLogTemplate' is not defined, the file will be formatted with one entry per line using the following macro format: "[filename,12] [filemonth]/[fileday]/[fileyear4] [filesize,RIGHT,7] [areatagname,10] [filedesc]". This macro format will produce a listing of files as follows: FAN_146.ZIP 11/11/1992 150206 SDSMAX New FAN release! AnnounceLogMonthIndex This keyword indicates which set of month names to use if [filemonthname] is specified in the AnnounceLogTemplate. If it is not defined, the first set of month names will be used (index 1). FAN Users Manual Page 30 ---------------------------------------------------------------------- Reading Tick's Configuration File FAN will read Tick's configuration file if you specify the path and name of the file using the keyword 'TickConfigurationFile'. You will want to use this feature only if you are "hatching" files into a file distribution network and want FAN to processes the resulting *.RAD files created by Tick. Bad Tick Files When Tick has trouble with an incoming file (bad CRC, invalid password, etc.), it will rename the *.TIC file to *.BAD. FAN can announce these files using the special TIC file area tag "BAD_TICS". Simple specify BAD_TICS on the 'Announce' line in your Announcement Definition just as you would any other file area tag name. Please see the example configuration file, FAN.CFG, for an example. I strongly recommend that Tick first be run in it's "check only" mode. In this mode, Tick will first check all the *.TIC files for valid CRC's, file names, password matches, etc and rename an invalid *.TIC files to *.BAD. Then, FAN will announce these *.BAD files to you privately while announcing all the good *.TIC files publically. Otherwise, if you only run Tick once, FAN will possibly erroneously announce *.TIC files that are later renamed *.BAD by Tick. To use the "check only" mode, first run Tick with the /OC option on the command line. Then run Tick again without that option. See Appendix A for an example using this method. Announcing Locally "Hatched" Files If you enable the RAID keyword in your Tick configuration file, any files hatched from your system can also be announced using FAN. With this keyword enabled, Tick will create *.RAD files in the Tick Hold directory. FAN will scan the Tick Hold Directory for *.RAD files. After it reads the *.RAD files, it will delete them to prevent duplicate announcements. 'TickConfigurationFile' must be defined in your FAN configuration file in order to process *.RAD files. Using SEAL's FileDesc Statement SEAL, an excellent echo/file remote management program by Robert Presland, supports file area descriptions. If you use this utility, FAN will automatically read these descriptions from the ;FileDesc statements found in the TICK configuration file. These descriptions are accessed using the [fileareadesc] token. FAN Users Manual Page 31 ---------------------------------------------------------------------- Unresolved (Unresolvable?) Bugs The following bugs have been reported and are unresolved. If you have any information that would be helpful in determining a solution to the following problem reports, please netmail me at any of the addresses listed at the top of this document. Any help would be much appreciated! Using FAN with ZMail under DOS One beta tester using ZMail noticed that ZMail would report the error "Short Packet" when processing the mail packets (*.PKT files) created by FAN. It would appear that this is a warning message only since ZMail then proceeded to process the packet and distribute the mail correctly. I have been unable to determine exactly what ZMail means by "Short Packet". Using FAN with AutoBoot 2.00 and Opus under DOS One beta tester noticed an odd memory corruption problem using FAN with AutoBoot and Opus. After running FAN he tried to compile his Opus control (*.CTL) files. The compiler would insert "garbaged" lines after some of his AREA statements. If he first removed AutoBoot from his AUTOEXEC.BAT and rebooted, then everything worked normally. He could run FAN and the Opus compiler without errors. Once he installed AutoBoot and ran FAN again, the errors returned. He is running the BBS on a 386 with 2MB RAM and QEMM memory manager. FAN Users Manual Page 32 ---------------------------------------------------------------------- Future Possible Features/Enhancements + New configuration file keyword: CatagoryCode Create a new token [catcode] which will expand to the catagory code for a particular file area. For example: CatagoryCode FTSC 001 CatagoryCode SDS-BBS 002 CatagoryCode SDSADMIN 003 CatagoryCode SDSBINK 004 CatagoryCode SDSMAX 005 CatagoryCode SDSRBBS 006 CatagoryCode SOFTDIST 007 Thus, if a file was being announced from any of those areas, [catcode] would expand to the catagory code associated with appropriate area. + Multiple origin lines Add the ability to define multiple origin lines which can then be specified as an "index" in various announce areas, much as the Months keyword is used. Thus, origin lines can be in different languages or have different "flavors". For example, instead of: OriginLine LiveNet! Tulsa's OS/2 Warehouse. 918-481-5715 you might have several different origin lines: OriginLine 1 LiveNet! Tulsa's OS/2 Warehouse. 918-481-5715 OriginLine 2 LiveNet! South US ibmNET Host. 918-481-5715 OriginLine 3 LiveNet! An OS/2 dedicated system. 918-481-5715 These origin lines can then be referenced in an Announcement Definition using the keyword OriginLineIndex. + Support to scan RA's new FILE database format Currently, FAN only processed *.TIC or FILES.BBS formatted files. A future enhancement will be to also be able to read RA's 2.xx FILE database format. FAN Users Manual Page 33 ---------------------------------------------------------------------- Appendix A - Example REXX procedure calling FAN /*------------------------------------------------------------* * TICK.CMD * * * * Rexx procedure to process *.TIC files * *------------------------------------------------------------*/ echo off cls isfile "c:\binkley\inbound\*.tic" if ( rc <= 0 ) then return /* No *.TIC files received */ call bbslog "Tick", "Initiating TICK" /* * Run TICK in "check only" mode so that any bad *.TIC files are * renamed to *.BAD. These files will then not be erroneously * announced using FAN later. */ "c:" cd "\bbs\tick" TICP "/OC >> c:\bbs\logs\tick.log" if rc <> 0 then do call bbslog "Tick", "ERROR ", rc, " returned from TICK /OC" return end /* * Set the archive dates to the "True" archive date. */ truedate "c:\binkley\inbound\* /Quiet" /* * Call FAN (File Announcement Utility) to send out announcement * messages. */ "c:" cd "\bbs\fan" fan "/tosslog = c:\bbs\fan\fantoss.log" /* * Scan and Toss the newly created messages from FAN */ FAN Users Manual Page 34 ---------------------------------------------------------------------- "c:" cd "\bbs\squish" squish "IN OUT SQUASH -fc:\bbs\fan\fantoss.log" del "c:\bbs\fan\fantoss.log > nul: 2>&1" /* * Now call TICK to do the actual distribution */ "c:" cd "\bbs\tick" TICP ">> c:\bbs\logs\tick.log" if rc <> 0 then do call bbslog "Tick", "ERROR ", rc, " returned from TICK" return end /* * Update Maximus's global download file database */ "c:" cd "\bbs\max\system" fb call bbslog "Tick", "Completed TICK" exit FAN Users Manual Page 35 ---------------------------------------------------------------------- Appendix B - Example DOS procedures calling FAN This is an example DOS batch file contributed by Raymond Beriau (1:242/90) meant to execute after your mailer recieves mail. echo Checking to see if there are .TIC files if exist c:\netfile\*.tic goto tick_ok if not exist c:\netfile\*.fle goto exit :tick_ok for %%d in (d: cd\max\tick) do %%d logentry TICK Checking Received Files... >> d:\bink\bink.log tick /ctic.cfg /oc >> d:\max\tickdir\tick.log :fan_fido logentry FAN Creating File Announcements... >> d:\bink\bink.log fan /Config=fan.cfg /Quiet /TossLogFile=echotoss.log :tick logentry TICK Processing Received Files... >> d:\bink\bink.log tick /ctic.cfg >> d:\max\tickdir\tick.log :squish cd\max logentry TICK SQUISH Processing >> d:\bink\bink.log squish out squash -csquish.cfg -aareas.bbs -fechotoss.log if exist echotoss.log del echotoss.log :update logentry TICK Updating Maximus FileList... >> d:\bink\bink.log fb d:\max\area.dat x_list xlist.ctl :exit quit FAN Users Manual Page 36 ---------------------------------------------------------------------- Another DOS batch file example executed after your mailer recieves mail. Rem FAN Processing Following *.Tic File Arrivals :TOSS_IN Rem Are There *.Tic Files? If Not Exist c:\In\*.Tic GoTo Mail Cd\Files Rem Cyclical Redundancy Check (CRC) of file integrity, measured Rem against CRC values listed in accompanying *.Tic files, Rem renaming *.Tic to *.Bad if CRCs don't match. Tick /cC:\Cfg\Tic.cfg /oc >> D:\Bink\System.Log Rem FAN Command Line Fan.Exe /Conf=C:\Cfg\Fan.Cfg /Quiet /TossLogFile=C:\Bink\EchoToss.Log Rem TICK File Processing Command Line Tick /cC:\Cfg\Tic.Cfg Rem Update Maximus FileList Database If NOT Errorlevel 1 Fb.Exe D:\Max\Area.Dat X_list Xlist.Ctl Rem Turn Off Files.Bbs Archive Bit C:\Dos\Attrib -a D:\New\Files.bbs :MAIL CD\In For %%a In (mo tu we th fr sa su pk) Do If Exist *.%%a* GoTo UNPACK GoTo MAILER :UNPACK Rem Toss & Link Inbound EchoMail, Net Mail Packing & Routing... Cd\Bink Squish In Squash Link -cc:\Cfg\Squish.Cfg -aC:\Cfg\Areas.Bbs -fEchoToss.Log If Exist EchoToss.Log Del EchoToss.Log :EXIT GoTo MAILER FAN Users Manual Page 37 ---------------------------------------------------------------------- A DOS batch file example to detect and announce new BBS uploads at logoff. Rem The following TARGET and 4DOS command lines represent two Rem ways to accomplish the same thing: execute a DOS command Rem only if a check of specified Files.Bbs files reveals an Rem archive bit turned off (-A). If the archive bit is on (+A), Rem meaning no uploads recently modified the Files.Bbs, FAN Rem doesn't waste its time thrashing disk for nothing. C:\Util\Target d:\new\files.bbs -z -c"GoTo FAN" Rem -=-=-=-=-=-=-=-=-=- Rem TARGET15.LZH 73907 07-21-92 File Locator & Manipulator. Target 1.5 (C) 1992, by McAfee Rem -=-=-=-=-=-=-=-=-=- Rem Opps, TARGET came up empty. GoTo MAIL_OUT If %@ATTRIB[d:\new\files.bbs,N] == 1 GoTo MAIL_OUT Rem -=-=-=-=-=-=-=-=-=- Rem 4DOS401P.ARJ 263649 06-14-92 DOS Command.Com replacement. Rem Program Executables & Rem Support Files. 4DOS v4.01 Rem (C) 1988-1992, JP Software Inc. :FAN Rem -=-=-=-=-=-=-=-=-=- Rem FAN Command Line Rem -=-=-=-=-=-=-=-=-=- Fan.Exe /Conf=C:\Cfg\Fan.Cfg /Quiet /TossLogFile=C:\Bink\EchoToss.Log Rem Turn off Files.Bbs Archive Bit C:\Dos\Attrib -a d:\new\files.bbs :MAIL_OUT Squish Out Squash Link -cc:\Cfg\Squish.Cfg -aC:\Cfg\Areas.Bbs -fEchoToss.Log If Exist EchoToss.Log Del EchoToss.Log FAN Users Manual Page 38 ---------------------------------------------------------------------- Appendix C - Examples that place BBS caller information in DOS Environment Variables The following example was written with RemoteAccess v1.11 in mind but should work as well for any QuickBbs system or one of its clones. Hitting the [U]pload prompt should execute a (Type 12) questionnaire that looks something like this: ---------------------------| Begin Example |---------------------------- ClearScreen ChangeColor 14 0 Display "Please describe what you're sending.|" Display " We haven't a clue.|" Display " Make it as detailed as you like.||" ; ; Two choices here, each accomplish more or less the same thing: ; MenuCmnd 7 C:\COMMAND.COM /C Echo Set WHOUP=*F *L>C:\Qbbs\WhoUp.Bat ; ; - OR - ; MenuCmnd 7 *SWhoUp.Bat ; ; This command looks in RA's system directory for the file called ; WHOUP.RAT, expands any 'User Parameter Codes' it finds within ; it and creates WHOUP.BAT in the same directory. My WHOUP.RAT ; file contains 'Full UserName', 'User Location' and 'User ; FirstName' codes and looks like this: ; ; Set whoup=A ; Set loc=B ; Set fn=W ; MenuCmnd 33 D:\New\ /L ; ; The '/L' upload switch above enables long descriptions. ; Quit ----------------------------| End Example |----------------------------- The following commands are executed at BBS logoff: ---------------------------| Begin Example |---------------------------- If Exist C:\Qbbs\WhoUp.Bat For %%a In (Call Del) Do %%a C:\Qbbs\WhoUp.Bat Target D:\New\Files.Bbs -z -c"C:\Bink\FAN.Exe /Conf = C:\Cfg\Fan.Cfg" For %%a In (FN LOC WHOUP) Do Set %%a= ----------------------------| End Example |----------------------------- -------------------------| File: PRELOCAL.FAN |------------------------- This just in from %eLOC . . . ------------------------------| End File |------------------------------ FAN Users Manual Page 39 ---------------------------------------------------------------------- -------------------------| File: SUFLOCAL.FAN |------------------------- Total Kilobytes: %QKb (Thanks, %eFN!) ------------------------------| End File |------------------------------ ---------------------------| File: FAN.CFG |---------------------------- ; ; NetMail announcement area ; ------------------------- MsgAreaName NETMAIL AddressFrom 1:323/109 AddressTo 1:323/108 From %eWHOUP To His Dudeness Subj Cosmic Debris Landed On The Mudflat Attributes LPK Announce MUDFLAT SHESAW Local_Uploads ; ; ; Local Upload announcement area ; ------------------------------ MsgAreaName ARRIVALS PrefixTemplate C:\Cfg\PreLocal.Fan SuffixTemplate C:\Cfg\SufLocal.Fan Announce Local_Uploads From %eWHOUP To %eWHOUP Subj Something I just uploaded... ; ------------------------------| End File |------------------------------ Date: Fri Feb 15 1993 15:42:00 From: Joe Blow To: Joe Blow Subj: Something I just uploaded... Attr: New File Arrivals ------------------------------- This just in from Pothole, R.I. . . . TEST 31 05-Feb-93 This is a test. Had it been an actual alert, you'd have been notified where to tune in your area... Total Kilobytes: 0.0Kb (Thanks, Joe!) FAN Users Manual Page 40 ---------------------------------------------------------------------- --- FAN 1.63 beta * Origin: MudFlat File Distribution - Looking for a file? Ask! (1:323/109)