Commands - msub
Moab Workload Manager®

msub

(Moab Job Submit)

Synopsis

msub  [-a datetime][-A account][-c interval][-C directive_prefix][-d path]
      [-e path][-h][-j join][-k keep][-l resourcelist][-m mailoptions]
      [-M user_list][-N name][-o path][-p priority][-q destination][-r]
      [-S pathlist][-u userlist][-v variablelist][-V][-W additionalattributes]
      [-z][script]

Overview

msub allows users to submit jobs directly to Moab.  When a job is submitted directly to a resource manager (like TORQUE), it is constrained to run on only those nodes that the resource manager is directly monitoring.  In many instances, a site may be controlling multiple resource managers.  When a job is submitted to Moab rather than to a specific resource manager, it is not constrained as to what nodes it be be executed on.  msub can accept command line arguments (with the same syntax as qsub), job scripts (in either PBS or LoadLeveler syntax), or the SSS Job XML specification.

Submitted jobs can then be viewed and controlled via the mjobctl command.

Access

When Moab is configured to run as root, any user may submit jobs via msub.

Format

Flag Name Format Default Description Example
-a Eligible Date
[[[[CC]YY]MM]DD]hhmm[.SS]
---
Declares the time after which the job is eligible for execution
msub -a
> msub -a 12041300 cmd.pbs
Moab will not schedule the job until 1:00 pm on December 4, of the current year
-A Account
<ACCOUNT NAME>
---
Defines the account associated with the job
msub -A research cmd.pbs

(Moab will associate this job with account research)
-c Checkpoint Interval
[n|s|c|c=<minutes>]
---
Checkpoint of the will occur at the specified interval
n - No Checkpoint is to be performed
s - Checkpointing is to be performed only when the server executing the job is shutdown
c - Checkpoint is to be performed at the default minimum time for the server executing the job
c=<minutes> - Checkpoint is to be performed at an interval of minutes
msub -c=12 cmd.pbs

(the job will be checkpointed every 12 minutes)
-C Directive Prefix
'<PREFIX NAME>'
First known prefix
(#PBS, #@, #BSUB, #!,
#MOAB, #MSUB)
Specifies which directive prefix should be used from a job script
  • It is best to submit with single quotes. '#PBS'
  • An empty prefix will cause Moab to not search for any prefix. -C ''
  • Command line arguments have precedence over script arguments.
  • Custom prefixes can be used with the -C flag. -C '#MYPREFIX'
  • Custom directive prefixes must use PBS syntax.
  • If the -C flag is not given, Moab will take the first default prefix found. Once a directive is found, others are ignored.
msub -C '#MYPREFIX' cmd.pbs

#MYPREFIX -l walltime=5:00:00 (in cmd.pbs)

(Moab will use the #MYPREFIX directive specified in cmd.pbs, setting the wallclock limit to five hours)
-d Execution Directory
<path>
$HOME
Specifies in which directory the job should begin executing
msub -d /home/test/job12 cmd.pbs

(the job will begin execution in the specified directory)
-e Error Path
[<hostname>:]<path>
$SUBMISSIONDIR/$JOBNAME.e$JOBID
Defines the path to be used for the standard error stream of the batch job
msub -e test12/stderr.txt

(the stderr stream of the job will be placed in the relative (to execution) directory specified)
-h Hold
N/A
---
Specifies that a user hold be applied to the job at submission time
msub -h cmd.ll

(the job will be submitted with a user hold on it)
-j Join
[oe|n]
n (not merged)
Declares if the standard error stream of the job will be merged with the standard output stream of the job. If "oe" is specified, the error and output streams will be merged into the output stream.
msub -j oe cmd.sh

(the stdout and stderr will be merged into one file)
-k Keep
[e|o|eo|oe|n]
n (not retained)
Defines which (if either) of output and error streams will be retained on the execution host (overrides path for stream)
msub -k oe

(stdout and stderr for the job will be retained on the execution host)
-l Resource List
<STRING>
(either standard PBS/TORQUE options or resource manager extensions)
---
Defines the resources that are required by the job and establishes a limit to the amount of resource that can be consumed.  Either resources native to the resource manager (see PBS/TORQUE resources) or scheduler resource manager extensions may be specified
msub -l
> msub -l nodes=32:ppn=2,pmem=1800mb,walltime=3600 cmd.sh
the job requires 32 nodes with 2 processors each, 1800mb per task and a walltime of 3600 seconds
-m Mail Options
[[n]|[a][b][e]]
a
Defines the set of conditions (abort,begin,end) when the server will send a mail message about the job to the user
msub -m
> msub -m be cmd.sh
mail notifications will be sent when the job begins and ends
-M Mail List
<user>[@<host>][,<user>[@<host>],...]
$JOBOWNER
Specifies the list of users to whom mail is sent by the execution server
msub -M jon@node01,bill@node01,jill@node02 cmd.sh

(mail will be sent to the specified users if the job is aborted)
-N Name
<string>
STDIN or name of job script Specifies the user-specified job name attribute
msub -N chemjob3 cmd.sh

(job will be associated with the name chemjob3)
-o Output Path
[<hostname>:]<path>
$SUBMISSIONDIR/$JOBNAME.o$JOBID
Defines the path to be used for the standard output stream of the batch job
msub -o test12/stdout.txt

(the stdout stream of the job will be placed in the relative (to execution) directory specified)
-p Priority
<INTEGER> (between -1024 and 0)
0
Defines the priority of the job
To enable priority range from -1024 to +1023, see ENABLEPOSUSERPRIORITY
msub -p 25 cmd.sh

(the job will have a user priority of 25)
-q Destination Queue (Class)
[<queue>][@<server>]
[<DEFAULT>]
Defines the destination of the job
msub -q priority cmd.sh

(the job will be submitted to the priority queue)
-r Rerunable
[y|n]
y
Declares whether the job is rerunable
msub -r n cmd.sh

(the job cannot be rerun)
-S Shell Path
<path>[@<host>][,<path>[@<host>],...]
$SHELL
Declares the shell that interprets the job script
msub -S /bin/bash

(the job script will be interpreted by the /bin/bash shell)
-u User List
<user>[@<host>[,<user>[@<host>],...]
UID of msub command
Defines the user name under which the job is to run on the execution system
msub -u bill@node01 cmd.sh

(on node01 the job will run under bill's UID - if permitted)
-v Variable List
<string>[,<string>,...]
---
Expands the list the environment variables that are exported to the job (taken from the msub command environment)
mrsvctl -v DEBUG cmd.sh

(the DEBUG environment variable will be defined for the job)
-V All Variables
N/A
N/A
Declares that all environment variables in the msub environment are exported to the batch job
msub -V cmd.sh

(all environment variables will be exported to the job)
-W Additional Attributes
<string>
---
Allows the for the specification of additional job attributes (See Resource Manager Extension)
msub -W x=GRES:matlab:1 cmd.sh

(the job requires one resource of "matlab")
-z Silent Mode
N/A
N/A
the job's identifier will not be printed to stdout upon submission
msub -z cmd.sh

(no job identifier will be printout the stdout upon successful submission)

Job Script

   The msub command supports job scripts written in any one of the following languages:

Language Notes
PBS/TORQUE Job Submission Language ---
LoadLeveler Job Submission Language Use the INSTANTSTAGE parameter as only a subset of the command file keywords are interpreted by Moab.
SSS XML Job Object Specification ---
LSF Job Submission Language enabled in Moab 4.2.4 and higher

/etc/msubrc

  Sites that wish to automatically add parameters to every job submission can populate the file '/etc/msubrc' with global parameters that every job submission will inherit.   For example, if a site wished every job to request a particular generic resource they could use the following /etc/msubrc:

/etc/msubrc
-W x=GRES:matlab:2

Usage Notes

   msub is designed to be as flexible as possible, allowing users accustomed to PBS, LSF, or LoadLeveler syntax, to continue submitting jobs as they normally would.  It is not recommended that different styles be mixed together in the same msub command.

   When only one resource manager is configured inside of Moab, all jobs are immediately staged to the only resource manager available.  However, when multiple resource managers are configured Moab will determine which resource manager can run the job soonest.  Once this has been determined, Moab will stage the job to the resource manager.

   It is possible to have Moab take a "best effort" approach at submission time using the forward flag.  When this flag is specified, Moab will do a quick check and make an intelligent guess as to which resource manager can run the job soonest and then immediately stage the job.

   Moab can be configured to instantly stage a job to the underlying resource manager (like TORQUE/LOADLEVELER) through the parameter INSTANTSTAGE.  When set inside moab.cfg, Moab will migrate the job instantly to an appropriate resource manager.  Once migrated, Moab will destroy all knowledge of the job and refresh itself based on the informat ion given to it from the underlying resource manager.

   In most instances Moab can determine what syntax style the job belongs to (PBS or LoadLeveler); if Moab is unable to make a guess, it will default the style to whatever resource manager was configured at compile time.  If LoadLeveler and PBS were both compiled then LoadLeveler takes precedence.

   Moab can translate a subset of job attributes from one syntax to another.  It is therefore possible to submit a PBS style job to a LoadLeveler resource manager, and vice versa, though not all job attributes will be translated.

Example 1

> msub -l nodes=3:ppn=2,walltime=1:00:00,pmem=100kb script2.pbs.cmd

4364.orion 

See Also