Again assume that the full pathname of the contest directory is
$CONTESTDIR.

Before running any contests you will have to make available to the
teams a Makefile that they can use during contests and the files str.h
and string.o that between them provide some Turbo Pascal emulation
functions.  The Makefile the teams should use is
$CONTESTDIR/comp.Makefile, with str.h and string.o both in
$CONTESTDIR/src.  The easiest thing to do is to copy these three files
into a publicly accessible directory and to change the value of
STRINGDIR in the comp.Makefile copy to be the full pathname of that
directory.


Running a contest
=================

To run a contest, you will need to do the following things:

1. Decide on the problem set you are going to use.  Print out the
problem set.

2. Ask each team to specify the usercode they will use while doing
the contest.

3. In the "subs" directory of the selected problem set, create a
subdirectory to hold the submissions of each team.  The subdirectory
created for each team MUST have the same name as the team's usercode.
Note: if you are using the setuid version of dispatch then 
permissions on each team subdirectory should be 711.

4. Create a symbolic link $CONTESTDIR/current.comp that points to the
directory containing the problem set that is to be used
($CONTESTDIR/NZ.89).  This is the contest that submission and judging
programs will access by default.  current.comp can be overridden
(for both submission and judging programs) by setting the environment
variable PROBSET to the name of the contest directory that should be used.
For example:

setenv PROBSET NZ.89

5. Submission of programs.  Teams are advised to create a separate
subdirectory for each problem, and to copy comp.Makefile (under the
name Makefile) into each (although the program submission software
doesn't rely on this).  Teams must name C solutions problemX.c, Pascal
solutions problemX.p and Modula-2 solutions problemX.mod where X is
the lowercase letter of the problem.  So, for example, a C solution to
problem A must be put into a file called problema.c.

The progsub program should be used to submit solutions:

progsub problem_letter

To submit a solution to problem a the following command should be
entered (current directory must contain the C, Pascal or Modula-2
solution):

progsub a

progsub copies the submission into the appropriate directory and sends
an email message to the judge.  The default usercode for the judge is 
that specified in $CONTESTDIR/src/contest.h, but this can be overridden
by setting the JUDGE environment variable.


6. Testing a solution.  The testprob command can be used to test
a submission:

testprob team problem_letter [version]

The team argument is the usercode being used by the team, and the
problem_letter is the (lowercase) letter of the problem to test.  Team
submissions are numbered from 1.  By default, testprob tests the most
recent (highest numbered) submission, but a version number can be
specified if for some reason an earlier version is to be tested.

testprob first compiles the submission then runs it to get its output
when run over the judge's test input file.  "Judging" is then
performed in one of two ways.  Most problems are defined in such a way
that the output produced should be identical to that of the judge's
solution.  In such cases diff(1) is used to compare the team's output
with the judge's.  The following line is printed followed by any
differences.

Judge <, team_name >

Lines preceded by a < are from the Judge's output file, and lines
preceded by a > are from the team's.  If there are no differences
then the team's submission is correct.

For a few programs the problem specification means that a check using
diff is impossible.  In these cases individual checking programs
have been written, and these are used to check the team's output file.
If no error is found the the message "Team's solution is correct" is
printed.  If errors are found the suitable error messages are printed.

If neither of these judging methods is provided then judging must be by
hand (currently only one problem).  Such problems are documented in
the README file for the problem set.


7. Based on output produced by testprob you should reach some conclusion
on the correctness of the submission in accordance with the possible
results given in $CONTESTDIR/doc/messages.{tex,ps}.  Having reached
your decision you should record it with recmark:

recmark team problem result [version]

team, problem and version are as for progsub.  If no version is specified
then it is assumed that it is the latest that's being marked.  A 
previous decision can be changed by specifying the appropriate version
number.  result is an integer between 0 and 9, with 0 meaning correct and
1 to 9 meaning that an error occurred whose number matches the error
message numbers given in messages.

recmark emails the judge's decision back to the team.


8. Scoring.  The score command can be used to check on the progress of
a team:

score [-v] team "dd/mm/yy hh:mm"

team is as for progsub and recmark.  The last argument is the date and
time of the start of the contest.  Because a blank is embedded in this
argument it must be quoted to the shell.  If the -v (verbose) flag
is not specified then a single line of output is produced for the 
specified team giving the number of problems solved, the total time
taken to solve them (computed as per $CONTESTDIR/doc/rules.{ps,tex}),
the number of problems for which solutions have been submitted and
the name of the team.  If the -v option is given a detailed breakdown
of info on all submissions (including times and judge's decisions)
is given.

The results program can be used to print out the result of a contest:

results "dd/mm/yy hh:mm"

The only argument is the date and the time of the start of the contest.
Teams are listed from first to last.
