Running Job Scripts With DRMAA
By templedf on Oct 21, 2005
DRMAA is intended as a general purpose API, which means it has to assume as little as possible about the jobs it runs. Grid Engine recognizes two broad classes of jobs: scripts and binaries. A script is a text file that is to be run by a shell and which may have embedded SGE options in it. (Lines starting with #$ are parsed by Grid Engine at job submission time for embedded options. See the man page for more info.) A binary is anything else. The user controls whether a job is treated as a binary or a script with the -b (for binary) qsub option. The Grid Engine default is to assume that all jobs are scripts.
DRMAA, however, makes a different assumption. The minimum assumption that DRMAA can make is that jobs are opaque and cannot be parsed, i.e. that all jobs are binary. This assumption is exactly the opposite of the one Grid Engine makes. Because jobs aren't assumed to be scripts, there are a few extra steps required to running scripts through DRMAA.
First off, it's important to note that DRMAA doesn't actually have a problem running scripts, even without the additional steps. The meaning of assuming a job to be "binary" is that DRMAA does not parse the job for embedded options, and it doesn't send the job as a text attachment with the internal job structure. A script that is treated as a binary still works just fine. The primary effect is that embedded options are ignored.
In order to have embedded options not be ignored, one of three things has to happen. Either the native specification (DRMAA_NATIVE_SPECIFICATION in the C binding or nativeSpecification in the JavaTM language binding) must contain the option, "-b n", or the job category (DRMAA_JOB_CATEGORY or jobCategory) must reference a qtask entry which contains "-b n", or "-b n" must appear in one of the sge_request files. See my previous post for information about precedence.
The next issue is that some options are silently ignored by DRMAA. They are:
|-cwd\*||The implementation is not thread safe; use DRMAA_WD or workingDirectory instead|
|-help||For obvious reasons|
|-t||Handled by drmaa_run_bulk_jobs() or Session.runBulkJobs()|
|-verify||Does not make sense in DRMAA context|
|-w w|v||Same as -verify|
\* Because -cwd was not forbidden until a later update release, a mechanism was provided to re-enable it. By setting the environment variable, SGE_DRMAA_ALLOW_CWD, in the shell, the -cwd option will be treated normally. As noted above, though, the processing of the -cwd option is not thread safe.
Nothing else should be different when running scripts versus running binaries. It is important to note that in both cases, shell environment variables embedded in the script or binary name or in the arguments will not be interpreted. To force shell variables to be interpreted, write a wrapper script and run it as the job.