The following general rules apply to job command files.
Figure 10 is an example of a simple serial job command file which is run from the current working directory. The job command file reads the input file, longjob.in1, from the current working directory and writes standard output and standard error files, longjob.out1 and longjob.err1, respectively, to the current working directory.
Figure 10. Serial Job Command File
# The name of this job command file is file.cmd. # The input file is longjob.in1 and the error file is # longjob.err1. The queue statement marks the end of # the job step. # # @ executable = longjob # @ input = longjob.in1 # @ output = longjob.out1 # @ error = longjob.err1 # @ queue |
To specify a stream of job steps, you need to list each job step in the job command file. You must specify one queue statement for each job step. Also, the executables for all job steps in the job command file must exist when you submit the job. All information in the first step is inherited by all succeeding steps.
LoadLeveler treats all job steps as independent job steps unless you use the dependency keyword. If you use the dependency keyword, LoadLeveler determines whether a job step should run based upon the exit status of the previously run job step.
For example, Figure 11 contains two separate job steps. Notice that step1 is the first job step to run and that step2 is a job step that runs only if step1 exits with the correct exit status.
Figure 11. Job Command File with Multiple Steps
# This job command file lists two job steps called "step1" # and "step2". "step2" only runs if "step1" completes # with exit status = 0. Each job step requires a new # queue statement. # # @ step_name = step1 # @ executable = executable1 # @ input = step1.in1 # @ output = step1.out1 # @ error = step2.err1 # @ queue # @ dependency = (step1 == 0) # @ step_name = step2 # @ executable = executable2 # @ input = step2.in1 # @ output = step2.out1 # @ error = step2.err1 # @ queue |
In Figure 11, step1 is called the sustaining job step. step2 is called the dependent job step because whether or not it begins to run is dependent upon the exit status of step1. A single sustaining job step can have more than one dependent job steps and a dependent job step can also have job steps dependent upon it.
In Figure 11, each job step has its own executable, input, output, and error statements. Your job steps can have their own separate statements, or they can use those statements defined in a previous job step. For example, in Figure 12, step2 uses the executable statement defined in step1:
Figure 12. Job Command File with Multiple Steps and One Executable
# This job command file uses only one executable for # both job steps. # # @ step_name = step1 # @ executable = executable1 # @ input = step1.in1 # @ output = step1.out1 # @ error = step1.err1 # @ queue # @ dependency = (step1 == 0) # @ step_name = step2 # @ input = step2.in1 # @ output = step2.out1 # @ error = step2.err1 # @ queue |
See Additional Job Command File Examples for more information.
In addition to building job command files to submit serial jobs, you can also build job command files to submit parallel jobs. Before constructing parallel job command files, consult your LoadLeveler system administrator to see if your installation is configured for parallel batch job submission.
For more information on submitting parallel jobs, see Chapter 4, Submitting and Managing Parallel Jobs.