job statement
Jobs can be defined in the database independently (as described in Job), or as part of job streams. In either case, the changes are made in the database and do not affect the production plan until the start of a new production plan.
Syntax
[workstation#]jobname [as newname]
{scriptname filename | docommand “command”}
streamlogon username
[description “description”]
[tasktype tasktype]
[interactive]
[succoutputcond Condition_Name "Condition_Value"]
[outputcond Condition_Name "Condition_Value"]
[recovery
{stop
[after [workstation#]jobname]
[abendprompt "text"]]
| continue
[after [workstation#]jobname]
[abendprompt "text"]]
|rerun [same_workstation]
[[repeatevery hhmm] [for number attempts]]
[after [workstation#]jobname]
| [after [workstation#]jobname]
[abendprompt "text"]}
[workstation#]jobname [as newname]
Arguments
- as
- The name you want to use to refer to the job instance within that job stream.
For the other keywords refer to Job definition.
Comments
When defining a job as part of a job stream as the job stream definition is added to the database also the new job definition is added and can be referenced, from that moment on, also from other job streams.
When a job stream is added or modified, the attributes or recovery options of its jobs are also added or modified. Remember that when you add or replace a job stream, any job modifications affect all other job streams that use the jobs. Note that the cross reference report, xref, can be used to determine the names of the job streams including a specific job.
For more information about cross reference report refer to xref.
Examples
schedule bkup on fr at 20:00 :
cpu1#jbk1
cpu2#jbk2
needs 1 tape
cpu3#jbk3
follows jbk1
end
schedule sked4 on mo :
job1 scriptname “d:\apps\maestro\scripts\jcljob1”
streamlogon jack
recovery stop abendprompt “continue production”
site1#job2 scriptname “d:\apps\maestro\scripts\jcljob2”
streamlogon jack
follows job1
end