Delayed Batch Job Processing -- the  at  and  qsub  Commands

Any user can queue a job to run at a later time. Users running particularly large, compute-intensive, and/or long-running jobs are required to queue their jobs using the Portable Batch System (PBS) that makes use of rcf-01. For more information, see below, as well as our online document "Portable Batch System (PBS)":
www.usc.edu/hpcc/systems/use-l-4.php

To queue your job to run at a later time, you can use the  at  UNIX command. This requires that you place your invocation command and all other specifications (such as the filename of the program and any options or switches) into an executable shellscript file, and then specify the executable in an  at  command, such as

at 2:30a < execthis

where  execthis  is an executable shellscript you have created. (Of course, the name  execthis  is arbitrary, and can be any filename you choose.)

Let's say you have a statistics package called THYSTAT (for those who take documentation literally, note that this is a mythical package name, for illustration only), and your THYSTAT program is contained in  myprog.thystat1  which you keep in your home directory (~/) in a subdirectory called  programs. Part of the peculiar syntax of THYSTAT is that before the batch file name, you use a switch spelled  -in. For whatever reason, you wish to run your program late at night. To make an executable shellscript to run your batch program, enter the following into a file called  execthis :

#!/bin/sh -f
thystat -in ~/programs/myprog.thystat1

Then mark this file as an executable shellscript by typing the following at your UNIX prompt:
chmod u+x execthis

You can then run the  at  command, as shown above, and specify any time you feel would be best to run your job. For more details on the  at  and  chmod  commands, see the man pages or call the consultants.

The  qsub  Command and the PBS System

Multiple batch programs can be entered into a queue and run at a later time, allowing the user to 'submit' any number of jobs and still meet the system's limitation of one compute-bound job running at any given time. This method is required for jobs that are compute-intensive and/or will need multiple processors or extensive system resources. This type of queueing is done with the  qsub  command, which sends a request to the Portable Batch System (PBS).

RCF users normally can use the  qsub  command automatically. If it is not immediately available, run

source /usr/usc/pbs/default/setup.csh

Once this is set up, you can type  man pbs  and  man qsub  for complete online help information. Another helpful man page is  man pbs_resources_linux  which details the resource options (e.g., walltime, cput [cpu time], etc.) available for the  qsub  command.

The  qsub  command itself runs a script file, and inside the script file is the batch invocation of the software you wish to run (along with any other appropriate UNIX commands.  qsub  also writes to a LOG file that you specify, so you can see the STDIN and STDOUT messages associated with the running of your queued job. The general form of the  qsub  command is

qsub <flags> SCRIPTFILE

Once again, as in the example above, let's say you have a statistics package called THYSTAT (this is just a mythical example, to be substituted with whatever real command name and syntax you want to queue) and your THYSTAT program is contained in  myprog.thystat1  which you keep in your home directory (~/) in a subdirectory called  programs. Part of the peculiar syntax of THYSTAT, let's say, is that before the batch file name, you use a switch spelled  -in. Normally, you would run it in batch as follows:

thystat -in ~/programs/myprog.thystat1

In order to queue it with  qsub  and have the system run it later, you would create a qsub-appropriate SCRIPTFILE containing at least one line with a pound symbol ( # ) followed by the invocation of your software program, as shown above. Let's say you decide to put this into a file called  my.qsub.script. The contents of that file would be

#!/bin/csh -- a line beginning with # must begin the script file 
thystat  -in  ~/programs/myprog.thystat1

(Once again, remember that thystat is a bogus name, for example purposes only, and needs to be substituted with a real command name and syntax of your choice.)

The following command would queue your THYSTAT program for execution at a later time chosen by the system.

qsub -m be -k eo my.qsub.script

where  -m be  asks NQS to broadcast a message (i.e., to tell you) when the request ends execution;  -k eo  tells qsub to keep the STDERR and STDOUT output. A number of other flags are available, as listed in  man qsub  (remember to  source  the pbs setup file as shown above).

Many flags can be incorporated into the script file itself. For example, if you want your program always to report the results to your home directory, the -k eo flag may be entered into the file. Also, directions as to how much time to allow (walltime), how many nodes to use (nodes), and how many processors to use (ppn). If you want your job to run on the main rcf-01 processors, you can specify that in a separate nodes instruction (as shown in the example). Following is a sample (and simple!) script file that includes these requests. (The ls command is used as an example of a simple program that returns a detailed listing of the files in your home directory.)

#!/bin/csh -- any text here

#PBS -k eo
#PBS -l walltime=2:00:00
#PBS -l nodes=rcf-01
#PBS -l nodes=1:ppn=1

# run the program
ls -la ~/
exit

IMPORTANT NOTES:

• The syntax for the walltime value is hh:mm:ss (hours, minutes, seconds)
• The value for nodes= must always be 1 when submitting jobs to rcf-01, as the facility is configured as a single node.
• If explicit paths are used for commands or file specifications in the script file, /export and /auto must not be used. Instead, use the form /home/rcf-nn/username, where nn is the number of the file system partition where the files are stored, and username is the username of the home directory where the files are stored.

Often the  qsub  command will execute within a few minutes, though in some cases it could be delayed until the system is relatively unbusy at night.