Previous Topic: Nonexistent Predecessor EvaluationNext Topic: How to Identify Work to Perform


Canceled Predecessors

The only predecessor requirements honored are those that represent predecessor jobs that are scheduled to run in the current workload (also referred to as being “in the tracking file”). Because of this rule, the cancellation of any predecessor job (which removes that job from the tracking file) results in that predecessor requirement being ignored. The cancellation of a predecessor job that was referenced as dynamic effectively satisfies the predecessor requirement, allowing any successor jobs to run. If the predecessor requirement was referenced as static, any successor jobs remain in a "wait on predecessor" state (WPRED).

While many enterprises find this behavior intuitive and useful for dynamic predecessor requirements, others do not. To support each enterprise’s preference, the CA NSM JM Option components provide an option that lets you change the default effect of the cancel command so that successors (those jobs that define the canceled job as a predecessor) are not automatically posted. For information about specifying this option using the Post on Cancel and CAISCHD0014 environment variables, see Configuration Environment Variables.

For procedures to form groups of related tasks, see Defining Jobsets in the online CA Procedures.