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 |
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:
(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:
|
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 EventsLink copied to clipboard
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.
A SMART folder contains three jobs that are dependent on each other, as follows:
-
Job_C waits for Job_B to successfully complete execution before it begins execution.
-
Job_B waits for Job_A to successfully complete execution before it begins execution.
If Job_B is not scheduled to execute on a specific day, then Job_C cannot execute at all, since it indefinitely waits for Job_B to finish execution. Adjust Events enables Job_C to execute and not wait for Job_B.
Adjust Events is applied to events created in a SMART folder or sub-folder. If a job waits for an event that is not created in one of these folders, the event is not adjusted by an Adjust Event.
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.
-
-
-
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.
Events that are deleted by an unscheduled job after it has finished executing are handled, as follows:
You can view the job log or SMART folder log to see the messages of the Bridge.