Prerequisites

Prerequisites are submission criteria that must be met for a folder, sub-folder, or job to execute. When all job prerequisites and scheduling criteria are met, jobs are submitted for execution.

The following table describes the submission criteria as follows.

Criteria	Description
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.
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.
Resources	Enables you to control the load of jobs in your workflow A flow of jobs that executes at specific times, in a specific sequence, and under specific conditions., as follows: Lock Resources Resource Pools
Lock Resources	Defines a job flow, preventing multiple jobs from running at the same time. If multiple jobs require access to a database and run concurrently, the database can crash or overwrite entries. Lock Resources controls the flow by sharing resources or locking resources exclusively, avoiding concurrent execution of jobs. Lock resources enables you to add a lock Type to a job, as follows: Name: Defines the name of the lock resource using the following valid values: Characters: 1–64 Case Sensitive: Yes Invalid Characters: Blank spaces, ' (apostrophes). Type: Determines the type of lock 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.
Resource Pools	Determines the quantity of resources you can allocate from the Resource Pool for each job to run. Resource Pools are defined at job level only 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.
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.

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.

  

• Yes: Control-M executes the unscheduled job as a dummy job.

• 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.

  

  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.

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.