OS/2 Shareware BBS: 2 BBS

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

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / yatp101x.zip / YATIC.TXT < prev next >

Wrap

Text File | 1993-03-21 | 44KB | 1,255 lines

YaTic v1.00 A 5D TIC processor DOS and OS/2 Documentation Berin Lautenbach 1992-93 3:620/248 58:2600/100 93:9160/103 Introduction 2 Licensing and all that guff 2 Configuration 4 YtConfig 4 System Info 4 Domains 7 System AKAs 7 Reports 7 Areas 10 Editing an Area 10 Global 12 Nodes 12 Import/Export 14 Text Files 14 YatMan templates 14 Report Templates 15 Running YaTic 16 Normal Running 16 Maintenance 16 Other Switches 16 Hatch 17 Area Manger - YatMan 18 Afterword - Future Directions 19 Credits and Acknowledgments 19 ─────────────────────────────────────────────────────────────────── Introduction ─────────────────────────────────────────────────────────────────── YaTic is a 5D aware TIC processor that I wrote in my spare time. I run a lot of points on my system, and thought it would be nice to be able to send them some of the WinNet stuff. YaTic fully understands 5D addressing, both under a oMMM environment, such as Binkley, or a straight *.MSG controlled environment, such as Front Door. However, within the TIC files themselves, YaTic will only handle 4D addressing, any domain lines found in the file will be ignored. This should not be a hassle at this time, since no software that I am aware of uses 5D aware addressing (and only a few programs, such as AllFix, allow 4D). Apart from that, it has the following features : o YatMan - an inbuilt Area Manager o Reporting of processed files o Easy to use configuration program o Terminal Nodes - Nodes that do not get *.TIC files o Autoadding of new (unknown) areas from trusted nodes o Automatic adding of selected nodes to autoadded areas o Passthrough areas o Full dupe checking (optional) o Full CRC checking (optional) o Imports/Exports areas and nodes from/to a standard TIC.CFG o Hatch - both command line and interactive ─────────────────────────────────────────────────────────────────── Licensing and all that guff ─────────────────────────────────────────────────────────────────── YaTic is free. That's not to say it's freeware, I still retain the copyright, and will not make the source freely available. However, if you like the program, and you want to use it, do so with my blessing <GRIN>. All I ask is that the distribution archive not be messed with in terms of the files within it - it may be re-packed using your favourite archiver, but the files inside it may not be tampered with. If you do like it and use it though, I would appreciated a postcard from wherever you are. That just keeps me a happy man, and much more likely to fix bugs or add features. See below for an address. Yatic v1.00 Page : 2 ─────────────────────────────────────────────────────────────────── On the other hand, if it breaks, or it breaks your system, I will accept no responsibility. YOU USE YATIC AT YOUR OWN RISK, AND I WILL NOT BE HELD LIABLE FOR ANY PROBLEMS THAT MIGHT OCCUR THROUGH ITS USE. That out of the way, if you report any bugs to me, I will try and get them fixed for you. The program runs AOK here, but no one can be sure how it will run on other systems. Many thanks to the Beta Testers for all there help : o Grant Wilson o Craig Gibson o Harry Konstantinou o David Leach o Ben Elliston o Noel Roberts o Colin Lean o Paul Marwick o Hamish Moffatt o Jeffrey Itzstein o Heinz Mueller Also many thanks to those who reported bugs and then helped me fix them - always much appreciated. The latest version can be file requested from my system using the magic name YATIC, and the latest public beta as YT_BETA. For any support contact one of the following addresses : 3:620/248.0@fidonet (Fidonet) 58:2600/100.0@intlnet (IntlNet) 20 Yiman St (Snail Mail) Waramanga Australia, ACT, 2611 I hope you like the program. Yatic v1.00 Page : 3 ─────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────── Configuration ─────────────────────────────────────────────────────────────────── Configuration of YaTic is a reasonably straightforward procedure, consisting of two steps. The first is to run YtConfig in the programs directory, and fill in all the blanks. The second is to modify the text files used by YatMan to suit your system. YtConfig ─────────────────────────────────────────────────────────────────── YtConfig is the basic configuration program of YaTic. It handles all the areas, nodes and general points about your system. It's basically self explanatory, with a help line at the bottom of the screen to tell you what various options are for. It starts up in the main menu, with the following options. Note that for all edit screens, the information is saved by hitting Ctrl-Enter. System Info ─────────── The first menu option simply brings up a new menu, used to define the necessary information about your system. It has the following three sub options : General ─────── Selecting this will bring up a general information screen. The options within this are as follows Binkley : Tells YaTic whether you are using an oMMM environment. Under Binkley file attaches are done directly in the outbound area. If you select 'N' here, YaTic will use matrix mail (*.MSG) to attach new files. Use Intl : Many systems these days (usually those running more than one domain) prefer to ensure that ALL messaged leaving the system use the ^AINTL kludge line, rather than just those going to another zone. Select 'Y' here to ensure this kludge line is always on. Dupe Checks : Globally turn off all dupe checking. This overrides any areas that are checking for dupes. If set to 'Y', YaTic goes by the selection for each area as to whether to check for dupes within it. Yatic v1.00 Page : 4 ─────────────────────────────────────────────────────────────────── Check CRC : Files usually come with a CRC in their associated TIC file. This is used to ensure the integrity of the file when it reaches your system. CRC checking takes most of the time required to process inbound files, otherwise turning this off will not affect things much, but might allow garbled files to get passed on. Delete Requests : Delete YatMan requests once handled. If this is set to 'N', YatMan will mark the request as received and continue. Delete Replies : If this is set, YatMan will mark the replies it makes as delete when sent. When this is set to 'N', all replies will be kept after they are sent. Delete TIC files : Only applies to FD systems (i.e. those that use a *.MSG style file attach). When this is active, YaTic will use two attach messages to send a new file to a system, one for the file, and the other for the TIC file (marked as Kill File when Sent). This way, you know TIC files are being deleted ASAP. On the other hand, when set to 'N', YaTic will use one message for both attaches, using less disk space, but implying that the TIC files are kept until a maintenance run is performed (YATIC /maint). Default Mail Type : The mail type (Hold, Normal, Crash or Direct) to be used on nodes that you do not know. I.e. nodes who send YatMan requests, but who are not known on your system. This mail type will also be used when a new system is added to the node database, either through inserting a new one, or through importing a TIC configuration. Default List Entry : This is a standard FILES.BBS entry string (as seen below in the section on the areas database), and is used as the default whenever a new area is autocreated, or as the default entry when you are adding a new area to the database. Default List Name : As for above, but for the name of the file. Directories ─────────── This menu defines all the major directories needed under your system for YaTic to run properly. All directories should end without a slash, i.e. c:\binkley not c:\binkley\. The entries are as follows : Matrix Mail : Where your netmail is kept. Used for attaches in a FD environment, and for YatMan requests. Inbound Files : Where YaTic should look to find inbound TIC files etc. Yatic v1.00 Page : 5 ─────────────────────────────────────────────────────────────────── Out TIC files : Where YaTic should place TIC files on their way out of your system. This is also where files in passthru areas will be placed until they have been sent to all your downlinks. NO FILES SHOULD BE PUT IN THIS DIRECTORY unless by YaTic. Any files not known by YaTic will be deleted. Autoadd Root : YaTic allows defined nodes to create new areas. It will set up undefined areas from these nodes with the info from the TIC file the new area was found in, and will create a directory under the autoadd root with the name of the area. Thus if the autoadd root is c:\bbsfiles, and a new area YT_DEV comes in from a node that is allowed autoadd, the directory c:\bbsfiles\yt_dev will be created (if it does not exist) and will be used for the new area. Dupe Files : The directory where dupe info will be kept. When asked to, YaTic keeps a file for each area containing the file names of files it has seen. Along side this it keeps the CRC's of those files and the date they were seen. (These are kept in files made up as area_name.DUP, i.e. YT_DEV.DUP for the YT_DEV tic area). You should run YaTic /maint regularly to clear this directory out. See the section on maintenance for more on this. Passthru Files : Where YaTic should store passthru files until all downlinks have picked them up. WARNING - Do not keep any other files in this directory, as they will be deleted due to maintenance. (*.TIC files will NOT be deleted, so the OUT TIC FILES directory can be used, though this slows maintenance down.) Log File : The file all YaTic activities will be logged to. This should be a full filename, but should not be opened by any other program whilst YaTic is running, since no sharing is supported (yet). Templates ───────── The names (and directories) of the files to be used as templates for YatMan can now be specified. They default to the names from earlier versions, and in the current directory. System Unknown : The file to be used as a template when sending a reply to a system unknown in your node database. Password Incorrect : Where to find the template file for the password incorrect message. Help : Template for the message sent to the remote system when they ask for help (using the %HELP keyword). Log ─── Yatic v1.00 Page : 6 ─────────────────────────────────────────────────────────────────── YaTic allows you to select what it will put in the log. At the base level, with nothing else being logged, only fatal errors, and the names of the actual TK*.TIC files will be logged, along with a line saying a message from a node has been processed by YatMan. Apart from that, you can define other bits that will be defined, such as the names of actual files coming in, the CRC's of those files, description etc. By setting the particular box to 'Y', YaTic will log it. Setting Debug to 'Y' will turn on ALL messages, regardless of there individual setting. Domains ─────── This section is mainly for Binkley users, and is not really accessed during normal operation. However, it is used when exporting TIC files, and should always be defined. For Binkley users, there are a number of entries, each broken into three parts - zone, domain name and domain directory. For the zone, enter your zone for this domain, for the name, enter the domain name with no frills. (I.e. fidonet, not fidonet.org). For the directory, enter the main directory stub, without any zone extension. The first entry MUST be the main zone under Binkley. Thus for zone 3 in fidonet as the main domain, and zone 58 of intlnet, the form would look like : 3 fidonet C:\BINKLEY\OUTBOUND 58 intlnet C:\BINKLEY\INTLNET Note that the intlnet directory does NOT have a zone extension. System AKAs ─────────── You should enter all the addresses your system is known by here. Full 5D addressing can be used (though it need not be). The first entry should be your main address, as this will be the address defaulted to when YaTic can not match any other address to the outgoing mail/files. Reports ─────── Reports are new in v1.00, and are the YaTic method of reporting inbound (or hatched) files that come through your system. You can define up to ten report templates, and each file that comes in will be checked against each of the these templates as to whether it should be reported here. Each template defines an echo area to put the message in, and the groups (inbound) that are to be Yatic v1.00 Page : 7 ─────────────────────────────────────────────────────────────────── reported. YaTic will automatically perform reporting of any (successfully processed) files during a normal toss operation. Yatic v1.00 Page : 8 ─────────────────────────────────────────────────────────────────── Upon selecting this menu option, you will be presented with a list showing the ten possible templates. Each has four columns specifying whether it is active, whether it will also report hatches, what echo area it is put into, and lastly, the groups that are to be reported using this template. You can select any of these 10 templates to edit. All reports go into packets. I found this to be the most convenient system for outputting echo mail, since it removes the problems of having to write an interface for all the available mail types. You should address the packets to your own system (either from your own system, or from a bogus address), and ensure that your mail tosser does not check the systems that are sending mail in that area. Selecting one will bring up a new entry screen showing the options available for that template. These options are as follows. Active : If set to 'N', this template will be ignored when processing inbound attaches. Hatches : Should hatches within the given areas also be reported here? To Addr : The address echomail messages (and the associated packets) should be addressed. (I would suggest your own address, and using an area that is not secure in your mail tosser). From Addr : The address the echomail messages (and packets) should be marked as coming from. I use an address that does not exist for that area, and an insecure area (within my mail tosser). That means I can put messages into the area and have them exported to all connected systems without having any mail lost or sent to nonexistent systems. Area : The echomail tag of the area to place the messages in. To User : Who to address the messages to. In Groups : Inbound files must come in one of these (inbound) groups before they will be reported. Subject : The subject line of the message containing the report. Origin : The origin line of the message. Template : The text file describing the format of the message itself. This file is described in much greater detail below, and a sample should have come in the archive. Yatic v1.00 Page : 9 ─────────────────────────────────────────────────────────────────── Areas ───── YaTic has it's own inbuilt area database that is maintained here. It is very similar to that seen in the echo mail processor TosScan and later such programs. You can cycle through the areas set up using the left and right arrows, along with the home and end keys. The following keys will also work : del : Delete the current area ins : Insert a new area F1 : Edit the current area F2 : Edit the list of systems connected to this area F3 : Select AKA to be used for this area. (You will be given a menu of defined addresses to choose from.) F3 : Go into "global" mode, changing attributes over a set of areas, defined by in and out security. To make jumping to an area easier, the manager will accept normal ASCII input, and will use the string selected so far to find the best match area. Thus pressing 'BBS' will jump to the area BBS_FILES (or the nearest possible match to a string starting with 'BBS'.) Editing an Area ─────────────── Hitting ins or F1 on an area will put you into edit mode. This is a TCXL entry form, allowing you to edit most of the fields (the list of connected systems is handled later). The fields you can edit are as follows : Area Name : The TIC name (tag) of this area. This is the name YaTic will look for in the TIC file associated with a given file. Comment : This is a comment you might want to make about this area. The comment will appear in YatMan lists sent to requesting systems, so it should explain what the area is. Directory : The directory into which files for this area will be moved. List Filename : The name of the file that will have the information about new files in this area appended to. This is typically just FILES.BBS (for RA systems and the like). It can be fully pathed, or the name given here will be appended onto the directory for this area. Thus, for an area residing in the directory C:\TIC, we could have a list filename of LIST\FILES.BBS, and the new line would be appended to the file C:\TIC\LIST\FILES.BBS Yatic v1.00 Page : 10 ─────────────────────────────────────────────────────────────────── List Style : This allows you to uniquely specify the line that will be added to the List file given above. It is a normal text string with control words embedded in it. For Example : %12NAME% [00] %DESC% This will give the name of the file just imported, left justified in a field of 12 characters, followed by a space, followed by [00], a space, and the description of the file. if I had written %12!NAME%, I would have got the name of the file right justified in a field of 12 characters. Just %NAME% would have given the name without any spacing before or after. (The line above gives a standard FILES.BBS entry with a two digit download counter). Currently the only other control word known by YaTic is %AREA% to give the area name of this area in the files list. I have plans to improve the number of elements in this list in the near future. Inbound Group : This is the main security section of YaTic, and is a single letter, from 'A' to 'Z'. For a file to be accepted from a node in this area, that node MUST have this letter in its inbound security area list. Outbound Group : Similar to above, but it is for node receiving files from you. This means you could have to nodes who ONLY send files into the area, but never want any. All the nodes that receive the files in this area would have this letter, but not the two that send files to it. Passthru : Defines this area as a passthrough area. That means that you don't keep files in it. They are simply sent on to downlinks who require them, and then deleted. Note that in this case the directory argument is ignored. Files will be placed in the tic outbound directory, and deleted after all downlinks have received them. Note that for these file to be deleted, yatic /maint MUST be run. This checks the TIC files in the outbound, and any extraneous files without an attached TIC file will be deleted. It is NOT done automatically by tic, so as to speed up normal processing. Allow Replace : This means REPLACES lines are allowed in this area. Later versions of TIC allow for updates of files to come in, deleting the older version of this file. If you do not want updates to work in this area, simply set this to 'N'. Yatic v1.00 Page : 11 ─────────────────────────────────────────────────────────────────── Dupes Age : Dupe lists can tend to get a bit large, and yatic /maint is needed to reduce them in size. The sets the number of days you will keep dupe information for inbound files. Any dupe info older than this number will be deleted on the next maintenance run. Setting this to 0 will ensure that dupes are never packed by age in this area. Dupes Number : Similar to above, but sets the maximum number of dupe entries to keep. Any amount greater than this number will be reduced by deleting the oldest files when /maint is run. Setting this to 0 will ensure that dupes are never packed by number. (Setting both number and age to 0 will ensure that dupes are just never packed!). Check Dupes : This option will turn of dupe checking for this area entirely. Note that even if this is 'Y', dupes will not be checked for unless the same option in the general configuration is also 'Y'. Global ────── You can also make changes over many areas at a time. Hitting F3 will bring you to the global menu. Simply select the option you wish to change from this menu, and then the inbound and outbound groups an area must belong to be changed. You will find that for each option, a new window will pop up asking for related information - the information wanted here is discussed in the sections above. Nodes ───── As for areas, nodes are stored in a special database that YaTic can access easily. Selecting nodes in the main menu will take you to a section similar to that for areas above. Here you can move through the nodes as above, deleting or inserting. (You will find that if you enter this option with no nodes defined you will be placed straight into edit mode of a new node. The same goes for areas above). Unlike areas however, there are no global options on nodes. When editing a node, the options are as follows : Address : The address of this mode. This can be a full 5D address, just zone:net/node or zone:net/node.point. Yatic v1.00 Page : 12 ─────────────────────────────────────────────────────────────────── Password : This is the password that YaTic will expect to see in TIC files from this node, and will send in TIC files to this node. It is also the password to be used in YatMan requests (on the subject line). In Security : The list of inbound security groups belonged to by this node. For this node to send you files in an area, he must have that areas In Security group in this list. Out Security : The list of outbound security groups belonged to by this node. In order to receive files in a given area, the node must have the Out Security for that area in this list. Auto In Sec : If this node is allowed to Create new areas (see Can Create below), this is the In Security that will be given to any areas so created. Auto Out Sec : Similar to above, but corresponds to the outbound security of the autoadded areas. YatMan : Is this node allowed to make YatMan requests? If set to 'N' the only way the node will be able to alter his/her connected lists is by direct request to the SySop, since YatMan will ignore any requests. (In fact it will send back a reply saying "I don't know you"). Can Create : This is normally used on your main TIC hub. Sometimes this node might send through new areas to you without telling you first. If this option is enabled, YaTic will simply add the area to it's list of areas, and process the area as normal. Any nodes with 'New Areas' set to 'Y' will be connected to the area, and the directory for the area will be set to your autoadd dir with the area name concatenated on the end. You should only allow this option for trusted nodes. 4D Compatible : Tick does not (at the time of writing) know about points as such, and will throw out error messages if it comes across seenby lines with points. For downlinks using TIC you might want to remove such lines. Setting this to 'Y' will mean that TIC files going to this system will be filtered, and such lines removed. Remote Maint : Again this option should only be turned on for VERY trusted nodes. It allows such nodes to remove areas. (At a later date it will be able to do more). This would be primarily used by your uplink when he/she removes an area from the system. Sending YatMan a maintenance request at the same time will help ensure you have no redundant areas on your system. A request to delete an area is exactly as for a normal removal request, except that instead of '-' a '^' is prepended to the area name. Yatic v1.00 Page : 13 ─────────────────────────────────────────────────────────────────── Terminal : Terminal nodes do not resend files to anyone, and do not want the TIC file normally associated with echoed files. Setting this option to 'Y' will mean that any files sent to this system will not be accompanied by the corresponding tk*.tic file. New Areas : If this option is set to 'Y', then this node will automatically be hooked up to areas autoadded by other nodes. Mail Type : This is way of holding mail for this node. It can be one of 'H'old, 'N'ormal, 'D'irect, 'C'rash. Import/Export ───────────── YaTic can import information about the areas and connected nodes on your system from a TIC.CFG file. NOTE : This option will delete your old area list. It should be noted that by necessity this option is fairly limited. All added nodes are given an in/out security of 'A' and so are all areas. This means you will have to go through and edit these by hand. Also nodes are given the first password that YaTic can find in the TIC file, so care should also be taken here. You will also have to set up other information, such as your system addresses and the like, by hand. As of version 1.00, YaTic will also export a TIC file. It is however somewhat primitive, and the control information may have to be edited by hand (remembering that YaTic and Tick handle certain functions in different manners). Text Files ─────────────────────────────────────────────────────────────────── YatMan templates ──────────────── YaTic uses some additional text files in its configuration. These are for YatMan messages. At this time, the following files are used. The names and locations of these files can all be defined within YTCONFIG : YATPASS.TXT : Will be sent to a node who sent a request with the wrong password. YATUNKN.TXT : Sent to nodes that do a YatMan request, and who are unknown on your system. Yatic v1.00 Page : 14 ─────────────────────────────────────────────────────────────────── YATHELP.TXT : Sent to any node requesting help from YatMan (using the %HELP command in the request message). These files should be straight text, formatted as you want them to appear in the message. For ease of use, you can uses embedded control words, similar to those used in the list string. Allowable control words are : %name% : Full name of the requester. %firstname% : First name of the requester. %lastname% : Last name of the requester. %passfailed% : The password that failed (should only be used for YATPASS.TXT). %address% : The address of the node that sent the request. Report Templates ──────────────── In order for YaTic to report on processed files, it needs a template to tell it how to format the information in the message. The template is broken into blocks, according to the part of the message it is describing. Each block starts with a block descriptor (a command beginning with a '\' telling YaTic which block this is), and continues until another block starts. Any text within the block (after the command line) will be used for that part of the message, with control words being translated as for the message templates given above. An example template came with the distribution archive, under the name REPORT.TPL. The blocks that can be used are as follows : \header : Starts of the message. Anything here will be put at the start of the report. This might tell people what the messages is, or the hours you allow file requests. \file : This block is put into the message once for every file processed. It is used to put the name, description and/or any other information you desire. The control words usable are listed below. \break : When the message is getting too long, YaTic will break it into parts. This block will be placed at the end of every message that makes up the report, but is not the last. \continuation : Placed at the start of messages that continue a report started in previous messages. It might contain something as simple as "Continued from previous message". \trailer : The round up. This block is placed on the end of the final message in the report. I use it to tell the reader how many bytes of files were processed. Yatic v1.00 Page : 15 ─────────────────────────────────────────────────────────────────── The following control words can be used in the report. Formatting is as given for the message templates above : %name% - Name of the file just processed. %desc% - Description of the file just processed. %file_size% - Size of the file just processed. %area% - Area of the file just processed. %area_desc% - Description of the current area. %total_size% - Total bytes of all files processed. Other control words will be added in future versions. Any requests, let me know. ─────────────────────────────────────────────────────────────────── Running YaTic ─────────────────────────────────────────────────────────────────── YaTic is run from the command line, and should be run from it's own directory. (This will be fixed at a later date to allow to run from ANY directory). Running YATIC /? will bring up a help screen. Normal Running ────────────── During a normal run, when you want Yatic to scan for inbound tic files and YatMan requests normally, you should run plain YATMAN in your batch file. However there may be times when you wish to disable YATMAN. This is done by running YATIC /nomgr Maintenance ─────────── YATIC /maint will run the maintenance required for YaTic. This includes packing the dupes files according to the information you have provided in the area manager. It will also delete files in passthru areas that have been sent to all the downlinks. If you do have passthru areas, then /maint should be run at least once a week to ensure space on your drive is freed up. Other Switches ────────────── There are two other switches to help in day to day running of YaTic, these are /NOCRC to turn off any CRC checking while processing files, and /NODUP to turn off dupe checking. These might be useful when something goes wrong with inbound files and a re-process is needed. Yatic v1.00 Page : 16 ─────────────────────────────────────────────────────────────────── Hatch ───── YaTic also allows you to hatch files into an area by creating the appropriate TIC file and sending the file to ALL your downlinks. To hatch a file, use the command YATIC /hatch YaTic will then prompt you for the name of the file to hatch (full name, no wildcards allowed) and the area name. It will then send the file. At this time YaTic does not support delayed releases of files; this will be supported in future versions. YaTic also now supports command line hatching (mainly for batch file processing). The command YATIC /hatch /? will bring up a help screen listing the options associated with hatch. These are : /f File name. FULL PATH and name of the file to be hatched. At this time, wildcards are not supported. /a Area name. The area tag of the area for the file to be hatched in. /d A description of the file being hatched. This is in inverted commas, and should be kept as short as possible. /r Replaces. This activates the replaces function in YaTic hatch. The file name given will be put with the REPLACES keyword in all outbound TIC files. Any receiving system will replaces the file given here with the new file (deleting the old). This option is generally used for new versions of a program. Thus the command line : YATIC /hatch /f d:\yat19.arj /a YT_DEV /d "New Yatic" /r yat18.arj will hatch the file d:\yat19.arj in the area YT_DEV with the description New Yatic. The file yat18.arj in the area will be replaced with the new version. Yatic v1.00 Page : 17 ─────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────── Area Manger - YatMan ─────────────────────────────────────────────────────────────────── YatMan is the remote area manager associated with YaTic. It can be used by your downlinks so that they can connect to and disconnect from areas without having to worry you about it. For a downlink to utilize YatMan they simply send a netmail message to your system as follows : FROM : Remote sysops name TO : YatMan SUBJECT : Password <── This is the password for the node in the node manager. ─────────────────────────────────────────────────────────────────── SOFTDIST <── Turn this area on WIN_UTIL <── And this -BBSFILES <── Turn this area off ^win_prog <── Delete this area entirely %LIST <── Send a list of possible areas %QUERY <── Send a list of connected areas and information. %HELP <── Send a list of commands ─── This request, if the password in the subject field is correct, will turn on the echos SOFTDIST and WIN_UTIL, and turn of BBSFILES. Following this it will delete the area win_prog from the YaTic database ENTIRELY (assuming the node is allowed to perform remote maintenance). It will then send the node a list of all the echos it may connect to, with those that it IS connected to marked with a '*' on the left. The query option will send the node a list of all the areas it is connected to, along with some other information about the capabilities of that node, and the help option will send a help message, outlining these options. Anything after the tear line will be ignored. YaTic will delete any messages it processes and mark the replies as Kill/Sent according to the options specified in the configuration. Yatic v1.00 Page : 18 ─────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────── Afterword - Future Directions ─────────────────────────────────────────────────────────────────── I hope that YaTic is in itself a complete program, and I hope you get a lot of use out of it. However, I am planning to add a few enhancements to it in the near future : o Improve the area manager. Would like to have the areamanager automatically send unlink requests to downlinks when it gets told to delete an area. o It would also be nice to have a system whereby, when a person creates a new area, the first TIC file they send will contain the area description. o A file area manager. One of the problems with the TIC system is a lot of stuff neither you nor your users ever want to use comes through the system. It would be nice for YaTic to see how many times a file is downloaded over time, and if it isn't enough, move it to another area where you as the SySop can deal with it as wished. o Secondary areas (as per TIC). o Better import/export options. Ability to export to various BBS formats (such as FILES.RA). o Automatic updating of various database formats being used to store file lists for fast updates. ─────────────────────────────────────────────────────────────────── Credits and Acknowledgments ─────────────────────────────────────────────────────────────────── The following copyrighted programs were mentioned in the document : o Tosscan Joaquim Homrighausen o Tick Barry Geller o AllFix Harms Software Engineering o Raid George Peace Yatic v1.00 Page : 19 ───────────────────────────────────────────────────────────────────