[GE users] SGE questions

john.li at mindspeed.com john.li at mindspeed.com
Thu Mar 1 18:19:54 GMT 2007


Now that I think of the time when I was evaluting Condor, it was behaving 
just like SGE.

However, LSF's behavior is much easier for the end user to submit a job...

Thanks,





"Rayson Ho" <rayrayson at gmail.com> 
03/01/07 10:16 AM
Please respond to
users at gridengine.sunsource.net


To
users at gridengine.sunsource.net
cc

Subject
Re: [GE users] SGE questions






On 3/1/07, john.li at mindspeed.com <john.li at mindspeed.com> wrote:
> There is no distinction betweeen a binary executable and a script.   In 
LSF, I don't
> worry
> about it.  I submit either a binary or a script, as long as it is in my 
search path, LSF
> will have no problem of running it.

Again, this behavior of LSF is not POSIX compliant. Other common batch
systems spool the job script.

Rayson




>
>
>
>
>
>
> Reuti <reuti at staff.uni-marburg.de>
>
> 03/01/07 10:05 AM
>
>
> Please respond to
> users at gridengine.sunsource.net
>
>
> Tousers at gridengine.sunsource.net
>
> cc
>
> SubjectRe: [GE users] SGE questions
>
>
>
>
>
>
>
>
>
> Am 01.03.2007 um 18:29 schrieb john.li at mindspeed.com:
>
> >
> > Hi Rayson,
> >
> > Thanks for the reply.   And thanks for correct my mistake on the
> > description.
> >
> > The reason that I brought this behavior up is due to the umask
> > issue that I mentioned
> > in my original email.   The umask seems to inherit user shell umask
> > when a job is
> > submitted as a script.  (Inherit environment umask is what I
> > want)   but not as a binary.
> > But SGE doesn't use $PATH to search for a script, which is not good
> > as far as I concern.
> > I don't have this problem in LSF at all.
>
> You mean something like:
>
> qsub `which myscript.sh`
>
> Is LSF spooling the jobscript, or using the original during the later
> execution?
>
> -- Reuti
>
>
> > Thanks,
> >
> >
> >
> >
> > "Rayson Ho" <rayrayson at gmail.com>
> > 02/28/07 03:07 PM
> > Please respond to
> > users at gridengine.sunsource.net
> >
> >
> > To
> > users at gridengine.sunsource.net
> > cc
> > Subject
> > Re: [GE users] SGE questions
> >
> >
> >
> >
> >
> > On 2/28/07, john.li at mindspeed.com <john.li at mindspeed.com> wrote:
> > > I'm new to SGE and trying to deploy SGE to replace LSF.
> >
> > Good :)
> >
> > > 3.  It seems that if I use -b y in the qsub  command, I MUST
> > specify the
> > > full path
> > > for the binary executable or it is in the current working
> > directory.   SGE
> > > doesn't
> > > use the $PATH variable to locate the binary executable.   But SGE
> > will use
> > > $PATH
> > > to locate a script if I use -b n for a script.   Is there a
> > reason for this
> > > behavior?
> >
> > Shouldn't it be the other way around??
> >
> > "-b n" tells qsub that the job is a script, and SGE will look for the
> > job script in the current directory or the location specified at qsub
> > time.
> >
> > "-b y" tells qsub that the job is a binary program, and SGE will not
> > spool the binary to the master machine. Since the location of the
> > binary can be different with different OSes/architectures, recording
> > the path does not make sense.
> >
> > I've just tested on my cluster and that's the behavior... and I
> > believe it has something to do with POSIX 1003.2d (standard for batch
> > queuing systems).
> >
> > * also note that LSF does not spool the job script or the binary at
> > bsub time.
> >
> > Rayson
> >
> >
> >
> >
> > >
> > > I have more questions, but this is good for now.  :-)
> > Someone,  please
> > > help...
> > >
> > > Best regards,
> > >
> > > John,
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> > For additional commands, e-mail: users-help at gridengine.sunsource.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net





More information about the gridengine-users mailing list