Another Undocumented Feature
By templedf on Aug 10, 2009
In reading the comments for Issue 409, I came across another undocumented feature I hadn't seen before. Apparently, if you pass a variable to your job through qsub or qrsh with the -v switch, and if that variable starts with
SGE_COMPLEX_ part will be stripped off, and the remainder will be treated as a resource request whose value will be placed in the job's environment.
An example will make it easier to explain. If your job is able to run on multiple architectures, but you always select on which architecture you're running it when you submit, you could add "-v SGE_COMPLEX_arch" to the qsub submission parameters, and the job's environment would then contain the value of
arch that was requested as the
-l arch=... resource request. In action, it would look like:
% qrsh -l arch=sol-amd64 -v SGE_COMPLEX_arch echo \\$SGE_COMPLEX_arch sol-amd64
Nice, but why is it useful? Well, maybe your script is capable of operating in multiple environments, but it needs to know about how it was submitted. For example, maybe the script changes your application's startup parameters based on the memory limits. The script could use this feature to get the memory limits from the submission parameters and act accordingly. Of course, it could also get the memory limits from
ulimit(1), so maybe not the best example. Licenses may be a better example. The OS is blissfully unaware of license assignments. The only way for your script to find out about how many licenses were requested for it would be to use this feature (or do some clever digging with qstat).
You might have noticed by now that you could get the same effect by just passing in the requested complex value as an environment variable, e.g. "qsub -l arch=sol-amd64 -v arch=sol-amd64 ..." The difference between using the
SGE_COMPLEX_ feature and using an environment variable explicitly is that with the
SGE_COMPLEX_ feature you don't have to know what the requested value was, i.e. you can add it to an
sge_request(5) file or write it into your script. And now we come to the real value. If you have a job that needs to know about its submission parameters, you can embed submission directives to add the needed complexes' values to the environment. Pretty handy. Whenever you can, it's a good idea to make your jobs and scripts as self-contained as possible.
Update: It would appear that this feature no longer works in 6.2. The last version I was able to verify it in was 6.1u2. Not such a big deal, though, because with 6.2 we introduced JSVs, which let you do the same thing and a tremendous amount more.