No direct support for that in SGE. When a job is released from hold (like when another starts) does not mean it is executed. Hence you would not have not any guarantee that both are running at the same point in time.
You could submit the successor before the other one and give it the job id of the successor as context (-ac) and then in the job or a prolog you could trigger removing the hold from the successor when a certain criteria is met. In UGE there is a qsub -sync r … which blocks until the job is in running state - then you could do the other job submission within a job submission script. qsub -sync r myjob.sh && qsub myotherjob.sh If you really want to executed multiple jobs at the same time then a newer enhancement (sorry, again UGE) would be qsub -tcon yes -t 1-2 myjob.sh That would execute myshob.sh as job array with two instances (-t 1-2) and guarantee that both are scheduled at the same time (-tcon yes). Then you can differentiate using the SGE_TASK_ID environment variable which task number it is and which code is executed. Most flexibility about job submission and job workflow control you have of course by using an external API like the DRMAA API. Daniel > Am 14.06.2016 um 05:56 schrieb Hikonuki Ueki <[email protected]>: > > I believe somebody has already asked this, but I couldn't find it in the > mailing list archive. > > I am trying to figure out the equivalent option of LSF bsub -w > "started(aJob)" for qsub. > > I easily found that bsub -w "done(aJob)" could be achieved by qsub -hold_jid > aJob. > > I guess it is very natural that someone wants to execute a job when a certain > job starts to cowork with it. > > What am I missing? > > Thank you, > > Ueki > > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
