Defining steps for your workflow
A workflow is composed of one or more units of work called steps. A workflow definition file must contain at least one step; each step can contain substeps. In the Workflows task, a wizard guides the user through a step, which can be either manual or automated. For a manual step, the wizard only displays the instructions required for the user to perform the step. For an automated step, the wizard uses a template to create a file or execute a REXX exec, UNIX shell script, or JCL job. Optionally, the wizard can perform substitution by referencing variable values.
Every step has a name and contains a title and description. Steps can contain substeps, which can also contain substeps, up to five levels of nesting. For example, Step 1 can contain Step 1.1, which can contain Step 1.1.1, which can contain Step 1.1.1.1, which can contain Step 1.1.1.1.1. The total aggregation of steps and their substeps across the entire workflow cannot exceed 500.
The step name must be unique across the entire workflow. The step name is not displayed in the Workflows task, but it is used within the workflow to reference prerequisite steps. The title should be brief, and will be displayed in the step table when opening a workflow. Step titles are indented for substeps. The step description can be more detailed. It is only displayed in the "General" tab when viewing the step properties to provide a bit more context, if necessary.
A step can be designated as optional. This designation has effects on how its weight is used in the calculation of the percentage-complete for a workflow. Weights are described in Parent steps and leaf steps.
Any step can optionally contain a set of references to prerequisite steps (by step name) which must be completed before this step can be performed. Each prerequisite is identified in its own <prereqStep> element. The Workflows task will display the prerequisite chain for a step (in the "Details" tab when viewing the step properties), and will keep track of dependencies in terms of the state of any given step.
Any prerequisite step must have been defined previously in the workflow (though not an ancestor of the referencing step). If the reference is to a step with substeps, the substeps are treated as prerequisites (they need not be explicitly specified). If only certain substeps under a parent step are dependencies, they can be listed explicitly.
A step can contain multiple prerequisites steps, but these need not be cumulative. That is, if Step3 depends on Step2, and Step2 depends on Step1, then Step2 would identify Step1 as a dependency, and Step3 would identify Step2 as a dependency. If Step3 identified both Step2 and Step1, no harm would occur, but it makes the workflow more complex than necessary, and perhaps more difficult to maintain over time.
A step can be defined as conditional. Such a step is available to be performed based on whether a logical condition is satisfied on the z/OS system. For example, a conditional step might become eligible to be performed if a job run by another step ends with a particular return code. A conditional step, which depends on a logical condition, is different than a dependent step, which depends on a particular step being completed. For more information, see Making a step conditional.
What is described here applies to any step. For the distinctions between a parent step and a leaf step, see Parent steps and leaf steps.
Table 7 describes the elements that make up a step.