As you have probably heard before, Control-M was the best workload manager. Now that you are using it regularly you are very familiar with Control-M however, unfortunately, conditions management has become a real nightmare. Welcome to the real world. I will try to give you a few hints.

Even if I personally consider Control-M a very good job scheduler, I find that nevertheless it is made heavier and more bulky by the conditions. This is what motivated me to write this article and share my experience to avoid what I call “the trap of the conditions”.

In Control-M if you want to plan two jobs (J1 and J2) one external and the other internal in a smart folder) you have to put a result condition in J1 and put the same name of the condition in entery for J2. Since you do things well like BMC recommended, you delete the condition in the result of J2. You have then put the same name in three different places… you repeat this action as many times as you have successors from J1. And of course, since you test the return codes from the predecessors you have as many scenarios from this threesome to define.

Then things start to get complicated when you delete one of the successors from J1 (job obsolete for example) and forget to modify J1. Since you have not deleted this related condition in J1, it will remain assigned by J1 without ever being deleted by its successor which has disappeared. Everyday there will be as many registrations in the database.

Therefore little by little you put in place a management script which will delete the lost conditions. You have to pay attention to certain conditions which have to remain over a future period. These are the conditions which, for example, build the link related to scheduling periods ; typically a daily condition which depends on a monthly condition.

Imagine all of this in a Production of hundreds or hundreds of thousands of jobs…

To conclude, with Control-M you have to distinguish and modify the predecessors when you add successors to them. You have to modify the two definitions of the job each time you create a condition. Defining the resources of a successor in a predecessor is a very good practice (the links are too strong) – that’s my point of view anyway. Very quickly you will be obliged to put in place a tool for managing these conditions that “could” be lost.

I accept that this is powerful, easy to manage and very dynamic due to the Control-M engine, however, in my opinion, it generates too many management problems when the Production is bulky and extensive.

Note: in particular if you want to keep the control and ownership of your Production, do not put the command Control-M in your scripts which start your application. This principal must not be used, not only for Control-M but also for all the workload managers. You take the risk of creating a strong link between your application and the batch manager.

Customer case on conversion

In the case of our migrations with uMSe, during a conversion from Control-M to another workload manager, we noted a large number of lost conditions. Rather more than with other schedulers. Of course, our uMSe engine does not ever renew yet our customers are not perturbed by the idea of having to be confronted with an excess of conditions. Instead, they are quickly reassured that they will no longer have to manage this in their new Production.

The other pernicious effect of this management in Control-M is that our engine uMSe detects duplicate conditions or even more. In fact, after several years and many IT specialists, the conditions Control-M have been added without ever deleting those that are duplicated.  Not only that, we have noticed on average 4.7 conditions per job in some Control-M whereas generally there are only 1.7 to 2.1 conditions per job.