Bugzilla – Bug 2306
Unique job id as RSL substitution variable
Last modified: 2005-11-08 17:49:48
You need to log in before you can comment on or make changes to this bug.
It would be useful to have a unique job id as a rsl substitution variable. For example, it would allow for resuing the same RSL for multiple jobs on the same resource: <job> <executable>foo</executable> <stdout>/tmp/stdout.${GLOBUS_JOB_ID}</stdout> <stderr>/tmp/stderr.${GLOBUS_JOB_ID}</stderr> <fileStageOut> <transfer> <sourceUrl>file:///tmp/stdout.${GLOBUS_JOB_ID}</sourceUrl> <destinationUrl>gsiftp://target/out.${GLOBUS_JOB_ID}</destinationUrl> </transfer> </fileStageOut> </job> As a comparison, most batch schedulers provide something like this in their job descriptions. LSF: If you use the special character %J in the name of the error file, then %J is replaced by the job ID of the job. If you use the special character %I in the name of the error file, then %I is replaced by the index of the job in the array if the job is a member of an array. Otherwise, %I is replaced by 0 (zero). PBS: PBS_JOBID the job identifier assigned to the job by the batch system. PBS_JOBNAME the job name supplied by the user.
Added to the trunk. I didn't add a scheduler test case since I don't know how to test it effectively. I would need control of the globusrun-ws command so I could specify a submission ID that would end up as the value for the substitution.
YOU SHOULD NOT ADD THAT GLOBUS_JOB_ID EXISTS IN THE 4.0 DOCUMENTATION TREE!!!
I commented out references to GLOBUS_JOB_ID in the 4.0 doc. Let me know with screaming, all-caps text if I missed something.
Apologies about the screaming. I discovered today (the hard way) that GT4 didn't work as I had expected it to work. That GLOBUS_JOB_ID would be one of the available substitution variables seemed like a very natural thing to me, and I had to spend the rest of the day engineering ugly workarounds. The pressure valve collapsed and steam had to be let off somewhere... Another way to look at it: since this functionality has been part of the 4.0 documentation, wouldn't the fix be a candidate for 4.0.2? ;-)
The documentation was accidentally added rather recently, so the doc has been without it for much longer than it has been included. It's also clearly an interface change, and interface changes are prohibited for the 4.0.x series of releases.