Hi, Am 06.12.2011 um 12:52 schrieb Ed Spittles:
> When I came across this problem, there was resistance to changing either > the parent or the child script (or program) - if it works without using the > queue, then it should work transparently when using the queue. I agree with > that position, in general. We use -V so that all of the environment is > passed, and we use a wrapper to qsub, so that any command line can be > submitted to the queue, using a prefix command, without the user needing to > know anything about a jobscript. (I think the wrapper may have to tweak the > environment a little to allow for the case that the submitting process is > already a queued process.) this is something I faced in the past with my users in the opposite way: in the beginning they used -V and sometimes they changed the local environment and wondered why the jobs are not working any longer. So I started to go for self-contained scripts and we try to use them all the time. This way they can mess up their local environment, and the submitted jobs still run successfully. But anyway, then you could use a double wrapper: First use the submission wrapper/jsv to convert the relevant environment variables to job arguments (or maybe better: one long one separated by a special character, so that the users can still use their own arguments to any command). Then in a starter_method of the queue you make the opposite action: read the job argument(s) and set variables accordingly before exec'ing the real jobscript. The real jobscript/command can stay untouched this way. == Or maybe easier: When I get you right, you create a job script on-the-fly already. Then you could also just add a couple of lines in the jobscript to set the found environment variables directly before calling the original issued command. I.e. no -v/-V, instead several export commands in the jobscript. -- Reuti > So, I agree: there are several tactics we can apply, but they are not > transparent for the parent and child unless we can apply them in our wrapper. > And I agree, treating the environment or the command line as an unlimited > resource is not a wise thing to do! But not all users are wise. _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
