Each batch request receives a limited amount of system resources, such as CPU time and memory. Certain platforms may enforce only a subset of limits. To determine which limits are enforced on your NQS server, use the following command:

qlimit

---

Note: You must issue all NQE commands that begin with q on an NQS server; the NQE commands that begin with q are not NQE client commands. See “Command Line Interface” in Chapter 1, for a list of the commands that are available from remote NQE clients.

---

The following display shows the results of this command on a workstation:

% qlimit
  Per-process core file size           -lc
  Per-process data segment size        -ld
  Per-process permanent file size      -lf
  Per-request permanent file size      -lF    Not run-time enforceable
  Per-process memory size              -lm    Not run-time enforceable
  Per-request memory size              -lM    Not run-time enforceable
  Nice value                           -ln
  Per-process quick file size          -lq    Not run-time enforceable
  Per-request quick file size          -lQ    Not run-time enforceable
  Per-process stack segment size       -ls
  Per-process CPU time                 -lt
  Per-request CPU time                 -lT    Enforced per-process
  Per-request tape drive type a        -lUa   Not run-time enforceable
  Per-request tape drive type b        -lUb   Not run-time enforceable
  Per-request tape drive type c        -lUc   Not run-time enforceable
  Per-request tape drive type d        -lUd   Not run-time enforceable
  Per-request tape drive type e        -lUe   Not run-time enforceable
  Per-request tape drive type f        -lUf   Not run-time enforceable
  Per-request tape drive type g        -lUg   Not run-time enforceable
  Per-request tape drive type h        -lUh   Not run-time enforceable
  Per-process temporary file size      -lv    Not run-time enforceable
  Per-request temporary file size      -lV    Not run-time enforceable
  Per-process working set size         -lw
  Per-request MPP processing elements  -l mpp_p=<integer>
                                              Not run-time enforceable
  Per-process MPP time                 -l p_mpp_t=[[hrs:]min:]sec[:msec]
                                              Not run-time enforceable
  Per-request MPP time                 -l mpp_t=[[hrs:]min:]sec[:msec]
                                              Not run-time enforceable
  Per-process MPP memory size          -l p_mpp_m=<integer>
                                              Not run-time enforceable
  Per-request MPP memory size          -l mpp_m=<integer>
                                             Not run-time enforceable
  Per-request shared memory limit      -l shm_l[imit]=<value>[<units>]
                                              Not run-time enforceable
  Per-request shared memory segments   -l shm_s[egments]=<integer>
                                              Not run-time enforceable

You can specify resource requirements for your request by using either the NQE GUI or the command line interface.

If you use the NQE GUI, use the Submit window and select Job limits on the Configure menu.

If you use the command line interface, use the options to the cqsub command that begin with the letter l (for limit).

For an example of using limits, see “Example of Using Limits”.

When you specify a resource limit, NQE sends your request to a queue that can accommodate the limits you set.

If your resource limits exceed the limits of every possible batch queue destination, your request will not be accepted into a batch queue and therefore will not execute. You will receive a mail message that explains the problem.

You also can send your request directly to a queue that you know has the appropriate limits. To list the resource limits on all of the batch queues on your NQS server, use the following command:

cqstatl -b -d nqs -f

To list resource limits on another server, use the following command:

cqstatl -b -d nqs -f -h servername

cqstatl -d nqs -f requestid

qstat -f requestid

cqstatl -d nqedb -f tid

qstat -f $QSUB_REQID

You can specify a time after which a request will run. This can be a very useful option, especially if it is less expensive to run your requests during off-peak hours. The request waits in an NQS queue until the time you specify is passed. NQS schedules the request for execution as soon as possible after the specified time.

To specify a time after which to run your request, you can use either the NQE GUI or the command line interface, as follows:

You can specify date and time, as follows:

[date][time] [time-zone]

If you omit date, the current day is assumed. The date can be the words today or tomorrow, or an actual date.

You can specify an actual date for date in one of the following ways:

MM is the number of the month, such as 11. Month is the name of the month, which you can abbreviate to a minimum of the first 3 characters. Month can be in any combination of uppercase or lowercase. Any of the following are valid: March, MARC, MaR, mar, or MAR.

DD is either the name of the day or the number of the day within the month. You can abbreviate the name of the day to a minimum of the first 3 characters, and it can be in uppercase or lowercase. Any of the following are valid: MOND, mon, Mon, or 23.

YY is the last 2 digits of the year within the current century. YYYY is the full year. Any of the following are valid: 98 or 1998.

The time can be the word noon or midnight, or an actual time, specified as follows:

hour[:minutes[:seconds]][meridian]

Only the hour is required. A 24-hour clock is assumed, unless you specify meridian. The meridian can be am, pm, or m (indicating noon).

The time-zone is specified as any North American time zone (such as CDT) or Greenwich mean time (GMT). If you omit time-zone, the local time zone is used.

A change in time zones may occur from the time that you submitted the job to the time that the job runs. For example, your time zone may change from standard time to daylight savings time, or the job may be sent from a machine in one time zone to a machine in another time zone. In such cases, you can specify the desired time zone of the request. For example, to run a job at 12:00 P.M. on December 1, you can specify the time zone as follows:

"01-December-1995 noon CST"

---

Note: If you use the command line interface, the -a option must precede date and time specifications; such as, cqsub -a "01-December-1995 noon CST".

---

If the date and time specification includes space characters, you must enclose it within single or double quotation marks.

The following are examples of valid date and time specifications:

"July 4, 2026 12:31 EDT"
"01-Jan-1995 12am, PDT"
"Tuesday, 23:00:00"
"11pm tues."
'tomorrow 23 GMT'
12:00
noon
12m

If you specify -a 12pm, your job will run at 12:00 P.M. or 24:00:00. If you want your job to run at 12:00 A.M. or 12:00:00 (noon), use one of the following time specifications:

-a 12:00
-a noon
-a 12m

When your request is waiting for the time you specified to pass, the Status column in the NQE GUI Status window will indicate it is waiting with a WAITING or a W status code. Figure 5-1 shows an example.

Figure 5-1. Waiting Request Example

After the time has passed, the status code will change to an R, indicating that the request is running.

NQS uses a two-shell invocation method by default. When you submit a batch request to NQS, you can use the cqsub -s or qsub -s command to specify the full path name of the first shell used to interpret your request's shell script. You can specify the csh, ksh, or sh shell names. If no shell is specified with the -s option, NQS uses your default login shell. If you want to specify another shell, you can specify it in the following two ways:

NQS sets the QSUB_SHELL environment variable to the shell that you were in when you executed the -s option. NQS sets the SHELL environment variable to the initial shell that was executed by NQS.

When NQS initiates a request, a second shell is spawned. The second shell invoked is always /bin/sh, unless you have specified another shell. The two-shell invocation method allows stdin read-ahead by commands such as the remsh(1B) and cat(1) commands.

If you use csh or tcsh and do not specify the shell as the first line of the request file, NQS will run the batch request under sh. This is normal csh behavior and is documented in the csh(1) man page.

---

Note: When NQS reads your .cshrc file or your request script file, it may encounter commands it cannot invoke and cause your request not to run. You will see these problems reflected in your standard error file.

---

To specify that NQS invoke just one shell, use the following command (for each request) to set the NQSCHGINVOKE environment variable to true or yes (this example uses csh syntax):

setenv NQSCHGINVOKE true

If NQSCHGINVOKE is set to true or yes, and you do not request a shell by using the -s option, NQS invokes the request owner's UDB shell.

To export environment variables when you submit the request, use one of the following methods:

For a discussion of the passing of environment variables to a batch request, see “Environment Variables Automatically Set” in Chapter 9.

---

Note: NQS sets an environment variable called ENVIRONMENT to value BATCH for each NQS initiated job. This variable can be checked within a .profile, .login, or .cshrc script and be used to differentiate between interactive and batch sessions; this action can be used to avoid performing terminal setup operations for a batch job. A benefit of NQS initiating the batch job as a login shell is that .profile, .login, or .cshrc scripts are run and your environment is set up as expected.

---

The NQE administrator can define a default queue that applies to all NQS users. You also can define a default queue for your own use in the following ways:

To display the name of the system default queue, use the following command on your NQS server:

% qmgr
Qmgr: show parameters
show parameters

  Checkpoint directory = /nqebase/3.0/ice/database
/spool/private/root/chkpnt
  Debug level = 1
  Default batch_request queue = nqenlb

If no default queue is defined, or if you want to use a queue other than the default, specify the name of the queue you want to use.

Your NQE administrator can define queues so that they cannot accept requests directly. If this has been done for the queue you specify, your request will be rejected. To determine whether a batch queue can accept requests, you can use the cqstatl -f command or qstat -f command, as in the following example:

cqstatl -d nqs -f queue

The section of the display under the <ACCESS> heading lists whether the Route is Unrestricted or Pipe Only. For details about using the cqstatl -f command or the qstat -f command, see “Displaying Queue Details” in Chapter 11.

Unless you specify a request name, your request inherits the name of the request file. To specify a name for a request, do one of the following:

The request name is used in status displays and in naming your output files, unless you specify another name for your output file. For information about specifying output files, see Chapter 6, “Working with Output Files”.

If your NQE administrator has used password validation as a method of authorizing users, you can ensure that you always provide a password when needed. You can specify that you want to be prompted for a password in the following ways:

To specify an alternative UNICOS account name or the IRIX project name under which your request will be executed, you can use either the cqsub -A or qsub -A command, or select the NQE GUI Submit -> Configure -> General Options window. For example, if you currently are logged in as user pat, and the current UNICOS account name of your interactive session is dept_a (as shown by using the newacct -l command), but you want to execute the request under the UNICOS account name dept_b, enter the following command:

% qsub -A dept_b sleeper

nqs-181 qsub: INFO
  Request <402.coal>: Submitted to queue <express> by <pat(456)>.
%

The account name is a valid UNICOS account name for the user on the host on which the request will run. The project name is a valid IRIX project name for the user on the host on which the request will run.

Alternatively, to run a request under a specific UNICOS account name or IRIX project name, you can set the NQS_ACCOUNTNAME environment variable to the required account name or project name before job submission. If you later specify the -A option, it overrides the setting of the environment variable.

If an alternative account name or project name is not specified, and the request executes at the local host, the request uses your account name or project name at the time of submission. If an alternative account name or project name is not specified, and the request executes at a remote host, the request uses your default account name or project name at the remote host.

On UNICOS systems, to find your current, default, and valid account names, use the newacct(1) command. For more information, see the newacct(1) man page.

On IRIX systems, to find your default and valid project names, view the /etc/project file; the first project name on the list is your default project name.

Unless you indicate otherwise, the batch request executes under the user name used when you submitted the request. You can specify that a request will run under another user name in the following ways:

The following example enables you, currently logged in as user pat, to execute the request under user name bill. You issue the following command:

cqsub -u bill job1

The following example enables jack, who is currently logged in, to become jjackson (the owner of the request) and to submit request job1 to the NQE database as Chemdept (no spaces are allowed between the comma and the name of the owner of the request):

cqsub -u dbuser=Chemdept,jjackson job1

For a complete description of the -u option syntax, see the cqsub(1) or qsub(1) man page.

---

Note: When you specify an alternative user name, you must ensure that you have authorization to use the specified user name. For more information, see Chapter 2, “Preparing to Use NQE”.

---

Two priority types affect a queued NQS request:

Execution Priorities

For an executing request, the priority value is its nice value. A nice value exists for every executing process. The NQE administrator defines a default nice value increment for each batch queue. This value is assigned to a request when it is placed in the batch queue.

The nice value assigned to a request is the sum of the default system nice value, the request's nice increment, and the request owner's nice increment on the machine of execution.

You can override this default value in the following ways:

• Use the NQE GUI Submit window and select Job limits on the Configure menu. Enter the nice value for the Nice Increment option, and apply your entry (click on the Apply button). To save your changes, use the Save Current Job Profile option.

• Use the cqsub -ln command or the qsub -ln command.

To view nice values for requests, see “Determining Resources”.

---

Note: If you decrease the nice value, you increase the relative execution priority of a process. If you increase the nice value, you decrease the relative priority of the request.

---

You can specify nice increments that are outside the limits for the executing host. In such cases, NQS limits the specified nice increment to a value within the necessary range. Any nice increment that you specify must be acceptable to the batch queue in which the request is placed.

The IRIX 6.5 release introduces a new scheduler called the Miser scheduler. The Miser scheduler (also referred to as Miser) is a predictive scheduler. As a predictive scheduler, Miser evaluates the number of CPUs and amount of memory a batch job will require. Using this information, Miser consults a schedule that it maintains concerning the utilization of CPU and memory resources on the system. Miser will determine when the batch job can be started so that it meets its requirements for CPUs and memory. The batch job will be scheduled to begin execution based on that time.

Miser reserves the resources that a batch job requests. As a result, when the batch job begins to execute, it will not need to compete with other processes for CPU and memory resources. However, Miser may require that a job wait until its reservation period begins before it begins execution. There are some exceptions to this process. Batch jobs must provide the Miser scheduler with a list of resources that they will require. Currently, those resources are the number of CPUs, the amount of memory, and the length of time required.

For a request to be successfully submitted to the Miser scheduler on an NQE execution host, the following criteria must be met:

qsub -X miser,seg,c=INT,m=INT[k|m|g][b],t=[H:M.S|INT[s|m|h]]
[,static][,mult=INT][,exc=kill][,seg,c=INT,m=INT[k|m|g][b],
t=[H:M.S|INT[s|m|h]][,static][,mult=INT][,exc=kill][...]