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.