Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

Submitting Interactive Jobs

The submission of interactive jobs instead of batch jobs is useful in situations where a job requires your direct input to influence the job results. Such situations are typical for X Windows applications or for tasks in which your interpretation of immediate results is required to steer further processing.

You can create interactive jobs in three ways:

  • qlogin - A telnet-like session that is started on a host selected by grid engine software.

  • qrsh - The equivalent of the standard UNIX rsh facility. A command is run remotely on a host selected by the grid engine system. If no command is specified, a remote rlogin session is started on a remote host.

  • qsh - An xterm that is displayed from the machine that is running the job. The display is set corresponding to your specification or to the setting of the DISPLAY environment variable. If the DISPLAY variable is not set, and if no display destination is defined, the grid engine system directs the xterm to the 0.0 screen of the X server on the host from which the job was submitted.


    Note - To function correctly, all the facilities need proper configuration of cluster parameters of the grid engine system. The correct xterm execution paths must be defined for qsh. Interactive queues must be available for this type of job. Contact your system administrator to find out if your cluster is prepared for interactive job execution.


The default handling of interactive jobs differs from the handling of batch jobs. Interactive jobs are not queued if the jobs cannot be executed when they are submitted. A job's not being queued indicates immediately that not enough appropriate resources are available to dispatch an interactive job at the time the job is submitted. The user is notified in such cases that the cluster is currently too busy.

You can change this default behavior with the -now no option to qsh, qlogin, and qrsh. If you use this option, interactive jobs are queued like batch jobs. When you use the -now yes option, batch jobs that are submitted with qsub can also be handled like interactive jobs. Such batch jobs are either dispatched for running immediately, or they are rejected.


Note - Interactive jobs can be run only in queues of the type INTERACTIVE. See "Configuring Queues" in N1 Grid Engine 6 Administration Guide for details.


The following sections describe how to use the qlogin and qsh facilities. The qrsh command is explained in a broader context in Transparent Remote Execution.

Submitting Interactive Jobs With QMON

The only type of interactive jobs that you can submit from QMON are jobs that bring up an xterm on a host selected by the grid engine system.

At the right side of the Submit Job dialog box, click the button above the Submit button until the Interactive icon is displayed. Doing so prepares the Submit Job dialog box to submit interactive jobs. See Figure 3-8 and Figure 3-9.

The meaning and the use of the selection options in the dialog box is the same as that described for batch jobs in Submitting Batch Jobs. The difference is that several input fields are grayed out because those fields do not apply to interactive jobs

Figure 3-8 Interactive Submit Job Dialog Box, General Tab

Dialog box titled Submit Job. Shows General tab with fields for
interactive jobs filled in. Shows buttons for manipulating job submission information.

Figure 3-9 Interactive Submit Job Dialog Box, Advanced Tab

Dialog box titled Submit Job. Shows Advanced tab with fields
for interactive jobs filled in. Shows buttons for manipulating job submission information.

Submitting Interactive Jobs With qsh

qsh is very similar to qsub. qsh supports several of the qsub options, as well as the additional option -display to direct the display of the xterm to be invoked. See the qsub(1) man page for details.

To submit an interactive job with qsh, type a command like the following:

% qsh -l arch=solaris64

This command starts an xterm on any available Sun Solaris 64-bit operating system host.

Submitting Interactive Jobs With qlogin

Use the qlogin command from any terminal or terminal emulation to start an interactive session under the control of the grid engine system.

To submit an interactive job with qlogin, type a command like the following:

% qlogin -l star-cd=1,h_cpu=6:0:0

This command locates a low-loaded host. The host has a Star-CD license available. The host also has at least one queue that can provide a minimum of six hours hard CPU time limit.


Note - Depending on the remote login facility that is configured to be used by the grid engine system, you might have to enter your user name, your password, or both, at a login prompt.


Transparent Remote Execution

The grid engine system provides a set of closely related facilities that support the transparent remote execution of certain computational tasks. The core tool for this functionality is the qrsh command, which is described in Remote Execution With qrsh. Two high-level facilities, qtcsh and qmake, build on top of qrsh. These two commands enable the grid engine system to transparently distribute implicit computational tasks, thereby enhancing the standard UNIX facilities make and csh. qtcsh is described in Transparent Job Distribution With qtcsh. qmake is described in Parallel Makefile Processing With qmake.

Remote Execution With qrsh

qrsh is built around the standard rsh facility. See the information that is provided in sge-root/3rd_party for details on the involvement of rsh. qrsh can be used for various purposes, including the following:

  • To provide remote execution of interactive applications that use the grid engine system comparable to the standard UNIX facility rsh. rsh is also called remsh on HP-UX systems.

  • To offer interactive login session capabilities that use the grid engine system, similar to the standard UNIX facility rlogin. qlogin is still required as a grid engine system's representation of the UNIX telnet facility.

  • To allow for the submission of batch jobs that support terminal I/O (standard output, standard error, and standard input) and terminal control.

  • To provide a way to submit a standalone program that is not embedded in a shell script.


    Note - It is also possible to submit scripts with qrsh by using the ---b n option. For more information, see the qrsh man page.


  • To provide a submission client that remains active while a batch job is pending or running and that goes away only if the job finishes or is cancelled.

  • To allow for the grid engine system-controlled remote running of job tasks within the framework of the dispersed resources allocated by parallel jobs. See "Tight Integration of Parallel Environments and Grid Engine Software" in N1 Grid Engine 6 Administration Guide.

By virtue of these capabilities, qrsh is the major enabling infrastructure for the implementation of the qtcsh and the qmake facilities. qrsh is also used for the tight integration of the grid engine system with parallel environments such as MPI or PVM.

Invoking Transparent Remote Execution With qrsh

Type the qrsh command, adding options and arguments according to the following syntax:

% qrsh	[options] program|shell-script [arguments] \
	[> stdout] [>&2 stderr] [< stdin]

qrsh understands almost all options of qsub. qrsh provides the following options:

  • -now yes|no - -now yes specifies that the job is scheduled immediately. The job is rejected if no appropriate resources are available. -now yes is the default. -now no specifies that the job is queued like a batch job if the job cannot be started at submission time.

  • -inherit - qrsh does not go through the scheduling process to start a job-task. Instead, qrsh assumes that the job is embedded in a parallel job that already has allocated suitable resources on the designated remote execution host. This form of qrsh is commonly used in qmake and in a tight parallel environment integration. The default is not to inherit external job resources.

  • -binary yes|no - when specified with the n option, allows you to use qrsh to submit script jobs.

  • -noshell - With this option, you do not start the command line that is given to qrsh in a user's login shell. Instead, you execute the command without the wrapping shell. Use this option to speed up execution, as some overhead, such as the shell startup and the sourcing of shell resource files, is avoided.

  • -nostdin - Suppresses the input stream STDIN. With this option set, qrsh passes the -n option to the rsh command. Suppression of the input stream is especially useful if multiple tasks are executed in parallel using qrsh, for example, in a make process. Which process gets the input is undefined.

  • -verbose - This option presents output on the scheduling process. -verbose is mainly intended for debugging purposes and is therefore switched off by default.

Transparent Job Distribution With qtcsh

qtcsh is a fully compatible replacement for the widely known and used UNIX C shell derivative tcsh. qtcsh is built around tcsh. See the information that is provided in sge-root/3rd_party for details on the involvement of tcsh. qtcsh provides a command-shell with the extension of transparently distributing execution of designated applications to suitable and lightly loaded hosts that use the grid engine system. Which applications to execute remotely and which requirements apply to the selection of an execution host are defined in configuration files that are called .qtask.

Transparent to the user, such applications are submitted to the grid engine system through the qrsh facility. qrsh provides standard output, error output, and standard input handling as well as terminal control connection to the remotely executing application. Only three noticeable differences exist between running such an application remotely and running the application on the same host as the shell.

  • The remote host might be more powerful, lower-loaded, and have required hardware and software resources installed. Therefore, such a remote host would be much better suited than the local host, which might not allow running the application at all. This difference is desired, of course.

  • A small delay is incurred by the remote startup of the jobs and by their handling through the grid engine system.

  • Administrators can restrict the use of resources through interactive jobs (qrsh) and thus through qtcsh. If not enough suitable resources are available for an application to be started through qrsh, or if all suitable systems are overloaded, the implicit qrsh submission fails. A corresponding error message is returned, such as Not enough resources ... try later.

In addition to the standard use, qtcsh is a suitable platform for third party code and tool integration. The single-application execution form of qtcsh is qtcsh -c app-name. The use of this form of qtcsh inside integration environments presents a persistent interface that almost never needs to be changed. All the required application, tool, integration, site, and even user-specific configurations, are contained in appropriately defined .qtask files. A further advantage is that this interface can be used in shell scripts of any type, in C programs, and even in Java applications.

Previous Previous     Contents     Index     Next Next