Job Templates
Home Up Previous Next Moab Workload Manager®

11.10 Job Templates

11.10.1 Job Template Overview

Job templates are used for two primary purposes: (1) to provide a means of generically matching and categorizing jobs, and (2) to provide a means of setting arbitrary default or forced attributes for certain jobs. Job templates can be used in many aspects of scheduling but they are most commonly applied in the areas of Dynamic Jobs and Peer Based Grid usage policies. Job templates are defined using the JOBCFG configuration parameter.

11.10.2 Applying Job Templates

11.10.2.1 Matching

The JOBMATCHCFG parameter allows relationships to be established between a number of job templates. JMAX and JMIN function as filters to determine whether a job is eligible for a subsequent template to be applied to the job. If a job is eligible, JDEF and JSET templates apply attributes to the job. The table in section 11.10.3 Job Template Extension Attributes indicates which job template types are compatible with which job template extension attributes. The following types of templates can be specified with the JOBMATCHCFG parameter:

Attribute Description
JMAX A potential job is rejected if it has matching attributes set or has resource requests that exceed those specified in this template.
JMIN A potential job is rejected if it does not have matching attributes set or has resource requests that do not meet or exceed those specified in this template.
JDEF A matching job has the specified attributes set as defaults but all values can be overridden by the user if the matching attribute is explicitly set at job submission time.
JSET A matching job has the specified attributes forced to these values and these values override any values specified by the submittor at job submission time.
JSTAT A matching job has its usage statistics reported into this template.

Note For JMAX, a job template can specify only positive non-zero numbers as maximum limits for generic resources. If a job requests a generic resource that is not limited by the template, then the template can still be used. 

# limit all users to a total of two non-interactive jobs

USERCFG[DEFAULT]  MAXJOB=2

# reservation configuration

SRCFG[test] DESCRIPTION="compute pool for interactive and short duration jobs"
SRCFG[test] JOBATTRLIST=INTERACTIVE
SRCFG[test] MAXTIME=1:00:00
SRCFG[test] HOSTLIST=R:atl[16-63]

# job template configuration

JOBCFG[inter.min] FLAGS=interactive
JOBCFG[inter.set] FLAGS=ignpolicies REQRSV=test

JOBMATCHCFG[interactive] JMIN=inter.min JSET=inter.set

In the preceding example, a reservation called test is created. This reservation is only accessible by interactive jobs and jobs that will take less than one hour to complete. Specifying MAXJOB=2 means that each user on the system is only allowed to run two jobs simultaneously.

The job template configuration is signified by the JOBCFG parameter. The inter.min template (JMIN) determines that if a job is marked as interactive it is eligible to have inter.set template applied to it. The JOBMATCHCFG parameter establishes the relationship between inter.min and inter.set. The inter.set template forces the ignpolicies flag on the job, which allows the job to ignore the MAXJOB policy. Also, the job automatically requests the reservation named test. Any user submitting a job may have as many interactive jobs running as resources permit, and the job runs inside the test reservation, which constrains the jobs to run on nodes at1[16-63]. With this template, users do not need to know to which nodes to send interactive jobs; Moab automatically sends interactive jobs to the nodes specified in the reservation.

11.10.2.2 Selecting

Rather than matching a job automatically based on job attributes, a specific template can be directly requested by setting the SELECT attribute to TRUE. Attributes specified in the job template are applied to the job.

JOBCFG[inter.set] FLAGS=ignpolicies REQRSV=test SELECT=true

In the preceding example, instead of the interactive jobs automatically going to the reservation named test (as in the Matching example), users can request the inter.set template for the ignpolicies flag and the requested reservation test to be applied to the job.

Use the following to request the job template:

msub -l template=inter.set myjob.sh

Selecting a specific reservation is often used in creating workflows. See 11.10.7 Creating Workflows with Job Templates for more information.

11.10.3 Job Template Extension Attributes

When creating a job template, any attribute acceptable within the WIKI workload query data format can be used. In addition, job templates can use any of the extension attributes in the following table. Note that a checkmark in the Template Type (JMIN, JMAX, JDEF, JSET) row indicates compatibility with the associated attribute.

ACCOUNT
Format: <ACCOUNT>[,<ACCOUNT>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: Account credentials associated with job. Used in job template matching.
Example: 
JOBCFG[public]      FLAGS=preemptee
JOBCFG[public.min]  ACCOUNT=public_acct
JOBMATCHCFG[public] JMIN=public.min JSET=public
   
ACTION
Format: HOLD or CANCEL
Template
Type:
JMIN JMAX JDEF JSET
      Yes
Description: Describes an action that is done to the job if the set template is applied.
Example: 
JOBCFG[test.min] QOS=high
JOBCFG[test.set] ACTION=CANCEL
JOBMATCHCFG[test] JMIN=test.min JSET=test.set
   
ALLOCSIZE
Format: <ALLOCSIZE>[,<DEALLOCSIZE>]
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Number of application tasks to allocate/deallocate at each allocation adjustment.
Example: 
JOBCFG[webdb] ALLOCSIZE=4
   
ALLOCDELAY
Format:
[[[DD]:HH]:MM]:SS
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description:
The amount of time to wait before trying to allocate a new resource. When you have a dynamic service job—ones that grow and shrink—ALLOCDELAY is the minimum amount of time Moab waits before allowing a change to the size of the service job. The size of the job should not change too quickly, so ALLOCDELAY specifies an amount of time that must elapse before another size change can occur.
Example: 
JOBCFG[webdb] ALLOCDELAY=1:00
   
ALLOCSYNCTIME
Format: [[[DD]:HH]:MM]:SS
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Time indicating maximum duration Moab waits before forcing allocation decisions via provisioning or other steps.

Note By default, when deallocating resources, Moab does not reassign resources from one service to another until the service/job initially assigned the resources reports successful de-allocation via the workload query response.
Example: 
JOBCFG[webdb]  ALLOCSYNCTIME=00:04:00
JOBCFG[sirius] ALLOCSYNCTIME=00:00:20

Moab forces the deallocation of resources assigned to webdb if the application does not release them within four minutes of a deallocation request. For the sirius application, Moab forces deallocation if not released by the application within twenty seconds of a deallocation request.
   
CLASS
Format:
<CLASS>[,<CLASS>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: Class credentials associated with job. Used in job template matching.
Example: 
JOBCFG[night]      FLAGS=preemptor
JOBCFG[night.min]  CLASS=night_class
JOBMATCHCFG[night] JMIN=night.min JSET=night
   
CPULIMIT
Format:
[[[DD]:HH]:MM]:SS
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description:
Maximum amount of CPU time used by all processes in the job.
Example: 
JOBCFG[job.min]  CPULIMIT=1:00:00:00
JOBCFG[job.max]  CPULIMIT=2:00:00:00
   
DESCRIPTION
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Description of the job.
Example: 
JOBCFG[webdb] DESCRIPTION="Template job"
   
DPROCS
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes   Yes
Description: Number of processors dedicated per task. Default is 1.
Example: 
JOBCFG[job.min]  DPROCS=2
JOBCFG[job.max]  DPROCS=4
   
EUSER
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: In a job template, EUSER is the effective user, meaning that when a job starts it will change the user running the job to the one on the template.
Example: 
JOBCFG[batch]    EUSER=render
   
FLAGS
Format: <JOBFLAG>[,<JOBFLAG>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: One or more legal job flag values.
Example: 
JOBCFG[webdb] FLAGS=NORMSTART
   
GNAME
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
      Yes
Description: Group credential associated with job.
Example: 
JOBCFG[webserv] GNAME=service

Note For matching the group, see the GROUP attribute.

   
GRES
Format: <generic resource>[:<COUNT>]
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Consumable generic attributes associated with individual nodes or the special pseudo-node global, which provides shared cluster (floating) consumable resources. Use the NODECFG parameter to configure such resources.
Example: 
JOBCFG[gres.set] GRES=abaqus:2

In this example, the gres.set template applies two Abaqus licenses per task to a matched job.
   
GROUP
Format: <GROUP>[,<GROUP>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: Group credentials associated with job. Used in job template matching.
Example: 
JOBCFG[webserv] GROUP=service

Note For setting the group, see the GNAME attribute.

   
MEM
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: Maximum amount of physical memory per task used by the job. See Requesting Resources for more information.
Example: 
JOBCFG[smalljobs] MEM=25
   
NODEACCESSPOLICY
Format: One of the following: SHARED, SHAREDONLY, SINGLEJOB, SINGLETASK , SINGLEUSER, or UNIQUEUSER
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Specifies how node resources will be shared by a job. See the Node Access Overview for more information.
Example: 
JOBCFG[serverapp] NODEACCESSPOLICY=SINGLEJOB
   
NODERANGE
Format: <MIN>[,<MAX>]
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum nodes allowed to be allocated to job. See Dynamic Jobs for more information.
Example: 
JOBCFG[vizserver] NODERANGE=1,16
   
NODES
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes   Yes
Description: Number of nodes required by job. Default is 1. See Node Definition for more information.
Example: 
JOBCFG[job.min]  NODES=2
JOBCFG[job.max]  NODES=4
   
PARTITION
Format: <PARTITION>[:<PARTITION>]...
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Specifies the partition (or partitions) in which a job must run.
Example: 
JOBCFG[meis] PARTITION=math:geology
   
PREF
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Specifies which node features are preferred by the job and should be allocated if available. See PREF for more information.
Example: 
JOBCFG[meis] PREF=bigmem
   
PRIORITY
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Relative job priority.
Example: 
JOBCFG[meis] PRIORITY=25000
   
PROCRANGE
Format: <MIN>[,<MAX>]
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum processors allowed to be allocated to job.
Example: 
JOBCFG[meis] PROCRANGE=2,64
   
QOS
Format: <QOS>[,<QOS>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: QoS credentials associated with job. Used in job template matching.
Example: 
JOBCFG[admin]      RFEATURES=bigmem
JOBCFG[admin.min]  QOS=admin_qos
JOBMATCHCFG[admin] JMIN=admin.min JSET=admin
   
RARCH
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
      Yes
Description: Architecture required by job.
Example: 
JOBCFG[servapp] RARCH=i386
   
RFEATURES
Format: <FEATURE>[,<FEATURE>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: List of features required by job.
Example: 
JOBCFG[servapp] RFEATURES=fast,bigmem
   
RM
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Destination resource manager to be associated with job.
Example: 
JOBCFG[webdb] RM=slurm
   
ROPSYS
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Operating system required by job.
Example: 
JOBCFG[test.set] ROPSYS=windows
   
SELECT
Format: <BOOLEAN> : TRUE | FALSE
Template
Type:
JMIN JMAX JDEF JSET
       
Description: Job template can be directly requested by job at submission.
Example: 
JOBCFG[servapp] SELECT=TRUE
   
SOFTWARE
Format: <RESTYPE>[{+|:}<COUNT>][@<TIMEFRAME>]
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Indicates generic resources required by the job. See SOFTWARE for more information.
Example: 
JOBCFG[servapp] SOFTWARE=matlab:2
   
SYSTEMJOBTYPE
Format:  
Template
Type:
JMIN JMAX JDEF JSET
Yes      
Description: System job type (ex. vmcreate).
Example: 
JOBCFG[vmcreate.min] SYSTEMJOBTYPE=vmcreate
JOBCFG[vmcreate.set] TRIGGER=atype=reserve,action="00:05:00",etype=end
JOBMATCHCFG[vmcreate] JMIN=vmcreate.min JSET=vmcreate.set
   
TARGETBACKLOG
Format: [<MIN>,]<MAX>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum backlog for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
Example: 
JOBCFG[pdb] TARGETBACKLOG=0.5,2.0
   
TARGETLOAD
Format: [<MIN>,]<MAX>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum load for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
Example: 
JOBCFG[pdb] TARGETLOAD=0.5,2.0
   
TARGETRESPONSETIME
Format: [<MIN>,]<MAX>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum response time for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
Example: 
JOBCFG[pdb] TARGETRESPONSETIME=0.5,2.0
   
TARGETTHROUGHPUT
Format: [<MIN>,]<MAX>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Minimum and maximum throughput for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
Example: 
JOBCFG[pdb] TARGETTHROUGHPUT=0.5,2.0
   
TASKS
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes   Yes
Description: Number of tasks required by job. Default is 1. See Task Definition for more information.
Example: 
JOBCFG[job.min]  TASKS=4
JOBCFG[job.max]  TASKS=8
   
TASKPERNODE
Format: <INTEGER>
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes   Yes
Description: Exact number of tasks required per node. Default is 0.
Example: 
JOBCFG[job.min]  TASKPERNODE=2
JOBCFG[job.max]  TASKPERNODE=4
   
TEMPLATEDEPEND
Format: <TYPE>:<TEMPLATE_NAME>
Template
Type:
JMIN JMAX JDEF JSET
       
Description: Create another job from the TEMPLATE_NAME job template, on which any jobs using this template will depend. This is used for dynamically creating workflows. See Job Dependencies for more information.
Example: 
JOBCFG[engineering] TEMPLATEDEPEND=AFTER:setup.pre
JOBCFG[setup.pre]   SELECT=TRUE EXEC=/tools/setup.pre.sh
   
UNAME
Format: <STRING>
Template
Type:
JMIN JMAX JDEF JSET
      Yes
Description: User credential associated with job.
Example: 
JOBCFG[webserv] UNAME=service

Note For matching the user, see the USER attribute.

   
USER
Format: <USER>[,<USER>]...
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: User credentials associated with job.
Example: 
JOBCFG[webserv] USER=service

Note For setting the user, see the UNAME attribute.

   
WCLIMIT
Format: [[HH:]MM:]SS
Template
Type:
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Description: Walltime required by job. Default is 864000 (100 hours).
Example: 
JOBCFG[job.min]  WCLIMIT=2:00:00
JOBCFG[job.max]  WCLIMIT=12:00:00
   
WORK
Format: <DOUBLE>
Template
Type:
JMIN JMAX JDEF JSET
    Yes Yes
Description: Unitless measure of work accomplished per task.
Example: 
JOBCFG[webserv] WORK=10.5
   

11.10.4 Resource Manager Templates

Job templates can also be applied to resource managers modifying attributes of jobs submitted to, migrated to, or routed through specified resource manager interfaces. In particular the RMCFG attributes MAX.JOB, MIN.JOB, SET.JOB, and DEFAULT.JOB can be used. However, the meanings of resource manager job templates are slightly different than their JOBMATCHCFG counterparts as described in the following table.

Attribute Description
MAX.JOB A potential job is not allowed to access the resource manager if it has matching attributes set or has resource requests that exceed those specified in this template.
MIN.JOB A potential job is not allowed to access the resource manager if it does not have matching attributes set or has resource requests that do not meet or exceed those specified in this template.
DEFAULT.JOB A job associated with this resource manager has the specified attributes set as defaults but all values can be overridden by the user if the matching attribute is explicitly set at job submission time.
SET.JOB A job associated with this resource manager has the specified attributes forced to these values and these values override any values specified by the submittor at job submission time.

11.10.5 Job Template Examples

Job templates can be used for a wide range of purposes including enabling automated learning, setting up custom application environments, imposing special account constraints, and applying group default settings. The following examples highlight some of these uses:

11.10.5.1 Example 1: Setting Up Application-Specific Environments

JOBCFG[xxx] EXEC=*app* JOBPROLOG=/usr/local/appprolog.x

11.10.5.2 Example 2: Applying Job Preferences and Defaults

JOBCFG[xxx] CLASS=appq EXEC=*app* PREF=clearspeed

NODEALLOCATIONPOLICY PRIORITY
NODECFG[DEFAULT] PRIOF=5.0*PREF

11.10.5.3 Example 3: Applying Resource Constraints to Fuzzy Collections

In the following example, a job template match is set up. Using the JOBMATCHCFG parameter, Moab is configured to apply all attributes of the inter.set job template to all jobs that match the constraints of the inter.min job template. In this example, all interactive jobs are assigned the ignpolicies flag that allows them to ignore active, idle, system, and partition level policies. Interactive jobs are also locked into the test standing reservation and thus only allowed to run on the associated nodes.

# limit all users to a total of two non-interactive jobs

USERCFG[DEFAULT]  MAXJOB=2

SRCFG[test] DESCRIPTION="compute pool for interactive and short duration jobs"
SRCFG[test] JOBATTRLIST=INTERACTIVE
SRCFG[test] MAXTIME=1:00:00
SRCFG[test] HOSTLIST=R:atl[16-63]

JOBCFG[inter.min] FLAGS=interactive
JOBCFG[inter.set] FLAGS=ignpolicies REQRSV=interactive

JOBMATCHCFG[interactive] JMIN=inter.min JSET=inter.set

11.10.5.4 Example 4: Resource Manager Templates

In the following example, interactive jobs are not allowed to enter through this resource manager and any job that does route in from this resource manager interface has the preemptee flag set.

JOBCFG[no_inter]    FLAGS=interactive
JOBCFG[preempt_job] FLAGS=preemptee

RMCFG[gridA.in] MAX.JOB=no_inter SET.JOB=preempt_job

11.10.6 Managing Job Templates

11.10.6.1 Dynamically Creating Job Templates

Job templates can be dynamically created while Moab is running using the mschedctl -m command.

Note Dynamically created job templates will only survive a Moab restart if the --flags=pers[istent] flag is used. 

> mschedctl -m --flags=pers "JOBCFG[preempt] FLAGS=PREEMPTOR"
> mschedctl -m --flags=pers "JOBCFG[preempt] SELECT=TRUE" 
> msub -l template=preempt mysjob.sh

11.10.6.2 Removing Job Templates

Job templates cannot be dynamically removed. You can only remove job templates by commenting out (or removing) the template definition (lines) in the moab.cfg file; then you must restart Moab.

11.10.6.3 Dynamically Modifying Job Templates

Job templates can be dynamically modified by using the mschedctl -m command.

Note Dynamic changes do not persist after a shutdown of the Moab server unless the --flags=pers[istent] flag is used. 

> mschedctl -m "JOBCFG[single] NODEACCESSPOLICY=SINGLEJOB"

11.10.6.4 Viewing Job Templates

Job templates can be viewed by specifying "template:" before the template name in checkjob and also by using the command mdiag -j as in the following example:

> mdiag -j --flags=policy

> checkjob -v template:match.min

11.10.7 Creating Workflows with Job Templates

Moab can create workflows from individual jobs using job templates. The Moab naming convention for jobs created with job templates is <moabid>.<templatename>. By default, when Moab submits jobs to only one resource manager, the job IDs are synchronized with the resource manger's job IDs. For consistency, the parameter USEMOABJOBID may be used so that a template-created job is easily associated with its parent job (such as moab.1, moab.1.setup.pre).

Note JSETs and JDEFs have only been tested using msub as the job submission command.

11.10.7.1 Example 1: Building a Workflow with Job Templates

In this example, creating a job in the engineering account generates a workflow based on a two-step setup. The job is set to depend on the completion of this workflow.

JOBMATCHCFG[engineering.job]  JMIN=engineering.match JSET=engineering
JOBCFG[engineering.match]     ACCOUNT=engineering

JOBCFG[engineering]     TEMPLATEDEPEND=AFTER:setup.pre2
JOBCFG[setup.pre2]      TEMPLATEDEPEND=AFTER:setup.pre SELECT=TRUE EXEC=/nfs/tools/setup.pre2.sh
JOBCFG[setup.pre]       TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE EXEC=/usr/tools/setup.pre.sh STAGEIN=TRUE

In the previous example, a job is submitted with the account name engineering. Moab then matches the submitted job with the engineering template. The engineering template states that the job must run after the setup.pre2 template job runs. Then the setup.pre2 template creates a job from the specified EXEC string; the setup.pre2 job must run after the setup.pre template job runs. The setup.pre template creates a job from the specified EXEC string. The new setup.pre job is specified for two processors and has a wallclock time of one minute.

Note that since the setup.pre.sh script is not on an NFS mount, it must be staged in. STAGEIN has a value of TRUE or FALSE. If set to TRUE, Moab ensures the executable is staged out to the compute host where the dependent job runs. If set to FALSE, Moab assumes the executable is already available on the compute host.

11.10.7.2 Example 2: A Workflow with Multiple Dependencies

In this example the job will depend on the completion of two other jobs Moab creates. Both jobs execute at the same time.

# Engineering2
JOBCFG[engineering2]           TEMPLATEDEPEND=AFTER:engineering2.pre2 TEMPLATEDEPEND=AFTER:engineering2.pre
JOBCFG[engineering2.pre2]      TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE EXEC=/usr/tools/engineering2.pre2.sh
JOBCFG[engineering2.pre]       TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE EXEC=/usr/tools/engineering2.pre.sh

JOBCFG[engineering2.match]     ACCOUNT=engineering2
JOBMATCHCFG[engineering2.job]  JMIN=engineering2.match JSET=engineering2

11.10.7.3 Example 3: Jobs that Run After the Submission Job

Three additional jobs are created that depend on the submitted job. 

# Workflow 2
JOBCFG[workflow2]           TEMPLATEDEPEND=BEFORE:workflow2.post1  TEMPLATEDEPEND=BEFORE:workflow2.post2 TEMPLATEDEPEND=BEFORE:workflow2.post3
JOBCFG[workflow2.post1]     TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow2.post1.sh
JOBCFG[workflow2.post2]     TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow2.post2.sh
JOBCFG[workflow2.post3]     TASKS=2 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow2.post3.sh

JOBCFG[workflow2.match]     ACCOUNT=workflow2
JOBMATCHCFG[workflow2.job]  JMIN=workflow2.match JSET=workflow2

11.10.7.4 Example 4: A Complex Workflow

A complex workflow that handles failures. 

# Workflow 4
JOBCFG[workflow4.step1]     TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step1.sh TEMPLATEDEPEND=BEFOREFAIL:workflow4.fail1

JOBCFG[workflow4.fail1]     TASKS=1 WCLIMIT=00:00:30 SELECT=TRUE  EXEC=/usr/tools/workflow.fail.1.sh TEMPLATEDEPEND=BEFOREANY:workflow4.fail2
JOBCFG[workflow4.fail2]     TASKS=1 WCLIMIT=00:00:30 SELECT=TRUE  EXEC=/usr/tools/workflow.fail.2.sh

# Submission job
JOBCFG[workflow4.step2]     TEMPLATEDEPEND=AFTEROK:workflow4.step1  TEMPLATEDEPEND=BEFOREOK:workflow4.step3.1  TEMPLATEDEPEND=BEFOREOK:workflow4.step3.2

JOBCFG[workflow4.step3.1]   TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step3.1.sh
JOBCFG[workflow4.step3.2]   TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step3.2.sh TEMPLATEDEPEND=BEFOREOK:workflow4.step4

JOBCFG[workflow4.step4]     TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step4.sh
JOBCFG[workflow4.step4]     TEMPLATEDEPEND=BEFOREOK:workflow4.step5.1  TEMPLATEDEPEND=BEFOREOK:workflow4.step5.2  TEMPLATEDEPEND=BEFORENOTOK:workflow4.step5.3

JOBCFG[workflow4.step5.1]   TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step5.1.sh
JOBCFG[workflow4.step5.2]   TASKS=1 WCLIMIT=00:01:00 SELECT=TRUE  EXEC=/usr/tools/workflow.step5.2.sh
JOBCFG[workflow4.step5.3]   TASKS=1 WCLIMIT=00:00:30 SELECT=TRUE  EXEC=/usr/tools/workflow.step5.3.sh

JOBCFG[workflow4.match]     ACCOUNT=workflow4
JOBMATCHCFG[workflow4.job]  JMIN=workflow4.match JSET=workflow4.step2

See Also

Home Up Previous Next
Searches Moab documentation only
© 2001-2010 Adaptive Computing Enterprises, Inc.