Prerequisites

Prerequisites are submission criteria that, in addition to scheduling criteria, must be met before a SMART folder, folder, sub-folder, or job can execute.

The following table describes the prerequisite types.

Prerequisite	Description
Requires User Confirmation	Determines whether user confirmation is required before a job is submitted for execution. Jobs with user confirmation status, require manual confirmation for job execution, as described in Confirming a Job.
Wait for Events	Defines one or more events An conditional entity that creates a sequential relationship between jobs by enabling the successor job to execute after the predecessor job has executed. that a successor job must wait for before it can execute, as described in Events.
Lock Resources	Defines the resources that are locked, which enables you to control the resource load used by jobs in your workflow, as described in Lock Resources. If multiple database-dependent jobs concurrently execute, the database can crash or overwrite entries. lock resources control the workflow by sharing or exclusively locking resources. You can the define the following types lock resources: Name: Defines the name of the lock resource according to the following valid values: Characters: 1–64; (z/OS): 1–20 Case Sensitive: Yes Invalid Characters: Blank spaces and '. Type: Determines the type of lock resource as follows: Shared: Shares the resource with other jobs. Jobs do not wait until the job releases the resource. Exclusive: Locks the resource exclusively, and all jobs that require this resource wait until the job releases the resource. (z/OS) From the On Fail drop-down list, select Release or Keep.
Resource Pools	Determines the quantity of resources that you can allocate from the resource pool for each job to run, as described in Resource Pools. Resource pools are defined at the job level, as follows: Name: Defines the name of a resource pool. Quantity: Determines the quantity of resources that the job requires, which cannot be more than the Total. (z/OS) From the On Fail drop-down list, select Release or Keep. (z/OS) From the On OK drop-down list, select Discard or Release.
Adjust Events	Determines how to handle the Wait for Events, if the predecessor job in a workflow is not scheduled to run, as described in Adjust Events.

Adjust Events

Adjust events enables you to maintain the functionality and order of execution of SMART folder or sub-folder jobs when these jobs are not scheduled to execute on a specific day. Control-M determines how to handle the wait for events of an unscheduled job to enable a successor job to execute.

You can define adjust events as follows:

• Yes: Deletes the Wait for Events from the unscheduled job to enable the successor job to execute.

  

• Yes: Executes the unscheduled job as a Dummy job.

• No: Does not adjust the unscheduled job and the Wait for Event is not deleted. The successor job remains in a Waiting status.

  

• Dummy: Executes the unscheduled job as a Dummy job and saves all the events. The successor job waits for the Dummy job event to execute. To use the Dummy option in a Distributed system, you must set the CTM_FOLDER_ADJUST_DUMMY Control-M/Server system parameter to Y, as described in Scheduling and Execution Parameters, and then set Adjust Event on the job parent folder to Yes.

• Bridge: Connects and enables scheduled jobs to execute when there are unscheduled jobs in the same folder, and maintains the order of execution and dependencies between jobs.

  If Job_A and Job_C execute every day and Job_B executes from Monday to Saturday, you can apply a bridge that enables Job_C to execute after Job_A on Sunday and not depend on Job_B to finish execution.

  

  • Bridge functionality does not support the following:

    • If a job that is used in a bridge contains complex wait for events, such as events with OR, Not, or ( ), the bridge is not applied.

    • If more than one job adds the same event, this is considered an implicit OR and a bridge is not applied. For example, job workflows A and B connect to Job_C with the same event, Event_1. This is considered an implicit OR, since Job_C can wait for Event_1 from job workflow A or B.

Events that are deleted by an unscheduled job after it has finished executing are handled, as follows:

• If the deleted event action is used once in the folder as a wait for event, the job that inherits the wait for event also inherits the delete event action.

• If the deleted event action is used by more than one job in the folder, the deleted event action is added to the relevant folder post processing actions.

You can view the job log or SMART folder log to see the messages of the Bridge.