Control-M Global Condition Prefixes

Control-M Global Condition Prefixes - best practice

This section provides recommendations for implementing global conditions between different Control-M installations.

Frequent updates to a global condition (toggles)

If the status of a global condition frequently changes (is added and deleted) within a short period of time, the Global Conditions server might become overloaded and the global conditions might not be distributed correctly.

To prevent this problem, find a balance for Global Conditions server processing by setting appropriate values using Global Conditions Server Parameters options from the root menu. These parameters define how the Global Conditions server should handle frequent updates to global conditions. For details, see the following menu options in the Control-M Administrator Guide:

Delete Time For Sent Conditions
Method for Handling Conflicting Conditions
The Mode for Handling Conflicting Conditions

Bi-directional global conditions

Global conditions can be “bi-directional,” meaning that if a global condition is added or deleted in one of several Control-M installations, it is automatically added to or deleted from the others.

However, the definition of bi-directional global conditions generates additional overhead and puts additional stress on system processing, particularly in the Global Conditions server. This can slow down other requests and data transmissions. For this reason, BMC Software recommends that you avoid implementing bi-directional global conditions.

You can achieve the benefits of bi-directional global conditions using regular,one-way global conditions. This more efficient alternative involves:

Definition of additional “dummy” jobs for maintaining (adding and deleting) global conditions
Definition of two global condition prefixes (instead of one), each representing a direction between the Control-M installations
Definition of two extra “dummy” global conditions for triggering the maintenance functions performed by the two “dummy” jobs

A sample implementation is provided below, first using bi-directional global conditions and then by simulating the use of bi-directional global conditions.

Sample scenario

A set of jobs can only run if the company’s intranet is up and running at all sites. Therefore, all sites (Control-M installations) have cyclic jobs that, at regular intervals, check intranet status and update the status using global conditions. If a particular intranet site in the company is down, a job deletes the global conditions that indicate that the intranet is up and running.

In this scenario, the company has two sites:

One Control-M installation exists in Seattle
Another exists in London

In Seattle, a job called CheckS checks and updates conditions starting with the Intranet prefix (such as IntranetS-Up and IntranetL-Up). In London, a job named CheckL performs the same function. Addition and deletion of conditions with the Intranet prefix in either location should always occur in both locations.

Using bi-directional global conditions (not recommended)

The following representation of the Global Conditions window illustrates a basic and intuitive way to define bi-directional global conditions.

Prefix	From Control-Ms	To Control-Ms
Intranet	Seattle, London	London, Seattle

This definition specifies that addition and deletion of a condition that begins with the characters Intranet in either the Seattle or London site automatically generates the same update at the other site. This is a valid definition for bi-directional global conditions, but is not efficient.

Using regular global conditions (recommended)

For more efficient distribution and processing of global conditions, define jobs and global condition prefixes as follows.

The setup

In this scenario, you would create the following job processing definitions:

Jobs	Purpose
CheckS	In Seattle, this job checks intranet status and updates global conditions starting with the prefixes defined below. This job updates two global conditions (instead of one, Intranet, as was done in the sample above) with each global condition representing one direction. CheckS updates conditions with an West2East prefix. Updates to these conditions are passed towards the East to London.
CheckL	In London, checks intranet status and updates global conditions starting with the prefixes defined below. This job updates two global conditions (instead of one, Intranet, as was done in the sample above) with each global condition representing one direction. CheckL updates conditions with an East2West prefix. Updates to these conditions are passed towards the West to Seattle.
MaintainS	Dummy job processing definition in Seattle for removing global conditions that are no longer necessary; serves administrative and maintenance purposes only. MaintainS tracks, and deletes, unnecessary conditions by updating dummy global conditions.
MaintainL	Dummy job processing definition in London for removing global conditions that are no longer necessary; serves administrative and maintenance purposes only. MaintainL tracks, and deletes, unnecessary conditions by updating dummy global conditions.

Define the following job global condition prefixes:

Prefix	From Control-Ms	To Control-Ms
East2West	Seattle	London
West2East	London	Seattle

Processing flow: an overview

The following figure provides an overview of the processing flow of jobs defines when implementing the recommended practice for simulating bi-directional global conditions. Each phase in the processing flow is numbered and described in detail under Processing flow: Step by Step below.

D_CTM_BEST_Global

Processing flow: step-by-step

The CheckS cyclic job in Seattle runs when the East2West Maint global condition is created (the first time, manually).
This job:
- Checks intranet status
- Creates a global condition named West2East Check
The Global Conditions server passes this condition to London.
The CheckL job is triggered by the creation of the West2East Check In condition.
This job
- Checks intranet status
- Creates the East2West Check condition
- Deletes the West2East Check condition locally (meaning, at the local Control-M installation only), because West2East is a one-way prefix.
The MaintS job, which waited for the creation of its East2West Check In condition, runs and
- Creates the West2East Maint condition
- Deletes the East2West Check condition locally
- Deletes the West2East Check condition in both Seattle and London
Because this condition was already deleted by CheckL in London, processing is minimal.
The MaintL job, which waited for the creation of its West2East Maint In condition,runs and:
- Adds the East2West Maint condition, which will trigger the CheckS job in Seattle
- Deletes the West2East Maint condition locally
- Deletes the East2West Check condition in both Seattle and London
Again, because this condition was already deleted in Seattle, processing is minimal.
The cycle begins again. The CheckS job is again triggered by its In condition, East2West Maint (this time, not manually).
When the CheckS job runs, it
- Checks intranet status
- Recreates the West2East Check condition, which will trigger the CheckL job in London
- Deletes the East2West Maint condition locally
- Deletes the West2East Maint condition in both Seattle and London, with minimal effect on processing
The CheckL job is again triggered by its West2East Check In condition, and the cycle continues.
When the CheckL job runs, it:
- Checks intranet status
- Recreates the East2West Check condition.
- Deletes the West2East Check condition locally
- Deletes the East2West Maint condition in both Seattle and London, with minimal effect on processing
The cycle is repeated beginning with Step 3.

Parent Topic

Best Practices