QSUB(1) Network Queuing Env. 3.3 Last changed: 4-13-98 NNAAMMEE qqssuubb - Submits a batch request to NQS SSYYNNOOPPSSIISS qqssuubb [--aa _d_a_t_e-_t_i_m_e] [--AA _a_c_c_o_u_n_t__p_r_o_j_e_c_t__n_a_m_e] [--CC _c_o_m_p_a_r_t_m_e_n_t_s] [--ee _f_i_l_e] [--eeoo] [--jj _f_i_l_e] [--JJ mm] [--JJ nn] [--JJ yy] [--kkee] [--kkjj] [--kkoo] [--ll _r_e_s_o_u_r_c_e__l_i_s_t] [--llaa _a_t_t_r_i_b_u_t_e_s] [--llcc _l_i_m_i_t] [--lldd _l_i_m_i_t] [--llff _l_i_m_i_t] [--llFF _l_i_m_i_t] [--llmm _l_i_m_i_t] [--llMM _l_i_m_i_t] [--llnn _i_n_c_r_e_m_e_n_t] [--llQQ _l_i_m_i_t] [--llss _l_i_m_i_t] [--lltt _l_i_m_i_t] [--llTT _l_i_m_i_t] [--llUU_t_y_p_e _l_i_m_i_t] [--llww _l_i_m_i_t] [--LL _l_e_v_e_l] [--mmbb] [--mmee] [--mmrr] [--mmtt] [--mmuu _u_s_e_r-_n_a_m_e] [--nncc] [--nnrr] [--oo _f_i_l_e] [--pp _p_r_i_o_r_i_t_y] [--qq _q_u_e_u_e-_n_a_m_e] [--rr _r_e_q_u_e_s_t-_n_a_m_e] [--rree] [--RRff] [--rroo] [--ss _s_h_e_l_l-_n_a_m_e] [--uu _u_s_e_r-_n_a_m_e] [--xx] [--XX _l_o_c_a_l-_s_c_h_e_d-_o_p_t_s] [--zz] [_f_i_l_e] IIMMPPLLEEMMEENNTTAATTIIOONN IRIX systems UNICOS/mk systems UNICOS systems AIX systems Digital UNIX systems HP-UX systems Solaris systems DDEESSCCRRIIPPTTIIOONN The qqssuubb command submits a file that contains a shell script as a batch request to the Network Queuing System (NQS). For an introduction to the use of NQS, see the _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148. The qqssuubb command supports the following options (for detailed information about each option and its arguments, see the Detailed Explanation of Options subsection): --aa Specifies the earliest date and/or time at which NQS should run the request. --AA (For systems running UNICOS or IRIX 6.2 or later only) Specifies the UNICOS account name or the IRIX project name under which the request will run. --CC Specifies active security compartments for the request. --ee Directs the standard error output produced by the request to the stated file destination. If you specify an incomplete path name, it will be interpreted on the originating machine. You should ensure (by using a complete path name, if necessary) that the output file name is valid on the execution machine. This is true whether or not the --rroo or --rree options are used. --eeoo Merges the standard error and standard output files produced by the request. --jj Directs the job log to the stated file destination. --JJ mm Appends the job log to the standard output file. --JJ nn Specifies that you do not want to receive a job log. --JJ yy Specifies that you want to receive a job log. --kkee Keeps the standard error file on the server that executed the request. --kkjj Keeps the job log file on the server that executed the request. --kkoo Keeps the standard output file on the server that executed the request. --ll Specifies the job resource limits. --llaa Specifies the request attributes. --llcc Specifies the per-process core file size limit. --lldd Specifies the per-process data segment size limit. --llff Specifies the per-process permanent file space limits. --llFF Specifies the per-request permanent file space limits. --llmm Specifies the per-process memory size limits. --llMM Specifies the per-request memory size limits. --llnn Specifies the per-process nice increment. --llQQ Specifies the per-request secondary data segment (SDS) limits. --llss Specifies the per-process stack size limit. --lltt Specifies the per-process CPU time limits. --llTT Specifies the per-request CPU time limits. --llUU_t_y_p_e Specifies the per-request tape drive limits, which can be aa, bb, cc, dd, ee, ff, gg, or hh. --llww Specifies the per-process working set size limit. --LL Specifies the active security level for the request. --mmbb Sends mail when the request begins execution. --mmee Sends mail when the request ends execution. --mmrr Sends mail when the request is rerun. --mmtt Sends mail when a request leaves a pipe queue for another destination. --mmuu Specifies the user name to which NQS will send mail about this request. --nncc (UNICOS UNICOS/mk, and IRIX systems only) Specifies that the batch request will not be checkpointed. --nnrr Specifies that the batch request cannot be rerun. --oo Directs the standard output to the stated file destination. If you specify an incomplete path name, it will be interpreted on the originating machine. You should ensure (by using a complete path name, if necessary) that the output file name is valid on the execution machine. This is true whether or not the --rroo or --rree options are used. --pp Specifies the user-requested priority for all systems or the Unified Resource Manager (URM) priority increment for UNICOS systems running URM. --qq Specifies the name of the queue in which the request will be initially submitted. --rr Assigns the specified name to the request. --rree Writes the standard error file of the request to its destination while the request executes. The output may not appear immediately in the output files due to ssttddiioo buffering (as much as 4K may be buffered). If the job output is small, it may not appear until the job completes. --RRff (UNICOS and UNICOS/mk systems only) Forces the request to be restarted from a checkpoint image. --rroo Writes the standard output file of the request to its destination while the request executes. The output may not appear immediately in the output files due to ssttddiioo buffering (as much as 4K may be buffered). If the job output is small, it may not appear until the job completes. --ss Specifies the initial shell spawned by NQS. --uu Runs the request under the specified user name. --xx Exports all environment variables with the request. --XX Specifies the options for the local scheduler extensions. Currently, the IRIX Miser scheduler is the only supported local scheduler extension. --zz Submits the request without displaying the confirmation message. _f_i_l_e Specifies the name of the script file that will be submitted as a batch request. If you omit it, the qqssuubb command creates the batch request from subsequent lines entered from standard input, until you press . During batch request submission, the script file is spooled so that subsequent changes to the original file do not affect the queued batch request. If the batch request is submitted successfully, NQS displays a _r_e_q_u_e_s_t _i_d_e_n_t_i_f_i_e_r associated with the batch request and the name of the NQS queue that initially accepted the request. If you specify the --zz option, qqssuubb displays no information. The request identifier uniquely identifies your batch request throughout the NQS network. The format of the identifier is as follows: _s_e_q_u_e_n_c_e-_n_u_m_b_e_r.._h_o_s_t NQS assigns the _s_e_q_u_e_n_c_e-_n_u_m_b_e_r to your batch request; _h_o_s_t is the name of the host at which the request was submitted. By default, NQS returns the files produced by your request to the host and directory from which the request was submitted, under the following names: Standard error file _r_e_q_u_e_s_t__n_a_m_e..ee_s_e_q_u_e_n_c_e__n_u_m_b_e_r Standard output file _r_e_q_u_e_s_t__n_a_m_e..oo_s_e_q_u_e_n_c_e__n_u_m_b_e_r Job log file _r_e_q_u_e_s_t__n_a_m_e..ll_s_e_q_u_e_n_c_e__n_u_m_b_e_r Only the first 7 characters of the actual request name are used for the _r_e_q_u_e_s_t-_n_a_m_e argument in the previous files. To override these file names, use the --ee, --jj, and --oo options of the qqssuubb command. If the UNICOS multilevel security (MLS) feature or the UNICOS/mk security enhancements are enabled on your NQS server, you cannot submit a request to a remote host if the remote host has a workstation access list (WAL) entry for the host of origin that restricts your access to NQS services. As an alternative to specifying options on the qqssuubb command line, you also can embed options within the script file. If the same option appears in the batch file and on the command line, the command-line option takes precedence. Options that are specified within the script file must precede the first executable shell command of the file. You must precede each line that contains an option with either the ## QQSSUUBB or ##QQSSUUBB string. For example, to specify that the batch request should be executed no earlier than 11 P. M. on Tuesday, enter the following command line: #QSUB -a "11pm tues." To append comments to an embedded option, precede them with the # symbol, as follows: #QSUB -a "11pm tues." # Sends request at 11 p.m. on Tuesday The following is an example of the use of embedded options within the script file: #QSUB -q batch1 # Queue request to queue: batch1. #QSUB -me # Send mail at request termination. #QSUB # No more embedded options. # . . . _R_e_s_t _o_f _s_c_r_i_p_t _f_i_l_e To specify the qqssuubb options for a batch request submitted from a front-end system through station software, include the options within the file, as described in the preceding example. The first line of the file must specify the user name and password of the submitter, as required by the station software. For other examples of NQS batch requests, see the EXAMPLES section. DDeettaaiilleedd EExxppllaannaattiioonn ooff OOppttiioonnss This section provides more detailed information about the qqssuubb options. --aa _d_a_t_e-_t_i_m_e Prevents the batch request from beginning execution until the specified date and time. The _d_a_t_e-_t_i_m_e argument is specified as follows: [_d_a_t_e] [_t_i_m_e] [_t_i_m_e__z_o_n_e] Permissible forms for _d_a_t_e are as follows: _M_M/_D_D _D_D-_M_o_n_t_h _Y_Y_Y_Y _Y_Y_Y_Y-_M_M-_D_D _M_M/_D_D/_Y_Y _D_D-_M_o_n_t_h _Y_Y_Y_Y-_M_M-_D_D _M_M/_D_D _Y_Y_Y_Y _D_D-_M_o_n_t_h-_Y_Y _Y_Y_Y_Y _M_o_n_t_h _D_D _M_o_n_t_h _D_D _D_D-_M_o_n_t_h-_Y_Y_Y_Y _Y_Y_Y_Y _D_D-_M_o_n_t_h _M_o_n_t_h _D_D _Y_Y_Y_Y If you omit _d_a_t_e, the current day is assumed. The _M_o_n_t_h is specified in full or as any acceptable prefix of the calendar month that is a minimum of three characters; _M_o_n_t_h is case-insensitive. The day (_D_D) is specified in full or as any acceptable prefix of the day of the week that is a minimum of three characters; _D_D is case-insensitive. An optional .. symbol may follow the specification. Alternative specifications are as follows: today tomorrow Permissible forms for _t_i_m_e are as follows: _H_H<_m_e_r_i_d_i_a_n> _H_H:_M_M<_m_e_r_i_d_i_a_n> _H_H:_M_M:_S_S<_m_e_r_i_d_i_a_n> noon midnight Permissible forms for _m_e_r_i_d_i_a_n are as follows: am pm m (indicating noon) If you omit _m_e_r_i_d_i_a_n, a 24-hour clock interpretation is assumed. The _t_i_m_e__z_o_n_e is specified as any North American time zone or GGMMTT. If you omit _t_i_m_e__z_o_n_e, the local time zone prevails. If time zones will change in the interval during which you submitted the request and the request is scheduled to run (for example, your time zone changed from standard time to daylight savings time, or the request was sent from a machine in one time zone to a machine in another time zone), you can specify the desired time zone of the request. For example, if you want to run a request at 12:00 P.M. on December 1, you can specify the time zone, as follows: qsub -a "01-December-1993 noon CST" You must enclose a _d_a_t_e-_t_i_m_e specification that contains space characters within double quotation marks, as follows: -a "July 4, 2026 12:31EDT" The following are valid _d_a_t_e-_t_i_m_e specifications: "01-Jan-1993 12am, PDT" "Tuesday, 23:00:00" "11pm tues." "tomorrow 23 MST" If you specify --aa 1122ppmm, 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 Because of a problem storing future date specifications, you currently cannot specify a date later than 31-December-2037. --AA _a_c_c_o_u_n_t__p_r_o_j_e_c_t__n_a_m_e (For systems running UNICOS or IRIX 6.2 or later only) Specifies the UNICOS account name or the IRIX project name under which the request will run. For UNICOS systems, _a_c_c_o_u_n_t__p_r_o_j_e_c_t__n_a_m_e is a valid UNICOS account name of the user on the host on which the request will run; it can be from 1 through 79 printable characters (for example, ASCII 0x20 (space) through 0x7E (tilde)). For IRIX systems, _a_c_c_o_u_n_t__p_r_o_j_e_c_t__n_a_m_e is a valid IRIX project name for the user on the host on which the request will run; it can be from 1 through 32 printable characters (for example, ASCII 0x20 (space) through 0x7E (tilde)). For more information about alternative account name or project name specification, see the NOTES section. --CC _c_o_m_p_a_r_t_m_e_n_t_s (UNICOS MLS enabled or UNICOS/mk security-enhanced systems only) Specifies the active security compartments for the request. _c_o_m_p_a_r_t_m_e_n_t_s has the following format: _c_o_m_p_a_r_t_m_e_n_t__n_a_m_e[,_c_o_m_p_a_r_t_m_e_n_t__n_a_m_e[,...]] The compartments must be symbolic compartment names (see sseettuuccmmpp(1)). If the compartment set does not dominate the active compartment set, the request will not be accepted into the batch queue. The setting of security compartments restricts where the output can be returned. If you do not specify either the --CC or --LL option, your active security label will be used for the job execution label. If you specify only one of these options, the other option will default to your job submission label. --ee _f_i_l_e Directs the standard error file ((ssttddeerrrr)) produced by the batch request to the specified destination. The following specifications for _f_i_l_e are valid: _f_i_l_e_n_a_m_e Uses the default destination, which is the user's working directory when the request is submitted. _d_i_r_e_c_t_o_r_y Returns the output to the specified directory on the local host (that is, the host from which the request was submitted). _h_o_s_t::_f_i_l_e_n_a_m_e Returns the output to the specified host and path name in the network. The path also can be a local directory. To return ((ssttddeerrrr)) to the standard output (ssttddoouutt) file, you must use the --eeoo option. If you specify the same file for both the --ee and --oo options, you will receive an error message. When you specify the --eeoo option in addition to the --ee _f_i_l_e option, you will receive an error message. When you specify the --kkee option in addition to the --ee _h_o_s_t:_f_i_l_e_n_a_m_e option, you will receive an error message. If the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on your system, the standard error file is created at the job execution label. You must specify an appropriately labeled directory. For more information, see the _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148. --eeoo Directs all output that usually is sent to the standard error (ssttddeerrrr) file to the standard output (ssttddoouutt) file for the batch request. When you specify the --ee _f_i_l_e or --kkee option in addition to the --eeoo option, you will receive an error message. When you specify the --rree option in addition to the --eeoo option, the option that is specified first is ignored (that is, if you specify the qqssuubb --eeoo --rree command, the --eeoo option is ignored and both the ssttddeerrrr and ssttddoouutt files are created). --jj _f_i_l_e Directs the job log file that the batch request produces to the specified destination. _f_i_l_e has the format described under the --ee option. To return the job log file to the standard output (ssttddoouutt) file, you must use the --JJ mm option. If you specify the same file for both the --jj and --oo options, you will receive an error message. If the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on your system, the job log file is created at the job execution label. You must specify an appropriately labeled directory. For more information, see the _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148. --JJ mm Appends all output that usually is sent to the job log by request to the standard output file for the batch request. --JJ nn Specifies that you do not want to receive a job log. --JJ yy Specifies that you want to receive a job log. --kkee Leaves the ssttddeerrrr file on the host at which the request executed; usually, NQS returns the ssttddeerrrr file to the host at which the request was submitted. If you specify the --eeoo option or if you include an explicit _h_o_s_t destination in the _f_i_l_e argument of the --ee option in addition to the --kkee option, you will receive an error message. --kkjj Leaves the job log file on the machine at which the request executed; usually, NQS returns the job log file to the machine from which the request was submitted. --kkoo Keeps the ssttddoouutt file on the host at which the request executed; usually, NQS returns the ssttddoouutt file to the host from which the request was submitted. If you include an explicit _h_o_s_t destination in the _f_i_l_e argument of the --oo option in addition to the --kkoo option, you will receive an error message. --ll _r_e_s_o_u_r_c_e__l_i_s_t Specifies the request resource limits; the _r_e_s_o_u_r_c_e__l_i_s_t is a series of resources that have the following format: _r_e_s_o_u_r_c_e = _v_a_l_u_e[,_r_e_s_o_u_r_c_e = _v_a_l_u_e,...] The valid resource names and descriptions are as follows: mmpppp__pp Specifies the maximum number of Cray MPP processing elements (PEs) on a Cray MPP system or the maximum number of CPUs on an Origin 64- bit system that are accessible at the local host; this variable is an integer from 0 to 65,536. The alternative form mmaaxxiimmuumm or uunnlliimmiitteedd, or any leading substring thereof, indicates that the maximum value permitted by the user is required. If the total number of Cray MPP PEs or CPUs requested by all processes of the request exceeds the specified limit, an error condition occurs. mmpppp__tt Specifies the maximum per-request CRAY T3D MPP wall-clock residency time or the CRAY T3E MPP connect time for a multiple processing element (PE) application. If the sum of the CRAY T3D MPP wall-clock residency time or the sum of the CRAY T3E MPP connect time for the multiple PE applications exceeds this limit, the batch request is terminated. For more information on the implementation of batch request limits and for a description of the syntax of these time limits, see the Limits subsection. pp__mmpppp__tt Specifies the maximum per-process CRAY T3D MPP wall-clock residency time or the CRAY T3E MPP connect time for a multiple processing element (PE) application. If the CRAY T3D MPP wall- clock residency time or the CRAY T3E MPP connect time for a multiple PE application process exceeds this limit, the batch request is terminated. For more information on the implementation of batch request limits and for a description of the syntax of these time limits, see the Limits subsection. sshhmm__ll[[iimmiitt]] Specifies the maximum shared memory size that the request can create. If you try to exceed this limit, an error condition occurs. For more information on the implementation of batch request limits and for a description of the syntax of a per-request shared memory size limit, see the Limits subsection. sshhmm__ss[[eeggmmeennttss]] Specifies the maximum number of shared memory segments that the request can create. The alternative syntax forms mmaaxxiimmuumm and uunnlliimmiitteedd, or any leading substring thereof, indicate that the maximum value permitted to the user is required. If you try to exceed this limit, an error condition occurs. --llaa _a_t_t_r_i_b_u_t_e_s Specifies the attributes of your request; _a_t_t_r_i_b_u_t_e_s has the following format: _a_t_t_r_i_b_u_t_e__n_a_m_e[,_a_t_t_r_i_b_u_t_e__n_a_m_e[,...]] When you specify _a_t_t_r_i_b_u_t_e_s, it restricts your request to the queues that have the specified attributes or to queues that have no attributes. If you do no specify request attributes, the request may be sent to any queue. To specify an attribute name, you can use the following characters: A through Z, a through z, 0 through 9, and the _ symbol. All embedded spaces are removed. When you specify more than one attribute, ensure that each attribute is separated with a comma. If you specify multiple --llaa options on a command line or in a script file, they are combined into one set of attributes in their respective command line or script file. If you specify --llaa options on a command line and a script file, the options on the command line take precedence. For example, you might specify the following attributes on a command line: qsub -la fast -la abc You might specify the following attributes in a script file: #QSUB -la xyz #QSUB -la 123 The attributes on the submitted job are as follows: qsub -la fast,abc --llcc _l_i_m_i_t Per-process core file size limit; the maximum size of a core file produced by any process in the request. --lldd _l_i_m_i_t Per-process data segment size limit; the maximum size to which the data segment can grow for any process in the request. This option is not enforced under UNICOS; the --llmm option is used instead to specify the UNICOS process memory limit. --llff _l_i_m_i_t Sets the per-process permanent file space limit; the maximum amount of disk space that can be allocated by any process of the job. The per-process request limit is the maximum size of files created by all processes of the request in any type of directory. For more information, see the Limits subsection. --llFF _l_i_m_i_t Sets the per-request permanent file space limit; the maximum amount of disk space that can be allocated by the request. The per-request limit is the maximum amount of disk space used by all processes that make up an NQS request. For more information, see the Limits subsection. --llmm _l_i_m_i_t Specifies the maximum memory size per process in a request. For more information, see the Limits subsection. --llMM _l_i_m_i_t Specifies the maximum memory size allowed for a request. If the total memory used by a request exceeds the specified limit, processes in the request are not allowed to allocate more memory. For more information, see the Limits subsection. --llnn _i_n_c_r_e_m_e_n_t Specifies the nice increment with which the nice value for the batch request will be adjusted on the executing machine. The nice value determines the execution time priority of a process relative to all other processes in the system. A decreasing nice value increases the relative execution priority of a process; an increasing nice value decreases the relative priority. The nice value assigned to a request at initiation is the sum of the default system nice value, the request's nice increment, and the request owner's user database (UDB) nice increment on the machine of execution. You can specify nice increments that are outside the limits for the executing machine. In such cases, NQS limits the specified nice increment to a value within the necessary range. Any nice increment that is specified by the use of this option must be acceptable to the batch queue in which the request is ultimately placed. For more information, see the Limits subsection. --llQQ _l_i_m_i_t (Cray PVP systems only) Specifies the maximum size of the secondary data segment (SDS) allowed for a batch request; the default is 0. The per-process SDS limit is set to the value of your UDB entry for per-process SDS limits. If the total SDS size used by a request exceeds the specified limit, processes in the request are not allowed to allocate more storage. For more information, see the Limits subsection. --llss _l_i_m_i_t Per-process stack segment size; the maximum size to which the stack can grow for any process in the request. --lltt _l_i_m_i_t Specifies the maximum CPU time for each process of a batch request (see the CAUTIONS section). If the CPU time limit is exceeded, the offending process is terminated. For more information on the implementation of batch request limits and for a description of the syntax of a per-process CPU time limit, see the Limits subsection. For CRAY T3D MPP systems, this option specifies the per-process maximum CPU time that is used by the attached Cray PVP system. For CRAY T3E MPP systems, this option specifies the per-process maximum CPU time that is used by a command processing element (PE). --llTT _l_i_m_i_t Specifies the cumulative CPU time limit allowed for a batch request (see the CAUTIONS section). If the total CPU time of all processes that constitute this request exceeds this limit, the batch request is terminated. For more information on the implementation of batch request limits and for a description of the syntax of a per-request CPU time limit, see the Limits subsection. For CRAY T3D MPP systems, this option specifies the per-request maximum CPU time that is used by the attached Cray PVP system. For CRAY T3E MPP systems, this option specifies the per-request maximum CPU time used by a command processing element (PE). --llUU_t_y_p_e _l_i_m_i_t Specifies the maximum number of tape drives of a specific device group allowed for a batch request. _t_y_p_e can be aa, bb, cc, dd, ee, ff, gg, or hh. Do not place a space character between --llUU and _t_y_p_e. If the total number of drives of a specific device group used by a request exceeds the specified limit, an error condition occurs. For more information, see the Limits subsection. --llww _l_i_m_i_t Specifies the per-process working set size; the maximum size to which the working set can grow for any process in the request. If you use this option when running Solaris 2.5 and using the Distributed Computing Environment (DCE) with NQE 3.2, you must specify a value of 77mmww or larger, or the request will not be accepted. --LL _l_e_v_e_l (UNICOS MLS-enabled or UNICOS/mk security-enhanced systems only) Specifies the active security level for the request. If the security level requested is lower than the current active level for a locally submitted request or lower than the user's minimum level for a remotely submitted request, the job will not be accepted into a batch queue. The setting of the security level restricts where the output can be returned. If you do not specify either the --LL or --CC option, your active security label will be used for the job execution label. If you specify only one of these options, the other option will default to your job submission label. --mmbb Sends mail to the user who submitted the request when the request begins execution. If you also use the --mmuu option, NQS sends mail to the user specified by the --mmuu option rather than to the submitting user. --mmee Sends mail to the user who submitted the request when the request has ended execution. If you also use the --mmuu option, NQS sends mail to the user specified by --mmuu, rather than to the submitting user. --mmrr Sends mail to the user who submitted the request when the request is rerun. If you also use the --mmuu option, NQS sends mail to the user specified by the --mmuu option, rather than to the submitting user. --mmtt Sends mail to the user who submitted the request when the request is routed from a pipe queue to another destination. If you also use the --mmuu option, NQS sends mail to the user specified by the --mmuu option rather than to the submitting user. --mmuu _u_s_e_r-_n_a_m_e Specifies that any mail that concerns the request is delivered to the user _u_s_e_r-_n_a_m_e; _u_s_e_r-_n_a_m_e may take the form _u_s_e_r (containing no @ symbol) or _u_s_e_r@@_h_o_s_t. If you omit the --mmuu option, NQS sends any mail that concerns the request to the user name who submitted the request at the host from which the request was submitted. To send mail to more than one user, you can specify multiple _u_s_e_r_n_a_m_e arguments that are each separated by a comma (for example, --mmuu ffrreedd@@wwoorrkk11,,ssaallllyy@@wwoorrkk22, with no space between the comma and the _u_s_e_r_n_a_m_e argument. --nncc (UNICOS, UNICOS/mk, and IRIX systems only) Specifies that the request should not be checkpointed at the time of an NQS shutdown. If you use the qqcchhkkppnntt(1) command within the request, this option also prevents any checkpoint being taken. If you use the --nncc option, NQS may try to rerun the request, unless you also use the --nnrr option. For more details, see the description of --nnrr. If you omit the --nncc option, NQS assumes that a request can be checkpointed. When the system is shut down and later restarted, the batch request resumes processing from its restart image at the time of the system shutdown. Requests that are not running at the time of a NQS server crash or shutdown are always preserved for later requeuing, with or without this option. For more information about the checkpoint and restart of batch requests, see the NOTES section. --nnrr (UNICOS systems only) Specifies that the batch request cannot be rerun; if the request was running at the time of an NQS shutdown or system crash, the request does not rerun at the next NQS startup. If you omit the --nnrr option, NQS assumes that the request can be rerun. A request that is not running at the time of a NQS server crash or shutdown is always preserved for later requeuing, with or without this option. --oo _f_i_l_e Directs the standard output file (ssttddoouutt) that the batch request produces to the specified destination. _f_i_l_e has the format described under the --ee option. To return the ssttddeerrrr file or the job log file to the ssttddoouutt file, you must use the --eeoo or --JJ mm options, respectively. If you specify the same file for the --ee, --jj, and --oo options, you will receive an error message. When you specify the --kkoo option in addition to the --oo _h_o_s_t:_f_i_l_e_n_a_m_e option, you will receive an error message. If the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on your system, the output file is created at the job execution label. You must specify an appropriately labeled directory. --pp _p_r_i_o_r_i_t_y Specifies the user-requested priority for all systems or the Unified Resource Manager (URM) priority increment for UNICOS systems running URM. The _p_r_i_o_r_i_t_y is an integer between 0 and 63. If you do not use this option, the default is 1. If you are running URM, the _p_r_i_o_r_i_t_y is passed to URM during request registration. URM adds this value as an increment value to the priority that it calculates for the request. --qq _q_u_e_u_e-_n_a_m_e Specifies the queue to which the batch request is submitted. If you omit this option, NQS examines the QQSSUUBB__QQUUEEUUEE environment variable and sends the request to the queue defined there. If the environment variable is not found, the request is sent to the default batch request queue designated by the system administrator. If the system administrator has not defined a default queue, the qqssuubb command displays an error message and the request is not submitted. --rr _r_e_q_u_e_s_t-_n_a_m_e Assigns the specified _r_e_q_u_e_s_t-_n_a_m_e to the request. If a request name begins with a digit, the letter RR is automatically prefixed to it. If you omit the --rr option, the default request name is the name of the script file that has the leading path name removed, as given on the command line. If the commands that will be submitted are being read from standard input, rather than from a script file, the request name is SSTTDDIINN. --rree Specifies that the ssttddeerrrr output that the request produces is written to the final destination file while the request executes. If the destination file is at an NQS server other than the execution server, this option is ignored. By default, all standard error output that a request generates is spooled to a temporary file in a protected directory, which NQS maintains on the executing machine. When the batch request completes execution, this file is spooled to its final destination, possibly at a remote system. When you specify the --eeoo option in addition to the --rree option, the option that is specified first is ignored (that is, if you specify the qqssuubb --rree --eeoo command, the --rree option is ignored and all output that usually is sent to the ssttddeerrrr file is sent to the ssttddoouutt file). --RRff (UNICOS and UNICOS/mk systems only) Specifies that the request can be restarted from a checkpoint image, even if the files have been modified since the checkpoint image was created. --rroo Specifies that the ssttddoouutt file that the request produces is written to the destination file while the request executes. If the destination file is at an NQS server other than the execution server, this option is ignored. By default, all standard output that a batch request generates is spooled to a temporary file in a protected directory on the executing machine. When the batch request completes execution, this file is spooled to its final destination, possibly at a remote system. --ss _s_h_e_l_l__n_a_m_e Specifies the full path name of the first shell used to interpret your batch request's shell script; by default, NQS uses your default login shell. You can specify the ccsshh, kksshh, or sshh shell names. NQS uses a two-shell invocation method by default. If no shell is specified with the --ss option, your login shell is used. When NQS initiates the request, a second shell is spawned. The second shell invoked is always //bbiinn//sshh, unless you have specified another shell. The two-shell invocation method allows ssttddiinn read-ahead by commands such as rreemmsshh(1B) and ccaatt(1). To specify a shell other than //bbiinn//sshh to interpret your batch request, you must include the following command as the first line of the request file (before any ##QQSSUUBB directives): ##!! _s_h_e_l_l__p_a_t_h The _s_h_e_l_l__p_a_t_h argument is the full path name to the shell that you want to use (such as //bbiinn//ccsshh). You can include shell options on this line. NQS sets the QQSSUUBB__SSHHEELLLL environment variable to the shell that you were in when you executed the qqssuubb command. NQS sets the SSHHEELLLL environment variable to the initial shell that was executed by NQS. The initial shell is not necessarily the same shell as the second shell. The second shell is always //bbiinn//sshh, unless you include the ##!! _s_h_e_l_l__p_a_t_h command as the first line of the batch request. When your ..ccsshhrrcc file is read, the shell may find commands that it cannot invoke and cause your request not to run. You will see these problems reflected in your standard error file. To specify the one-shell invocation method, use the following command (for each request) to set the NNQQSSCCHHGGIINNVVOOKKEE environment variable to ttrruuee or yyeess (this example uses the ccsshh syntax): sseetteennvv NNQQSSCCHHGGIINNVVOOKKEE ttrruuee You can now submit the request and include the qqssuubb --xx option to export environment variables. If NNQQSSCCHHGGIINNVVOOKKEE is set to ttrruuee and you do not request a shell by using the qqssuubb --ss command, NQS invokes the request owner's UDB shell. --uu _u_s_e_r-_n_a_m_e Specifies the UNICOS user name that will own the request. When the submitting user is rroooott, this option is not valid. For more information about alternative user specification and user validation, see the NOTES section. --xx Exports all environment variables (except EENNVVIIRROONNMMEENNTT). When a batch request is submitted, NQS saves the current values of the HHOOMMEE, SSHHEELLLL, PPAATTHH, LLOOGGNNAAMMEE, MMAAIILL, TTZZ, and UUSSEERR environment variables to be created again as the respective QQSSUUBB__HHOOMMEE, QQSSUUBB__SSHHEELLLL, QQSSUUBB__PPAATTHH, QQSSUUBB__LLOOGGNNAAMMEE, QQSSUUBB__MMAAIILL, QQSSUUBB__TTZZ, and QQSSUUBB__UUSSEERR environment variables. If you specify the --xx option, all remaining environment variables whose names do not conflict with the automatically exported variables also are exported. When the batch request is spawned for execution, these additional environment variables are re-created under the same name. If you omit the --xx option, no other environment variables are exported from the originating host for the batch request. --XX _l_o_c_a_l-_s_c_h_e_d-_o_p_t_s Specifies the options for the local scheduler extensions. The generic format for _l_o_c_a_l-_s_c_h_e_d-_o_p_t_s is as follows: _l_o_c_a_l__s_c_h_e_d_u_l_e_r__n_a_m_e[,_s_u_b_o_p_t[=_v_a_l][,_s_u_b_o_p_t[=_v_a_l]]...] You must specify a _l_o_c_a_l__s_c_h_e_d_u_l_e_r__n_a_m_e suboption. It identifies the local scheduler extension feature of the specified option. The processing of the option is based on the _l_o_c_a_l__s_c_h_e_d_u_l_e_r__n_a_m_e suboptions. The valid _l_o_c_a_l__s_c_h_e_d_u_l_e_r__n_a_m_e suboptions and descriptions are as follows: mmiisseerr Specifies the local scheduler extension options for the IRIX Miser scheduler. The syntax for the Miser suboptions is as follows: miser,seg,c=_I_N_T,,mm==_I_N_T[[kk||mm||gg]][[bb]],,tt==[[_H::_M._S||_I_N_T[[ss||mm||hh]]]] [[,,ssttaattiicc]] [[,,mmuulltt==_I_N_T]][[,,eexxcc==kkiillll]] [[,,sseegg,,cc==_I_N_T,,mm==_I_N_T[[kk||mm||gg]][[bb]],,tt==[[_H::_M.._S||_I_N_T[[ss||mm||hh]]]] [[,,ssttaattiicc]][[,,mmuulltt==_I_N_T]][[,,eexxcc==kkiillll]][[......]] Currently, Miser allows only one resource segment description. As a result, only one of the segment keywords, and following resource suboptions are allowed. You must define the sseegg, cc, tt, and mm suboptions for a segment. The suboptions are as follows: sseegg Begins the definition of a new Miser resource segment. cc==_I_N_T Defines the number of CPUs to reserve. mm==_I_N_T[[kk||mm||gg]][[bb]] Defines the amount of memory, in bytes, to reserve. You can optionally specify the bytes as either kk (or kkbb), mm, or gg for kilobytes, megabytes, or gigabytes, respectively. tt==[[_H:_M._S|_I_N_T[[ss||mm||hh]]]] Defines the amount of time that the resource segment reservation will last. The time can be specified either as _h_o_u_r_s:_m_i_n_u_t_e_s._s_e_c_o_n_d_s or as a value that uses a suffix to define it as seconds (ss), minutes (mm), or hours (hh). If you do not specify a suffix, seconds will be used. The time value does not specify a wall-clock time for the reservation. The specified time value should be the wall-clock time desired, multiplied by the number of CPUs requested. ssttaattiicc Specifies that the request will run as a static Miser request. A request that is submitted to the Miser scheduler can run opportunistically, unless it is specified that the request is static. An opportunistic request will run before its reservation period, if free resources exist on the host. The time spent running opportunistically is not counted against the reservation period that Miser maintains for the request. A static request cannot run before the reservation period that is scheduled by the Miser scheduler. mmuulltt==_I_N_T Defines the multiples of CPUs that are required for the request to run. If the number of CPUs cannot be supplied by Miser, this value will indicate the minimum sets of CPUs that are required to schedule the job. For opportunistic requests, this also indicates the multiples of CPUs that must be free for the request to be scheduled by the operating system as a runnable set of processes. eexxcc==kkiillll Defines how Miser should handle exceptions events. Exceptions events include the expiration of the reservation period or exhausting the memory reservation. Currently, the only exception handling selection that Miser allows is to kill the request. An example of the use of the --XX option to specify Miser resources is as follows: qsub -q batch1 -X miser,seg,c=32,m=1230m,t=32:00 This example submits a request to the queue bbaattcchh11. When the job is selected to run it must be able to obtain a schedule for 32 CPUs and 1.23 Gigabytes of memory for one hour. During the scheduled period, the request has exclusive access to the CPU and memory resources. In order for a request to be scheduled through the Miser scheduler, the following criteria must be met: 1. The request must specify Miser options through the local scheduler extension options (the --XX option). 2. The execution host must be running with the NQS job scheduling class of mmiisseerr nnoorrmmaall (see the qqmmggrr(8) command). 3. The NQS batch queue must be directed to forward any requests to a Miser queue. 4. Miser must be active on the system. 5. The destination Miser queue must be available. If all of these criteria are met when the request is being analyzed to determine if it can be launched, Miser will be queried to determine if the request can be scheduled to run before the scheduling window expires (the scheduling window is defined to move requests from the NQS batch queue to the Miser queue). If the request can be scheduled, it is executed and placed under control of the Miser scheduler. --zz Submits the batch request silently. If the request is submitted successfully, no indicating messages are displayed. Error messages are still displayed. _f_i_l_e Specifies the name of the file that will be submitted as a batch request to NQS. NNOOTTEESS The following subsections provide more detailed information on how NQS processes batch requests. SSeeqquueennccee ooff EEvveennttss When NQS selects a batch request for execution, the following events occur in the specified order: 1. NQS validates any user name specified by the qqssuubb --uu command. 2. NQS creates the job that consists of all processes of the batch request. For a local UNICOS or IRIX (6.2 or later release) job submission, the Account/Project field is set to the account name (UNICOS) or project name (IRIX) in use when the request is submitted; otherwise, the Account/Project field is set to the default account name or project name for the user at the local host. 3. NQS sets the real and effective user IDs of the parent process to those of the submitter. 4. NQS sets the real and effective group IDs of the parent process to the default (login) group IDs of the submitter. 5. NQS sets the user file creation mask to the value existing on the originating machine at the time of submission. 6. If you specify a shell, NQS selects the specified shell to execute the batch request; otherwise, the shell defined by your user database (UDB) is used. 7. NQS sets the HHOOMMEE, SSHHEELLLL, PPAATTHH, LLOOGGNNAAMMEE, MMAAIILL, and UUSSEERR environment variables from the local password file entry of the submitter. 8. NQS adds the environment string EENNVVIIRROONNMMEENNTT==BBAATTCCHH to the environment so that shell scripts (including ..pprrooffiillee, ..ccsshhrrcc, and ..llooggiinn files) can test for batch request execution when appropriate. 9. NQS adds the following variables to the environment of the request: QQSSUUBB__HHOOSSTT Name of the host at which the request was submitted QQSSUUBB__RREEQQIIDD NQS request identifier QQSSUUBB__RREEQQNNAAMMEE Name of the NQS request QQSSUUBB__WWOORRKKDDIIRR Current directory when the request was submitted 10. NQS adds all other variables of the submitter's environment at the time the batch request was spawned. When a batch request is initially submitted, the current values of the HHOOMMEE, SSHHEELLLL, PPAATTHH, LLOOGGNNAAMMEE, MMAAIILL, TTZZ, and UUSSEERR environment variables are saved for re-creation when the request executes. To avoid conflicts with the names of newly created environment variables, NQS adds the prefix QQSSUUBB__ to the exported variables, as follows: QQSSUUBB__HHOOMMEE, QQSSUUBB__SSHHEELLLL, QQSSUUBB__PPAATTHH, QQSSUUBB__LLOOGGNNAAMMEE, QQSSUUBB__MMAAIILL, QQSSUUBB__TTZZ, and QQSSUUBB__UUSSEERR. If you specify the --xx option, NQS adds any other variables present in the original environment of the submitter on the originating host. 11. The NNQQEE__GGRROOUUPP environment variable is exported unchanged into the request. For more information, see the cceevveenntt(1) man page. 12. NQS sets the current working directory to the home directory on the executing machine. The chosen shell then executes the batch- request shell script with the environment constructed as outlined in the preceding steps. 13. As a final step, NQS spawns the chosen shell as though it were the login shell. If the standard or Korn shell executes the script, the ..pprrooffiillee file is read. If the C shell executes the script, the ..ccsshhrrcc and ..llooggiinn scripts are read. QQuueeuuee AAcccceessss NQS supports queue access restrictions. For each queue, access may be either restricted or unrestricted. If access is unrestricted, any request may enter the queue. If access is restricted, a request can enter the queue only when the requester or the requester's login group has access to that queue. To determine who has access to a particular queue, use the qqssttaatt(1) command. LLiimmiittss NQS lets users set resource limits within which a request must execute. The system administrator can set the queue-specific request resource limits to prevent access by those requests whose resource requirements exceed those allowed by a particular queue. If you do not request any resources by using the qqssuubb options, the default limits for tapes and quickfile space is 0. Finite limits are expressed as a time, a quota, or an integer value. Finite time limits have the following format: [[_h_o_u_r_s:]_m_i_n_u_t_e_s:]_s_e_c_o_n_d_s[._m_i_l_l_i_s_e_c_o_n_d_s] The following time limits are all valid: "1234:58:21.29" _1_2_3_4 _h_o_u_r_s, _5_8 _m_i_n_u_t_e_s, _a_n_d _2_1._2_9_0 _s_e_c_o_n_d_s 12345 _1_2,_3_4_5 _s_e_c_o_n_d_s 121.1005 _1_2_1._1_0_1 _s_e_c_o_n_d_s 59:01 _5_9 _m_i_n_u_t_e_s _a_n_d _1 _s_e_c_o_n_d Finite quotas can have one of the following formats: ._f_r_a_c_t_i_o_n [_u_n_i_t_s] _i_n_t_e_g_e_r [._f_r_a_c_t_i_o_n] [_u_n_i_t_s] The _i_n_t_e_g_e_r token represents a string of up to 10 decimal digits. The _f_r_a_c_t_i_o_n token is rounded to the nearest 0.001 unit. The combined integer and fraction tokens cannot exceed 2,147,483,647. In both cases, you can specify the _u_n_i_t_s of allocation as one of the case-insensitive strings: bb Bytes ww Words. (A word is defined as the number of bytes returned by the C language ssiizzeeooff((lloonngg)) function. 1 word is 8 bytes on UNICOS, UNICOS/mk, and 64-bit IRIX systems; 4 bytes on all other supported systems.) KKbb Kilobytes (2**10 bytes) KKww Kilowords (2**10 words) MMbb Megabytes (2**20 bytes) MMww Megawords (2**20 words) GGbb Gigabytes (2**30 bytes) GGww Gigawords (2**30 words) In the absence of any _u_n_i_t_s specification, bytes are assumed. A finite integer value can be expressed with no units, and optionally it can be signed. To specify an unlimited value, use the string uunnlliimmiitteedd or any initial substring thereof (such as uunnll). If a resource request or limit cannot be exactly enforced because of its implementation, it will be rounded up to the next highest value that the implementation can enforce. If a batch request specifies a limit that cannot be enforced by the underlying UNIX implementation, the limit is ignored, and the batch request operates as though no limit exists. You cannot specify a limit value of 0, except when specifying nice values, tapes, and SDS limits. UUNNIICCOOSS RReessoouurrccee LLiimmiittss The limits currently enforced by the UNICOS system, their corresponding options, and the actions taken by the UNICOS system when the limits are reached are as follows: Per-process permanent file space limit (--llff) Per-request permanent file space limit (--llFF) If a job process tries to write to a file and that write exceeds the process's or the request's file space limit, the write fails with the EEDDIISSKKLLIIMM error. Per-process memory size limit (--llmm) Per-request memory size limit (--llMM) If you try to exceed these limits, the bbrrkk(2) and ssbbrrkk(2) system calls will fail with the EENNOOMMEEMM error. Per-request quickfile size limit (--llQQ) (CRAY PVP systems only) If you try to exceed the secondary data segments (SDS) limit, the ssssbbrreeaakk(2) system call will fail with the EENNOOMMEEMM error. Per-process CPU time limit (--lltt) Per-request CPU time limit (--llTT) If the per-process limit is exceeded, the SSIIGGCCPPUULLIIMM signal is sent to the offending process. By default, SSIIGGCCPPUULLIIMM terminates the process and the parent shell recognizes SSIIGGCCPPUULLIIMM and sends an error message to standard error. If the per-request CPU time limit is exceeded, the SSIIGGCCPPUULLIIMM signal is sent to all processes in the process group, which includes the parent shell. Per-request tape-drive limit (--llUUaa, --llUUbb, --llUUcc, --llUUdd, --llUUee, --llUUff, --llUUgg, --llUUhh) An attempt to exceed the tape drive limit for the batch request, using the rrssvv(1) command, fails with the EETTJJLLXX error. To determine the type of tape device group, use the ttppssttaatt(1) command. The first device group name listed in the ddggnn column of the ttppssttaatt display is type aa, the second listed is type bb, and so on. If you have not specified this option for the proper device group, the rrssvv(1) command in your file will fail. Per-request Cray MPP processing element (PE) limit (--ll mmpppp__pp) (Cray MPP systems only) An attempt to exceed this limit causes the failure of the loading of the associated binary file with the EEMMPPPPPPEEJJLLIIMM error. Per-process CRAY T3D MPP wall-clock residency time limit or the per-process CRAY T3E MPP connect time for a multiple processing element (PE) application (--ll pp__mmpppp__tt) Per-request CRAY T3D MPP wall-clock residency time limit or the per-request CRAY T3E MPP connect time for a multiple processing element (PE) application (--ll mmpppp__tt) (CRAY T3D MPP and CRAY T3E MPP systems only) If an executing CRAY T3D MPP or CRAY T3E MPP process exceeds the per-process limit, the SSIIGGCCPPUULLIIMM signal is sent to the offending process. After a predetermined amount of time has passed, the SSIIGGKKIILLLL signal is sent to the CRAY T3D MPP or CRAY T3E MPP process. An attempt to exceed either the per-process CRAY T3D MPP wall-clock residency time limit or the per-process CRAY T3E MPP connect time used by a multiple PE application when loading a binary file results in failure with the EEMMPPPPTTIIMMPPLLIIMM error. If a CRAY T3D MPP or a CRAY T3E MPP session exceeds the per-request limit, the SSIIGGCCPPUULLIIMM signal is sent to all executing CRAY T3D MPP or CRAY T3E MPP processes of the session. After a predetermined amount of time has passed, the SSIIGGKKIILLLL signal is sent to all of these processes. If the per-request limit has already been exceeded, any other attempts to load another CRAY T3D MPP or CRAY T3E MPP binary file will fail with the EEMMPPPPTTIIMMJJLLIIMM error. Per-request shared memory size limit (--ll sshhmm__ll[[iimmiitt]]) Per-request shared memory segment limit (--ll sshhmm__ss[[eeggmmeennttss]]) An attempt to exceed these limits causes the failure of the sshhmmggeett() system call with the EEMMEEMMLLIIMM error. IIRRIIXX RReessoouurrccee LLiimmiittss The limits currently enforced by the IRIX system, their corresponding options, and the actions taken by NQS when the limits are reached are as follows: Per-process core file size limit (--llcc) If the size of the process is larger than this limit, the writing of the core file will terminate at this size. If the core file size limit is uunnlliimmiitteedd, there is no restriction on the size of the core file. See the RRLLIIMMIITT__CCOORREE resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-process data segment size limit (--lldd) If a process tries to exceed the size limit of its data segment (or heap), the bbrrkk(2) function will fail with _e_r_r_n_o set to EENNOOMMEEMM. See the RRLLIIMMIITT__DDAATTAA resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-process permanent file space limit (--llff) If a process tries to create a file larger than the limit, the attempt fails. A limit of 00 prevents the creation of a file. See the RRLLIIMMIITT__FFSSIIZZEE resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-process memory size limit (--llmm) If a process tries to exceed the memory size limit, the bbrrkk(2) and mmmmaapp(2) functions will fail with _e_r_r_n_o set to EENNOOMMEEMM. See the RRLLIIMMIITT__VVMMEEMM resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-request memory size limit (--llMM) NQS checks the total memory that is allocated by all processes that are part of the request one time during each limit checking interval. If the total memory allocated exceeds the limit, the request is terminated through a SSIIGGTTEERRMM signal followed by a SSIIGGKKIILLLL signal. Requests can exceed the memory limit between the limit checking intervals. See the IRIX Per-request Limits Interval Processing subsection. Per-process stack segment limit (--llss) If a process tries to exceed its stack segment limit, it receives a SSIIGGSSEEGGVV signal. See the RRLLIIMMIITT__SSTTAACCKK resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-process CPU time limit (--lltt) If a process tries to exceed the CPU time limit, it receives a SSIIGGXXCCPPUU signal. See the RRLLIIMMIITT__CCPPUU resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-request CPU time limit (--llTT) NQS checks the total amount of CPU time that is used by all processes that are part of the request. If the total CPU time exceeds the limit, all processes in the request receive a SSIIGGXXCCPPUU signal, followed by the SSIIGGTTEERRMM and SSIIGGKKIILLLL signals. See the IRIX Per-request Limits Interval Processing subsection. Per-process working set limit (--llww) This limit imposes a cap on the amount of physical memory to be given to the process. If the kernel requires memory, it prefers to take memory from the processes that are exceeding their declared size. See the RRLLIIMMIITT__RRSSSS resource for the sseettrrlliimmiitt(2) function (on the ggeettrrlliimmiitt(2) man page). Per-request processor limit (--ll mmpppp__pp) If all the processes in the request exceed the physical processor limit, all processes in the request are terminated through a SSIIGGTTEERRMM signal followed by a SSIIGGKKIILLLL signal. Requests can exceed the processor limit between the limit checking intervals. See the IRIX Per-request Limits Interval Processing subsection. IIRRIIXX PPeerr--rreeqquueesstt LLiimmiittss IInntteerrvvaall PPrroocceessssiinngg The per-request limits are checked one time during each limits interval. The interval value is defined by the NNQQEE__NNQQSS__JJLL__IINNTTEERRVVAALL variable in the nnqqeeiinnffoo file. The default value is 0, which disables limits checking. To enable limits checking, you must specify a time interval value in seconds. Typically, values range from 15 seconds for high accuracy values to 120 seconds for low overhead checking. The limits that accumulate through time (such as CPU usage) are checked every interval and the limit action is applied to the job if the limit is exceeded. The limits that are snapshots of the current request usage (such as the amount of memory or the number of processors) are checked at the interval and the limit action is applied if the limit is exceeded. However, requests can exceed these limits between interval checks. SSiiggnnaall HHaannddlliinngg When an NQS batch request is spawned, a new job is established. Subsequently, all processes of the request exist in the same job. If you use the qqddeell(1) command to send a signal to an NQS batch request, the signal is sent to all processes of the request in the created job. When NQS checkpoints a batch request (checkpointing is available only on UNICOS, UNICOS/mk, and IRIX systems), there may be a grace period before the request is actually checkpointed. NQS sends a signal (the SSIIGGSSHHUUTTDDNN signal on UNICOS and UNICOS/mk systems and the SSIIGGCCKKPPTT signal on IRIX systems) to the batch request, waits until the grace period expires (if one exists), and then issues the checkpoint request. For more information on checkpointing, see the cchhkkppnntt(2) command on UNICOS and UNICOS/mk systems or the ccpprr(1) command on IRIX systems. The standard or Korn shell (sshh(1)) ttrraapp command provides an easy way of handling signals sent to a request. BBaattcchh RReeqquueesstt RReessttaarrtt When an operator shuts down NQS, NQS checkpoints and saves in a restart file all processes of a job that comprise a restartable running request on the local host. Checkpointing is available only on UNICOS, UNICOS/mk, and IRIX systems. For more information about checkpoint and restart on UNICOS and UNICOS/mk systems, see cchhkkppnntt(2) and rreessttaarrtt(2) in the _U_N_I_C_O_S _S_y_s_t_e_m _C_a_l_l_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, publication SR-2012, and the _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148. For more information about checkpoint and restart on IRIX systems, see the ccpprr(1) command on IRIX systems, and the _C_h_e_c_k_p_o_i_n_t _a_n_d _R_e_s_t_a_r_t _O_p_e_r_a_t_i_o_n _G_u_i_d_e, Silicon Graphics publication 007-3236-001. When a system administrator starts up NQS, checkpointed requests are restarted from the images in their respective restart files. The processes resume execution from a point before the checkpoint. Checkpoint and restart are automatic, unless you specified the --nncc option or the request does not meet the checkpoint and restart criteria. If the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled on your system, a checkpointed job cannot be restarted if the job execution label is no longer in the valid label range for the job owner and the host of origin. AAlltteerrnnaattiivvee AAccccoouunntt NNaammee oorr PPrroojjeecctt NNaammee (For systems running UNICOS or IRIX 6.2 or later only) To run a request on UNICOS systems under a specific account name or on IRIX systems under a specific project name, you can either use the --AA option or set the NNQQSS__AACCCCOOUUNNTTNNAAMMEE environment variable to the required account name or project name before request submission. When you specify the --AA option, it overrides the setting of the environment variable. If you do not specify an alternative account name or project name and the request executes at the local host, the request uses your account name or project name at time of submission. If you do not specify an alternative account name or project name 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 nneewwaacccctt(1) command. On IRIX systems, to find your default and valid project names, view the //eettcc//pprroojjeecctt file; the first project name on the list is your default project name. AAlltteerrnnaattiivvee UUsseerr To run a request under a user name different from that used to submit the request, you either must use the --uu option or set the NNQQSS__UUSSEERRNNAAMMEE environment variable to the alternative user name. After this is done, when the request enters a batch queue or is transferred to a remote machine, the alternative user owns the request. When the request begins execution, it is initiated as though the alternative user had submitted the request. UUsseerr VVaalliiddaattiioonn NQS supports two types of user validation, password checking and validation file checking. The qqmmggrr(8) command controls the selection of the types of user validation that are in effect. The validation is performed either when a request is transferred to a remote system or when a request is submitted by using the --uu option. If no validation is specified as being in effect, the target user is not checked. The --uu option may not be valid for remote requests that use file validation on UNICOS MLS or UNICOS/mk security-enhanced systems. When the UNICOS MLS feature or the UNICOS/mk security enhancements are enabled, the system might be configured to require the //eettcc//hhoossttss..eeqquuiivv and ..rrhhoossttss files to each contain a match for the remote host and require that the remote user and local user names match (that is, the --uu option is not allowed). For more information about user validation, see the _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148. CCAAUUTTIIOONNSS If you are running as rroooott, the CPU time limit does not apply. EEXXIITT SSTTAATTUUSS An exit status of 0 indicates normal completion. An exit status of 1 indicates a user error. An exit status of 2 indicates an NQS error. MMEESSSSAAGGEESS The standard error (ssttddeerrrr) file lists explanatory messages for all irregularities. The job log file lists explanatory messages for request-related events. EEXXAAMMPPLLEESS SSiimmppllee BBaattcchh RReeqquueesstt The following qqssuubb command line submits a script file called tteessttjjoobb to the default NQS queue: $ qqssuubb tteessttjjoobb Request <123.crayone>: Submitted to queue by . $ The following example submits tteessttjjoobb to a queue called eexxpprreessss: $ qqssuubb --qq eexxpprreessss tteessttjjoobb Request <124.crayone>: Submitted to queue by . $ BBaattcchh RReeqquueesstt wwiitthh CCoommmmaanndd--lliinnee OOppttiioonnss The following is an example of an NQS batch request submitted using command-line options: $ qqssuubb --rr bbiiggjjoobb --eeoo --oo lliisstt//bbiiggjjoobb..11 --llUUaa 22 --llMM 110000MMww --llTT 1100000000 tteessttjjoobb Request <125.crayone>: Submitted to queue by . $ This batch request has the name of bbiiggjjoobb (overriding the name that would be taken by default from the script file name). Its standard error (ssttddeerrrr) and standard output (ssttddoouutt) files are merged and returned to the lliisstt//bbiiggjjoobb..11 file, relative to the submitter's current directory. It requires the use of two tape drives of type aa, 100 Mwords of memory, and 10,000 CPU seconds. BBaattcchh RReeqquueesstt wwiitthh EEmmbbeeddddeedd OOppttiioonnss An example of an NQS batch request file that contains embedded qqssuubb options follows: #QSUB -r job #QSUB -eo #QSUB -o list/job.o #QSUB -j list/job.l #QSUB -a TOMORROW date In this example, the batch request has the name of jjoobb. Its standard error (ssttddeerrrr) and standard output (ssttddoouutt) files are merged (--eeoo) and returned to the lliisstt//jjoobb..oo file, relative to the submitter's current directory. A job log is requested (--JJ yy) and will be returned with the name lliisstt//jjoobb..ll. The request is scheduled to run tomorrow. TTeessttiinngg ffoorr tthhee BBaattcchh EEnnvviirroonnmmeenntt You can set up different batch and interactive environments in your ..pprrooffiillee and ..llooggiinn files. You can test the EENNVVIIRROONNMMEENNTT variable to see whether a script is executing in batch or interactive mode; when the job is an NQS batch request, it is set to BBAATTCCHH; when the job is not an NQS job, it is not set. The following examples illustrate the use of EENNVVIIRROONNMMEENNTT. Example 1: The following example shows how a standard or Korn shell script file can switch on command echoing that includes time stamps if it is executing in batch mode: # # sh .profile script # if test "$ENVIRONMENT" = "BATCH" then set -xS Example 2: This example shows how a C shell script file can switch on command echoing with time stamps if it is executing in batch mode: # # csh .login script # if ($?ENVIRONMENT) then if ("$ENVIRONMENT" == "BATCH") then set timestamp set echo endif endif UUsseerr VVaalliiddaattiioonn EExxaammppllee The following is an example of how the user ssaamm on host iiccee would submit a request to run as user ttoomm on host hhoott, assuming that the queue hhoott on host iiccee has a queue on hhoott listed as its destination: ice% qqssuubb --uu ttoomm --qq hhoott jjoobbnnaammee If password validation is in effect on the local machine, the user will be prompted for a password: Dest. password: The user then can enter the password or press , which indicates a null password. This request enters the hhoott pipe queue and is transferred to the host hhoott. While this request remains on iiccee, user ssaamm owns it. After the transfer begins, the validity of the --uu option is checked on host hhoott. User ttoomm must be a valid user on hhoott, and, if password validation is being used, the correct password must have been entered. If file validation is in effect, either the //eettcc//hhoossttss..eeqquuiivv file on hhoott must contain an entry for iiccee, or the following entry must exist in user ttoomm's ..nnqqsshhoossttss or ..rrhhoossttss file on the submitting host: ice sam When the request completes execution, the standard output, job log, and standard error files are returned to the directory from which the request was submitted (in this case, on iiccee). If file validation is being used, user ssaamm on host iiccee must have an entry for user ttoomm on host hhoott in a ..nnqqsshhoossttss or ..rrhhoossttss file or the //eettcc//hhoossttss..eeqquuiivv file on iiccee must include an entry for hhoott. The validation file entry in ssaamm's home directory would be as follows: hot tom NQS checks the ..rrhhoossttss file only when the ..nnqqsshhoossttss file does not exist. SSEEEE AALLSSOO ccaatt(1), cceevveenntt(1), ccsshh(1), mmaaiill(1), nneewwaacccctt(1), nniiccee(1), qqaalltteerr(1), qqcchhkkppnntt(1), qqddeell(1), qqlliimmiitt(1), qqmmssgg(1), qqssttaatt(1), rreemmsshh(1B), sseettuuccmmpp(1), sseettuullvvll(1), sshh(1), ttppssttaatt(1), uuddbbsseeee(1) ccpprr(1) on IRIX 6.4 or later systems for information about checkpoint and restart mmiisseerr(1) on IRIX 6.5 or later systems for additional information about Miser and Miser resource descriptions bbrrkk(2), cchhkkppnntt(2) on UNICOS and UNICOS/mk systems only, rreessttaarrtt(2), ssssbbrreeaakk(2) in the _U_N_I_C_O_S _S_y_s_t_e_m _C_a_l_l_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, publication SR-2012 bbrrkk(2) on IRIX 6.2 or later systems for information about changing the data segment space allocation mmmmaapp(2) on IRIX 6.2 or later systems for information about mapping pages of memory sseettrrlliimmiitt(2) on IRIX 6.2 or later systems for information about setting resource limits pprroojjeecctt(4) and pprroojjiidd(4) on IRIX 6.2 or later systems for information about valid user projects mmiisseerr__ssuubbmmiitt(5) on IRIX 6.5 or later systems for additional information about Miser and Miser resource descriptions nnqqeeiinnffoo(5) for information on the nnqqeeiinnffoo file qqmmggrr(8) for information about NQS administration in the _U_N_I_C_O_S _A_d_m_i_n_i_s_t_r_a_t_o_r _C_o_m_m_a_n_d_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, publication SR-2022 _N_Q_E _U_s_e_r'_s _G_u_i_d_e, publication SG-2148 _N_Q_E _A_d_m_i_n_i_s_t_r_a_t_i_o_n, publication SG-2150 _C_h_e_c_k_p_o_i_n_t _a_n_d _R_e_s_t_a_r_t _O_p_e_r_a_t_i_o_n _G_u_i_d_e, Silicon Graphics publication 007-3236-001 This man page is available only online.