Prerequisites

Prerequisites are submission criteria that must be met for a folder, sub-folder or job to run. 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 eventClosedAn entity that creates a sequence 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 workflowClosedA flow of jobs that execute at specific times, in a specific sequence, and with available resources, 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 values as follows:

  • Characters: 1-64, z/OS: 1-20

  • Case sensitive: Yes

  • Invalid characters: Blanks, single quotation marks

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.

(z/OS) From the On Fail drop-down list, select Release or Keep.

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.

(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 run order of jobs in a SMART folder or sub-folder when a job within the folder is not scheduled to run on a specific day. Control-M determines how to handle the Wait for Events of an unscheduled job to enable a successor job to run.

If you have a folder containing Jobs A, B, and C, and Job B is not scheduled to run, Job C cannot run. Adjust Events enables Job C to run, and not wait for Job B.

Adjust Events is applied to the events created within the folder. If a job waits for an event that is not created in the folder, the event is not adjusted.

You can define Adjust Events with one of the following:

  • Yes: Control-M deletes the Wait for Events from the unscheduled job and the successor job is able to run.

  • 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 runs the unscheduled job as a dummy job and saves all the events. The successor job waits for the event from the dummy job to run. In a Distributed System, if you want 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 run when there are unscheduled jobs in the same folder and maintains the order and dependencies between jobs.

    If jobs A and job C run every day and job B runs Monday to Saturday, you can apply a bridge that enables job C to run 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 parentheses, 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.

        If there are two job flows A and B, which connect to job C with the same event E1, it is considered an implicit OR, as job C can wait for E1 either from job flow A OR job flow B.

  • Events that are deleted by the 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.