PC Online 1997 March

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

/ PC Online 1997 March / PCO3_97.ISO / filesbbs / dos / xor115.arj / XOR.DOC < prev next >

Wrap

Text File | 1997-01-23 | 54.4 KB | 1,500 lines

╒══╕ ╒══╕ ╒═══════╕ ╒═══════╕ │░░│ │░░│ │░░░░░░░│ │░░░░░░░│ ╘══╛ │░░│ │░░╒════╛ ╘════╕░░│ ╒════╛▒▒│ │▒▒│ ╒══╕ ╒════╛▒╒╛ │▒▒▒▒▒▒▒│ │▒▒│ │▒▒│ │▒▒▒▒▒▒╘╕ │▓▓▓▓▓▓▓│ │▓▓│ │▓▓│ │▓▓╒═╕▓▓│ │▓▓╒════╛ │▓▓╘═╛▓▓│ │▓▓│ │▓▓│ │██│ ╒══╕ │███████│ │██│ │██│ │██│ │██│ │███████│ │██│ │██│ ╘══╛ ╘══╛ ╘═══════╛ ╘══╛ ╘══╛ An online request processor for McMail, FrontDoor, Intermail and compatible systems V e r s i o n 1.15 Program and documentation Copyright (c) 1993-97 by Mirko K. Mucko Overview 0 Overview / legal notes 1 Introducing this software 1.1 Hardware requirements 1.2 Software requirements 1.3 Other requirements 2 Getting started.... 2.1 xOR.CFG - the configuration file(s) 3.1 Command line parameters 3.2 Calling from McMail 3.3 Calling from FRONTDOOR 3.4 Calling from INTERMAIL 4.1 FBBS2IDX 4.2 RA2_IDX 4.3 xORUTIL 4.4 Special macros 4.5 Command line parameters for xOR 5.1 Trademarks 5.2 Thanks 'n such stuff 5.3 Contact the author 5.4 Registration sites Legal notes xOR is neiter public domain nor sales-war. I wrote it in the spirit of shareware, which means you may use it for 30 days, and if you like to continue, you must register or stop using it. I spent over 3000 hours working on this project, so registering will keep myself working on new features :-) Even so, xOR, it's documentation, executable and source code is protected by international law and both, written and copyrighted by Mirko K. Mucko, Duesseldorf, Germany. The distribution packet, originally stamped with my PKware's ZIP authentitiy verification, may be freely distributed as long as no modifications on the archive, the contens of the archve or the single codes, includung the text files, will appear. I cannot guarante for the errorfree function of xOR, nor for neither implicied or explicied failures succeeding of the usage or even owning of xOR. But I tried my best to avoid any damages to you, the user, as long as you do not start hacking in the EXE files. All functions introduced with this sign "{+}" are features only avail in the fully registered version. 1. Introducing this software I guess, it was in late september '93, my file base was grown to a maximum of 15.000 files with 2 GB in size, and my front end mailer, FrontDoor, was no longer able to handle on the one hand such lots of files and on the other hand, there was the highly demand from friends and also from my site to reduce the number of requests for several people (called "sucker" :-). It was also my impression, FrontDoor is too unflexible concerning passwort protected file requests, limits, events and so on. At the same time, I got FrontDoor 2.20.a.ml, which was the very first mailer supporting external file request processors like you're about to install. So, I tried to design such a program, and hopefully I may say, it's a success. Within the first few weeks after releaesing gamma 1, I got lots of registrations, and nearly everyone who took time enough to install this programm said it's "great stuff". So I collected new feature requests and checked over and over the damn source code, which is actually about 2.1 MByte in size. The version you hold actually on your [hard] disk is the latest release of an external request processor, which provides many features such as multiline awareness, extensively fast speeded search in own indexed file databases, an file, time and number counting system including different limitations for different users, event management, also password management with in/excluding different users or groups of users from special pathes or files and so on. You see, it's worth continue reading 1.1 Software requirements Required is as operating system MS-DOS version 3.3 or higher or DOS Box of WIN'95 build 950 or higher or PC-DOS version 3.3 or higher or DR-DOS version 5.0 or higher or Novell DOS version 7.0 or higher or any compatible operating system Also, you need a mailer such as McMail 1.00g1 or higher or FrontDoor version 2.20 or higher or FrontDoor version 2.11/reg or higher or Intermail version 2.27 or higher or any compatible mailer system xOR has been extensively tested with this software : MS-DOS 5.0, 6.0 up to 6.22 MS-DOS 7.0 DR-DOS 6.0 Novell DOS 7.0 up to patch level 9 NOVELL Netware 3.11, 3.12, 4.02 and 4.1 with SFT-III 4.1 4DOS 4.00, 4.01, 5.0f and 5.50 QEMM 7.01 up to 8.00 and many other high memory driver Quarterdeck's DESQview version 2.42 and 2.63 1.2 Hardware requirements xOR requires intel processor 80386 or any higher or compatible processor and min. 350 KByte during run-time. To make this possible, we suggest a absolute minimum of one megabyte RAM for swapping features of your mailer and xOR. xOR needs a minimum of 400 KByte on your hard disk plus additional storage for the compiled index, which may increase to an unlimited size [with 20.000 files, the index is 7 MB in size]. It is recomendet but not required to have some EMS avail for buffering operations. 1.3 Other requirements Also, you need either a "FILES.BBS" in each directory or must have your files in one of the supported indexed filebase. Actually, xOR does support from startup these indices : FILES.BBS included RA 2.0x included RA 2.5x included as BETA version ( I didn't get any feedback) EzyCom 1.10 Ezy2xOR 0.5x written by B. Huertgen If your favourite software is not yet included, pass me the structures and we will see whether it's neccessary to implement these structures. 2.0 Getting started It seems you're still interested in xOR - OK, I'll warn you: xOR is not easy to configure if you want make use of all its features, but I can tell you : it's realy worth it ! To run xOR, you need in single line environments a config file called xOR.CFG which must be found in the same directory as xOR.EXE. If you're running multiline environments, you have two choices : 1) You may use the same config file for all lines -> it's ok. Just call it xOR.CFG 2) You want different configs, perhaps due to different AKAs [even if xOR will handle unlimited] or have some other mad thing in mind : null problemo! The names are xOR<TASK>.CFG. During startup, xOR determines the CFG name by the environment variable "TASK". So on startup, xOR checks the configs in this way : 1) xOR<TASK>.CFG avail ? If no, 2) xOR.CFG avail ? If no - > abort! 2.1 xOR.CFG - the configuration file Now, I'll explain the sample configuration file accomplished with this package line by line ..... Note for all records : all AKAs, Passwords, path entries and so on are only limited by the free memory, RAM and on hard disk. So, xOR handles all memory usage dynamically! MAINAKA 2:2433/920 TXT This defines your MAIN aka. This AKA is used whenever no AKA matching is possible for response mails, either due to missing configuration lines or due to unknown AKAs on the remote site. The last parameter is the extension for all response message texts. So, as default, all responses will be taken from files with extension ".TXT". For usage of these files, please read late on. AKA 144:4913/0 144:*/*.* GAM AKA 144:4913/410 144:4915/*.* GA2 AKA 95:2408/0 95:*/*.* RAF Now, we have three more AKAs. For all users requesting with "144" as zone,my AKA 144:4913/0 is used and ".GAM" as extension, but if there're nodes/points from within my network, I'd like to use other text files and my normal node AKA. Also, the extension ".RAF" and my AKA 95:2408/0.0 is taken for the RA File Network. LOGFILE F:\LOG\xOR$%TASK%$.LOG This is the name and path of xOR's logfile. This is the "long" versions for muoltiline systems, but may be used also on single line systemes if TASK as environment variable is set. The same applies to OLILOGFILE, which is used for the off line interface of xOR. INBOUND C:\MCM\INBOUND.SEC INBOUND is you *.pkt directory. xOR posts here several text files to be imported either as netmail or as echomail. Therefor, if you have a "secure" inbound for your mail tosser, use that one. NETMAIL F:\SHRD\NETMAIL NETMAIL defines the path to your *.MSG (="Matrix") messages. HOMEPATH D:\TP\PRG\FIDO\xOR This is xOR's main path. Here xOR will try to find it's CFG files and other more or less important files :-) PKTPATH C:\TEMP\xOR This is the path for temporary storing files such as SWAP files or temporary response packets. This dir may point also to a RAM disk. Now, let's come to some data bases and related files : ALIASFILE D:\ALIAS.IDX ALIASDESCBASE D:\ALIAS.DSC Use these statements to define the name and path of the xOR internal database holding all ALIASes you will define. Now, you don't have to have a FILES.BBS in this directory since xOR will evaluate during compiling time the description of your ALIAS files. Note these things: The aliases name *AS DEFINED IN xOR* must be in your description file (FILES.BBS,RAindex or what so ever) So, if you define "POINTLST PR24LIST.###", be sure that "PR24LIST.###" is listed in your FILES.BBS !!!! DATABASE C:\TEMP\xOR\xOR.FDX This is the name and path of your "primary" database. It will contain after compiling the index files an quick index with all file NAMEs. DESCBASE C:\TEMP\xOR\xOR.DSF This is perhaps the largest database. Due to the circumstances xOR will support ANY kind of external file database, it is required due to speed on the one hand and due to the fact also other programmers may support xOR's index files to keep all descriptions in one file. CDINDEX C:\TEMP\xOR\xOR.CDX This file will contain all files which are included from the CD's if you're using CDs for file request. CDDESCBASE C:\TEMP\xOR\xOR.DCD This is, if you're using xOR also for CD file areas, the description database for these files. CDPATHINDEX C:\TEMP\xOR\xOR.CDP This file contains all pathes from which files are requestable concerning CDs. PATHBASE C:\TEMP\xOR\xOR.PDX This file will contain all pathes xOR will send files from. USERBASE C:\TEMP\xOR\xOR.USR In this file, xOR will keek it's statistical records concerning the user's bahaviour to determine the free amount per day and so on. ResumeIndexPath C:\TEMP\xOR\RESUME As you may see, this is not a file but a PATH. Be sure this path DO exist when you run xOR ! In this path, information about requested files will kept, e.g. for determining whether a user requests one file twice due to CARRIER LOST or similar reasons. StatisticBase C:\TEMP\xOR\STATIS.DAT DLStatisticBase C:\TEMP\xOR\DLSTATIS.DAT These statements are required if you wish to use statistic funtions for requested files (number of accesses, last time ect) and update the download counter in your BBS software. If you wish to use DLStatisticBase in conjuntion with FILES.BBS via FBBS2IDX, use also these statments : DLDigits 3 DLBrackets [] With these statements, a download counter will be inserted with three digits (filled with "0") and in these brackets : [ and ]. CDBUFFER C:\TEMP\xOR If you enable this switch, and users request files from CDs, due to speed reasons the files are copied before sent by your Mailer. Its advantage over "unbuffered" sending is that after the file has been copied, you may do everything you want with the CD, including change it (e.g. if you have a CD ROM changer like me). Warning : if you're running multi line environments (e.g. via SET TASK=<Task>), xOR will *not* copy the files from CD to this path but to a path defined by the environment variable TASK as extension. So, if TASK is 3, the diretory to which xOR will copy the file would be "C:\TEMP\xOR.3". Be *sure* this directory exist ! SYSOP Mirko Mucko This is your name. It should be equal to the name in the key file. OLICFG D:\TP\PRG\FIDO\OLI.CFG OLICFG defines an alternate configuration file for xOR. This file is passed to XOR, *not* to XOROLI on calling. Use it e.g. if you have different pathes for online / offline requests or similar. The file will be passed to XOR via "/C<FILE>" command line argument. Ommit this to use the default cfg file. AliasList F:\SHRD\FILES\ALIAS.LST This is the name and path to your raw alias input file. It defines the context of the file someone requests ans the resulting response. The syntax within this within this file is <ALIAS> <Corresponding file(s)> [!password] [#Release-Time] The "[" "]" are not required of cause :-) You may also define wildcards within the list, like "ALLNLIST NODELIST.*" would do. Also, if you do not want include secondary files, you may specify the aliases within xOR.CFG with this dtatement: ALIAS CD F:\SHRD\FILES\XFILES\CDROM.ZIP ALIAS NODELIST F:\SHRD\NODELIST\ORG\NODELIST.>* ALIAS 24000 G:\FILES\ANTR\24000.ZIP !PNTLIST Here, we have also a very important macro for aliases : the extension ">*" will be translatet to the latest file matching "NODELIST.*" in this case. To explain the "Release-Time" thing, look at this example : ALIAS xOR C:\FILES\xOR115.ZIP #230197-0000 This means, starting on Jan, 23rd 1997 at 00:00h,with the magic "xOR" you may get the version 1.15. This is useful if you're about to spread files by magic starting on a special date/time. Note that date/time is expressed in European format, not in US. The description for aliases is taken from RA or FILES.BBS. Note that the description must fit to the file, not to the entry in xOR (concerning wildcards and "latest file" function ), so if you specify "NODELIST.>*", and "NODELIST.A93" is the current one, be sure that in FILES.BBS or RA is NODELIST.A93 defined. If not, the alias compiler will note you. I'd like to explain how the alias description is taken: in FILES.BBS environment, it's no problem to take the desc. from the FILES.BBS which is in the same path as the alias file itself. In RA2.xx environment, xOR saerches in the path database from RA for an matching path and then searches in the file database for the matching entry. So, the fastes way is to have file area 1 in RA as an "invisible" area in which you summarize all of your alias files. To grant users access to files, you have to use three statements. First of all, you have to define groups: UserGroup AllUser ALL UserGroup PROT Protected UserGroup UNPROT Unprotected UserGroup Unlist Unlisted UserGroup MyNet 2:2433/*.* 2:2440/*.* UserGroup MyPoints 2:2433/920.* 2:2433/921.* UserGroup Friends 2:2433/1800 2:2433/500 2:2433/503 2:2426/2004 UserGroup MCMBETA 2:2426/2004 2:2426/2090 UserGroup Sysop 2:2433/920.0 Then, you have to define Groupnames for Pathes: PathGroup AllFiles g:\Files PathGroup CDFiles L:\ M:\ N:\ O:\ P:\ NW312SVR\FILES:\PUBFILE PathGroup Erotic K:\ g:\Files\xgif Note that xOR fully supports Netware Server\Volume: specifications like in sample above! In the next step,we concat both groups with each other [very simply, just belive in it :-] Grant AllFiles EXCEPT Erotic TO AllUser Grant CDFiles To AllUser Grant Erotic To MyNet Grant Erotic To Friends Examining these statements, you should come to this conclusion: 1) all files in g:\files [group "AllFiles] EXCEPT the files in g:\files\erotic are accessable to all user 2) all CD ROM files [Group CDFILES] are ok for all user 3) the files in K:\ and g:\files\xgif are only valid for my friends, defined in group FRIENDS. Ths provides very simple, fast and flexible operations. Now, I'd like to show you how to define different request limits for different requesting systems. Line User Baud Time minutes files kbytes minutes files kbytes Group Group Group per day per request DEFINE 0 Mypoints ALLSPEED ALLTIMES -1 50 50000 60 50 50000 DEFINE 0 Friends ALLSPEED ALLTIMES 30 20 -1 15 20 -1 DEFINE 0 MyNet ALLSPEED ALLTIMES 25 20 -1 15 20 -1 DEFINE 0 UNLISTED ALLSPEED ALLTIMES 10 10 512 10 10 512 DEFINE 0 PROT ALLSPEED ALLTIMES 50 50 5120 25 50 5120 DEFINE 0 UNPROT ALLSPEED ALLTIMES 20 10 1024 10 70 1024 In the first last lines, I define a more or less "global" setting for all users. DO NOT MISS THESE SETTINGS, also no one will be able to request until defined later on ! All users, which are "unprotected" may request 10 files with 1 MB in size, using a maximum of 20 min per day. A "day" starts actually at 00:00h at your local time. For all nodes within my net (line 3), I grant 25 minutes, 20 files and an unlimited ammount of kbyte . In that way it's for ISDN nodes within our net possible to get about 20 MB/day :-) Perhaps you noted already : the "-1" is a special number, which doesn't represent a negativ abount of time, size or files, but an UNLIMITED. So, be carefull when you use it. To deny completely a special user, you may set his/her limit to "0". Ok, that's it. Now, we come to some mathematical stuff. Since different BBSes have different line qualities, you may specify for your own BBS a transfer rate based on your own experience. Be *sure* to define here all rates your modem can connect at, elso it will result in a failure if this non-defined CONNECT string appears ! CONNECT CPS string rate BAUD 1200 110 BAUD 2400 235 BAUD 4800 400 BAUD 7200 600 BAUD 9600 800 BAUD 12000 1100 BAUD 14400 1250 BAUD 16800 1450 BAUD 19200 1900 BAUD 38400 3500 BAUD 64000 7500 This means e.g. if you do have a CONNECT 64000/REL, 7500 bytes of data will be transfered each second [in generall]. If you forget to enter a baud rate, xOR assumes "Baud / 10" as a CPS rate for that request. A related command is OLIBAUD 64000 OLI (as abbrevication for Off Line Interface) has to receive "virtual baud rate", which could represent the highest baud rate your system supports or any other numeric variable. Based on that speed, the off line interface of xOR handles requests. After we've defined the more limits, let's come to the general limitations and event behaviour: TimeGroup DAYTIMES 0800 1800 All TimeGroup ALLTIMES 0000 2400 All TimeGroup NIGHTTIMES 1800 0800 All For FILES.BBS systems and EZY2xOR, these pathes and statements are required: FILELIST D:\TP\PRG\FIDO\xOR\FDOKFILE.LST FILELIST D:\TP\PRG\FIDO\xOR\ADD.LST FILELIST D:\TP\PRG\FIDO\xOR\ADD.UN This statement defines the list(s) to include if your files are based of FILES.BBS (it's xOR's default). Note that all statements are additive, so do NOT define a path twice ! Also, **DO NOT INCLUDE CD ROM PATHES HERE** since CDs are handed in another way ! For CD's, use these statements : CD j:\MSDOS\4DOS j:\MSDOS\4DOS\FILES.BBS CD j:\MSDOS\ABC J:\MSDOS\ABC\FILES.BBS The first parameter defines, as usually, the group which has access to this path. Then, you define the PATH, and later on the index file in which we can find the files listed. Normally, this is a FILES.BBS. If you use FILES.BBS index routines, these statements are REQUIRED for CD access! For RemoteAccess 2.xx index compiler, these statements are required RALIST <=20 RALIST >=20 A6+ RALIST <20 If you're familiar with RA, there should no problem.The flags refer to the "DOWNLOAD FLAGS" in the area configuration of RA, the number rtepresents the level of area to include. <X or <=X means all areas less (and equal) to level "X" will be included >X or >=X means all areas greater (and equal) to level "X" will be included =X means all areas with level "X" will be included <>X means all areas with level "X" won't included But note: this statement RALIST <=65535 RALIST <>20 won't exclude areas with level 20 'cause the first statement overrides the last one ! Also note: you don't have to handle CDs and local files in a different way since CD areas are automatically excluded during FILE indication and vice versa. Ok, the next statement is very intersting and enables the TIC file generator. Yes, it IS possible for users to request a TIC file altogether with the file, the name of the TIC area is specified by : TICAREA NEW_REQ You may define what ever you want, but do a favour to your users and don't change it dayly .-) This area will be taken under two circumstances : 1) the user has not defined an "own" area via the %PWD macro 2) You have set this command SAVETICDATAS OFF Why this ? Well.... whenever a user requests and uses a macro concerning the TIC area or the TIC password, these datas will be stored in the user database. To avoid this (I dunno why, but one sysop requested to do so..) you may disable storing the datas to make user's life harder .-) To treat your user in a bad way, you can also DISable some nice features, namely TIC and FILES.BBS by these statements: AllowTIC OFF AllowBBS OFF The meaning should be clear. In that way, you disable completely support for generating TIC files ans FILES.BBS lists for a requesting system. Hey, dude, you got it nearly. Now, we come to a very important and perhaps most dangerous part. It's the possiblity to execute external programs DURING run time (which means while the user is online). xOR gives all control to the external program, so YOU are responsible for the correct execution and return IN TIME ! COMMAND SYSOP TEST DIR /W \BAD\*.TIC >\TMP\TEST.TXT ^=\TMP\TEST.TXT !BOSS Starting with this sample, we have all possibilities in one run. The first parameter is, once again, the group. Than you tell xOR the "magic" or "alias" which have to be requested to execute this command. The next parameters are the command itself, including the redirection to "\TMP\TEST.TXT". The next parameter for xOR starts right after the "^" and must be one of this chars: = -> delete file if successfully transfered by mailer - -> delete file in ANY case after transfer + -> do no not and never delete this file ! Since Intermail unfortunately does NOT support such commands, the "do after.." parameter won't be passed to Intermail but only to Frontdoor and compatible systems. The last parameter ("!BOSS" in this sample) it to protect the execution and transfer of this external command. You may also transfer several meta commands passed by the mailer to xOR to the external program by these keywords : =A is the AKA of remote's system, e.g. "2:2433/900" =B is the current BAUD rate, e.g. "19200" =O is the operator's name of the remote system =P is the session passwort or none if not defined =S is the requested "magic" word =X is "SECURE" or "UNSECURE" Now, we come to the text files. Note that no file must have an extension since the extension is added by the AKA or MAINAKA statement described earlyer ! FOOTER D:\TP\PRG\FIDO\xOR\TXT\FOOTER This file will be added right after the list of successfully requested files. HEADER D:\TP\PRG\FIDO\xOR\TXT\HEADER This it the file which is shown before the list of files. Note that within ALL text files so called "macros" are available! For these features, pls refer to the MACRO.DOC and the the sample text files! NOMAILER D:\TP\PRG\FIDO\xOR\TXT\NOTERM This is an etremely powerful statement. Since some mailers are used by rare TWITs (e.g. TERMINATE) it's nearly possible for everyone to get your files, even if he/she is no point/node in your network. If you ENable this statement, selected mailer will never get ANY file of your system, but instead receive this text file. Pls take a look at the sample file :-)) NOREQNOW D:\TP\PRG\FIDO\xOR\TXT\SENDFAIL This text file will be sent in events where no request is allowed DENYTWITTEXT D:\TP\PRG\FIDO\xOR\TXT\NOTWIT This text file will be sent if a user or an AKA is defined as "TWIT" (see later on). TOOSLOWTEXT D:\TP\PRG\FIDO\xOR\TXT\TOOSLOW This text file will be sent if the requesting user is too slow for your system. To set the minimum required speed, read later on! BREAKTIMETEXT D:\TP\PRG\FIDO\xOR\TXT\BREAK Since WaaZoo, EMSI and any known protocol won't wait eternal for the responding system, you should set a "break time". If this time is overrun, xOR will send this text file. For the time, keep on reading ! FIRSTTIMETEXT D:\TP\PRG\FIDO\xOR\TXT\FIRSTTIME This is a textfile sent to all users on their first request. It should contain important information about your request limits, about your online ours or anything like that, and will be sent as a netmail. NoNewerFound No file later than the required time found NoMatching No matching file found PswdFailure Password failure TooMuchFiles Per day too much file numbers requested TooMuchSize Per day too much file size requested TimeOut Per day too less time left for this file RTooMuchFiles Per request too much file numbers requested RTooMuchSize Per request too much file size requested RTimeOut Per request too less time left for this file CDFileRemoved CD no more presend, dismounted or changed! FileRemoved File no more found, perhaps removed DupRequest Duplicate file requested. Check your brain! NotReleased This file is not released yet, try later ! These statements are samples for the texts which will appear after each file in case of the result during request. The meaning of the templates are: NoNewerFound on UPDATE REQUEST, no newer file is found NoMatching no file is found during request PswdFailure a file is found, but password protected TooMuchFiles the user tried to request more files by number than allowed TooMuchSize the user tried to request more files by size than allowed TimeOut the transfer time would be larger than allowed either by definition or by next event which does not allow file requests RTooMuchFiles the user tried to request more files by number than allowed in one session. RTooMuchSize the user tried to request more files by size than allowed in one session. RTimeOut the transfer time would be larger than allowed either by definition or by next event which does not allow file requests. This belongs to the current session. CDFileRemoved if a requested and found file is on CD,and either the CD or the file is no more found, ths is sent FileRemoved if the file is still in index, but not more physically found on your disk(s) NotReleased in conjunction with ALIASes, you may define release datas, and if you too early, this is the result. DupRequest the user requested more than one time the same file during one request Reflecting about the last point, you may choose the way xOR checks for duplicate request : ShowDupRequest ON Only if ShowDupRequest is set to ON, xOR will show to the user he/she requested one or more files twice or more. If not, the user will receive the file one time without further notification. There're 4 levels of dup checking now avail definable with the key DupCheckLevel <0..3> It's meaning is 0 No Dupcheck at all 1 strict check. The path and file name must be equal. This is only possible if you include the same path twice to your filebase 2 normal check. The filename including the extension must be equal to stamp a file as DUPlicate 3 relaxed check. Only the file NAMES must be equal. Since this could result in a problem during request of the latest 3 NODEDIFFs e.g., you have to define the extensions which may be there to determine a file as duplicate. This is done by the IGNOREEXTONDUP statement: IgnoreEXTonDUP ARJ IgnoreEXTonDUP ZIP IgnoreEXTonDUP ARC IgnoreEXTonDUP LHA IgnoreEXTonDUP LZH IgnoreEXTonDUP RAR So, if you request xOR*.*, xOR114.ZIP and xOR114.ARJ would be the "same file" for xOR and therefor determined as an duplicate request. But on the other hand, NODELIST.A69 and NODELIST.A76 would be treated as different files. WEEKDAYS Sunday Monday Tuesday Wednesday Thursday Friday Saturday Everyday For several reasons you may need to output the current dayte, including the day of week. So, define here the days, e.g. in your native language. Now, the stuff with the response text files is hopefully ready, so let's come to internal specifications.... UseEMS ON UseEMSBuffer ON UseXMS OFF UseXMSFirst OFF With these four statements, you may define the usage of EMS and XMS during run time. On my system, EMS management is faster than XMS, so I make only EMS memory avail for xOR. USEEMSBuffer belongs only to one single part: whether you want xOR to copy the whole FILE INDEX to EMS during runtime for a very fast access. If you haven't enough EMS, xOR will tell you so and proceed in the normal way. BreakTime 60 This statement defines the absolute maximal time in seconds xOR will spend for searching files in indices, copy files from CD to disk ect... I decided it's better to break at a special point than searching for eternity, since the user's mailer will drop carrier in EMSI/WaaZoo sessions since 60 seconds without any response from your site. Twit 241:*/*.* With this statement, you may define a single user or even a whole zone as "twit", which meanse you absolutely deny any kind of request. TwitName Ron Dwight Instead of AKAs, you may also exclude users by name. With the following keyword, you may also exclude special strings presented by remote system in the SITEINFO field. This may be TERMINATE e.g. TWITMAILER TERMINATE With the following keyword, you may also exclude requester by their (ISDN) phone number delivered by the PTT e.g. TWITNUMBER 0211987654321 Here, you define the minimum speed file file requests: MinReqSpeed 19200 Since commercial environment immigrates into file requesting, you may place some addvertisement in the response mails :-) Pleas, be so kind and KEEP IT SMALL. I guess if you attach a 3 MB *.FLI annimation to show your users who smart you look like, they'll swear to kick your ass to hell sometimes.... You have 2 ways to make such adds: AddFilePKT G:\FILES\XMAIL\*.* F:\SHRD\FILES\XMAIL.REG Each time a users requests any file matching "G:\FILES\XMAIL\*.*", I'd like to send the latest register form to the user as netmail. So, the text file taken from "F:\SHRD\FILES\XMAIL.REG" will be converted to an PKT and appended to the files sent afterwards. AddFile G:\FILES\GIF\*.* F:\FILES\VPIC.ZIP If you cannot send a netmail, e.g. because the file you want to send if of binary code, you may also attach it as a file. The syntax is same as on ADDFILEPKT. Also intersting for your users could be a short descrioption of the current request event. You may add files or pkts using these statemtnts: AddTime F:\ANYTEXT AddTimePKT F:\ANYTEXT Note that these files are once again without extension since the extension is defined by remote system's AKA! FreeFile F:\FILES\LISTEN\24330920.ZIP FreeFile I:\FILES\XRATE\*.GIF FreeFile xOR114.ZIP Now, let's say you will give all users the possibility to get "special" files of your BBS, perhaps the dayly updated filelist or any sililar files. You may define these files as "free" which means the ammount of size and numbers during file request won't be increased by these datas! A "freefile" statement may refer to either a file with path (and wirldcards) or to a single file WITHOUT any wildcards (as shown above). The final "tuning" belongs to the password manager in xOR. A password definition block starts with "REQUESTPASSWORD" and has several commands in the folowing lines. Take an example : RequestPassword PATH G:\FILES\XRATE PSWD EROTIC INCLUDE ALL Here I define for all files in path "G:\FILES\XRATE" AND IT'S SUBDIRECTORIES !!!!!!! the password "erotic" [case doesn't matter]. It's very important to realize it's a "string matching" comparison I do here, so with "G:\" you will protect the whole volume with a single password (for special CD's very good !!) This password is required for all requesting systems. This was the easy way, not let's have fun with the expert settings. Take another sample : RequestPassword PATH I:\ PATH F:\FILES ShowBad OFF PSWD HIDDEN INCLUDE ALL EXCLUDE Friends EXCLUDE McMBeta I protect with this statement all files on disk "I:" and all files in path "F:\FILES" and its subdirectories. The password is set to "hidden". Since there might be files I never want show to "unauthorized persons", I set "ShowBad" to "NO" which means IF the user requests a asswort protected file which is found on "I:\" or "F:\FILES", the user will get the normal message for "file not found", else the user will receive the full file name and "password failure". Imagine what will happens if you have e.g. some pirate software in your BBS and want share it with good friends only. Now, a "normal" user requests "QEMM*.*", perhaps to get the QEMM manuals. What will happen? In case of "ShowBad ON", which is default (!), the user might get a response like QEMM704.ZIP Password failure which could result in a visit at the local prison cell :-) Note the EXCLUDE statement. Let's say I do have a session password with 2:2433/1200. Than via this password the user is already "verified". And now we assume the user might get all files from these pathes, so why I should annoy him/her with nasty passwords ? I do know this user (via EMSI handshake) and he/she's verified via password protected session (hopefully, else a session handshake failure must have occured before!) and the user will get files from this path without any password. To go away from illegal stuff, take another sample which might be more representative to explain the EXCLUDE statement : RequestPassword PATH F:\FIDO\NET_DIFF\*.Z?? PSWD SECRET2433 INCLUDE *:/*.* EXCLUDE 2:2433/*.* Now, all users presenting the AKA of my network my request the lastest version of network update file matching "F:\FIDO\NET_DIFF\*.Z??". You got it ? Ok, then let's come to the very last statements, which might represent a bonbon for registered users. Sometimes, it may be important to be informed whenever special files are requested, either just to check xOR's password entrys or to be reminded when a user requests "*.GIF" or any other non public programms or datas. So, let's include this statement: ExecOnAccess EXECFORPATH I:\FILES\GIF EXECFORPATH C:\FILES\PRIVATE EXEC SEND.EXE "=A requests special files!" TO SUPERVISOR OnlyIFPSWDOK YES This have to be explained. EXECFORPATH is the keyword, followed by a file, path or parts of both (as usually). EXEC defines the program called by xOR whenever a file is requested from one of the matching pathes. "OnlyIfPswdOK" means, the function is only executed, if user┤s limts as well as the password is ok, so in short words, if the file will be transfered in fact. You may of course use all macros explained on "COMMAND" before. Additionally, there are three functions implemented internal in xOR: EXEC #SEND <USERNAME> EXEC #SEND SERVER EXEC #NETMAIL <AKA> <UserName> The first command will send a broadcast message to <USER> within a NOVELL Netware environment on the default file server. The second command displays the corresponding message on the default server's operator console. Both commands will only be executed IF the general statement USENETWAREFEATURES YES is configured. Even if xOR will check presence of IPX/ODI/VLM shell on startup, do not use this function unless you're running NOVELL or any 100% compatible environment.(xOR uses for broadcasts Intr 21h, function e1, subfunction 00h and 09h.) The last command requires one additional line: MAILTEXT <TextFile WITH extension> This textfile is converted to pkt and placed in your inbound. A new feature since 1.07 is support of the *not documented* feature of some mailers. I just call it "Time Request". In fact it is a ASCII #0 during xOR searches for files in large databases which causes remote mailers not to drop carrier even if no datas are received for several seconds. Currently, McMail and even FrontDoor supports this feature, InterMail does NOT. To activate this, either SRIF must be used or the command line parameter /CP<COMPORT> with COMPORT in range from 1 to 8 must be used in conjuntion with these parameters: TimeRequest ON|OFF Use this to enable / disable this feature and the following to set the time between two "time requests": TimeRequestDelay 5 The parameter is time in seconds. 5 is OK for Hydra as well as old Z-Modem by Frontdoor. Starting with version 1.08, you may limit xOR's search pattern with this command: MATCHSTOP 1 This funcion is only activ if a file w/o wildcard is requested. If so, the search run stops after the first matching file. If a remote user requests e.g. "xOR111.EXE", after the first valid entry in your databse, xOR stops searching for that file and continues action either with next file or with generating the response mails ect. But if a user requests "xOR111.*", this function is *not* active and xOR will search the whole database. Finally, I implemented a command which should never be used .-) Whenever a critical error in xOR occures, xOR starts beeping and sounds like hell to draw your attention. To avoid such run time error sounds, use that parameter ERRORSOUND OFF 3.1 Calling from McMail Up to version 1.00 Gamma 1: McMail has as sample in its latest CFG already included the sample line for usage of xOR. You should have this line (with an adapted path) in your master configuration file : ReqProcessor f:\mailer\xOR.exe /A=PA /B=BR /P=PW /O=RS /H=MR /X=SU /R=FL /T=XL That's enough. If you're running v1.00 gamma 1 of McMail, it may be McMail says something like "no request control file present". To fix this behaviour, use that line in MCMAIL<TASK>.CFG: RequestCfg f:\mailer\request.cfg And be sure this file exist. It should contain only one semicolon (";"). McMail Version 1.00 Gamma 2 and above: The calling syntax is the same except this, remove all internal request processor statements and call xOR by ReqProcessor f:\mailer\xOR.exe /M=SRIF That's enough for a good mailer :-) 3.2 Calling from FRONTDOOR For proper installation, you may run the FD Install tool distributed with that package, or enter it manually. If you run the tool, be sure xOR is in your path or update the datas manually. If you're running a multiline system, it's more easy to run the tool since it discovers multiline systems and ASKs you whether it may update all lines seperatly or not. For proper usage with FrontDoor 2.20.c.ml and 2.12 S/W reg., use these settings in FDSETUP.EXE, Mailer/File requests/Request processor: ╔════════════════════════════════════════════ Request processor ╗ ║ ║ ║ Program D:\FD\xOR\xOR.EXE /R=R /F=F /T=T /X=X /H=H ║ ║ Enabled Yes ║ ║ Swapping Yes ║ ║ ║ ╚═══════════════════════════════════════════════════════════════╝ It's very important to activate FD's swap features since xOR needs as much memory as possible. To avoid interference with FD, turn off all request limits like I did : ╔═══════════════════════════ Request limits ╗ ║ ║ ║ Allowed systems Any ║ ║ Stop after first match No ║ ║ Maximum match (files) 0 ║ ║ Maximum time (minutes) 0 ║ ║ Maximum size (kb) 0 ║ ║ Minimum speed (bps) 0 ║ ║ Limited hours No ║ ║ Start time 00:00 ║ ║ End time 00:00 ║ ║ Days -------A ║ ║ ║ ╚═══════════════════════════════════════════╝ 3.3. Calling from INTERMAIL For proper setup of Intermail's door, use this screenshot as an example: Exit Global Mailer Editor Terminal Modem Printer Manager ═══════════════════┌──────────────────┐══════════════════════════════════ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ Miscellaneous │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ╔════════════════════════════════════════════════════════ File requests ╗ ║ ║ ║ Mode Anyone can request ║ ║ List D:\IM\LIST.LST ║ ║ Alias D:\IM\MAGIC.LST ║ ║ Message D:\IM\BADREQ.MSG ║ ║ Max match 0 ║ ║ Max time 0 ║ ║ Max size 0 ║ ║ Min speed 2400 ║ ║ Limited No ║ ║ Start 00:00 ║ ║ End 00:00 ║ ║ Days -------A ║ ║ External D:\IM\xOR\xOR.EXE /A%A /B%B /X%X /R%F /O%O /P%P /IM ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════╝ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ────────────────────────────────────────────────────┤ Mail server: 001 ├─ Ext. request processor (parameters: %A-node#, %P-password, %F-list Datei) The settings in "LIST", "ALIAS" and "MESSAGE" are not of importance, but it seems some versions of Intermail do realy need there a VALID name. 4.0 Additional programms / maintenance Actualy, the number of utilities for xOR is still growing. Here are the utilities explained which are distributed altogether with the xOR package. 4.1 FBBS2IDX FBBS2IDX is the main program to generate the index files based on FILES.BBS in each directory defined via in corresponding statements in xOR.CFG. There are three parameters /C create index for FILE base /R create index for Readonly Media such as CD ROMs /A create ALIAS index /S update download counter in FILES.BBS Usually, the CD ROM index will be created only one time, and that's good since creating index for more than 70.000 files is not as fast as other things. The normal FILE index should be created whenever you receive new files, at least once a day. As optional second parameter, you may use /Cfilename for an alternate configuration file. 4.2. RA2_IDX RA2_IDX transfers the files from RA database to xOR's database. The switches /C, /R, /A and /S are possible like in FBBS2IDX. To speed up RA2_IDX, you may add a numeric parameter representing your maximal description length, e.g. RA2_IDX /C 512 which results in that you longest description is 512 chars. That speeds up the compiler a little bit. 4.3 xORUTIL xORutil is the maintenance utility for the RESUME indices and for the user base. It also contains the statistical functions. Command line parameters for XxORUtil are /M runs maintenance. Additional parametes are /D=<Days> This function purges the user base and erase old RESUME file record /US runs user statistic. By default, xOR posts statistic to netmail. REQUIRED parameters are: /I=<AKA> the AKA(s) included in statistic,e.g. /I=*:*/*.* for all users Optional parameters are: /F=<FileName> posts results in that file /A=<AREA> posts statistic to EchoArea instead of Netmail /D=<Days> care only about x days /FS runs file statistic. By default, xOR posts statistic to netmail. Optional parameters are: /F=<FileName> posts results in that file /A=<AREA> posts statistic to EchoArea instead of Netmail /D=<Days> care only about x days 4.4. Special macros During file request, xOR scanns different "macros". Actually, there are 6 macros defined yet : %TIC %TICOFF %BBS %BBSOFF %PWD=<Password> or %PSWD=<Password> %AREA=<Tic_Area> %AKA=<AKA> or %ADDR=<AKA> or %ADR=<AKA> TIC and TICOFF handles whether the user gets TIC files along with the requested files or not, BBS and BBSOFF are responsible for creation of a FILES.<LineNr>. That improoves speed of processing files at the requesting site since by many programs, TIC files may be evaluated and distributed to other systms. PWD and PSWD are equal keywords and define the area the TIC password, AREA defines the area the file is sent in. This may vary from the area defined by the sysop. Normaly, these datas are stored in the user base until denied by the sysop by SAVETICDATAS OFF (see above). ADR,ADDR and AKA set the sender's AKA in TIC files. Within all textfiles which are posted, these macros are valid, but may, depending on the situation, stupid to use and therefor not initialized by a real value. %FOUND.SIZE \ %FOUND.FILES -- refers to THIS request (how much found..) %FOUND.TIME / %TODAY.SIZE \ %TODAY.FILES -- refers to the current day (how much found ..) %TODAY.TIME / %TOTAL.SIZE \ %TOTAL.FILES -- refers to the life time (if user base ok) %TOTAL.TIME / %REMAINING.SIZE \ %REMAINING.FILES -- refers to the current day %REMAINING.TIME / %REQUEST.SIZE \ %REQUEST.FILES -- refers to the current request %REQUEST.TIME / %REQUEST.DAYS -- on these days, this event is active %REQUEST.STARTTIME \ The start and end time of %REQUEST.ENDTIME / current Request Event %FIRSTREQ -- first listed day of request %USER.AKA \ Requester's AKA and NAME as transfered in %USER.NAME / EMSI handshake %SESSION.TYPE - can be PROTECTED or UNPROTECTED %SESSION.NEXTEVENT - minutes til next event w/o file request allowed %SESSION.BAUD - current baud rate (e.g. 19200) %SESSION.CPS - current CPS (e.g. 1800) %SESSION.PASSWORD - current session password (if any) %TICAREA - name of ticarea or none %TICPSWD - TIC password or none 4.5 All Command line switches Valid parameters for xOR are /M<FILE> Standarized Request Information file or /C<FILE> use alternate config file /A<AKA> primary AKA of remote system /B<BAUD> current connect rate /T<FILE> filename of xOR return file /R<FILE> filename of request list file /H<MIN> minutes till next event which denies requests in min. /X<SECURE|UNSECURE> the corresponding string /W<LISTED/UNLISTED> the corresponding string IM /IM activate INTERMAIL mode FD /F<FD-SREQ-File> This file can be found via the "=F" macro /P Session password /L<Loc> Remote's location /N<Name> Remote's site info /O<Name> Remote operator's name /CP<Port> Communication (=modem) port [1..8] /T<FILE> filename of xOR return file /R<FILE> filename of request list file In <Loc> and <Name>, replace spaces by "_" !'); 5.1 Trademarks MS-DOS is a registered trademark of Microsoft Corporation Win95 is a registered trademark of Microsoft Corporation DR-DOS is a registered trademark of Digital Research, Inc. Novell DOS and NetWare are registered trademarks of NOVELL,Inc. DESQview and QEMM are registered trademarks of Quarterdeck Office Systems, Inc. Ezycom is a registered trademark of Peter Davies McMail is a trademark of Albert Freriks and Gordian Schuermann FrontDoor is a registered trademark of Joaquim Homrighausen Intermail is a registered trademark of Scandinavian PC Systems AB and InterZone Software, Inc. RemoteAccess is a registered trademark of WanTree Development 4DOS is a registered trademark of Rex Conn & JP Software Inc. PKZIP is a registered trademark of PKWare Inc. Terminate is a registered trademark of Strathrory Systems Limited The xOR logo is performed by B. Huertgen All brands and product names are trademarks or registered trademarks of their respective holders. 5.2 Thanks I'd like to thank Borland, Inc. and Borland Deutschland GmbH, for Borland Pascal. My thanks goes also to the beta team. The guys who were in the most time of xOR, even before version 0.99 gamma1 has been released, are Abels, Wim Dueker, Sven Freriks, Albert Huertgen, Boris Schuermann, Gordian Special thanks to Gordian and Albert for very good cooperation concerning the Standarized Request Information File and publishing them as FSC-0086 document. Also, other persons helped me developing the latest release, some of these soldiers for bug-free software are : Frank Weber Frank Cremers Uwe Boettjer Marc M. Braun Thomas Bahr Thank you very much. 5.3. Contact the author My AKA is 2:2433/920 till /928 in FIDONet, but you may reache me also via other networks, currently via : 9:49/0 VirNet 16:16/0 ZyXELNet 21:497/900 GerNet 73:7491/0 RANet 95:2408/0 RAFileNet 100:494/300 BorlandNet 144:490/0 GamesNet InterNet mirko.mucko@technet.net Or via my BBS at these phone numbers +49-211-9083300 ZyXEL 19.2 +49-211-9083491 ISDN X75 +49-211-9083301 USR V.Every +49-211-9083492 ISDN X75 +49-211-9081685 ZyXEL V.34 +49-211-9081686 ISDN X75 +49-211-9081687 ZyXEL V.34 +49-211-9083026 ISDN X75 +49-211-9083026 ZyXEL 19.2 Also, in Germany the FidoNet Mailarea "xOR.GER" is avail from many sites. 5.4. Registration sites Germany / REGISTER.GER Mirko K. Mucko Netmail Thomas-Mann-Str. 43 40470 Duesseldorf FIDO 2:2433/920.0 DANMARK / REGISTER.DK Kåre O. Markussen Netmail Nordborggade 21, 6mf 8000 Århus C FIDO 2:238/92 DANMARK CMN 10:450/105 All other countries / REGISTER.TXT Mirko K. Mucko Netmail Thomas-Mann-Str. 43 D-40470 Duesseldorf FIDO 2:2433/920.0 Germany