California State University, Sacramentos
PC2
Version 7.6
Contest Administrators
Installation and Configuration Guide
Table of Contents
Overview . 3
Startup Checklist for Geniuses . 4
Installation .. 5
Initialization Files .. 6
Execution Scripts .. 8
Startup Procedure
1. Registry .. 10
2. Server .. 13
3. Clients . 14
Contest Configuration
1. Accounts 15
2. Contest Problems 19
3. Contest Languages .. 21
4. Additional Functions 22
Starting the Contest 27
Scoreboard 28
Appendices
1. Java Security Policy 31
2.
ini Files . 323. Sample Execution Scripts . 35
4. Registry Advanced options .. 41
5. Report Generation .. 42
Overview
PC2 (the Programming Contest Control System) provides support for running Programming Contests. PC2 was developed at California State University, Sacramento, in part under a grant from IBM Corporation, to support the ACM International Collegiate Programming Contest, including its Regional and Local contests. PC2 provides mechanisms for Contest Administrators to configure various contest parameters, for contestants to submit problem solutions, for Judges to fetch and evaluate submissions and return results to contestants, for computing and displaying contest standings, and a variety of other features.
PC2 is a dynamic, distributed real-time system written in Java. It includes support for multi-site contests, heterogeneous platform operations including mixed Windows and Unix in a single contest, and dynamic real-time updates of contest status and standings to all sites. Further information on PC2, including how to obtain a copy of the system, can be found at http://www.ecs.csus.edu/pc2.
The latest release of PC2, Version 7.6, consists of three primary modules: the Registry, the Server, and the Client. The Registry is always started first, and after initializing the Java RMI (Remote Method Invocation) system, the Registry waits to be contacted via RMI by other modules. The Server module is started next on one machine at each site in the contest, and handles all communications for that site during the contest. The Client is started once on each machine used by a human in the contest each Judge machine, each Team machine, each Scoreboard machine, and each Contest Administrator machine.
The following communication requirements must be met in order to run a contest using PC2: (1) every machine running a PC2 Server (one at each site in a multi-site contest) must be able to communicate via TCP/IP with the machine running the Registry, and with the Server machine at every other site; and (2) every machine running a PC2 Client (e.g. Teams, Judges, Scoreboards) must be able to communicate via TCP/IP with the machine running the Registry and with the machine running the Server at its own site. In particular, there must not be any "firewalls" which prohibit these communication paths; the system will not operate if this communication is blocked. It is not necessary for Client machines to be able to contact Servers at other sites.
Each PC2 module reads one or more ".ini" initialization files when it starts; these files are used to configure the module at startup. The Client module also tailors its configuration when a user (Team, Judge, etc.) logs in. It is permissible for the Registry and the Server to run on the same machine. It is also permissible to run multiple Clients on the same machine.
Setting up and running a contest using PC2 involves the following steps: (1) installing Java and PC2 on the contest machines; (2) creating/editing the necessary initialization files; (3) starting the Registry, Server(s) and Clients(s); (4) configuring PC2 for the contest via an Administrator Client (including providing an execution script to control contestant program execution); and (5) starting the contest so that users can log in. These steps are listed in checklist form in the next section, and are described in detail in the remainder of this manual.
PC2 Startup Checklist for Geniuses
For those people who hate to read manuals and would rather take a chance with a shortcut list, here is a very terse summary of the steps necessary to install PC2 and get it running. Please note that this is provided as a convenience for geniuses (or gluttons for punishment). The remainder of the manual was written to help everyone else. If you have problems after following this list, please read the rest of the manual before sending us a request for help.
Installation for the rest of us
In the event that the preceding checklist is a bit too terse, the remainder of this manual discusses the details of using PC2 to configure and run a contest. The first step is to install the necessary software, as follows.
Initialization Files
When a PC2 module (Registry, Server, or Client) begins running, it reads a set of one or more "initialization files" from the directory in which it was started. The Contest Administrator must ensure these files are present as needed, and edit them as necessary, prior to starting a PC2 module. This section describes the principle initialization files and their contents (note: some default initialization files are provided with the PC2 distribution package; these must be edited as necessary). Further descriptions of initialization files and their contents can be found in the Appendices.
pc2v7.ini
Every PC2 module reads a file named "pc2v7.ini" at startup. This ".ini" file provides key initialization information to the module. The file is formatted in sections. Each section starts with a section-name in square brackets; for example, [server]. Each PC2 module reads the entire file, but silently ignores any information which does not pertain to it. All lines starting with "#" or ";" are comments and are also ignored, as are blank lines. Section names are case-sensitive.
Sections may appear in any order in the pc2v7.ini file, and not all sections are required to be present (depending on which module is being initialized). Currently defined sections (see the Appendices for details) include:
[global] [registry] [server] [client]
[admin] [board] [judge] [team] [region]
Each section contains one or more lines containing "attribute assignment" statements of the form
attribute_name=value
The "attribute_name" is a predefined string chosen from list of PC2 configuration attributes. The "value" is the value to which the corresponding attribute is set when the .ini file is read by a module. No spaces are allowed in front of the "value" after the equal-sign.
Some attribute assignment statements are specific to particular sections and have no meaning for other sections (or for the modules that read them). Other attribute assignments are relevant to multiple sections/modules and can appear in different sections. Most attribute assignments are optional and PC2 will provide default values if they are omitted. However, two attribute assignments are mandatory:
The following attribute assignment must appear in the pc2v7.ini file for every Server and every Client module, in the [global] section:
registry=<IPAddress>:<portNumber>
# Specifies the IP Address and port (socket) number at which
# modules (other than the Registry module) should attempt to contact
# the PC2 Registry. Every Server and every Client module MUST have a
#"registry=IPaddress:port" entry in the [global] section of its pc2v7.ini file.
The following attribute assignment must appear in the pc2v7.ini file in the [client] section (for machines running PC2 Clients) or in the [server] section (for machines running PC2 servers):
site=<site_name_string>
# Tells the module which Site it is Serving (in the case of a Server) or to
# which Site Server it should connect (in the case of a Client).
# The site_name_string is a CASE SENSITIVE string chosen
# from the list of site names provided when the Registry is started (see below). # Site names must be unique across all contest sites.
A complete list of pc2v7.ini file attribute_name items, together with a specification of the allowable values for the attribute and a list of the section(s) in which the attribute may be assigned, can be found in the Appendices.
team.ini
When a contest team starts a PC2 Client and then logs in using a PC2 Team Account (as defined by the Contest Administrator; see below), the Team Client expects to find a PC2 initialization file named team.ini. The contents of the team.ini file are a single line containing a 13-digit Team Initialization Key. An acceptable Team Initialization Key value in the absence of information to the contrary is 2001030101240. Use of any other value in the team.ini file may result in undesirable contest operations. Authorized Contest Administrators may contact us via email at pc2@ecs.csus.edu for further information regarding the effects of the Team Initialization key.
PC2 Execution Scripts
When a team makes a PC2 "TEST RUN" on their machine or submits a program to the Judges using the "SUBMIT RUN" function, it is necessary for the program to be compiled, linked, executed, and provided with run-time access to the appropriate data file(s) either on the team machine (in the case of a TEST RUN) or on the Judges machine (in the case of a SUBMIT RUN). It sometimes also is desirable to perform additional operations such as controlled display of the program output or invocation of an "automated judging" routine to analyze the output for correctness (in the case of a run submitted to the Judges).
Since these actions are highly language-, vendor-, and operating system-dependent, it is not desirable to hard code those instructions into PC2. The way this is handled is by providing hooks from the Team and Judge interfaces to an external "script" (or "batch file"). This is referred to as the "execution script", since it specifies how to compile, link and then execute a program. (Note: in earlier versions of PC2 this was called a "judging script"; the term "execution script" is a better description of the function of the script since it is used for TEST RUNs on the team machine as well as for Submitted Runs on the Judges machine).
Conceptually, each contest problem requires its own execution script (although it is possible to merge multiple scripts into one; see the discussion below). When a Team makes a TEST RUN, or when a Judge invokes the "Execute Run" function, PC2 arranges that the source files for the run, along with the appropriate data files (from the Team in the case of a TEST RUN; from the Judges in the case of a Submitted Run) are copied into a special "execute" directory, and then it invokes the "execution script" for the problem specified in the run.
The execution script for each problem must be provided by the Contest Administrator. (There are sample scripts in the "samps" directory in the PC2 distribution; these sample scripts can be used as a starting point from which to create a customized execution script for your own contest environment.) Execution scripts are loaded into PC2 at configuration time (see the section on Configuring Contest Problems). Note: when an execution script is loaded into PC2, an internal copy of the script is made. If it is desired to change the script at some point, it is necessary to edit the original version and then reload the execution script.
Parameters for Execution Scripts
PC2 defines a fixed interface to an execution script, passing it certain parameters describing the program specifically, the full file name of the program file, the file name with no extension, and the language name (as defined during configuration by the Contest Administrator). It is then the responsibility of the script to do whatever the Contest Administrator deems necessary with the run compile it, execute it, save the output to a file, invoke a viewer on the output, etc. The parameters passed to the execution script by PC2 are summarized in the following table.
PC2 Execution Script Parameters
Order |
Example |
Description |
1 |
hello.c |
main file name with extension (no path) |
2 |
hello |
main file name, NO extension |
3 |
cpp |
short lang name (for example: java, cpp, etc.) |
4 |
2 |
number of the problem, starting at 1 (ie Prob A is 1, Prob B is 2, etc). |
Additional Notes on Script Operations
Startup Procedure
To begin running a contest using PC2, first complete the installation, initialization file editing, and execution script generation as described above. Then, start the PC2 Registry on the machine whose ID is specified in the pc2v7.ini file on the contest machines. To start the Registry, go to a command prompt, change to the directory containing the Registrys initialization files, and type the command
java pc2.Registry
(Be sure to note the upper-case "R" in Registry.) The Registry must be started before any other module in the Contest. In a multi-site contest, the Contest Administrator must insure that people at one site do not start other modules (Clients or Servers) until after the Registry has been started. Also, do not start more than one Registry in a contest (in particular, avoid the temptation to start a Registry at each separate site). If console and/or debug logging are enabled (as determined by the pc2v7.ini consolelevel and debuglevel attributes), the progress of the Registry startup steps will be displayed on the console and/or in the log file "pc2reg.log" in the Registrys startup directory.
The first time the Registry module is started for a contest, it will display the following window:
To complete the startup of the Registry, the PC2 Admin password and the name(s) of the contest site(s) must be defined on this screen. Enter the Admin Password and then retype the same password in the Confirm Password box. Then click on the Add button. The Add button will cause the following window to appear:
Enter a Site Name (such as the location where the site is hosted), then click the Update button to save that site name. As site names are added they will appear in the main Registry Contest Configuration window. For example, if "Site 1" was entered in the Site Information window, the name "Site 1" will appear in the Contest Configuration window as shown below:
It is IMPORTANT to note that Site Names are case-sensitive and that blanks are significant in a Site Name (for example, the name "Site 1" is different from the names "site 1" and "Site1"). The "site=<site_name>" entry in the pc2v7.ini file on Server and Client machines is used to associate a Server or Client site name with a site name as entered via the Registry; it is critical that case and spelling (including blanks) match exactly between the Registry Contest Configuration dialog and the pc2v7.ini file entries.
The Registry Contest Configuration window also provides the following OPTIONAL screen which can be used to configure the "Rejected Run Messages" which the Judges can return to teams:
The default (shown above) is the set of messages used in a large number of ACM ICPC Regional Contests around the world. Alternatives are the set of messages used in the ACM International Collegiate Programming Contest World Finals, or the specification of a custom set of messages which you create (Add/Edit/Remove) yourself.
The Registry Contest Configuration dialog also provides an ADVANCED screen which can be used to do a certain amount of "automatic configuring" of PC2. This option is restricted to use by experts; it is disabled in the default distribution of PC2.
Once the required and optional information has been entered in the Registry Contest Configuration window, click the "Continue" button. When the Registry has been successfully started the message "Registry is ready." will appear on the console and in the log file.
If any errors occur or the Registry fails to produce the "Registry is ready" message, check the "pc2.log" and "pc2reg.log" files for details.
Additional Note: the Registry configuration dialog only appears the first time the Registry is started. If a contest is started and then for some reason shut down and restarted, the values previously entered are retained and reused without prompting for them.
Once the Registry is running, the next step in starting a contest is to start a Server on one machine at each site in the Contest. To start a server, go to a command prompt, change to the directory containing the Servers initialization files, and type the command
java pc2.Server.Server
Again, note the case in the command; note also the doubling of the word "Server" (this is because the Server is a program [class] in a separate subdirectory [Java package] which is also named "Server").
When the Server starts, it will read the pc2v7.ini file to determine the location of the Registry. It will then contact the Registry and determine the sites that are defined. (Note that this means TCP/IP communication between the Server and Registry machine must be possible; there must not for example be any "firewall" prohibiting such communication.)
If there is no "site = " attribute defined in the Servers pc2v7.ini file that matches a site defined by the Registry, the Server will display the following "site selection" Login window:
Select the site for this server from the drop-down list and then click the Set button.
If console and/or debug logging are enabled (as determined by the Servers pc2v7.ini consolelevel and debuglevel attributes), the progress of the login will be displayed on the console and/or in the log file "pc2serv.log" in the Servers startup directory. Once the Server has successfully started, it displays the message "Server at site xxx is ready" on the console and in the log file (where "xxx" is the name of the site), then silently waits for connections or events from Clients at its site, or from other site Servers in the contest. Note that this implies all Server machines in a contest must be capable of communicating with each other via TCP/IP, and also that every Client machine in a contest must be capable of communicating with its own sites Server machine (Clients must also be able to communicate with the Registry machine).
If any errors occur or the Server fails to produce the "Server is ready" message, check the "pc2.log" and "pc2serv.log" files for details.
Once a site has a Server running, users at that site (a Team, Judge, Administrator, Chief Judge, or Scoreboard) can start a PC2 Client on their machine. To start a Client, go to a command prompt and type the following command (again, note the case in the command and the doubled name):
java pc2.Client.Client
The Client will read its pc2v7.ini file to determine its site name and the location of the Registry, contact the Registry to obtain a handle to the Server for its site (as specified in the site attribute in the pc2v7.ini file), and then contact its sites PC2 Server. Following this initialization sequence, the Client will display a "login" window as shown below, indicating that it is ready to accept a user (Team, Judge, Chief Judge, Administrator, or Scoreboard) login. Depending on the logging levels specified in the Clients pc2v7.ini file, the progress of these steps will be displayed and/or written to the file pc2.log in the Clients startup directory.
If any errors occur or the Client fails to produce the login screen, check the "pc2.log" file for details.
Contest Configuration
Account Creation
Once PC2 is set up and running, it is necessary to "log in" to the system via a Client login window in order to use it. A PC2 "account" is required in order to log in. Initially only a single account exists; the account name ("login ID") of this single account is "pc2". This account is a master Administrative account which is used to configure the PC2 system initially for the contest. Regular users (especially Teams) should NOT be given access to this account.
The default password for the pc2 account is empty (that is, no characters); the password should be set via the Registrys "Admin Password" box when the Registry is started for the first time. (Note that the default master password is given right here in this paragraph of this document, which is publicly available on the Web. Caveat Administrator.) It is also possible to change the pc2 Admin password via the "Manage Accounts" function on the "Accounts" tab; see below.
After logging in to the "pc2" Administrator account, the following screen will be displayed. This is referred to as the "main Administrator screen". It provides a series of "tabs" across the top to select various administrative configuration functions.
To create new accounts for users, click the Generate button under the Accounts tab on the main Administrator screen. This will display the following screen:
(Note that the (1) to the right of the Administrators label means that currently one Administrator account exists that one account is the pc2 account).
Enter the desired number in each box, then click the Generate button. (Note that it does not hurt to generate a few extra accounts in each category, for flexibility.) Depending on the number of accounts, number of sites, and communication delays, it will take anywhere from a few seconds to several minutes for the Account Generation to complete. When it does, a list of accounts will show up in the main Administrator screen, and the numeric entries in the Generate Accounts dialog will be cleared. Once this happens the accounts are generated; press the Close button to close the dialog.
Account Names and Passwords
Each generated account will be created with a password, but at present the default (only available) specification for passwords on newly-generated accounts is "Passwords same as Account Name". This means for example that the password for the account "team1" is "team1"; the password for the account "judge1" is "judge1"; etc. Each account name and password are created with all letters in lowercase.
Passwords for accounts can be changed from their default values by editing each account. To do this, click on the "Manage Accounts" radio button on the Accounts tab of the main Administrator screen, then use the "Account Type" drop-down list to select the type of account you wish to manage (change). For example, the following screen displays the list of Team accounts.
To edit an account, click on the account in the display grid to select it ("team1" has been selected in the display shown above), and then click the "Edit" button. This will display a new "Edit Account" window, shown below:
The "Display Name" for an account is the name which will appear on the PC2 Scoreboard; this can be set to any desired value (such as the name of the teams school, or the team members names). The "Password" and "Verify Password" fields can be used to set any desired password for the account. The "Active" checkbox determines whether the account will be considered in computing the scoreboard standings; if there are some accounts which will not be used then you should uncheck their "Active" checkboxes.
Newly created accounts are automatically distributed throughout the entire system (including across multiple remote sites if there are any in the contest). Note that PC2 accounts are "contest-wide" there is only ONE "Team #1" throughout the contest, regardless of site. Note also that PC2 accounts are unrelated to any user accounts which may otherwise exist on the systems being used for the contest.
Account Logoff
During a contest it is possible (likely, it seems from experience) that a team or judge will somehow manage to kill their PC2 Java VM after having logged in to PC2. This can happen in a variety of ways, such as a total machine crash or a simple inadvertent command to "kill" the "command window" which is running the Java VM (users should be warned not to terminate this command window).
In the event that a user becomes disconnected and/or kills PC2 somehow, they will (eventually) wish to log back in to the system. However, the PC2 server, unaware of the crash on the teams machine, will think they are still "logged in". For security (to prevent teams from acting as "someone else") PC2 refuses to allow multiple logins of the same account. Thus a disconnected user will not be able to log back in.
To solve this, the Accounts tab on the main Administrator screen provides a function to "force a logout" of a currently logged-in account. To invoke the "forced logout" function, click on the "View Logins" button on the Accounts tab, then click on the row in the display showing the user account that needs to be "logged out". This will activate the "Logout" button (see the Accounts tab screen, above). Pressing this button will then force the Server to drop the login connection, allowing that account to re-login.
PC2 must be provided with information about the problem set to be used in the contest. To enter this information, click on the Problems tab at the top of the main Administrator screen. This will produce a display similar to the following:
Note that initially no problems are listed since none have been added to the system. To add a problem, click the Add button. This will produce the following dialog display:
Enter the problem name, data file name (including the full path to it), and the name of the "execution script" which will be run to execute submissions for this problem. Note that the " " buttons can be used to pop up "file dialogs" to search for and select Data files and execution script files. Click the Update button to store the problem information.
Note: as described earlier, every problem must be provided with an "execution script" whose purpose is to tell PC2 how to execute "TEST RUNS" on the Team machine and "JUDGED RUNS" on the Judge machine. These scripts represent the interface between PC2 and the external environment. It is the responsibility of the Contest Administrator to provide correct "scripts" for the environment of the contest. The PC2 distribution contains a set of sample scripts (see the files "v7judge.bat" and "v7judge.sh" in the PC2 "samps" directory), but these must be customized for the specific contest environment. Refer to the section on PC2 Execution Scripts in for further details.
The additional fields on the Edit Problem dialog Scoring Type, Problem Description File, Go through Chief Judge, Problem Categories, and all the fields in the rightmost column of the dialog are for support of "subjective judging" capabilities in PC2; they should not be used unless you are configuring a contest where subjective judging will be used.
[Note in particular that the "Chief Judge" module of PC2 is intended only for support of "subjective judging". It is NOT intended to be used in a traditional contest where Judges return either a "YES" or "NO" response to teams. Do NOT use the Chief Judge module unless you are trying to run a contest supporting "subjective judging" of problems. It is not intended for use in a traditional contest.]
As each set of contest problem information is entered, it will be displayed on the main Administrator screen (when the Problems tab has been selected). To change some previously entered information for a problem, click on the problem row in the main display to select it, then click the Edit button. This will return to the Edit Problem dialog, where changes can be made.
PC2 must be provided with information about the programming languages used by contestants (Teams). To enter this information, click the Languages tab on main Administrator screen. This will bring up a display similar to the following:
Note that the display is empty because no languages have been defined yet. To add a language description, click the Add button. This will bring up a dialog similar to the following:
To define a language, enter both a "Name used in script" and a "Display Name" for the language. The "Display Name" for a language is an arbitrary string which is displayed on Team and Judge displays when a user selects a language. For example, the display name might be "GNU gcc Compiler" or "IBM VisualAge for Java". The Display Name is not used to invoke anything; it is merely used in human-readable displays.
The "Name used in script" is a CASE-SENSITIVE string which is used to uniquely identify each language in the contest. When a team chooses a language from the "Display Name" language list and then submits a (Test or Judged) run, the "Name used in script" corresponding to the chosen language is passed by PC2 to the execution script to identify the language for the run. For example, the script might expect to be passed the string "gcc" when a program is to be compiled using the GNU GCC compiler. The values entered for "Name used in script" for each language can be any string, as long as they match the string expected by the execution script for the corresponding language. See the section on PC2 Execution Scripts for more details.
Once the names for a language have been entered, click the Update button to store the information and return to the main Administrator screen. The language names will be displayed under the Languages tab on the main Administrator screen. To add more languages, click the Add button again to return to the Edit Languages screen. To modify a previously-entered language, click on the row containing the language description to select it and then click the Edit button.
On the main Administrator screen the "Display name" is displayed in the column titled "Long Name"; the "Name used in script" is displayed in the column titled "Short name".
The main Administrator screen contains several additional tabs which can be used to display and/or control various aspects of a contest. These are listed and described below.
Options
This tab can be used to access the "Options" display screen, which allows the Contest Administrator to select various contest configuration options. Currently the only supported (activated) option is "Show Team Numbers to Judges?". The default value for this option is "YES", which means that Judges will be able to see the Team number associated with runs as they are judging them. Selecting "NO" will hide the Team number from the Judges. (Some Contest Administrators prefer the extra assurance of impartiality afforded by this option.)
While there are a number of other options shown in the Options dialog, none of the other options have any effect in the current version of PC2; only the "Show Team Numbers to Judges?" option is currently implemented.
Sites
This tab displays a list of all the sites in the contest; this list should be checked to verify that PC2 knows about all sites. If the site is currently active (connected to the rest of the contest) the IP address for that sites server is displayed.
Run Judging Distribution
The Distribution tab on the main Administrator screen is used to control the routing of submitted runs to Judges. For a single site contest, this tab can be ignored.
Clicking this tab produces the following display:
Using this display the Administrator can select, for each specified contest site, which site Judges should see (and hence be able to select and judge) runs from the specified site. For example, in the sample shown above runs submitted by teams at the "Sacramento" site have been designated as going to Judges at both the "Sacramento" and "Houston" sites, but not to Judges (if there are any) at the "Salt Lake City" or "New York" sites. This means that if a team at the Sacramento site submits a run, it will be seen by (and potentially selected and judged by) Judges at the Sacramento site or the Houston site, but not the Salt Lake City or New York sites.
Each site can be chosen for configuration separately by using the "Site" drop-down list on the middle left of the display. The ">>" and "<<" "arrow" buttons are used to move sites between the "available" list (i.e. those sites which exist but are NOT destination sites for runs from the site being configured) and the "destination" list (the list of sites to which runs from the site being configured SHOULD be sent for potential judging). Pressing the Apply button saves the configuration information (and notifies all sites of the destinations to which runs submitted at the site should be forwarded for judging).
Runs
The Runs tab displays a grid showing all the runs which have been submitted so far in the contest (from all teams, at all sites). The run display grid can be sorted on any column by clicking in the column header; clicking multiple times toggles the sort between ascending and descending order. The columns can also be resized by moving the column separators in the header. An example run grid is shown below.
The primary function of this display is to provide the Administrator with the ability to select a run which has already been judged (and hence no longer appears on the Judges grid of available runs) and "give it back to the Judges" so that it may be re-judged. (Note that this assumes an Administrative decision to re-judge a run has been made for some reason; this is not a normal contest operation.)
To give a run back to the Judges, click on the row containing the run to select it, then click the Give button. This will cause the run to appear on the Judges screens so that it can be selected and re-judged. (Note: when a Judge selects a run which has been sent for re-judging, a warning message is displayed on the Judges screen asking for verification that the run really is intended for re-judging.) A run does not disappear from the Administrators grid when it is sent for re-judging; the Administrator always has a complete listing of every run submitted in the contest, from all teams at all sites.
A second purpose of the Runs display is to allow the Administrator to "take a run away" from a Judge. This can be used, for example, to take back a run which was given in error to the Judges for re-judging. Any time there is a run on the Judges display grid which should not be there (because it has already been judged and is not intended to be re-judged, for example), click on the run in the Administrators Runs display then click the Take button. This will remove the run from the Judges screens.
Another function of the Runs display is to mark a specific run as "Deleted". Deleted runs do not actually get removed from the database (nor from the Runs display), but they are marked in such a way that the scoring algorithms ignore them completely in determining contest standings. This allows the Administrator to make decisions regarding unanticipated situations where a run was submitted by a team but should not be counted.
Clars
The Clars tab displays a grid showing all the Clarification Requests which have been submitted so far in the contest (from all teams, at all sites), in a format similar to the Runs grid. Like the Run grid, the Clarification Request grid can be sorted and resized by manipulating the columns headers. The "Give" and "Take" functions are not implemented for Clars in the present version of PC2.
Time/Reset
The Time/Reset tab on the main Administrator screen is used to control the contest clock display and to start and stop the contest. See the description under Starting the Contest, below.
Startup Status
The Startup Status tab on the main Administrator screen is used to track the status of Teams once a contest has been started. This is particularly useful during a "practice contest" held just prior to a real contest; it allows the Contest Administrator to verify that all teams have been able to login and use the basic PC2 functions successfully.
A sample Startup Status screen is shown below. Initially all teams are displayed in RED, indicated that the team has not made any contact with the PC2 server. When a team logs in, their display changes to YELLOW; when they have submitted at least one run or clarification request their display changes to MAGENTA or BLUE respectively; once a team has successfully submitted both a run and a clarification the display changes to GREEN, indicating the team has successfully performed all the basic PC2 functions and should be ready to use the system in the real contest.
It is important to note that the Startup Status display contents are based on the state of the PC2 system when the Administrator Client is started. In particular, this means that if the Administrator is started and then used to create PC2 accounts, those accounts will not appear in the Startup Status display until the Administrator Client exits and then logs back in. Also, if a team logs in and then the Admin is exited and restarted, that login status will not be reflected in the Startup Status screen (i.e., the Startup Status screen does not retain state across Admin login sessions). In this latter case, however, the team status will update correctly as soon as the team performs any of the specified PC2 functions.
These anomalies should be corrected in the next release of PC2. Meanwhile, the appropriate way to take advantage of the Startup Status screen is to first start the Admin and create all team accounts, then log the Admin out and back in before any Teams are allowed to log in. As long as the Admin then remains running during the contest the Startup Status screen will correctly reflect the status of teams.
Reports
The Reports tab on the main Administrator screen provides a variety of options for generating statistical reports about a contest, both during and after the contest. Details of the Reports capabilities are given in the Appendices.
Starting the Contest
The Time/Reset tab on the main Administrator screen is used to control the contest clock display and to Start/Stop the contest. Clicking the Time/Reset tab produces the screen shown below:
The Set Contest Times button displays a screen which allows the Administrator to change the contest length to something other than the default length (5 hours). Pressing the Refresh Time button updates the "Remaining Time" display on the screen.
Note that the "Remaining Time" display does NOT update automatically; it requires a manual refresh operation. However, this does NOT affect the internal clock operations in PC2; run submission times are not based on the Admin "contest clock" but rather on "elapsed time since the contest was started" . It is also the case that the "Remaining Time" has no actual effect on the Contest; nothing happens in PC2 when this value reaches zero it is primarily a convenience display. (Hopefully in the next release of PC2 it will be more convenient by updating automatically J )
Once PC2 has been fully configured, the contest must be "started" before teams can submit runs (the Team Client will not accept run submissions . The Start Contest Time button on the Admin Time/Reset tab is used to tell PC2 to start the contest clock for the current site. The current site name is shown in the title bar. To start every site that is active (use the Admin Site tab to determine which sites are active/have IPs) click the Start All Sites button.
PC2 Scoreboard
PC2 contains a separate "Scoreboard" module which is used to keep track of the current standings in a contest. The Scoreboard, like the Team, Judge, and Admin, is a PC2 "Client", so to start a Scoreboard go to a command prompt and type the command
java pc2.Client.Client
Once the Client login window appears, enter a Scoreboard account name ("board1", "board2", etc.) and password as defined when PC2 accounts were created using the Admin. This will bring up the following Scoreboard display window:
Initially (as shown above) the scoreboard display will be empty, and the "Last Update" field will indicate "Never", meaning there have been no changes in the contest state since the contest was started (or restarted). As soon as any change occurs in the state of the contest the scoreboard will automatically update showing all the "active" teams, including their Rank, Name, Number of Problems Solved, and "Score" (Penalty Points accrued). The "Last Update" field will also be updated to show the time of the latest update.
The algorithm used in PC2 to compute Rank and "Score" (Penalty Points) is the one used in the ACM ICPC World Finals, which is as follows:
HTML Scoreboard
The standard PC2 scoreboard shown above can be used as the official contest scoreboard if desired. However, PC2 also generates a set of HTML files giving various levels of detail regarding the current contest status. These files are regenerated each time the scoreboard status changes, which occurs dynamically as the contest progresses. The Scoreboard HTML files are placed in the html directory beneath the PC2 installation directory.
The most common way to take advantage of the HTML scoreboard files is to run only a single PC2 Scoreboard module whose only purpose is to generate the HTML files, and then to run a separate external process (e.g. a batch script) which repeatedly copies the current PC2 HTML scoreboard files to some external location, reformats them in any desired way, and makes them available to teams and spectators using a standard browser.
There are several advantages to this method of operation. First, the PC2 HTML scoreboard files contain more information than what is shown on the standard PC2 scoreboard. (For example, one of the files displays a grid showing which teams have submitted runs for which problems and whether the team has solved the problem or not.) Second, the details of the appearance of the scoreboard can be customized by the Contest Administrator external to PC2. Thus the Contest Administrator can choose to take advantage of the additional scoreboard screens, or can choose to omit some or all of them. Finally, it is not necessary for teams, judges, spectators, etc. to run separate PC2 scoreboards, since most users will already have access to a browser. The Contest Administrator can arrange that the external scoreboard script builds the desired scoreboard display and puts the resulting HTML in a standard public location accessible to all users browsers.
The PC2 Scoreboard module generates as collection of HTML files in the html directory. Each file is a complete stand-alone HTML document (i.e. is bracketed by <html> </html>) and contains a <body> with an imbedded <table>. The information outside the <table> can be replaced as desired, for example by a header file giving the Contest Title, date, etc. (the Scoreboard generates a sample header file named header.sam in the PC2 installation directory which can be used as a guide).
The following HTML files are always generated (unless there is a pc2v7.ini entry to disable them):
Appendix 1 Java Security Policy File
In order to allow PC2 Java code to access various PC2 modules and routines, it is necessary to enable such access in the "Java Security Policy" access control file. If this access control file is not updated properly, you will get "Java access security violation" messages when you try to run a PC2 module.
To provide the appropriate access privileges, update the file "java.policy" under $JAVAHOME/jre/lib/security to include "grant codebase access privileges" for the PC2 installation directory and the files named swing.jar, swingall.jar, and s_mclb.jar in the PC2 installation directory.
For example, if you installed PC2 in a directory named c:\pc2home, then add the following lines to the java.policy file:
grant codeBase "file:/c:/pc2home" { permission java.security.AllPermission; }; grant codeBase "file:/c:/pc2home/swing.jar" { permission java.security.AllPermission; }; grant codeBase "file:/c:/pc2home/swingall.jar" { permission java.security.AllPermission; }; grant codeBase "file:/c:/pc2home/s_mclb.jar" { permission java.security.AllPermission; };
Note that all slashes are "forward", even in a Windows environment.
If you continue to get Java Security Access Violations even after updating the java.policy file, you may not be using the same java.policy file at runtime as the one you edited. This could happen in a variety of ways. For example, one of the things you have to do to run Java is add the $JavaHome/bin directory (for example, c:\jdk1.3\bin, if that's where you installed Java) to your PATH. Under certain conditions in a Microsoft environment, there is a COPY of the Java VM (the program java.exe) automatically placed in a Microsoft system directory (for example, it gets copied to WinNT\System32) during installation of Java. If you have this system directory in your PATH and it is AHEAD of the $JavaHome entry, then the operating system will find and execute this copy of Java instead of the one you installed in $JavaHome.
This copy of java.exe is precisely the same as the one under the Java installation directory, but IT USES A DIFFERENT JAVA.POLICY FILE (it apparently looks for a java.policy file in the "Program Files" directory hierarchy...). Since you probably didn't modify that java.policy file, you'll get a security access violation. To fix this, either find and modify the duplicate java.policy file, or move the $JavaHome entry to the FRONT of your PATH variable.
Amazing but true....
Appendix 2 pc2v7.ini File Entries
The following sections and attributes are defined for "pc2v7.ini" files:
Section |
Attribute |
global |
logfile |
global |
debugLevel |
global |
consoleLevel |
global |
archive |
registry |
logfile |
registry |
debugLevel |
registry |
consoleLevel |
server |
logfile |
server |
debugLevel |
server |
consoleLevel |
server |
site |
client |
logfile |
client |
alt1site |
client |
alt2site |
client |
alt3site |
client |
debugLevel |
client |
consoleLevel |
client |
shellPath |
client |
runCmd |
client |
workdir |
client |
site |
admin |
importdb |
judge |
defaultanswer |
team |
workdir |
board |
printmedals |
board |
printCategories |
board |
teamCategoryLead |
board |
summaryheaderletters |
board |
printfile |
board |
linesperpage |
board |
smtpServer |
board |
balloonEmail |
board |
includeNos |
board |
site + i + Email |
board |
site + i + IncludeNos |
board |
prob + i + Color |
board |
balloonMode |
board |
balloonOnly |
board |
prob + i + Color |
board |
generateHTML |
region |
count |
region |
id + i |
region |
name + i |
The following gives a short description of each of the supported pc2v7.ini entries:
[global]
; specify the Registry's IP (replace with the real IP address)
registry=127.0.0.1:2005
; debuglevel controls what gets printed to the logs, default = 2
debugLevel=13
; consolelevel controls what gets printed to the console, default = debugLevel
;consoleLevel=13
; global override for new OSes
;client.osname
; log file for messages in pc2.Client.Client
;logfile=pc2.log
; single command replacement for file viewer
;viewer=
; zip filename for ZipPC2, defaults to [server].site then [client].site
; then pc2archive
;archive=
[registry]
; Registry control of what gets printed to the logs
;debugLevel=2
; Registry control of what gets printed to the console
;consoleLevel=2
; log file for Registry messages
;logfile=pc2reg.log
[server]
; so the server does not prompt for site information on startup
site=Vancouver
; zip filename for ZipPC2, overrides global
;archive=
[client]
site=Vancouver
; default starting directory for filedialogs
workdir=c:\work
; log file for pc2.Client.Client messages
;logfile=pc2.log
; replaces cmdline[0] of exec string
;client.shellPath
; broken in v7.6, should replace cmdline[1] of exec string
;client.runCmd
; client override for new OSes
;client.osname
; alternate sites
; accessed using -alt or -alt1 arguments to Client
;alt1.site=Hawaii
; accessed using -alt2 arguement to Client
;alt2.site=Florida
; accessed using -alt3 arguement to Client
;alt3.site=Eindhoven
; client control of what gets printed to the logs
;debugLevel=2
; client control of what gets printed to the console
;consoleLevel=2
[admin]
; include "import" button on Accounts page, to import Bill's tab files
importdb=true
;only referenced on judge
[judge]
; one line answer for Judge's "Default Answer"
;defaultanswer=No Response, read problem statement.
;only referenced on team
[team]
; team default directory for dialogs
workdir=c:\work
;only referenced on scoreboard
[board]
; generate html files, default = true
;generateHtml=true
; generates full(nums)?X.html for each region
printCategories=true
; generates region.html for the region champions
teamCategoryLead=does not matter
; generate medals(-[gsb])?.html files
printmedals=true
; ballon mode settings
balloonmode=true
;balloonOnly=false
; balloon print settings
printfile=lpt1linesperpage=61
; or ballon mail settings
; global email address
;balloonemail=nobody@ecs.csus.edu
; who to send mail thru
;smtpserver=localhost
; colors, also used by reports/admin
prob1color=yellow
prob2color=green
prob3color=blue
prob4color=purple
prob5color=red
prob6color=orange
prob7color=white
prob8color=blue
; global send No balloon messages
;includeNos=yes
; per site send No balloon messages
;include1Nos=no
; per site email addresses
;site1email=nobody@ecs.csus.edu
;only referenced on scoreboard, if [board].teamCategoryLead is set
; static mapping of ACM ICPC PC2_Site.tab entries
[region]
count=6
id1=480
name1=Africa and the Middle East
id2=481
name2=Asia
id3=482
name3=Europe
id4=483
name4=Latin America
id5=484
name5=North America
id6=485
name6=South Pacific
Appendix 3 Sample Execution Scripts
Given below are some examples of execution scripts for PC2 contests. One is Windows-based (MS-DOS) "batch file"; the other is a Unix-based "Bourne shell" script. Note that PC2 determines internally what type of OS it is running under; the Contest Administrator must simply supply an appropriate script for the OS.
Windows Example
rem
rem File: v7judge.bat
rem Purpose: used as execution script (compile and execute) for pc2v7
rem Environment: Windows '95, '98, 'NT
rem Author: pc2@ecs.csus.edu
rem Revised: Sept 2, 2000
rem
rem Parameters:
rem 1: name of file with extension (no path)
rem 2: name of file with no extension
rem 3: language/compiler name
rem 4: problem number
if %3. == java. goto :dojava
if %3. == vaj. goto :dovaj
if %3. == pascal. goto :dopas
if %3. == tcpp. goto :dotcpp
if %3. == cpp. goto :docpp
if %3. == delphi. goto :dodelphi
if %3. == mvc. goto :domvc
echo.
echo Error - Unknown language %3
echo.
echo Usage: v7judge.bat name.ext name lang probnum
echo.
echo Example: v7judge hello.java hello java 1
echo.
goto :End
:dojava
set CLASSPATH=.;c:\java\lib;%CLASSPATH%
PATH=c:\java\bin;%PATH%
echo Compiling Java
javac %1
echo Executing program %2
java %2 > output.
echo program done - starting notepad...
notepad output.
Goto :End
:dovaj
rem Java using package named: solution
set CLASSPATH=.;c:\java\lib;%CLASSPATH%
PATH=c:\java\bin;%PATH%
echo Creating and clearing solution directory
mkdir solution 2> null
move *.java solution
echo Compiling Java
javac solution\%1
echo Executing program solution.%2
java solution.%2 > output.
echo program done - starting notepad...
notepad output.
Goto :End
:dopas
rem Turbo Pascal
echo Compiling Pascal
rem C:\tp\bin\tpc.exe %1
rem c:\turbo\turbo7/tpc.exe %1
tpc.exe %1
echo Executing program
%2.exe > output.
echo program done - starting notepad...
notepad output.
Goto :End
:docpp
rem IBM's VisualAge C++
rem echo target is a.exe
call C:\IBMCPPW40\BIN\setenv.BAT
path=C:\IBMCPPW40\BIN;%path%
rem option link(subsystem, "console")
rem {
rem target "Untitled.exe"
rem {
rem source "..\\tmp\\samps\\HELLO.CPP"
rem }
rem }
echo option link(subsystem, "console") > makefile.icc
echo { >> makefile.icc
echo target "a.exe" >> makefile.icc
echo { >> makefile.icc
echo source "%1" >> makefile.icc
echo } >> makefile.icc
echo } >> makefile.icc
echo Compiling %1 as C or C++
vacbld -noc makefile.icc
erase makefile.icc
echo Executing program...
a.exe > output.
echo program done - starting notepad...
notepad output.
goto End:
:dotcpp
rem Turbo C++
echo Compiling %1 as C or C++
path=%path%;c:\bc5\bin;
path=c:\bc5\bin;%path%;
bcc32 -IC:\BC5\INCLUDE -LC:\BC5\LIB %1
echo Executing program
%2.exe > output.
echo program done - starting notepad...
notepad output.
goto End:
:dodelphi
rem Delphi 4
PATH=%PATH%;"c:\Program Files\BORLAND\Delphi4\BIN"
rem PATH=%PATH%;"c:\Program Files\BORLAND\Delphi4\BIN"
echo Compiling %1 as Pascal
DCC32 %1
echo Executing program: %2
%2 > output.
echo program done - starting notepad...
notepad output.
goto End
:domvc
rem Microsoft Visual C++
echo Compiling Microsoft Visual C++
if exist c:\progra~1\micros~1\nul Path=C:\PROGRA~1\MICROS~1\VB98;C:\PROGRA~1\MICROS~1\VC98\bin;%PATH%
if exist c:\progra~1\micros~2\nul Path=C:\PROGRA~1\MICROS~2\VB98;C:\PROGRA~1\MICROS~2\VC98\bin;%PATH%
if exist C:\PROGRA~1\MICROS~1\VC98\nul set MSVCDir=C:\PROGRA~1\MICROS~1\VC98
if exist C:\PROGRA~1\MICROS~2\VC98\nul set MSVCDir=C:\PROGRA~1\MICROS~2\VC98
set PATH=%MSDevDir%\BIN;%MSVCDir%\BIN;%VSCommonDir%\TOOLS\%VcOsDir%;%VSCommonDir%\TOOLS;%PATH%
set INCLUDE=%MSVCDir%\ATL\INCLUDE;%MSVCDir%\INCLUDE;%MSVCDir%\MFC\INCLUDE;%INCLUDE%
set LIB=%MSVCDir%\LIB;%MSVCDir%\MFC\LIB;%LIB%
cl %1
%2.exe > output.
notepad output.
goto End
:End
rem end of script
Unix Example
#!/bin/sh
#
# vi ts=4:sw=4:ai:ic
#
# File: v7judge.sh
# Purpose: used as juding script (compile and execute) for pc2 v7
# System: CSUS Programming Contest system (pc2)
# Environment: Unix
# Author: pc2@ecs.csus.edu (laned)
# Revised: Wed Oct 6 22:32:43 PDT 1999
#
# Revision 4 - laned
# In order to show what is generated by this script all output lines
# from this script are preceeded by -- in the output file.
# Added check for input file
# Added check for whether executable is generated, if that applies.
# Better messages when fails during compile
#
#
# Parameters:
# 1: name of file with extension (no path) ie. proba.java
# 2: name of file with no extension
# 3: language/compiler name
# 4: problem number
#
# Examples:
# sh v7judge.sh hello.java hello java 1
# sh v7judge.sh hello.c hello cpp 1
#
#
# Name of output file
#
OUTFILE=output
rm -f $OUTFILE
#
# Viewer Command
#
VIEWER="cat "
VIEWER="xterm -e view "
echo "-- Date/time for run: " `date` >> $OUTFILE
if [ "$DISPLAY" = "" ] ; then
echo "Note: DISPLAY environmental variable not set, bummer "
fi
#
# Under pc2 this should never occur, but if hand executed it may
#
if [ "$1" != "" ] ; then
if [ ! -f "$1" ] ; then
echo
echo "-- source file $1 does not exist --" >> $OUTFILE
echo "Script halted, missing source file --" >> $OUTFILE
echo
$VIEWER $OUTFILE
exit 2
fi
fi
#
# Usage
#
if [ "$1" = "" ] ; then
echo "$0 filename basename langname "
echo
echo Compiles filename and runs basename, output to a file named $OUTFILE
echo then displays that file using the following command: $VIEWER
echo
echo Parameters:
echo " filename - name of file with extension (no path) ie. proba.java"
echo " basename - name of file with no extension ie. proba"
echo " langname - language/compiler name (Ex. cc) "
echo
echo Example of usage: sh v7judge.sh hello.java hello java
echo
echo "This script is part of pc2. http://ecs.csus.edu/pc2 or e-mail pc2@ecs.csus.edu"
echo for questions
echo
elif [ "$3" = "perl" ] ; then
echo "-- Output for $1 --" >> $OUTFILE
echo Executing program $1
/usr/bin/perl $1 2>&1 >> $OUTFILE
echo "-- End Output Listing $2 --" >> $OUTFILE
echo program done - starting viewer...
$VIEWER $OUTFILE
elif [ "$3" = "gcc" ] ; then
# There may be many commands for C++
CC=gcc
CC=g++
CCPATH=/usr/bin
# remove target executable
rm -f $2
echo "Compiling $1 using $CC "
echo "-- Compiler listing for $1 using $3 --" >> $OUTFILE
$CCPATH/$CC -o $2 $1 2>&1 >> $OUTFILE
if [ -f ./$2 ] ; then
echo "-- Output for $2 --" >> $OUTFILE
echo Executing program $2
./$2 >> $OUTFILE
else
echo "Compile failed - program $2 not created " >> $OUTFILE
fi
echo "-- End Output Listing $2 --" >> $OUTFILE
echo program done - starting viewer...
$VIEWER $OUTFILE
elif [ "$3" = "cc" ] ; then
CC=cc
CCPATH=/usr/bin
# remove target executable
rm -f $2
echo "Compiling $1 using $CC "
echo "-- Compiler listing for $1 using $3 --" >> $OUTFILE
$CCPATH/$CC -o $2 $1 2>&1 >> $OUTFILE
if [ -f ./$2 ] ; then
echo "-- Output for $2 --" >> $OUTFILE
echo Executing program $2
./$2 >> $OUTFILE
else
echo "Compile failed - program $2 not created " >> $OUTFILE
fi
echo "-- End Output Listing $2 --" >> $OUTFILE
echo program done - starting viewer...
$VIEWER $OUTFILE
elif [ "$3" = "java" ] ; then
echo Compiling Java
JAVAHOME=/usr/jdk1.1.7
JAVAHOME=/usr/jdk_base/
export PATH=PATH:$JAVAHOME/bin:$PATH
export CLASSPATH=.:$JAVAHOME/lib:$CLASSPATH
# remove target executable
rm -f $2.class
echo "Compiling $1 using java"
echo "-- Compiler listing for $1 using $3 --" >> $OUTFILE
javac $1 2>&1 >> $OUTFILE
if [ -f ./$2.class ] ; then
echo "-- Output for $2 --" >> $OUTFILE
echo Executing program $2
java $2 >> $OUTFILE
else
echo "Compile failed - program $2.class not created " >> $OUTFILE
fi
echo "-- End Output Listing $2 --" >> $OUTFILE
echo program done - starting viewer...
$VIEWER $OUTFILE
else
echo "Error - Unknown language $3, contact Contest Staff "
echo "Error - Unknown language $3, contact Contest Staff " > $OUTFILE
$VIEWER $OUTFILE
fi
# end of script
Appendix 4 Registry "Advanced" Dialog Option
The Registry defines the following "Advanced" screen for expert use in systems where it is enabled:
Appendix 5 Reports
The Reports Tab in the Admin Module provides the ability to generate a number of reports that show the current contest status. The Reports screen looks like the following:
The "Report Option" drop-down list allows choosing one of a number of different report formats. Pressing the "Generate" button will generate the selected report and place it in the file named in the "Report File Name" text box. Pressing the "Generate and View" button will generate the selected report and show the output to the user (using notepad in Windows or vi in Unix).
The list of available reports is summarized in the following table:
Option |
Description of report |
-runs |
dump run database |
-all |
dump all probs, team names, langs and run info |
-complete |
same as -all but dumps all reports as well |
-prob |
dump prob definition info |
-clars |
dump all clarification info |
-1 |
submissions by language |
-3 |
number of teams that solved each problem |
-4 |
number of correct and incorrect solutions by problem |
-6 |
summary submissions, solutions, times by team/problem |
-5 |
print summary of who should have balloons (balloon report) |
-7 |
run listing per team by problem |
-8 |
run summary grid |
Revised: 03/15/01 7:34 PM