Control-M code deployment best practices

[kondalmrao]

Hi There,

I am quite new to Control-M and I am into this project where they use a very unique way of deploying the control-m xml into production as part of every new release of our application.

1. Every time there is a new release, we generate the complete control-M xml file containing all the jobs using a custom built shell-script based tool.
2. This tool takes some excel sheets(with job dependencies and other relevant etc) as inputs and comes out with a complete XML for all the 3000 jobs.
3. Even if there is 1 new job as part of release, we need to completely generate this new xml and deploy in production. (well, this is how its been for the past 7 years)
4. Once the xml's are ready, we purge and do a complete upload for all the 3000+ jobs in production.

This approach is causing us huge problems lately because of wrong xml generations etc.

Now, I would like to understand various ways of moving the control-m code(may be xmls or something else) from one environment to other and kindly let me know if there is an industry-wide best practice that is followed.

Also, is there any best way of maintaining the code(xml or something else) in any configuration management tools?

By the way, we use Control-M 6.3 on unix. Please apologize if i missed to give you any obvious information that I should have. Its just lack of knowledge.

Thanks Guys!
Kondal

[th_alejandro]

I don't understood. Why xml ?, excel definitions ?

You have a desktop and can export draft files to load then into production. The draft can be generates as xml to avoid shell generation and maintain upgrades.

[philmalmaison]

my way :
make a sleeping controlm em making ecs util export/import process, allow you to upgrate the sleeping one first (do what you want for going in prod), when start the slepping one, disconnect gateways and anythink to start the sleeping one.
so then you can update the prod export/import and disconnect to the first active server .....
if it's a long way to MAJ, but no services out during process ...

regards
philmalmaison

[Walty]

Hi,

Small preview of how we work in v6.3

We have industrialized our way of defining the scheduling activity using our own generator with its proprietary database.

- This database is our repository of reference for scheduling jobs.
- The definitions are imported after in Control-M/EM and uploaded in Control-M/Server.

The generation is done once for all jobs and facilitates the generation and deployment of an environment to another, because only the 1st letter of jobname, conditions, resources, .... change like : P = prod, D = devl, I = intg, ..... and not the contents.

The output build by the generator is a standard <deftable> XML format.

When the generation is complete, we use Control-M where 2 cyclic jobs are scheduled (technical window) to run the deployement in the specific environment. Jobs execute this:

Job1) Invoke the utility <deftable> to import Table(s) issue by generator in the Control-M/EM db
Job2) Invoke the utility <ecs cli with parm TABLE_UPLOAD> to complete the upload for specifics Table (s) in the Control-M/Server db

If a job(s) needs to be changed, the entire scheduling Table(s) are regenerated, imported and uploaded.

Generally we use Control-M/Desktop for:

- The definition of specific jobs such as SAP (few jobs) or specific technical maintenance activities
- The correction of an urgent job / table (knowing it will be updated using the generator later)
- Creation calendars

Table(s) generated by the Control-M/Desktop have a specific suffix (ie: table_name-D) to differentiate them.