Crawly Crypt Collection 1

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

/ Crawly Crypt Collection 1 / crawlyvol1.bin / bbs / vmgr_201 / votemgr.doc < prev next >

Wrap

Text File | 1994-06-27 | 26KB | 807 lines

------------------------------------------------------------------ votemgr-st 2.00 - a vote manager for atari fidonet systems - Jun 03, 1994 USER MANUAL Copyright (c) 1993-94 SubSoft Development All Rights Reserved. Written by Harrie Beuvink Documentation originaly written by Carlos Terre ------------------------------------------------------------------ --------------------- -1 ACKNOWLEDGEMENTS --------------------- I own Carlos Terre the idea of this program, because he wrote it originaly for all the SM-dossers. ;-) After reading the doc's and studing the controlefile I decided to write a Atari version. Now, this Atari version is more complexer and cofigurable than the original "sm-dos" version... Multi-choice votings are implemented, more then only a Yes or No! I also want to thank all of you who have registered VOTEMGR-ST ;-) You can registrate it by sending a nice postcard to: Harrie Beuvink P.O.Box 340 7500 AH Enschede the Netherlands In return you will recieve your free registrationnumber, send to you by netmail. So don't forget to mention your mainaddress on this postcard!! Without this registrationnumber VOTEMGR-ST won't work! ----------------------- 0 THE LEGAL BUSINESS ----------------------- VOTEMGR is guaranteed only to take up space on your hard disk. Use it at your own risk. No warranty is stated or implied. The author shall not be responsible for any damages resulting from it's use, directly or indirectly. VOTEMGR-ST is distributed as a Freely Available Copyrighted POSTCARD-KEYWARE Program, provided it is used in a NONCOMMERCIAL environment: You can use it as long as you do not use it within a commercial environment. It doesn't matter if you are making money by using it or not, if you are using it within commercial walls, you may not use the noncommercial version. No fee may be charged for distribution and the distribution archive is not to be tampered with or altered in ANY way. VOTEMGR-ST cannot be distributed in a modified form of any sort. VOTEMGR-ST can no longer be repackaged for distribution. Distribution file must not be changed in any way. No additional files may be included and original files may not be modified. Registered users will have support. Allow the necessary time to process your request, and don't forget to write down your main netmail address on the postcard, so I can send you the key by netmail! You can contact me at the following network address: Harrie Beuvink at 2:283/705.0@fidonet.org or 90:5/0.0@nest.ftn ------------------------------------------- 1 THE DISTRIBUTION ARCHIVE (VMGR_200.ZIP) ------------------------------------------- This archive should have included the following files: VOTEMGR.DOC - The Documentation, you read it as we speak. VOTEMGR.HIS - The history and updates of VOTEMGR-ST. VOTEMGR.TTP - The Executable Program. VOTEMGR.CTL - A Control File example. HELP.TXT - A voters guide for using VOTEMGR-ST *.TXT - Other sample TXT files. ----------------- 2 WHAT IT DOES ----------------- VOTEMGR-ST is meant to take charge of votings carried on at your system. It is designed in such a way that "voters" can send messages to it, the same way they send messages to AREAMGR, AREAFIX, or FILEFIX: voters actually "talk" to VOTEMGR-ST. In return, VOTEMGR-ST will send messages to voters (if you decide so) to keep them informed of possible errors or to, simply, acknowledge correct ballot processing. You can edit your own messages editing ASCII files that will be defined in the control file. Here is what "vote manager" will be up to: SPECIFICATIONS: o Up to 25 different votings at a time. (Unregistrated copies only 1 voting) o Multi-choice votings ("more ballots in ONE voternetmail"). o Value added error control and result computation. o Feedback messages to voters. o Full control of receipt messages text. o Full control of Dates and electoral periods. o Logging of activities. o Results automatically posted into any echoarea of your choice o Multi-domain SPECIFICATIONS FOR EACH VOTING: o Up to 100 different choices. o Up to 1000 validation keys for systems ("ALL" macro is OK) o Up to 1000 rejection keys for systems ("ALL" macro is OK) o Full description of the election and results with TXTfiles. o Public/Secret result reports. o NULL and wrong votes controled. o Full control of point systems' validation. --------------------------------- 3 DISK AND MEMORY REQUIREMENTS --------------------------------- Anything will, most likely, do ;-) Should you have trouble, drop me a message! ----------------------------------- 4 THE CONTROL FILE : VOTEMGR.CTL ----------------------------------- In order to know your system configuration, and to define what your votings will be about, you must edit a plain vanilla ASCII file called VOTEMGR.CTL The .CTL file must be in the same folder as the .TTP file. The .TXT files can be put in any folder as long as you discribe the full path and filename in the controlefile. If you only specify the filename, the .TXT files must be in the same folder as the .TTP file. VOTEMGR.CTL structure can be devided in three groups: . general options . receipt text files . election definition block structure Each of these different groups defines different types of parameters votemgr needs to work. Parameters are entered following a KEYWORD, and order is not significant "most of the times". Items enclosed in square brackets ([]) are optional 4.1 General Options -------------------- 4.1.0 USERCODE USERCODE <1stname_lastname> You must simply enter your name. This parameter is mandatory. 4.1.1 USERKEY [USERKEY] <the keynumber you received from Harrie Beuvink on 2:283/705.0@fidonet.org or 90:5/0.0@nest.ftn> If you didn't sent me a postcard yet, with your netmailaddress written on it, and you didn't receive the keynumber, this program only supports ONE vote! This parameter is mandatory. 4.1.2 ADDRESS ADDRESS z:net/node.point [{ADDRESS z:net/node.point }] Your addresses. You can use more then one address. The first address MUST be your address you've used to ask for the key! The addresses MUST be 4-D! This parameter is mandatory. 4.1.3 NETMAIL NETMAIL <path/filename> Your NET Mail areaname without extention. ( ie c:\msgs\0025 ). This parameter is mandatory. 4.1.4 STATUS STATUS {pkcdh} Return receipt message defaultstatus. Here you can set the status of the messages that votemgr will send to voters. All you have to do is build up a string with the letters of the status you want activated: p -> private k -> kill/sent c -> crash d -> deleted h -> hold Note that if you don't want votemgr to send feedback messages to voters you must flag them as DELETED Note that it's also possible to define the STATUS command in any voting definition block structure. ; 4.1.5 ERRORSTRING ERRORSTRING <string> <String> should contain a line like: "You made the folowing errors:" This line is a header-line and will be followed by the text-bodies of: - ERRVOTTXT - ERRCHOICETXT - NOPWTXT 4.2 Receipt Text Files ----------------------- These files should be plain vanilla ASCII texts. This parameters aren't mandatory. 4.2.0 HELPFILE HELPTXT <[path]filename> This text is the main header of the body of the message addressed to voters who are asking for the main-helpfile about how to use VOTEMGR-ST. 4.2.1 ACTIVETXT ACTIVETXT <[path]filename> This text is the main header of the body of the message addressed to voters when they request information about active votings held at your system. 4.2.2 CHOICESTXT CHOICESTXT <[path]filename> This text is the main header of the body of the message addressed to voters when they request information about the valid choices for one particular voting held at your system. Following this text, the list of valid choices for a particular election will be displayed. 4.2.3 RECEIPTTXT RECEIPTTXT <[path]filename> This text is the body of the message addressed to voters when their ballot has been successfully processed by votemgr. 4.2.4 DUPLICATETXT DUPLICATETXT <[path]filename> This text is the body of the message addressed to voters when they try to vote twice and one ballot has already been successfully processed by votemgr for one particular election. Obviously, one person can only send one ballot to one particular voting. 4.2.5 ERRVOTTXT ERRVOTTXT <[path]filename> This text is the main header of the body of the message addressed to voters when they make a mistake (or typo) when they refer to a voting which is *not* defined at your system. This text should explain that an error has ocurred, and that they should send another message correcting the error. Following this text, ACTIVETXT will be displayed; and after it, the list of active votings held at your system. 4.2.6 ERRCHOICETXT ERRCHOICETXT <[path]filename> This text is the main header of the body of the message addressed to voters when they make a mistake (or typo) in their ballot. This text should explain that an error has ocurred, and that they should send another ballot correcting the error. Following this text, CHOICESTXT will be displayed; and after it, the list of valid choices for the particular voting. 4.2.7 ERRVALTXT ERRVALTXT <[path]filename> This text is the body of the message addressed to persons who try to vote even though they are not validated. 4.2.8 TOOLATETXT TOOLATETXT <[path]filename> This text is the body of the message addressed to voters when their ballot is received too late, and therefore will *not* be processed by votemgr. This text should contain a message telling the voter to contact votemgr supervisor. 4.2.9 TOOSOONTXT TOOSOONTXT <[path]filename> This text is the body of the message addressed to voters when their ballot is received too soon, and therefore will *not* be processed by votemgr. This text should contain a message telling the voter to try again within the electoral period. 4.2.10 NOPWTXT NOPWTXT <[path]filename> This text is the body of the message to voters who didn't specify a password or who used an invalid password. 4.2.11 SIGNOFFTXT SIGNOFFTXT <[path]>filename> This text is the body of the last line at the end of any message to voters. After these lines, votemgr-st will write down your name 4.3 Election Definition Block Structure ---------------------------------------- This block can be repeated as many as 25 times, defining 25 different votings at your system. 4.3.1 DEFINE DEFINE <electname> Definition block start mark. <electname> MUST be a valid DOS file name (max 8 chars). VOTEMGR-ST will use this name to create a folder and all the temporary files related with the voting defined, will be stored in this folder. DEFINE has its counterpart in ENDDEF, which is the block end mark. Both must always be used! 4.3.2 VALIDATE VALIDATE <address [{address}]> Validate statements allow you to specify who is allowed to vote. You can write multiple addresses following one VALIDATE statement, and you can use maximal 100 VALIDATE statements as you need. So more than 1000 addresses can be defined <address> can be either a particular address or a set of addresses gathered by means of the ALL macro. ALL macro is supported. When entering an address, you may specify ALL in any, or all, address portions (the 4 valid address portions are: Zone, Net, Node and Point). The addresses MUST be 4-D! Note that wildcarding will *NOT* auto-flow in a greater to lesser direction, IN CASE YOU DON'T SPECIFY A RULE FOR LESSER DIRECTION. That means that if you specify ALL in the Net position, Node and Point will not be wildcarded. The most general rule is, then, 2:all/all.all which validates whatever fido-address in zone-2 you may think of. This is a very powerfull feature, and should be used together with the REJECT statement, explained below. VOTEMGR-ST will use the zonenumber defined here to choose the correct ADDRESS when it sends messages back to the voters. If you're the votemanager for a NeST (zone 90) voting, be sure the first VALIDATE address starts with a "90:"!! 4.3.3 REJECT REJECT <address [{address}]> Reject statements allow you to specify who is *not* allowed to vote. You can write multiple addresses following one Reject statement, and you can use maximal 100 Reject statements. The addresses MUST be 4-D! This statement follows the same rules as VALIDATE, and is intended for use with VALIDATE in order to make exceptions to global VALIDATE statements. i.e.: VALIDATE 2:343/ALL.0 REJECT 2:343/100.0 2:343/200.ALL 2:343/300.0 4.3.4 AREA AREA <[path]filename> EchoMail Area FILENAME ( ie c:\msgs\sysops28 ) of the echomail conference (whitout the extention .MSG or .HDR) for which mail will be created. 4.3.5 ORIGINLINE [ORIGINLINE <origin_line>] The originline you want to use for this echomail. 4.3.6 FROMDATE FROMDATE <mm.dd.yyyy> Date of start of ballot processing. Ballots received previous to this date, will be ignored, and addressee will be notified so he can vote again. 4.3.7 TODATE TODATE <mm.dd.yyyy> Last day of ballot processing. Ballots received after this date will be ignored, and addressee will be notified so he can know. 4.3.8 PRIVATE [PRIVATE] Hides names and addresses when reporting results FOR THIS VOTING. 4.3.10 INFOTXT INFOTXT <filename> Description of the election to be displayed in the active votings list. This text should describe what the voting is about and who is validated to vote. This file MUST be place in the folder defined at the statement DEFINE <electname>. Only a filename is valid. DON'T MENTION A PATH HERE!! 4.3.11 RESULTTXT RESULTTXT <filename> This text will be the header for results. This text defaults to INFOTXT if is left undefined. This file MUST be place in the folder defined at the statement DEFINE <electname>. Only a filename is valid. DON'T MENTION A PATH HERE!! 4.3.12 CHOICES & ENDCHOICES CHOICES ... ENDCHOICES CHOICES keyword starts the list of valid choices for the voting. Only one choice can be defined per line. Up to 100 different choices can be defined for one particular voting. ENDCHOICES keyword finishes the list of valid choices. For example: CHOICES yes no blank ENDCHOICES (we declare three valid choices for a voting: "yes", "no" and "blank") 4.3.13 ENDDEF ENDDEF Voting Definition block END marker. NOTICE! YOU MUST ALWAYS FINISH YOU VOTING DEFINITION BLOCK!!! ------------------------ 5 COMMAND LINE SYNTAX ------------------------ Usage: VOTEMGR [-scan] [-report {<voting_name> <voting_name>|*}] Items enclosed in [] are entirely optional. Items enclosed in {} are a "list" of optional items. Items enclosed in <> are parameters. Switches: o -scan Instructs VOTEMGR-ST to scan your netmailarea looking for messages addressed to votemgr. You should include an external event and execute this command on a daily basis -at the least-. o -report <voting_name> -report * Instructs VOTEMGR-ST to create a report of the specified voting. If the electoral period has not expired yet, no echomail will be created. If electoral period has expired, then echomail will be created "once". A void file with extension .FLG will be created in the work folder to flag that echomail have already been created. If you want to to report all voting_names you also may use the option "-REPORT *" ------------- 6 EXAMPLES ------------- This example relates to the included sample .CTL file: votemgr -scan -report test sysop votemgr will scan your netmailarea for new ballots and will update result files. Eventually, votemgr will create report echomail You could use a longer command line if you wanted to create reports on more than one voting: votemgr -scan -report test sysop decide nec343 encrypt moderato You could use a very short command line if you wanted to create reports on all the votings: votemgr -scan -report * As you can see, not much is to be said about executing VOTEMGR-ST from the command line ;-) ----------------- 7 OUTPUT FILES ----------------- votemgr creates files in the work folder to keep results and account of ballots. These files have the name of the related voting, and four different extensions: .VOT, .RES, .QUO, .FLG 7.1 .VOT --------- .VOT keeps every processed and correct ballot for one voting. It stores information about voters, and should be kept protected, since this information should only be available to votemgr coordinator. 7.2 .RES --------- .RES is created when votemgr is run with the -report option, and is the list of results. This file is overwritten if VOTEMGR-ST is run again with more information in the related .VOT file. .RES is the same file that is posted in the echoarea to announce results, if and only if electoral period has expired. 7.3 .QUO --------- .QUO is created when votemgr is run with the report option, and is the list of systems participating in the election. This is the "quorum" file. This file is overwritten if VOTEMGR-ST is run again with more information in the related .VOT file. .QUO is the same file that is posted in the echoarea to announce participating systems, if and only if electoral period has expired. 7.4 .FLG --------- .FLG is created when votemgr is run with the -report option, and packets are created. This file is void, but acts as a semaphore to sign that results have already been posted in the echoarea. ------------------- 8 CLOSING MATTER ------------------- If you have any problems you can't fix or questions you can't answer then please contact me via NetMail. I will always do my best to support the software, but the unregistered version is, by definition, un-supported. I will answer queries as time allows, please be patient when awaiting a reply. ------------------------------------------------------------------- OPTIONAL PARAMETERS FOR MULTI-CHOICE VOTES ========================================== This is a rather short manualpart, handling the multi-choice votes. First install votemgr-st for the normal votings. This part isn't difficult, but it's better to have som experiment with votemgr-st. As we discussed above, VOTEMGR.CTL structure can be devided in three groups: . general options . receipt text files . election definition block structure Just put these optional parameter in the right group!! This multi-choice option allows users to choose more then one option. The voter must write a netmail like: From: User Name to : Votemgr-ST Subj: DECIDE ------------------------------------------------ ![password] <keyword> choice [<keyword> choice] .... [<keyword> choice] A password is a string, starting with a "!" and CAN contain spaces ' '. (ie. "!my security password") A keyword is a string NOT containing spaces ' '. (ie. "chairman") a choice can be anything. (ie. "Carlos Terre") ---------------------------------------------------------------------- OPTIONAL receipt text files for multi-choice votes. ---------------------------------------------------------------------- "received the same choices within one vote" Only used within a multi-choice vote. [DUPCHOICETXT <file_spec>] dupchoicetxt dupchoi.txt received the same keyword in a multi-choice vote. Only used within a multi-choice vote AND when using "UNIQUEKEYWORD" in a voting definition block. [KEYWORDUNIQUETXT <file_spec>] keyworduniquetxt uni_keyw.txt received the same choices in a multi-choice vote. Only used within a multi-choice vote AND when using "UNIQUECHOICE" in a voting definition block. [CHOICEUNIQUETXT> <file_spec>] choiceuniquetxt uni_choi.txt ---------------------------------------------------------------------- OPTIONAL election definition block structure for multi-choice votes. ---------------------------------------------------------------------- [ MAXCHOICES number>1 ] For a multi-choice vote NUMBER MUST BE BIGGER THAN 1 (ONE) !!!! MAXCHOICES is the maximal number of entries a voter may do in one vote. BEGINchoices ; NOTE: you have to define ALL the possible combinations!!!! chairman Carlos Terre chairman Miquel Piulats chairman Tirs Abril chairman Harrie Beuvink chairman Andre van Duin secretary Carlos Terre secretary Miquel Piulats secretary Tirs Abril secretary Jan Jans treasurer Carlos Terre treasurer Miquel Piulats ENDchoices If the keywords must be unique, so in this case only one chairman, one secretary or one treasurer can be choosen, you must use: <UNIQUEKEYWORD> If the choices must be unique, so only unique names in this vote, you must use: <UNIQUECHOICE> When the you want to give the vote a certain weight you can use the BEGINCOUNT/ENDCOUNT statement as shown here. Begincount 4 2 1 Endcount In this case, the voters first entry will have four points, the seccond two points en the third entry one point. The principal is the same as used with the European Song Contest. If there are any questions, or if some wants to write a good doc conserning the multi-choice vote, PLEASE contact me.