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.
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
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)
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
the job requires 32 nodes with 2 processors each, 1800mb per task and a walltime of 3600 seconds
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:
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.