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:
(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 Events
Adjust Events enables you to maintain the functionality and execution order 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, so that Job_C waits for Job_B, which waits for Job_A.If Job_B is not scheduled to execute on a specific day, then Job_C cannot execute at all, since it waits for Job_B to finish executing indefinitely. 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: Control-M deletes the Wait for Events from the unscheduled job so the successor job can execute.
-
No: The unscheduled job is not adjusted and the Wait for Events is not deleted. The successor job is in a Waiting status.
-
Dummy: Control-M executes the unscheduled job as a dummy job and saves all the events. The successor job waits for the dummy job event to execute. In a Distributed System, to use the Dummy option you must set the CTM_FOLDER_ADJUST_DUMMY to Y in System parameters and then set Adjust Event on your folder to Yes.
-
Bridge: Connects and enables scheduled jobs to execute when there are unscheduled jobs in the same folder and maintains the order and dependencies between jobs.
If Job_A and Job_C execute every day and Job_B executes Monday to Saturday, you can apply a bridge that enables Job_C to execute after Job_A on Sunday and not depend on the execution of Job_B.
This feature is supported in Control-M/Server 9.0.21 and higher.
The 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.
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.