submit job

To run this command, in the security file you must have submit (submitdb) access for the job with the name specified in its database definition and, if you use the alias keyword, also with the name specified with this keyword. In addition, if you use the recoveryjob keyword, you must have submit access for the job specified with that keyword.

Note that if you have security submitdb rights only, you are limited to submit jobs defined in the database. You cannot submit ad-hoc jobs.

To include needs and prompt dependencies, you must have use access to the resources and global prompts.

If you submit a shadow job, see Defining and managing cross dependencies for more details.

Syntax

{submit job | sbj} [workstation#]jobname
     [;alias[=name]]
     [;into=[workstation#]{jobstream_id
;schedid | jobstreamname([hhmm[date]])}]
     [;joboption[;...]]
     [;vartable=tablename]
     [;noask]

Arguments

workstation

Specifies the name of the workstation on which the job will be launched. Wildcard characters are permitted, in which case, the job is launched on all qualifying workstations. The default is the workstation on which conman is running. You cannot specify a domain or workstation class.

jobname

Specifies the name of the job. Wildcard characters are permitted, in which case, all qualifying jobs are submitted. If the job is already in the production plan, and is being submitted into the same job stream, you must use the alias argument to assign a unique name.

alias=name

Specifies a unique name to be assigned to the job in place of jobname. If you enter the alias keyword without specifying a name, a name is constructed using the first five alphanumeric characters of jobname followed by a ten digit random number. The name is always upshifted. For example, if jobname is jcrttx5, the generated name will be similar to JCRTT1234567890.

into=jobstream_instance

Identifies the job stream instance into which the job will be placed for launching. Select the job stream instance as follows:

[workstation#]jobstreamname([hhmm[ date]])

or

[workstation#]jobstream_id ;schedid

If into is not used, the job is added to a job stream named JOBS.

joboption

Specify one of the following:

at=hhmm [timezone|tz tzname] [+n days | mm/dd[/yy]] | [absolute | abs]

confirmed

critical

deadline=time[timezone | tz tzname][+n days | mm/dd[/yy]]

every=rate

follows=[netagent::][workstation#]{jobstreamname(hhmm [mm⁄dd[/yy]]) [.job | @] | jobstream_id.job;schedid}| job '[IF condition_name[| condition_name] [| ...]]' [;nocheck][;wait=time][,...]

The condition_name variable indicates the name of the condition defined in the job definition. Conditions can be status conditions, based on job status, or other output conditions, based on a mapping expression such as a return code, output variables, or output found in a job log. In each follows statement, you can specify only one dependency type: either status or output conditions. At submission time, you can add status or output conditions, but no joined dependencies.

wait

The time in seconds HCL Workload Automation waits before performing a second check on the dependency if the object specified in the dependency does not exist. If the object specified in the dependency was created during the wait interval, the submission is performed, otherwise the job is not submitted.

nocheck

Ignores the dependency. If the object specified in the dependency does not exist, the submission is performed anyway.

Note: The ;nocheck argument is not supported in internetwork dependencies.

maxdur=time[onmaxdur action]

mindur=time[onmindur action]

needs=[num] [workstation#]resource[,...]

opens=[workstation#]"filename"[(qualifier)][,...]

priority=[pri | hi | go]

prompt="[: | !]text" | promptname[,...]

recovery=stop | continue | rerun

recoveryjob= [workstation#]jobname

The name of a recovery job different from the one (if present) specified in the job definition in the database.

after [workstation#]jobname

abendprompt “text”

until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [;onuntil action]

vartable=tablename

Specifies the name of the variable table, if different than the default one, where the variables you intend to use are defined.

Remember:

• With this command, you can use variable substitution for the following keywords:
  • opens
  • prompt
  • abendprompt
• Enclose the variable between carets (^), and then enclose the entire string between quotation marks. If the variable contains a portion of a path, ensure that the caret characters are not immediately preceded by a backslash (\) because, in that case, the \^ sequence could be wrongly interpreted as an escape sequence and resolved by the parser as caret character. If necessary, move the backslash into the definition of the variable between carets.
• Variables specified in the job definition with the ${variablename} format are not resolved.

If you submit a job containing variables defined in a variable table that is not the default variable table and you do not specify the variable table in the run-cycle, job stream, or workstation, the variables are not resolved. See Customizing your workload using variable tables.

noask

Specifies not to prompt for confirmation before taking action against each qualifying job.

Comments

Jobs submitted in production from the conman command line are not included in the preproduction plan and so they cannot be taken into account when identifying external follows dependencies predecessors.

If you do not specify a workstation with follows, needs, opens, or into, the default is the workstation of the job.

at specifies at which time the job can be submitted. If the at keyword is used, then the job cannot start before the time set with this keyword. Note that if the master domain manager of your network runs with the enLegacyStartOfDayEvaluation and enTimeZone options set to yes to convert the startOfDay time set on the master domain manager to the local time zone set on each workstation across the network, you must add the absolute keyword to make it work.

The scheduler classifies follows dependencies as internal when they are specified only by their job name within the job stream. It classifies them as external when they are specified in the jobStreamName.workstationName.jobName format.

When you submit the object into a job stream and add a follows dependency that shares the same job stream name (for example, you submit the object into job stream schedA and define a follows dependency on schedA.job2), the dependency is treated as an external follows dependency. Since Version 8.3, unlike in previous versions, because the scheduler uses the sameday matching criteria to resolve external dependencies, dependencies originated in this way are never added the first time the object is submitted.

See also

From the Dynamic Workload Console you can perform the same task as described in:

Submitting predefined jobs.