California State University, Sacramento’s

 

PC2

Version 7.6

 

 

Contest Administrator’s

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 …………………………………………. 32

3. 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.

  1. Install the Java Development Kit (JDK) or Java Runtime Environment (JRE), version 1.2.2 or later on each machine. The remainder of this Guide assumes that "$JAVAHOME" represents the JDK installation directory. For information on obtaining the JDK, visit http://www.javasoft.com.
  2. Add "$JAVAHOME/bin" directory to the PATH environment variable on each machine (i.e., for each user).
  3. Add "." (‘the current directory’) and "$JAVAHOME/lib" to the CLASSPATH environment variable on each machine. (Note: the JRE does not use the CLASSPATH variable; when using JRE instead of JDK it is necessary to use the "-cp" parameter. See the JRE documentation for details.)
  4. Create a directory on each machine to house the PC2 system. The remainder of this Guide assumes that "$PC2HOME" represents the PC2 installation directory.
  5. Copy the pc2v76.zip (or gzip) file into the $PC2HOME directory.
  6. Unzip the pc2v76.zip file, being sure to tell the unzip program to "retain directory hierarchy" and "preserve case sensitivity". This should create directories named "pc2", housing the PC2 system, and "COM", housing the IBM common Java facilities. It should also create several ".ini", ".bat", ".sh", and ".jar" files.
  7. Add the "$PC2HOME" directory to the PATH environment variable on each machine (i.e., for each user).
  8. Add the directories "$PC2HOME", "$PC2HOME/swing.jar" and "$PC2HOME/s_mclb.jar" to the CLASSPATH environment variable on each machine.
  9. Modify the Java "Security Policy" file $JAVAHOME/jre/lib/security/java.policy to allow "all access" for the directories "$PC2HOME", "$PC2HOME/swing.jar" and "$PC2HOME/s_mclb.jar" (see the Appendices for an example of the lines which must be added to the Java Security Policy file for this step).

 

 

 

 

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 Judge’s 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 Judge’s 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

  1. Registry
  2. 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 Registry’s 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 Registry’s 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.

  3. Server
  4. 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 Server’s 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 Server’s 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 Server’s 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 Server’s 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 site’s 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.

     

     

  5. Clients

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 site’s 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 Client’s pc2v7.ini file, the progress of these steps will be displayed and/or written to the file pc2.log in the Client’s startup directory.

 

If any errors occur or the Client fails to produce the login screen, check the "pc2.log" file for details.

 

 

Contest Configuration

  1. Accounts
  2. 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 Registry’s "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 team’s school, or the team member’s 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 team’s 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.

  3. Contest Problems
  4. 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.

     

  5. Contest Languages
  6. 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".

     

  7. Additional Administrative Functions

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 site’s 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 Judge’s 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 Judge’s 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 Judge’s screen asking for verification that the run really is intended for re-judging.) A run does not disappear from the Administrator’s 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 Judge’s 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 Administrator’s Runs display then click the Take button. This will remove the run from the Judge’s 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:

    1. Teams are ranked according to the number of problems solved; a team solving more problems is always ranked higher than a team solving fewer problems.
    2. Within a group of teams solving the same number of problems, teams are ranked by increasing "Penalty Points" (that is, the team with the lowest number of Penalty Points is ranked highest within the group). Teams only accrue Penalty Points for problems which have been solved; unsolved problems do not affect the scoring in any way. Teams accrue Penalty Points for solved problems in two ways:

 

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 user’s 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