submit docommand

To run this command, in the security file you must have submit 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.

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

Syntax

{submit docommand = | sbd} [[folder/]workstation#]"cmd"
     [;alias[=name]]
     [;into=[[folder/]workstation#]
     {jobstream_id;schedid |[folder/]jobstreamname
       ([hhmm[date]])}]
     [;joboption[;...]]

Arguments

[folder/]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.

Note: Because of a limitation in the way Windows® manages the equal (=) sign in the shell environment, you must mask the equal (=) sign as follows '\='\ when submitting Windows® commands using submit docommand. For example, to set the local variable var1 to hello you must issue the following command:

%sbd "set var1\"=\"hello"

cmd

Specifies a valid system command of up to 255 characters. The entire command must be enclosed in quotes ("). The command is treated as a job, and all job rules apply.

alias=name

Specifies a unique name to be assigned to the job. If you enter the alias keyword without specifying a name, a name is constructed using up to the first six alphanumeric characters (in upper case) of the command, depending on the number of characters in the command, followed by a ten digit random number. If there are blanks in the command, the name is constructed using up to the first six alphanumeric characters before the blank. For example, if the command is "rm apfile", the generated name will be similar to RM0123456789. If the command is longer than six alphanumeric characters such as, "wlsinst", the generated name will be wlsins0396578515.

If you do not include alias the first time you submit the command, a job name is constructed using up to 255 characters of the command name. If you submit a command a second time from the same workstation, the alias keyword is mandatory and must be unique for each command submission.

into=[folder/]jobstream_instance

Identifies the job stream instance into which the job will be placed for launching and optionally, the path to the folder where the job stream is located. If [folder/] is omitted, then the root folder is assumed. Select the job stream instance as follows:

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

or

[[folder/]workstation#]jobstream_id ;schedid

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

joboption

Specify any of the following:

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

confirmed

critical

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

every=rate

follows=[netagent::][workstation#]{jobstreamname[hhmm [mm/dd[/yy]]][.job | @] | jobstream_id.job;schedid}| job[,...] [if 'condition_name[| condition_name][| ...]']

Note: Internetwork dependencies do not support folders, therefore, the network agent workstation, and the jobs and job streams running on them, cannot be defined in a folder different from the root (/). Folders are supported on all other workstation types as follows:

 [follows {[[folder/]workstation#][folder/]jobstreamname[.jobname]

follows=[[folder/]workstation#][folder/]{jobstreamname[hhmm [mm/dd[/yy]]][.job | @] | jobstream_id.job;schedid}| job[,...] [if 'condition_name[| condition_name][| ...]']

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. Network agent workstations do not support folders, therefore neither the network agent nor the jobs or job streams running on them can be defined in folders.

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.

interactive

Note: This keyword can be used in Windows® environments only.

maxdur=time[onmaxdur action]

mindur=time[onmindur action]

logon=user.

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

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

priority=[pri | hi | go]

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

recovery=stop | continue | rerun

recoveryjob=[[folder/]workstation#]jobname

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

after[[folder/]workstation#][folder/]jobname

abendprompt “text”

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

The default value for joboption is the user on the workstation from which the command is being run.

Using local parameters

Local parameters are defined and managed with the parms utility command in a local database on the workstation where the job is run. The parameters are resolved on the workstation while the submit command is in execution.

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.

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 workstationName#[folder/]jobStreamName.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.

See also

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

Submitting ad hoc jobs.