submit sched

To run this command, in the security file you must have submit access for the job stream with the name specified in its database definition and, if you use the alias keyword, also with the name specified with this keyword. To include needs and prompt dependencies, you must have use access to the resources and global prompts.

The submit schedule command uses the credentials set in the useropts file belonging to the TWS_user who installed that workstation.

Syntax

{submit sched | sbs} [workstation#]jstreamname
     [;alias[=name]]
     [;jstreamoption[;...]]
     [;vartable=tablename]
     [;noask]

Arguments

workstation

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

jstreamname

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

alias=name

Specifies a unique name to be assigned to the job stream in place of jstreamname. If set, this value corresponds also to the jobstream_id. If you enter the alias keyword without specifying a name, a name is constructed using the first five alphanumeric characters of jstreamname followed by a ten digit random number. The name is always upshifted. For example, if jstreamname is sttrom, the generated name will be similar to STTRO1234567890.

The authorization to submit the schedule is checked in the Security file using the original name not the alias name.

jstreamoption

Enter any of the following (refer to Job stream definition keyword details to find which options are mutually exclusive):

[at=hhmm [timezone|tz tzname] [+n days | date] [absolute | abs]] | [schedtime=[hhmm [date] | [+n days]]

where:

at specifies at which time the job stream can be launched. If the at keyword is used, then the job stream cannot start before the time set with this keyword (see the topic on the job stream definition keywords in the chapter on "Defining objects in the database" in "HCL Workload Automation User's Guide and Reference" for more information about the "at" 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.

schedtime represents the day and time when the job stream is positioned in the plan. If by this time the job stream is free from dependencies, and has no defined at time restrictions, it is launched. The value assigned to schedtime does not represent a dependency for the job stream. Its value is then displayed in the SchedTime columns in the output of the show commands. If an at restriction is defined, then the value assigned to schedtime is overwritten by the at value. When the job stream actually starts, the value assigned to schedtime is overwritten by the actual start time of the job stream.

The format used for date depends on the value assigned to the date format variable specified in the localopts file.

If no additional time zone is specified, the time zone set on the workstation running the command is assumed.

carryforward

Makes a job stream eligible to be carried forward to the next production plan if it is not completed before the end of the current production plan.

deadline=time[timezone | tz tzname][+n days | date]

If no additional time zone is specified, the time zone set on the workstation running the command is assumed.

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

The matching criteria used when submitting job streams in production is different from the way follows dependencies are resolved in the preproduction plan. When a job stream, for example JS_A, containing a follows dependency from a job or a job stream, for example JS_B, is submitted from the conman command line program, the predecessor instance of JS_B is defined following this criterion:

1. The closest instance of JS_B preceding JS_A.
2. If no preceding instance of JS_B exists, then the predecessor instance is the closest instance of JS_B following JS_A.
3. Otherwise an error is displayed and the command fails if the ;nocheck keyword is not used.

The predecessor job stream instance is searched among the instances added to the production plan when JnextPlan was run and the instances submitted in production with the sbs command, including those submitted with an alias.

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.

limit=joblimit

Limits the number of jobs that can run simultaneously in a job stream on the same CPU.

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

Defines resources that must be available before a job or job stream is launched. You can use the needs keyword either in a job stream definition or in the definition of the contained jobs, not in both.

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

Specifies files that must be available before a job or job stream can be launched.

priority=[pri | hi | go]

Sets the priority of a job or job stream. By assigning a different priority to jobs or job streams you determine which one starts first, if the dependencies are solved.

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

Specifies prompts that must be answered affirmatively before a job or job stream is launched.

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

Depending on the object definition the until keyword belongs to, specifies the latest time a job stream must be completed or the latest time a job can be launched.

If no additional time zone is specified, the time zone set on the workstation running the command is assumed.

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
• 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.

If you submit a job stream with jobs 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 stream.

Comments

Job streams 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, or opens, the default is the workstation of the job stream.

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 a job stream that includes a job with a follows dependency that shares the same job stream name (for example, job stream schedA includes a job named job6 that has a follows dependency on schedA.job2), the dependency is added 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 job streams.