You can customize the user interface and Job Submit logic by configuring the Job Submit form:

• user interface - You can fully customize the components that are displayed on the page, as well as other display options like the CSS and images shown to the end user.
• logic - You can map UI components to attribute values that should be submitted via the Moab msub command.

Modifying the jobs.xml file that is located in the VIEWPOINT_HOME directory allows you to configure the Job Submit page content, rules, and logic. CSS and images, which may also be customized, are located in the .war file that is distributed with Viewpoint.

Building the Job Submit form is similar to building all other Viewpoint forms, all sharing the common requirement of modification to the <pages>, <components>, and <queue> elements; use the following links and explanations to guide your efforts in configuring these elements:

• <pages> - An element that contains the page layout, describes navigation between pages, specifies which components belong to which sections on which pages, and specifies page validation.
• <components> - An element describing each component and their attributes, as well as any inter-component rules.
• <queue> - An element describing what information is stored in the request queue and how to display such to the user.

7.1.1 Allowing Users to Save and Load Job Forms

You can allow users to save and load form values on the Job Submit page by giving them the appropriate permissions. To allow them to save form values, give them the job.form.create permission. To allow them to load form values, give them the job.form.read permission. If a user has the appropriate permissions, the Save and Load links appear automatically on the Submit Job page. To allow users to read all job forms, give them the job.form.readall permission.

7.1.2 Configuring the Job Submit Request Element

Viewpoint allows you to customize and configure the msub command to match the needs and requirements specific to your site. The rules for creating the msub command are specified in the <request> element of jobs.xml. The child elements of <request> accept string, integer, or boolean deciders. These are the child elements of <request>:

• <account> - This field corresponds to the Account attribute and is the name of account associated with job (accepts any string value decider).
• <additional-attributes> Any additional command line arguments to be appended to the end of the 'msub' request. Each argument should be defined using a <attribute> element. Each child <attribute> element has two parts:
1. <value> (required) - The value of the command line argument. Accepts any string value decider.
2. <condition> (optional) - Accepts any boolean decider. If this is specified, Viewpoint includes the argument only if the condition evalutates to true.
• <apply-hold> - This field corresponds to the Hold attribute and specifies that a user hold be applied to the job at submission time (accepts any boolean value decider).
• <class> - This field corresponds to the Destination Queue (Class) attribute and defines the destination of the job. Moab uses the term Destination Queue for class (accepts any string value decider).
• <error-path> - This field corresponds to the Error Path attribute and defines the path to be used for the standard error stream of the batch job (accepts any string value decider).
• <execution-dir> - This field corresponds to the Execution Directory attribute and is the directory in which the job should execute (accepts any string value decider).
• <generic-resources> This field corresponds to the generic resources attribute. This works only with the table-map component. Here is an example:

  <generic-resource>
    <component id="generic_resource_table_map" />
  </generic-resource>
  

• <job-name> - This field corresponds to the Name attribute and is the user-specified job name (accepts any string value decider).
• <job-script> - This field corresponds to the Job Script attribute. This file accepts any string value decider. Typically, this value is determined from an upload-script component or a write-script component, however, you can hard code the value or determine the value from other means. Here is an example where the job script is determined from either an upload-script component or a write-script component, depending on which option the user had selected:

  <job-script>
   <calculate operation="conditional">
    <option>
     <value>
      <component id="upload-script" />
     </value>
     <condition comparison="equal">
      <first>
       <component id="script-chooser" />
      </first>
      <second>Upload</second>
     </condition>
    </option>
    <option>
     <value>
      <component id="write-script" />
     </value>
     <condition comparison="equal">
      <first>
       <component id="script-chooser" />
      </first>
      <second>Create New</second>
     </condition>
    </option>
   </calculate>
  </job-script>
  
  

• <memory> - This field corresponds to the Resource List attribute and is the maximum amount of physical memory used by the job (accepts any integer value decider).
• <node-count> - This field corresponds to the Resource List attribute and is the number of nodes to be reserved for exclusive use by the job (accepts any integer value decider).
• <node-features> - The list of node features the job requires (accepts any string list value decider).
• <operating-system> - The administrator defined operating system (accepts any string value decider).
• <output-path> - This field corresponds to the Output Path attribute and defines the path to be used for the standard output stream of the batch job (accepts any string value decider).
• <partition> - The required partition (accepts any string value decider).
• <preemptible> - The job is a preemptee and therefore can be preempted by other jobs (accepts any boolean value decider).
• <priority> - This is the priority of the job (accepts any integer value decider). Normally, this is between -1024 and 0.
• <proc-count> - This field corresponds to the Resource List attribute and is the number of processors per node requested (accepts any integer value decider).
• <qos> - The Quality of Service associated with job (accepts any string value decider).
• <restartable> - This field corresponds to the Rerunable attribute and declares whether the job is rerunable (accepts any boolean value decider).
• <swap> - The maximum amount of virtual memory used by all concurrent processes in the job in MB which is the amount of swap disk required by job (accepts any integer value decider).
• <variables> A collection of variables to be set on the job. This can have one or more <variable> child elements. Each child <variable> element has a minimum of two parts:
1. <key> (required) - The name of the variable and accepts any string decider.
2. <value> (required) - The value of the variable and accepts any string decider.
3. <rule> (optional) - Accepts any boolean decider. If this is specified, Viewpoint includes the variable only if the rule evaluates to true.
• <vm-usage> The environment in which the job will be run. This value must be one of the following:
  • requirepm - The job runs on a physical machine.
  • prefpm - The job runs on a physical machine, if possible; if not, it runs on a virtual machine.
  • createvm - The job creates a virtual machine on which to run. The newly-created VM is destroyed upon job completion.
  • createpersistentvm - The job creates a virtual machine on which to run, but the newly-created VM persists after job completion.
  • requirevm - The job does not run until a virtual machine is available on which it can run.
  • prefvm - The job runs on a virtual machine, if possible; if not, it runs on a physical machine.
• <wall-time> - This field corresponds to the Resource List attribute and is the maximum amount of real time during which the job can be in the running state in seconds (accepts any string integer decider).

7.1.3 Enable Submit Multiple Jobs

You can configure the Job Submit page to allow for multiple jobs to be submitted on each submit request. Since the <request> element does not support different requirements, the queue element will store all components on the form. There is no need to specify a <requirement-data> element in the XML configuration. See Configuring the Queue Element for more information.

The following is an example of a queue configured in jobs.xml that would enable multiple jobs to be submitted:

<queue name="Your Job Request">
 <queue-item>
  <title>
   <description>Job:</description>
    <component id="job-name" />
  </title>
  <row order="1" required="true">
    <description>Resources</description>
    <calculate operation="append-in-order">
     <value order="1">
      <component id="nodeCount" />
     </value>
     <value order="2"> Nodes, </value>
     <value order="3">
      <component id="procCount" />
     </value>
     <value order="4"> PPN</value>
    </calculate>
   </row>
   <row order="2" type="dynamic" source="storage-list">
    <description>Storage:</description>
    <component id="storage-list" />
   </row>
  </queue-item>
 </queue>

Once the queue is configured, users will see the job queue on the right side of the Submit Job form.