Black Box 4

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

/ Black Box 4 / BlackBox.cdr / bbs_opus / yms_200.arj / YMS.CTL < prev next >

Wrap

Text File | 1991-07-29 | 33.4 KB | 925 lines

; The ; ; YY YY MM MM SSSSS ; YY YY MMM MMM SS ; YY YY MMMM MMMM SS ; YYYYYY MM MMMM MM SSSSS ; YY MM MM MM SS ; YY MM MM SS ; YY MM MM SSSSS ; ; v2.00 ; Control File ; ; ; ; (C) 1990,1991 by Angelo Besani, All Rights Reserved ; ; <[ AmnesiA ]> CBCS (2:331/101@FidoNet) ; +39-331-772362 [HST/V.32] ; ; Bbs <bbs_type> ; -------------- ; The BBS software you are operating. Currently YMS supports ; OPUS 1.1x, OPUS 1.7x and MAXIMUS 1.02. ; Use Bbs Opus11x for OPUS 1.10 to OPUS 1.14, Bbs Opus17x for ; OPUS 1.70 and Bbs Max102 for Maximus 1.02. ; ; Bbs Opus11x ; OPUS 1.10, 1.11, 1.12, 1.13, 1.14 Bbs Opus17x ; OPUS 1.70 ; Bbs Max102 ; MAXIMUS 1.02 ; ; ; Address <[zone:]net/node[@domain]> ; ---------------------------------- ; Your Network address. Do not specify any point, Zone is not ; mandatory and if not specified defaults to 1 (maybe the ; Yankees would not like an European software defaulting to 2 ; <grin>). If you want to operate in a DOMAIN-aware environment, ; you can specify a domain too. If you specify a domain, YMS ; works using 5D, so you will be able to use domain in ; MatrixForwards too. ; Address 2:331/101@fidonet.org ; ; ; PointNet <Net> ; -------------- ; Your Point Network, if you have any. It is necessary for the ; particular way YMS processes netmail messages and only if you ; include your matrix area for forwarding. ; PointNet 21101 ; ; ; DomainGate <domain> <address_of_domaingate> ; ------------------------------------------- ; Since lots of people are still using domain-unaware mail ; processors, it is necessary that YMS takes care of ; domaingating. This means that YMS has to route a message ; destinated to another domain to a particular node of the ; current domain acting as a domain gate. With this statement ; you can define up to 16 domaingates. ; Here in Europe we have: ; DomainGate GreenNet 2:2/501 DomainGate EuroNet 2:2/502 DomainGate RBBSNet 2:2/508 DomainGate SIGNet 2:2/527 DomainGate ChatNet 2:2/544 DomainGate LIF-Net 2:2/701 DomainGate EarthNet 2:2/702 ; ; ; Log <PathName> ; -------------- ; YMS produces an Opus/Maximus-style logfile. The pathname ; stated here will generate the log of the COMPILE option, which ; must be run generally once a day, and, if you have a ; multitasker, in ONE TASK ONLY. ; For multiline environments, later you will have a chance to ; setup different logs for different tasks. ; Leaving it blank or commented will force YMS not to generate a ; COMPILE Logfile. ; Log D:\Opus\Opus.Log ; ; ; LogLevel <number> ; ----------------- ; Selects between one of the 5 different Opus-like log levels. ; YMS uses the following symbols for convention and ; compatibility with Opus-CBCS: ; ! = Error Messages ; * = NetMail Forwarding Messages ; # = Trace Activity and Warning Messages ; + = Normal Operations ; : = Unimportant Messages ; The different LogLevels include the following symbols: ; LogLevel 1 = ! ; Loglevel 2 = ! * ; Loglevel 3 = ! * # ; Loglevel 4 = ! * # + ; Loglevel 5 = ! * # + : ; If commented, LogLevel will default to 5. ; LogLevel 3 ; ; ; NoVideoWrap ; ----------- ; If not commented, YMS will truncate all log lines sent to the ; screen to 75 characters, ending them with '...'. Disk log ; lines will be left unchanged. ; NoVideoWrap ; ; ; AreaInclude <number[,...]> ; -------------------------- ; This statement specifies which areas YMS must process. ; You can specify every single area using "," as a separator, or ; define areas in a range using "-" as a separator. ; You can specify multiple AreaInclude lines, if you like. ; Valid area numbers are: ; For OPUS 1.1x: 0 to 254 ; For OPUS 1.7x: 0 to 2047 ; For MAXIMUS 1.02: 0 to 1295 ; Note for MAXIMUS users: since Maximus doesn't use area numbers ; but a 2-character 'name' (even these characters are normally ; digits), YMS assumes as area number the record each area is ; listed in the AREA.DAT file. So the first area in AREA.DAT is ; assumed to be area 0, the following one area 1 and so on. ; Limit is 65500 lines (!!). ; Examples: ; If you want to include areas 2, 5, 12, 13, 14, 15, 27 and 60 ; you can use ; AreaInclude 2,5,12,13,14,15,27,60 ; but also ; AreaInclude 2,5,12-15,27,30 ; On our system we have a plain... ; AreaInclude 1-70 ; ; ; UseExternMailCheck ; ------------------ ; OPUS 1.70 only. Don't include an area for message waiting if ; it hasn't the 'EXTERN MAILCHECK' flag in your OPUS control ; file. You can therefore decide which areas include for mail ; checking in OPUS control file (and not in YMS) by uncommenting ; UseExternMailCheck and selecting an 'AreaInclude 0-2047'. ; ; UseExternMailCheck ; ; ; LowLevel. ; --------- ; Enables lowlevel reading routines during COMPILE and UPDATE ; functions. ; This function is definitely VERY fast and absolutely NOT ; dangerous, as it does not perform any kind of write. ; It has been fully tested under DOS 3.20, 3.30, 3.31 and 4.01, ; SpeedStore and DiskManager with partitions of ANY size. ; In case that lowlevel would fail, YMS error detection logic ; would immediately switch to HIGH level and continue the ; COMPILE or UPDATE process, without hanging but simply issueing ; a warning message in the logfile. ; Implementing this routines took quite a big effort and is one ; of the main reasons that inspired the creation of YMS. Not to ; say that I definitely encourage you to use it, unless you are ; running a Local Area Network or have your message areas on ; JOINed drives. ; LowLevel ; ; ; SentAsReceived. ; --------------- ; Tells YMS to consider Sent messages as if they were already ; Received. ; If you believe in FidoNet Mail, do not uncomment it ;-) ; SentAsReceived ; ; ; IncludeReceived. ; ---------------- ; Got GigaBytes of RAM? Got WORM disks? Got just a few messages? ; Let's keep in the base Received messages too, so that we can ; show them to the users, if we like... ; ; IncludeReceived ; ; ; BbsDirectory <Pathname> ; ----------------------- ; For OPUS 1.1x, the path where the SYSTEM??.DAT and USER.IDX ; files are stored. ; For OPUS 1.7x, the path where the SYSMSG.DAT, NUMBER.MDX and ; USER.DAT files are stored. ; For Maximus 1.02 the path where you have the AREA.DAT and ; USER.BBS files. ; If these files are in different paths or (Maximus only) have ; different names than AREA.DAT or USER.BBS, use SystemDirectory ; and UserlistDirectory. See below. ; This entry is MANDATORY and you must specify it even if it is ; your current DOS directory, unless you use both ; SystemDirectory and UserlistDirectory. ; BbsDirectory D:\Opus\ ; ; ; SystemDirectory <Path/Filename> ; ------------------------------- ; If you can't use BbsDirectory (see above why), you must use ; SystemDirectory. ; For OPUS 1.1x: the path where you have the SYSTEM??.DAT files. ; For OPUS 1.7x: the path where you have both the SYSMGS.DAT and ; the NUMBER.MDX files. ; For Maximus 1.02: the actual FILENAME (not the pathname ; only!!) for you area list. ; ; SystemDirectory C:\MAX\MAXAREAS.DAT ; ; ; UserlistDirectory <Path/Filename> ; --------------------------------- ; Along with SystemDirectory, you must use Userlist directory. ; For OPUS 1.1x: the path where you have the USER.IDX file. ; For OPUS 1.7x: the path where you have the USER.DAT file. ; For Maximus 1.02: the actual FILENAME (not the pathname ; only!!) for you userlist. ; ; UserlistDirectory C:\MAXUSER\USER.BBS ; ; ; IncludeAlias ; ------------ ; Opus 1.70 only. Include aliases in the YMS userlist so you can ; show not only the mail waiting to the user's name, but to ; his/her alias too. See also TaskSearchShowAlias and ; TaskOnlineShowAlias below. ; ; IncludeAlias ; ; ; RamDisk <pathname> ; ------------------ ; The path used by YMS to store its temporary files. ; If you have a RamDisk, of course let it point there. If you do ; not have one, a normal DOS path will work. ; RamDisk L:\ ; ; ; YmsDirectory <Pathname> ; ----------------------- ; YmsDirectory, or: Where to store YMS' files? In Opus/Maximus' ; root?? ; Maybe, and it would be easier for SysOps that are keen on ; forgetting command line switches (see -D below...), but I'm ; not an easy man and I've placed them somewehere else... ; If left commented, it will default to the current directory. ; YmsDirectory D:\Opus\Yms ; ; ; NoAnonAreas ; ----------- ; If not commented, YMS will ignore broadcast messages in ; Anonimous areas, preventing users not allowed to enter ; broadcast messages from using an ALIAS to write such messages. ; NoAnonAreas ; ; ; EnableToAll <name> ; ------------------ ; This is the list of the persons that are allowed to create ; messages marked as BroadCast. Typically they will be the SysOp ; and the Co-SysOps. ; If this option is commented out it will default to "any user". ; It means that every single user will generate BroadCast ; messages if they are addressed to the name specified in ; AllUser (see below). ; Is it useful?? Mmmmmm....maybe in some cases. I personally ; prefer an automatic bulletin <grin>. ; The list may be up to 16 names, with one name per line. ; EnableToAll Angelo Besani ; ; ; AllUser <name> ; -------------- ; The name contained in the To: field of messages that have to ; be considered as BroadCast messages. Do not choose a very ; common name.... ; We use "**|ALL|**" instead of "All" so that we can create ; BroadCast messages just in case. ; On the contrary, if you have commented EnableToAll out, you ; will prefer to specify ; ; AllUser All ; ; so that every single message sent To: All will be shown as ; "BroadCast Message" to every user that searches his/her mail ; using YMS. ; Leaving AllUser commented out means that there will be NO ; BroadCast messages. ; If you like, you can have up to 16 AllUser lines. ; AllUser **|ALL|** ; ; ; Notify "Name1" to "Name2" ; ------------------------- ; Note that the quotes and the 'to' keyword are MANDATORY. ; Show to "Name2" the mail waiting for "Name1". "Name2" MUST be ; in the YMS userlist, while "Name1" can be or can be not. If ; "Name1" is in the userlist, then his/her mail can be shown ; searching either for "Name1" mail or "Name2" mail. In this ; second case, the messages to "Name1" are shown together with ; ones to "Name2", but have an attribute of ALIASED, which can ; be shown. See the description about YMS_MAIL files. ; You can have up to 32 Notify lines. ; Notify "Sysop" to "Angelo Besani" ; ; ; MatrixFwdAreaInclude ; -------------------- ; The list of areas to be processed with the MatrixForward ; logic. ; They can be LOCAL or ECHO areas, and the NETMAIL area can be ; included too, if you want YMS to forward netmail messages to ; different addresses. ; The separators work in the same way as for AreaInclude. ; Note that (differently from YMS 1.00), these areas are valid ; ONLY for the MatrixForward lines (see below) which FOLLOW this ; MatrixFwdAreaInclude, and a new MatrixFwdAreaInclude cancels ; the previous one. To cancel ALL areas, use ; MatrixFwdAreaInclude without listed areas, or ; MatrixFwdAreaInclude None. ; MatrixFwdAreaInclude 1-74 ; ; ; ForcedFwdAreaInclude ; -------------------- ; Virtually (and sintactically) the same as ; MatrixFwdAreaInclude, but these areas cannot be excluded by ; the IEP (see below). This can be useful if one of your ; point/nodes wants to receive forward of messages in areas he ; is linked to. See the documentation for more details. ; ; ForcedFwdAreaInclude ; ; ; MatrixForward <[zone:]net/node[.point][@domain] name> ; ----------------------------------------------------- ; You can have YMS forwarding to nodes or points local messages ; addressed to them, or you can have it remapping wrongly ; addressed netmail messages. ; I once had many points, and they enjoyed very much reading ; ECHOmail on their PC's, but they were annoyed not to receive ; local mail addressed to them. Specifying their name and point ; here will do so. ; But the problems did not finish: these points grew up and ; became SysOps. But many people knew their addresses as points ; of my node, and a lot of netmail lied unread in my Matrix ; area. YMS will also forward netmail arrived on your system to ; the persons listed here, at the address that you specify. ; This function is both Point and Zone aware and if YMS is ; working in 5D (see description of 'Address' above) you can ; specify a domain too. ; You can have up to 256 MatrixForward lines, with one address ; and one name per line. ; MatrixForward 2:331/101.3 Luigi Callegari MatrixForward 2:331/101.6 Paolo Zibetti ; MatrixFwdAreaInclude 1-4 ;The following MatrixForward are ; active on areas 1-4 only. ; MatrixForward 2:331/103 Massimo Vallo' MatrixForward 2:331/104 Beppe Malinverni MatrixForward 2:331/105 Bruno Grampa MatrixForward 2:331/106 Luca Spada MatrixForward 2:331/108 Luca Croci MatrixForward 2:331/109 Alberto Bassani ; ; ; MatrixFwdPublic ; MatrixFwdPrivate ; ---------------- ; You can choose to forward only private messages, only public ; messages or both. ; On <[ AmnesiA ]> I find very useful to have YMS forwarding ; private messages only because of this reason: I have a few ; local areas setup as pseudo-echos for my points only. These ; areas are public+private, and I didn't want to have my points ; reading private messages directed to other people, so I setup ; QM not to echo private messages. ; Result: private messages for my point users lied in my local ; areas, unread. This option of YMS solves the problem (and my ; points enjoy it!). ; The Netmail area is not affected by this logic: if the Matrix ; area is included in MatrixFwdAreaInclude the forwarding will ; work on ANY message, regardless of its public/private ; privilege. ; Netmail messages generated by this function of YMS will ; contain: ; FMPT/TOPT line (if necessary) ; INTL line (if necessary) ; MSGID line ; FLAGS/PID informations are stripped ; "Forwarded...." line ; Message Text ; In ECHOmail messages "* Origin" is changed to "MsgOrigin" to ; avoid letting any mail processor run into confusion; SEEN-BY ; and ^APATH are stripped. ; ; MatrixFwdPublic MatrixFwdPrivate ; ; ; IEPAreasBbs <filename> ; IEPEchoCtl <filename> ; IEPSysMsgDat (OPUS 1.70 only) ; ----------------------------- ; Intelligent ECHOmail Processing. ; YMS can now forward messages to point/nodes from any of your ; message areas. While this can be useful, it is quite annoying ; to have messages forwarded from an echomail area which is ; already received via a regular echomail feed. To avoid this ; you should keep your MatrixFwdAreaInclude(s) accurate and ; change them everytime one of your nodes/points changes the ; areas he/she is linked to. But YMS can do this work itself by ; reading your echomail informations. YMS can read ECHO.CTL ; format files (using IEPEchoCtl <filename>) or AREAS.BBS format ; files (using IEPAreasBbs <filename>) or internal OPUS 1.70 ; informations (using IEPSysMsgDat). You can obviously use more ; than one format at the same time. On <[ Amnesia ]> I have my ; echomail informations divided in two files, so I have to ; specify both: ; IEPAreasBbs D:\Opus\Confarea.bbs IEPAreasBbs D:\Opus\Locareas.bbs ; IEPEchoCtl <filename> ; IEPSysMsgDat ; ; ; IEPNotFwdedMsgs <Option> ; ------------------------ ; Where <Option> can be either Show, Hide or Mark. ; This verb indicates how to handle messages which hasn't been ; forwarded because the IEP has excluded the area. You can have: ; Show: (default option). Show them when the user logs in. This ; could not be the best thing since these message should ; have already been read by the user on his/her ; node/point. ; Hide: Simply not show these message to the user. I don't ; recommend this option since it has a high overhead ; during the YMS COMPILE phase although it works as ; expected. ; Mark: Mark these message as "received", as they have been ; really read by the user. ; ; IEPNotFwdedMsgs Show ; IEPNotFwdedMsgs Hide IEPNotFwdedMsgs Mark ; ; ; UseUTCTime ; ---------- ; Tells YMS to use UTC time when marking forwarded messages with ; its own kludge (and specify it adding UTC as a suffix). ; You must have the TZ environment set correctly to have this ; function work properly. ; UseUTCTime ; ; ; RecordsPerUser <number> ; ----------------------- ; This defines the maximum number of messages that YMS can ; remember for each user. The maximum is 8000. Consider that ; increasing this number will have YMS eating up more memory and ; more disk space, so choose a number that fits your current ; users' needs. ; On my system I have it set to 128, and has no problems, except ; for some occasional users that read their messages on other ; systems and have this limit exceeded. ; Exceeding this limit will generate a message in the logfile ; and the messages for that user, beginning from [n+1] will not ; be recorded in the base. No other problem occurs. ; RecordsPerUser 128 ; ; ; ExcludeMr <name> ; ExcludeMrs <name> ; ExcludeMiss <name> ; ------------------ ; Mmmmmm....you seem not to like seeing all those RecordsPerUser ; limits exceed?? Would you like to exclude some of your users ; from the mail-search base? You can specify multiple lines of ; this statement, followed by the user's name, placed as it is ; in the USER.DAT file. ; Which is the difference between Mr, Mrs and Miss? Technically ; none, of course, but, ya know, Italians *LOVE* to be courteous ; with women...:-) ; ; ExcludeMr Angelo Besani ; ExcludeMr Giampaolo Muraro ; ExcludeMrs Feliciana Antolini ; ExcludeMiss Mara Bruni ; ExcludeMr Lincoln Dale ;......mph...who chose these names?? <grin> ; ; ; IncludeMr <name> ; IncludeMrs <name> ; IncludeMiss <name> ; ------------------ ; Since YMS has now the possibility to search for a specified ; user's mail (YMS_MS "username", see documentation for details) ; it can be useful to search for names who aren't in your BBS ; userlist. It is then necessary to add them to your BBS ; userlist. When this cannot be done, since it's useless or for ; security reasons, you can include these names in the mail- ; search base only. ; ; IncludeMr Jaap Kramer ; ; ; NetMail <pathname> ; ------------------ ; I bet some of you have decided not to search for mail in the ; NetMail area but, of course, would like MatrixForward to ; work.... ; No problem! If you did not include the Matrix area using ; AreaInclude, but you have MatrixFwdAreaInclude and ; MatrixForward enabled, place your NetMail area path here, and ; YMS will work and forward messages via NetMail. ; I suggest you to use this option even if you have AreaInclude- ; d the Matrix. It will be redundant but, as YMS will not bother ; about it, you will be sure that the forward functions will ; work even if for some kind of problem, the Matrix area would ; be disabled from the message waiting base. ; Note that if you leave this verb uncommented, YMS will ; consider your MATRIX area the area which has both the MATRIX ; flag AND this path. ; NetMail d:\opus\msg\fidomail\ ; ; ; Task <number> ; ------------- ; The show goes on: you are entering the YMS multitasking ; environment. With this statement you tell YMS how to behave in ; each of you system's tasks. If you are not using different ; tasks, say here: ; Task 0 ; You can have up to 256 tasks (I guess they are enough!) ; This statement is in DECIMAL numbers. YMS will provide ; hexadecimal conversion in YMS_PRM.D?? ; This entry must be the first when defining a task and it acts ; as a separator: when YMS COMPILE/CTLCOMPILE encounters another ; Task argument, it will assume you are beginning to setup the ; environment of another task. ; Task 1 ; ; ; TaskLastUser <[drive:pathname\]filename.ext> ; -------------------------------------------- ; Tells YMS which lastuser file to read for task one. If you are ; not using tasks, the file will be [drive:\path\]lastus00.dat ; or [drive:\path\]lastuser.bbs if you are using Maximus. ; Remember that if you have more than 9 tasks, you will have to ; use hexadecimal suffixes for your LASTUS??.DAT or .BBS file ; (i.e. Task 10 will have LASTUS0A.DAT, task 99 will have ; LASTUS63.DAT) ; If left commented out, it will default to ; [BbsDirectory\Lastus(task#).DAT] for OPUS systems or ; [BbsDirectory\Lastus(task#).BBS] for Maximus systems so there ; are good chances that YMS will look for the right lastuser ; file. ; TaskLastUser D:\opus\lastus01.dat ; ; ; TaskUpdateLog <[drive:pathname\]filename.ext> ; --------------------------------------------- ; You cannot have YMS running in two different tasks and writing ; in the same LOGfile, in the same way as you cannot do it with ; Opus or Maximus. ; If you have an Opus/Maximus' logfile for Task 1, place it ; here; if you do not have multiple tasks, specify your sole ; logfile here. ; Leaving it blank will cause YMS to default to the log file ; specified for YMS COMPILE; if commented will force YMS not to ; generate an Update LogFile. ; TaskUpdateLog D:\Opus\Opus.log ; ; ; TaskSearchLog <[drive:pathname\]filename.ext> ; --------------------------------------------- ; If you like, you can have YMS generating a Search Logfile too. ; The main reason why UpdateLog and SearchLog can be configured ; separately is because earlier versions of Opus (up to 1.12) ; did not allow writing to Opus' logfile from a ^OC embedded ; command. ; Opus 1.13 flushes the log each time writes to it, and ; therefore you can put everything in the same file, if you ; like. ; Leaving it blank will cause YMS to default to the log file ; specified for YMS COMPILE; if commented will force YMS not to ; generate a Search LogFile. ; TaskSearchLog D:\Opus\Opus.Log ; ; ; TaskUpdateLogLevel <number> ; --------------------------- ; You can specify a different LogLevel for each logfile you ; have. The LogLevels are the same specified for the Log ; function (see above). If commented, it will default to the ; value specified for LogLevel. ; TaskUpdateLogLevel 4 ; ; ; TaskSearchLogLevel <number> ; --------------------------- ; Ditto, as for TaskUpdateLogLevel. ; TaskSearchLogLevel 5 ; ; ; TaskUpdateConflict <option> ; --------------------------- ; In multitasking environments it may happen that YMS is ; invoked at the same time in two different tasks. In this case, ; you can choose how to let it manage the conflict. <Option> can ; be: ; Exit: Exit will cause the UPDATE function to exit without ; doing anything, if another UPDATE is being performed ; at the same time. It may save time, as there is really ; no need of two concurrent UPDATEs (one will take care ; of the changes made by both tasks). ; Wait: With this option you can tell YMS to wait for the ; other task(s) to finish their update function before ; starting UPDATE in the current task. In this way, you ; will always have your message waiting base updated in ; real time. On the contrary, as it will hang two or ; more tasks, it is advisable not to use it on computers ; with slow CPUs and slow disks. ; Ignore: Useful only in a monotask environment. I recommend the ; use of this option in such environments because YMS ; will not use its "busy" flag, which can be left high ; due (for example) to a power failure (it happened!!). ; TaskUpdateConflict Exit ; TaskUpdateConflict Wait ; TaskUpdateConflict Ignore ; ; ; TaskUpdateWaitTime <number> ; --------------------------- ; NOTE!! The behaviour of this verb is slightly changed from YMS ; 1.00. Read on!! ; If not commented, TaskUpdateWaitTime will specify how much ; time YMS has to wait before taking the action specified with ; TaskUpdateConflict. So if you specify (for example) ; TaskUpdateConflict Exit and TaskUpdateWaitTime 5, YMS (in case ; of update conflict) will wait 5 seconds to see if the "busy" ; flag is lowered. If this happens, YMS will start updating; if ; the specified time ends, YMS will exit without doing nothing. ; With TaskUpdateWaitTime Ignore, YMS at the end of the 5 ; seconds would have started updating anyway. Wait is similar to ; Ignore, but clears the "busy" flag too. ; WARNING: if TaskUpdateWaitTime rolls over (and you have ; specified either Ignore or Wait for TaskUpdateConflict) while ; the other task is not hung, and is performing an UPDATE too, ; you will have the two tasks conflicting and you will ; completely lose your message waiting base, requiring a new ; compile. Therefore, in these cases, please choose a reasonably ; high time. ; In my humble opinion, you can have one task with ; TaskUpdateConflict Wait and a high TaskUpdateWaitTime and all ; other tasks with Exit and no TaskUpdateWaitTime. In this way ; the Exit tasks will be faster, and the Wait task will avoid ; that, if the other task crashed running YMS and leaving YMS' ; "busy" flag high, UPDATE would no longer take place. ; This is the main reason why Wait has been concepted: to create ; this kind of security and not to have a buch of tasks waiting ; for each other to have their own turn to run an UPDATE. ; Simply think about this: there is merely never the need of ; two UPDATEs to be run on different tasks at the same time (on ; <[ AmnesiA ]> (386/33) YMS updates 97 areas in 13 seconds, and ; it's hard to see a user in another task entering an area and ; writing a message in the same amount of time...). ; ; TaskUpdateWaitTime 120 ; ; ; TaskSearchConflict <option> ; --------------------------- ; There may also be YMS_MS.EXE (the mail-search module) ; accessing the base while another YMS function is being ; performed in another task (and this may definitely be more ; frequent than the above case). Also in this case, YMS can ; manage the conflict. <Option> can be: ; Notify: With this option you will see YMS notifying the ; conflict to the user, so he/she can try to search for ; his/her mail later. This option is very useful, and I ; encourage you to use it if you're running a m'tasker. ; Ignore: The mail-search module will simply Ignore the conflict ; and read the message waiting base regardless of other ; tasks. I suggest you not to use it, and use Notify ; instead, since it can produce inaccurate results. ; Wait: The mail-search module will wait for the other task(s) ; to finish their UPDATE function before performing mail ; search. This option will probably be used only by ; SysOps in local mode, as it would be definitely ; annoying for a user standing on line without knowing ; if the system is hung or not. ; TaskSearchConflict Notify ; TaskSearchConflict Ignore ; TaskSearchConflict Wait ; ; ; TaskSearchWaitTime <number> ; --------------------------- ; NOTE!! Like TaskUpdateWaitTime also this verb has a slightly ; changed behaviour than YMS 1.00. Read on!! ; If not commented, TaskUpdateWaitTime will specify how much ; time YMS has to wait (in case of conflict) before taking the ; action specified with TaskSearchConflict. So if you specify ; (for example) TaskSearchConflict Notify and TaskSearchWaitTime ; 5, YMS (in case of conflict) will wait 5 seconds to see if the ; "busy" flag is lowered. If this happens, YMS will search and ; show the mail to the user. If the specified time ends, YMS ; will notify the user. ; TaskSearchWaitTime 5 ; ; ; TaskOutFile <[drive:\pathname\]filename> ; ---------------------------------------- ; This is the file shown to the user after a mail search. It ; contains either the list of the messages, either other ; messages, if he has no mail waiting or if there is a serach ; conflict. You must, of course, specify different filenames for ; different tasks. ; No extension is required, and is specified will be ignored. It ; defaults to .BBS and cannot be changed (Opus/Maximus cannot ; display anything else than .BBS and .GBS files!) ; If commented, it will default to {BbsDirectory}Mail_{task#} ; (with extension .BBS). ; TaskOutFile l:\Opus\mail ; ; ; TaskSearchShowAlias ; ------------------- ; Opus 1.70 only. If you did include users' aliases in the base ; (see IncludeAlias above), you can now selectively choose ; either to show to your users or not. This option can be ; overridden with the switch '-a' in YMS_MS. ; ;TaskSearchShowAlias ; ; ; TaskShowReceived ; ---------------- ; If you did include received messages in the base (see above) ; you can now selectively choose either to show them to your ; users or not, depending on the task number. ; In fact, this option has been concepted much more for use by ; SysOps than by users (i.e. you may want to see how many RECV ; messages you have there for you, but do not want the users to ; read several pages of message listings). ; This option can be overridden with the switch '-s' in YMS_MS. ; ; TaskShowReceived ; ; ; TaskSearchSectOnly ; ------------------ ; For OPUS 1.70 only. If not commented, YMS_MS will search for ; mail ONLY in the section(s) the user is in. If commented, ; YMS_MS will search in all areas (checking for privileges and ; keys, obviously..) ; ; TaskSearchSectOnly ; ; ; TaskAllNotToEnabled ; ------------------- ; If not commented, YMS will NOT show broadcast messages to ; people listed in the EnableToAll list. Can be useful for ; SysOps who don't want to be notified of messages they write!! ; This option can be overridden with the switch '-b' in YMS_MS. ; ; TaskAllNotToEnabled ; ; ; TaskOnlineLog <filename> ; ------------------------ ; Same as TaskSearchLog, but for YMS_OS. See TaskSearchLog ; (above) for more details. ; TaskOnlineLog D:\Opus\Opus.log ; ; ; TaskOnlineLogLevel <number> ; --------------------------- ; Same as TaskSearchLogLevel, but for YMS_OS. See ; TaskSearchLogLevel (above) for more details. ; TaskOnlineLogLevel 4 ; ; ; TaskOnlineConflict <option> ; --------------------------- ; Same as TaskSearchConflict, but for YMS_OS. <Option> can be ; either Notify, or Wait or Ignore. See TaskSearchConflict ; (above) for more details. ; TaskOnlineConflict Notify ; ; ; TaskOnlineWaitTime <number> ; --------------------------- ; Same as TaskSearchWaitTime but for YMS_OS. See ; TaskSearchWaitTime (above) for more details. ; TaskOnlineWaitTime 5 ; ; ; TaskOnlineChangeSect ; -------------------- ; OPUS 1.70 only. If the user has messages in a section he/she ; isn't in, let YMS_OS add the required section to the user's ; ones to allow him to read his/her message. If commented, the ; message isn't shown to the user. Personally, I prefer to show ; all the mail to the user (with YMS_MS and without using ; 'TaskSearchSectOnly'), but let him/her read only messages in ; his/her current section(s) only. ; ; TaskOnlineChangeSect ; ; Task 2 ; ; Here begins the second task. No further explanations should be ; necessary, as nothing changes, except for the task number, and ; you can have up to 256 tasks (in a range from 0 to 255). ; However, a couple of words may be spent about the way I use ; this second task, and is checking for MY mail waiting, from my ; message reader, without using Opus or Maximus. ; TaskLastUser D:\opus\Thatsme.Dat ; ; Almost everything is ok, except that I have logged into my ; system and then I have renamed the LASTUS01.DAT file created ; into THATSME.DAT, and everything works fine. ; In this way I search for mail, view the file, and enter the ; editor (msged)... ; TaskUpdateLog c:\yms\yms.log ; TaskSearchLog ; TaskUpdateLogLevel ; TaskSearchLogLevel TaskUpdateConflict Exit ; TaskUpdateWaitTime 120 ; TaskSearchConflict Notify TaskSearchWaitTime 120 ; TaskOutFile l:\opus\mail2 ; ; TaskShowReceived ;