SGE_JOB_CLASS(5) File Formats Manual SGE_JOB_CLASS(5) NAME job class - job class entry file format DESCRIPTION When Univa Grid Engine jobs are submitted then various submit parame- ters have to be specified either as switches which are passed to com- mand line applications or through corresponding selections in the graphical user interface. Some of those switches define the essential characteristics of the job, others describe the execution context that is required so that the job can be executed successfully. Another sub- set of switches needs to be specified only to give Univa Grid Engine the necessary hints on how to handle a job correctly so that it gets passed through the system quickly without interfering with other jobs. In small and medium sized clusters with a limited number of different job types this is not problematic. The number of arguments that have to be specified can either be written into default request files, embedded into the job script, put into an option file (passed with -@ of qsub(1)) or they can directly be passed at the command line. Within larger clusters or when many different classes of jobs should run in the cluster then the situation is more complex and it can be challenging for a user to select the right combination of switches with appropriate values. Cluster managers need to be aware of the details of the different job types that should coexist in the cluster so that they can setup suitable policies in line with the operational goals of the site. They need to instruct the users about the details of the cluster setup so that these users are able to specify the required submission requests for each job they submit. Job classes have been introduced in Univa Grid Engine 8.1 to be able to: * specify job templates that can be used to create new jobs. * reduce the learning curve for users submitting jobs. * avoid errors during the job submission or jobs which may not fit site requirements. * ease the cluster management for system administrators. * provide more control to the administrator for ensuring jobs are in line with the cluster set-up. * define defaults for all jobs that are submitted into a cluster. * improve the performance of the scheduler component and thereby the throughput in the cluster. Imagine you have users who often make mistakes specifying memory limits for a specific application called memeater. You want to make it easy for them by specifying meaningful defaults but you also want to give them the freedom to modify the memory limit default according to their needs. Then you could use the following job class configuration (only an excerpt of the full configuration is shown): jcname memeater variant_list default,short,long owner NONE user_lists NONE xuser_lists NONE ... CMDNAME /usr/local/bin/memeater ... l_hard {~}{~}h_vmem=6GB ... Without going into the specifics of the job class syntax, the above job class will use a default of 6 GB for the memory limit of the job. It will, however, be feasible for users to modify this limit. Here are two examples for how users would submit a job based on this job class. The first maintaining the default, the second modifying it to 8 GB (again without going into the details of the syntax being used here): 1) qsub -jc memeater 2) qsub -jc memeater -l h_vmem=8GB Now assume a slightly modified scenario where you want to restrict a certain group of users called novice to only use the preset of 6 GB while another group of users called expert can either use the default or can modify the memory limit. The following job class example would accomplish this. And the trick is that job classes support so called variants as well as user access lists: jcname memeater variant_list default advanced owner NONE user_lists novice,[advanced=expert] xuser_lists NONE ... CMDNAME /usr/local/bin/memeater ... l_hard h_vmem=6GB,[{~}advanced={~}h_vmem=6GB] With this job class configuration, the novice users would only be able to submit their job using the first command example below while expert users could use both examples: 1) qsub -jc memeater 2) qsub -jc memeater.advanced -l h_vmem=8GB The two use cases for job classes above are only snippets for all the different scenarios to which job classes may be applied and they only provide a glimpse onto the features of job classes. The next sections describe all attributes forming a job class object, commands that are used to define job classes as well as how these objects are used during job submission to form new jobs. A set of examples with growing func- tionality will illustrate further use cases. This will be followed by describing how job classes can be embedded with other parts of a Univa Grid Engine configuration to extract the maximum benefit from job classes. Finally, specific means for monitoring job class jobs will be shown. FORMAT OF JOB CLASS ATTRIBUTES A job class is a new object type in Univa Grid Engine 8.1. Objects of this type can be defined by managers and also by users of a Univa Grid Engine cluster to prepare templates for jobs. Those objects can later on be used to create jobs. Like other configuration objects in Univa Grid Engine each job class is defined by a set of configuration attributes. This set of attributes can be divided into two categories. The first category contains attributes defining a job class itself and the second category all those which form the template which in turn eventually gets instanti- ated into new jobs. Following attributes describe characteristics of a job class: jcname The jcname attribute defines a name that uniquely identifies a job class. Please note that NO_JC and ANY_JC are reserved keywords that cannot be used as names for new job classes. There is one particular job class with the special name template. It acts as template for all other job classes and the configuration of this job class template can only be adjusted by users having the man- ager role in Univa Grid Engine. This gives manager accounts control about default settings, some of which also can be set so that they must not be changed (see below for more information on how to enforce options). variant_list Job classes may, for instance, represent an application type in a clus- ter. If the same application should be started with various different settings in one cluster or if the possible resource selection applied by Univa Grid Engine system should depend on the mode how the applica- tion should be executed then it is possible to define one job class with multiple variants. A job class variant can be seen as a copy of a job class that differs only in some aspects from the original job class. The variant_list job class attribute defines the names of all existing job class variants. If the keyword NONE is used or when the list con- tains only the word default then the job class has only one variant. If multiple names are listed here, that are separated by commas, then the job class will have multiple variants. The default variant always has to exist. If the variant_list attribute does not contain the word default then it will be automatically added by the Univa Grid Engine system. Other commands that require a reference of a job class can either use the jcname or jcname.default to refer to the default variant of a job class or they can reference a different variant by combining the jcname with the name of a specific variant. Both names have to be separated by a dot (.) character. owner The owner attribute denotes the ownership of a job class. As default the user that creates a job class will be the owner. Only this user and all managers are allowed to modify or delete the job class object. Managers and owners can also add additional user names to this list to give these users modify and delete permissions. If a manager creates a job class then the owner will be NONE to express that only managers are allowed to modify or delete the corresponding job class. Even if a job class is owned only by managers it can still be used to create new jobs. The right to derive new jobs from a job class can be restricted with the user_lists and xuser_lists attributes explained below. user_lists The user_lists job class parameter contains a comma separated list of Univa Grid Engine user access list names and user names. User names have to be prefixed with a percent character (%). Each user referenced in the user_lists and each user in at least one of the enlisted access lists has the right to derive new jobs from this job class using the -jc switch of one of the submit commands. If the user_lists parameter is set to NONE (the default) any user can use the job class to create new jobs if access is not explicitly excluded via the xuser_lists parameter described below. If a user is contained both in an access list enlisted in xuser_lists and user_lists the user is denied access to use the job class. xuser_lists The xuser_lists job class contains a comma separated list of Univa Grid Engine user access list names and user names. User names have to be prefixed with a percent character (%). Each user referenced in the xuser_lists and users in at least one of the enlisted access lists are not allowed to derive new jobs from this job class. If the xuser_lists parameter is set to NONE (the default) any user has access. If a user is contained both in an access list enlisted in xuser_lists and user_lists the user is denied access to use the job class. FORMAT OF JOB CLASS ATTRIBUTES THAT FORM A JOB TEMPLATE Additionally to the attributes mentioned previously each job class has a set of attributes that form a job template. In most cases the names of those additional attributes correspond to the names of command line switches of the qsub(1) command. The value for all these additional attributes might either be the keyword UNSPECIFIED or it might be the same value that would be passed with the corresponding qsub command line switch. All these additional job template attributes will be evaluated to form a virtual command line when a job class is used to instantiate a new job. All attributes for which the corresponding value contains the UNSPECIFIED keyword will be ignored whereas all others define the sub- mit arguments for the new job that will be created. All template attributes can be divided in two groups. There are tem- plate attributes that accept simple attribute values (like a character sequence, a number or the value yes or no) and there are template attributes that allow to specify a list of values or a list of key/value pairs (like the list of resource requests a job has or the list of queues where a job might get executed). The sections below explain all available template attributes. The asterisk character (*) tags all attributes that are list based. Within the description the default for each attribute is documented that will be used when the keyword UNSPECIFIED is used in the job class defini- tion. a Specifies the time and date when a job is eligible for execution. If unspecified the job will be immediately eligible for execution. Format of the character sequence is the same as for the argument that might be passed with qsub(1) -a. A Account string. The string sge will be used when there is no account string specified or when it is later on removed from a job template or job specification. ac (*) List parameter defining the name/value pairs that are part of the job context. Default is an empty list. ar Advance reservation identifier used when jobs should be part of an advance reservation. As default no job will be part of an advance reservation. b yes or no to express if the command should be treated as binary or not. The default for this parameter is no, i.e. the job is treated as a script. binding Specifies all core binding specific settings that should be applied to a job during execution. Binding is disabled as default. CMDARG (*) Defines a list of command line arguments that will be passed to CMDNAME when the job is executed. As default this list is empty. CMDNAME Specified either the job script or the command name when binary submis- sion is enabled (b yes). Please note that script embedded flags within specified job scripts will be ignored. c_interval Defines the time interval when a checkpoint-able job should be check- pointed. The default value is 0. c_occasion Letter combination that defines the state transitions when a job should be triggered to write a checkpoint. Default is 'n' which will disable checkpointing. ckpt Checkpoint environment name which specifies how to checkpoint the job. No checkpoint object will be referenced as default. cwd Specifies the working directory for the job. Path aliasing will not be used when this value is specified in a job class. In case of absence the home directory of the submitting user will be used as directory where the job is executed. dl Specifies the deadline initiation time for a job (see the chapter about deadline urgency in the administrators guide for more information). As default jobs have do defined deadline. e (*) List parameter that defines the path for the error file for specific execution hosts. As default the file will be stored in the home direc- tory of the submitting user and the filename will be the combination of the job name and the job id. h yes or no to indicate if a job should be initially in hold state. The default is no. hold_jid (*) List parameter to create initial job dependencies between new jobs and already existing ones. The default is an empty list. hold_jid_ad (*) List parameter to create initial array job dependencies between new array jobs and already existing ones. The default is an empty list. i (*) List parameter that defines the path for the input file for specific execution hosts j yes or no to show if error and output stream of the job should be joined into one file. Default is no. js Defines the job share of a job relative to other jobs. The default is 0. l_hard (*) List parameter that defines hard resource requirements of a job in the form of name/value pairs. The default is an empty list. l_soft (*) List parameter defining soft requests of a job. The default is an empty list. mbind Specifies memory binding specific settings that should be applied to a job during execution. Memory binding is disabled as default. m Character sequence that defines the circumstances when mail that is related to the job should be send. The default is n which means no mails should be send. M (*) List parameter defining the mail addresses that will be used to send job related mail. The default is an empty list. masterl (*) List parameter that defines hard resource requirements for the master task of a parallel in the form of name/value pairs. The default is an empty list. masterq (*) List parameter that defines the queues that might be used as master queues for parallel jobs. The default is an empty list. N Default name for jobs. For jobs specifying a job script which are sub- mitted with qsub or the graphical user interface the default value will be the name of the job script. When the script is read from the stdin stream of the submit application then it will be STDIN. qsh(1) and qlogin(1) jobs will set the job name to INTERACTIVE. qrsh(1) jobs will use the first characters of the command line up to the first occurrence of a semicolon or space character. notify yes or no to define if warning signals will be send to a jobs if it exceeds any limit. The default is no. now yes or no to specify if created jobs should be immediate jobs. The default is no. o (*) List parameter that defines the path for the output file for specific execution hosts. p Specifies the project to which this job is assigned. p Priority value that defines the priority of jobs relative to other jobs. The default priority is 0. pe_name Specifies the name of the parallel environment that will be used for parallel jobs. As default there is no name specified and as a result the job is no parallel job. pe_range Range list specification that defines the amount of slots that are required to execute parallel jobs. This parameter must be specified when also the pe_name parameter is specified. q_hard (*) List of queues that can be used to execute the job. The default is an empty list. q_soft (*) List of queues that are preferred to be used when the job should be executed. The default is an empty list. R yes or no to indicate if a reservation for this job should be done. The default is no. r yes or no to identify if the job will be rerun-able. The default is no. rou (*) List of online usage variables that shall get written to the reporting file and the reporting database. The default is an empty list. S (*) List parameter that defines the path of the shell for specific execu- tion hosts. The default is an empty list. shell yes or no to specify if a shell should be executed for binary jobs or if the binary job should be directly started. The default is yes t Defines the task ID range for array jobs. Jobs are no array jobs as default. V yes or no. yes causes that all environment variables active during the submission of a job will be exported into the environment of the job. v (*) List of environment variable names and values that will be exported into the environment of the job. If also V yes is specified then the variable values that are active during the submission might be over- written. xd (*) List of -xd switches for specifying arbitrary docker run options to be used in the creation of the container for Docker jobs. docker run means the run option of the docker command that is part of the Docker Engine. ACCESS SPECIFIERS Access specifiers are character sequences that can be added to certain places in job class specifications to allow/disallow operations that can be applied to jobs that are derived from that job class. They allow you to express, for instance, that job options defined in the jobs class can be modified, deleted or augmented when submitting a job derived from a job class. This means the job class owner can control how the job class can be used by regular users being allowed to derive jobs from this job class. This makes using job classes simple for the end user (because of a restricted set of modifications). It also avoids errors as well as the need to utilize Job Submission Verifiers for checking on mandatory options. Per default, if no access specifiers are used, all values within job classes are fixed. This means that jobs that are derived from a job class cannot be changed. Any attempt to adjust a job during the submis- sion or any try to change a job after it has been submitted (e.g. with qalter) will be rejected. Also managers are not allowed to change the specification of defined in a job class when submitting a job derived from the job class. To soften this restriction, job class owners and users having the man- ager role in a job class can add access specifiers to the specification of a job class to allow deviation at certain places. Access specifiers might appear before each value of a job template attribute and before each entry in a list of key or key/value pairs. The preceding access specifier defines which operations are allowed with the value that fol- lows. The full syntax for a job class template attribute is defined as : := | := ' ' [ ] ( | 'UNSPECIFIED' ) := ' ' [ ] ( | 'UNSPECIFIED' ) := [ ] [ ',' [ ] , ...] := Please note the distinction between and . is also an but it is the first one that appears in the definition of list based job template attributes and it is the reason why two access spec- ifiers might appear one after another. The first access specifier regu- lates access to the list itself whereas the following ones define access rules for the entries in the list they are preceding. These access specifiers () are available: The absence of an access specifier indicates that the corre- sponding template attribute (or sublist entry) is fixed. Any attempt to modify or delete a specified value or any attempt to add a value where the keyword UNSPECIFIED was used will be rejected. It is also not allowed to add additional entries to lists of list based attributes if a list is fixed. {-} Values that are tagged with the {-} access specifier are removable. If this access specifier is used within list based attributes then removal is only allowed if the list itself is also modifiable. If all list entries of a list are removable then also the list itself must be removable so that the oper- ation will be successful. Values that are tagged with the {-} access specifier are removable. {~} Values that are prefixed with the {~} access specifier can be changed. If this access specifier is used within list based attributes then the list itself must also be modifiable. {-~} or {~-} The combination of the {-} and {~} access specifiers indi- cates that the value it precedes is modifiable and removable. {+}UNSPECIFIED or {+...} The {+} access specifier can only appear in combination with the keyword UNSPECIFIED or before list attribute values but not within access specifiers preceding list entries. If it appears before list attribute values it can also be combined with the {~} and {-} access specifiers. This access speci- fier indicates that something can be added to the specifica- tion of a job after it has been submitted. For list based attributes it allows that new list entries can be added to the list. JOB CLASS VARIANTS Job classes represent an application type in a cluster. If the same application should be started with various different settings or if the possible resource selection applied by the Univa Grid Engine system should depend on the mode how the application should be executed then it is possible to define one job class with multiple variants. So think of it as a way to use the same template for very similar types of jobs, yet with small variations. The variant_list job class attribute defines the names of all existing job class variants. If the keyword NONE is used or when the list con- tains only the word default then the job class has only one variant. If multiple names are listed here, separated by commas, then the job class will have multiple variants. The default variant always has to exist. If the variant_list attribute does not contain the word default then it will be automatically added by the Univa Grid Engine system upon creat- ing the job class. Attribute settings for the additional job class variants are specified similar to the attribute settings of queue instances or queue domains of cluster queues. The setting for a variant attribute has to be pre- ceded by the variant name followed by an equal character (=) and enclosed in brackets ([ and ]). The position where access specifiers have to appear is slightly different in this case. The example section of this man page will show this. CLUSTER WIDE REQUESTS WITH THE TEMPLATE JOB CLASS After a default installation of Univa Grid Engine 8.1 there exists one job class with the name template. This job class has a special meaning and it cannot be used to create new jobs. Its configuration can only be adjusted by users having the manager role. This jobs class acts as par- ent job class for all other job classes that are created in the system. The values of job template attributes in this template job class and the corresponding access specifiers restrict the allowed settings of all corresponding job template attributes of other job classes. As default the {+}UNSPECIFIED add access specifier and keyword is used in the template job class in combination with all job template attributes. Due to that any setting is allowed to other job class attributes after Univa Grid Engine 8.1 has been installed. This parent-child relationship is especially useful when all jobs that are submitted into a cluster are derived from job classes. Managers might then change the settings within the template. All other existing job classes that violate the settings will then switch into the config- uration conflict state. The owners of those job classes have to adjust the settings before new jobs can be derived from them. All those users that intend to create a new job class that violates the settings of the template job class will receive an error. You will also want to use the template job class to enforce restric- tions on the access specifiers which can be used in job classes. Since any job class, whether create by a manager account or by regular users, is derived from the template job class those derived job classes are bound to stay within the limits defined by the template job class. So parameters which have been defined as fixed in the template job class, for instance, cannot be modified in any job class created by a manager or user. Likewise, parameters which have a preset value but are con- figured to allow deletion only cannot be modified in derived job classes. The following table shows the allowed transitions: AS in Template Allowed AS in Child JC UNSPECIFIED UNSPECIFIED {~} {~} {~} {-} {-} {-} {~} {-} UNSPECIFIED {-} {-~} {-~} {-~} {-} {-~} {~} {-~} UNSPECIFIED {-~} {+}... {+}... {+}... {-~} {+}... {-} {+}... {~} {+}... UNSPECIFIED {+}... RELATIONSHIP TO OTHER OBJECTS To fully integrate job classes into the already existing Univa Grid Engine system the possibility is provided to create new relations between current object types (like queues, resource quotas, JSV) and job classes. RESOURCES AVAILABLE FOR JOB CLASSES The profile of a job is defined by the resource requirements and other job attributes. Queues and host objects define possible execution envi- ronments where jobs can be executed. When a job is eligible for execu- tion then the scheduler component of the Univa Grid Engine system tries to find the execution environment that fits best according to all job specific attributes and the configured policies so that this job can be executed. This decision making process can be difficult and time consuming espe- cially when certain jobs having special resource requirements should only be allowed to run in a subset of the available execution environ- ments. The use of job classes might help here because job classes will give the scheduler additional information on which execution environ- ments will or will not fit for a job. The need to evaluate all the details about available resources of an execution environment and about the job's requirements will be reduced or can be completely eliminated during the decision making process. This is achieved by an additional paramter in the queue configuration which provides a direct association between queues and one or multiple job classes. This paramter is called jc_list and might be set to the value NONE or a list of job classes or job class variant names. If a list of names is specified then the special keyword ANY_JC and/or NO_JC might be used within the list to filter all those jobs that are in principle allowed to run in this queues. The following combinations are useful: Value Description NONE No job my enter the queue. ANY_JC Jobs may enter the queue that were derived from a job class. NO_JC Only jobs may enter the queue that were not derived from a job class. ANY_JC, NO_JC Any job, independent if it was derived from a job class or not, may be executed in the queue. This is the default for any queue that is created in a cluster. Only those jobs may get scheduled in the queue if they were derived from one of the enlisted job classes. NO_JC, Only those jobs that were not derived from a job class or those that were derived from one of the enlisted job classes can be executed here. This relationship helps the scheduler during the decision making to eliminate queues early without the need to further look at all the details like resource requirements. Managers of Grid Engine Clusters may want to take care that there is at least one queue in the cluster available that use the ANY_JC keyword. Otherwise jobs of users who have defined their own job class will not get cluster resources. Also at least one queue using the NO_JC keyword may need to be available. Otherwise conventionally submitted jobs will not get scheduled. DEFINING JOB CLASS LIMITS Resource quota sets can be defined to influence the resource selection in the scheduler. The jcs filter within a resource quota rule may con- tain a comma separated list of job class names. This parameter filters for jobs requesting a job class in the list. Any job class not in the list will not be considered for the resource quota rule. If no jcs fil- ter is used, all job classes and jobs with no job class specification match the rule. To exclude a job class from the rule, the name can be prefixed with the exclamation mark (!). !* means only jobs with no job class specification. JSV AND JOB CLASS INTERACTION During the submission of a job multiple Job Submission Verifiers can be involved that verify and possibly correct or reject a job. With conven- tional job submission (without job classes) each JSV will see the job specification of a job that was specified at the command line via switches and passed parameters or it will see the job parameters that were chosen within the dialogs of the GUI. When Jobs are derived from a job class then the process of evaluation via JSV scripts is the same but the job parameters that are visible in client JSVs are different. A client JSV will only see the requested job class via a parameter named jc and it will see all those parameters that were specified at the command line. All parameters that are defined in the job class itself cannot be seen. Job classes will be resolved within the sge_qmaster(8) process as soon as a request is received that tries to submit a job that should be derived from a job class. The following steps are taken (simplified process): (1) Create a new job structure (2) Fill job structure with defaults values (3) Fill job structure with values defined in the job class. (This might overwrite default values) (4) Fill job structure with values defined at the command line. (This might overwrite default values and values that were defined in the job class) (5) Trigger server JSV to verify and possibly adjust the job. (This might overwrite default values, JC values and values specified at the command line) (6) Check if the job structure violates access specifiers. If the server JSV changes the jc parameter of the job in step 5 then the submission process restarts from step 1 using the new job class for step 3. Please note that the violation of the access specifiers is checked in the last step. As result a server JSV is also not allowed to apply mod- ifications to the job that would violate any access specifiers defined in the job class specification. ENFORCE THE USE OF JOB CLASSES The global configuration object of Univa Grid Engine allows to define two attributes (default_jc, enforce_jc) to enforce the use of job classes. Find more in formation in sge_conf(5). STATES OF JOB CLASSES Job Classes have a combined state that is the result of following the sub states: enabled/disabled, no conflict/configuration conflict. The enabled/disabled state is a manual state. A state change from enabled to disabled can be triggered with the qmod(2) -djc command. The command qmod(2) -ejc command can be used to trig- ger a state change from disabled to enabled. Job Classes in the dis- abled state cannot be used to create new jobs. The no conflict/configuration conflict state is an automatic state that cannot be changed manually. Job classes that do not violate the config- uration of the template job class are in the no conflict state. A job class in this state can be used to create new jobs (if it is also in enabled state). If the template job class or a derived job class is changed so that either a configuration setting or one of the access specifiers of the template job class is violated then the derived job class will automatically switch from the no conflict into the configu- ration conflict state. This state will also be left automatically when the violation is eliminated. USING JOB CLASSES TO SUBMIT NEW JOBS Job Classes that are in the enabled and no conflict state can be used to create new jobs. To do this a user has to pass the -jc switch in combination with the name of a job class to a submit command like qsub(1). If the user has access to this job class then a new job will be created and all job template attributes that are defined in the job class will be used to initialize the corresponding parameters in the submitted job. Depending on the access specifiers that are used in the job class it might be allowed to adjust certain parameters during the submission of the job. In this case additional switches and parameters might be passed to the submit command. All these additionally passed parameters will be used to adjust job parameters that where derived from the job class. Additionally to the typical switches that are used to define job param- eters there is a set of switches available that allow to remove parame- ters or to adjust parts of list based parameters in a job specifica- tion. The same set of switches can also be used with the modification command qalter to adjust job parameters after a job has already been created. qsub/qalter -clearp The -clearp switch allows to remove a job parameter from the spec- ification of a job as if it was never specified. What this means depends on the job parameter that is specified by . For all those attributes that would normally have a default value this default value will be set for all others the corresponding attribute will be empty. Parameter names that can be specified for are all the ones that are specified in the table above showing job template attribute names. qsub/qalter -clears This switch allows to remove a list entry in a list based attribute of a job specification. might be any name of a job template attribute that is tagged with the asterisk (*) in the the table above. has to be the name of the key of the sublist entry for key/value pairs or the value itself that should be removed when the list contains only values qsub/qalter -adds -adds adds a new entry to a list based parameter. qsub/qalter -mods The -mods switch allows to modify the value of a key/value pair within a list based job parameter. EXAMPLE Assume that the following job class is defined in you cluster: jcname sleeper variant_list default,short,long owner NONE user_lists NONE xuser_lists NONE A UNSPECIFIED a UNSPECIFIED ar UNSPECIFIED b yes binding UNSPECIFIED c_interval UNSPECIFIED c_occasion UNSPECIFIED CMDNAME /bin/sleep CMDARG 60,[short=5],[long=3600] ckpt UNSPECIFIED ac UNSPECIFIED cwd UNSPECIFIED display UNSPECIFIED dl UNSPECIFIED e UNSPECIFIED h UNSPECIFIED hold_jid UNSPECIFIED i UNSPECIFIED j UNSPECIFIED js UNSPECIFIED l_hard {~+}{~}a=true,b=true,{-}c=true l_soft {+}UNSPECIFIED,[{~+}long={~}d=true] m UNSPECIFIED M UNSPECIFIED masterq UNSPECIFIED masterl UNSPECIFIED mbind UNSPECIFIED N {~-}Sleeper,[{~-}short=ShortSleeper],[{~-}long=LongSleeper] notify UNSPECIFIED now UNSPECIFIED o UNSPECIFIED P UNSPECIFIED p UNSPECIFIED pe_name UNSPECIFIED q_hard UNSPECIFIED q_soft UNSPECIFIED R UNSPECIFIED r UNSPECIFIED S /bin/sh shell UNSPECIFIED V UNSPECIFIED v UNSPECIFIED Now it is possible to submit jobs and to adjust the parameters of those jobs during the submission to fit specific needs: 1) qsub -jc sleeper -N MySleeper 2) qsub -jc sleeper.short -clearp N 3) qsub -jc sleeper.short -clears l_hard c -adds l_hard h_vmem 5G 4) qsub -jc sleeper.long -soft -l res_x=3 The first job that is submitted (1) will be derived from the sleeper.default job class variant but this job will get the name MySleeper. Job (2) uses the sleeper.short job class but the job name is adjusted. The -clearp switch will remove the job name that is specified in the job class. Instead it will get the default job name that would have been assigned without specifying the name in any explicit way. This will be derived from the last part of the script command that will be executed. This script is /bin/sleep. So the job name of the new job will be sleep. When job (3) is created the list of hard resource requirements is adjusted. The resource request c is removed and the h_vmem=5G resource request is added. During the submission of job (4) The list of soft resource request is completely redefined. The use of the -l will completely replace already defined soft resource requests if any have been defined. Please note that it is not allowed to trigger operations that would violate any access specifiers. In consequence, the following commands would be rejected: 5) qsub -jc sleeper -hard -l res_x 3 6) qsub -jc sleeper /bin/my_sleeper 61 Job (5) would remove the a and b resource requests and job (6) will be rejected because neither CMDNAME nor CMDARGS are modifiable. SEE ALSO sge__types(1), qconf(1) qsub(1) qmod(1) qalter(1) COPYRIGHT See sge_intro(1) for a full statement of rights and permissions. Univa Grid Engine File Formats UGE 8.5.4 SGE_JOB_CLASS(5)