Platform LSF Administration Guide Version 6.2
Using esub
Administering Platform LSF
498
External executables get called by several LSF commands (bsub, bmod, lsrun). This
variable contians the name of the last LSF command to call the executable.
General esub logic
After esub runs, LSF checks:
1
Is the esub exit value LSB_SUB_ABORT_VALUE?
a
Yes, step 2
b
No, step 4
2
Reject the job
3
Go to step 5
4
Does LSB_SUB_MODIFY_FILE or LSB_SUB_MODIFY_ENVFILE exist?
❖
Apply changes
5
Done
Rejecting jobs
Depending on your policies you may choose to reject a job. To do so, have esub exit
with LSB_SUB_ABORT_VALUE.
If
esub rejects the job, it should not write to either LSB_SUB_MODIFY_FILE or
LSB_SUB_MODIFY_ENVFILE.
Example
The following Bourne shell esub rejects all job submissions by exiting with
LSB_SUB_ABORT_VALUE:
#!/bin/sh
# Redirect stderr to stdout so echo can be used for
# error messages
exec 1>&2
# Reject the submission
echo "LSF is Rejecting your job submission..."
exit $LSB_SUB_ABORT_VALUE
Validating job submission parameters
One use of validation is to support project-based accounting. The user can request that
the resources used by a job be charged to a particular project. Projects are associated
with a job at job submission time, so LSF will accept any arbitrary string for a project
name. In order to ensure that only valid projects are entered and the user is eligible to
charge to that project, an
esub can be written.
Example
The following Bourne shell esub validates job submission parameters:
#!/bin/sh
. $LSB_SUB_PARM_FILE
# Redirect stderr to stdout so echo can be used for error messages
exec 1>&2
# Check valid projects