Hi to all.
We are testing the version v7 of Control-M.
I have read the documentation, but I fail to understand and solve:
As defined and which is the concept of Rule-Based Calendar (RBC).
Can you help me and explain their operation?.
RBC in Smart Table from Control-M v7
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
futre25,
Which version do you come from? RBC are nothing else than the former scheduling tags, which have been named so from version 6.0.0 till 6.4.0.
According to your background in that forum, one can beleive you have been using at least one 6.xx version.
If you never used scheduling groups - which is usefull but not mandatory - then this concept is new to you.
Please confirm and we might develop the issue
Cheers
Nicolas Mulot
Which version do you come from? RBC are nothing else than the former scheduling tags, which have been named so from version 6.0.0 till 6.4.0.
According to your background in that forum, one can beleive you have been using at least one 6.xx version.
If you never used scheduling groups - which is usefull but not mandatory - then this concept is new to you.
Please confirm and we might develop the issue
Cheers
Nicolas Mulot
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
Futre25,
The concept of scheduling groups has been introduced in V6.00 and includes several interesting features, among which the scheduling tags.
Scheduling tags combine scheduling parameters as you can find in the traditional “Scheduling” tab of your jobs definition.
You can define as many scheduling tags for a scheduling group: the group will be ordered as long as the current order date matches with any scheduling parm specified in any scheduling tag.
No job of the group can be ordered as long as the scheduling group itself is not ordered.
In the definition of a job belonging to a SG, the “Scheduling” tab is slightly different. You still have all the normal scheduling parms, but you have also a “Scheduling Tab selection” windows, as well as a “Tag relationship” field.
Though it is possible to combine jobs scheduling parameters with tags, is is not recommended to define complex rules on both sides.
You can refer any scheduling tag in the “Scheduling” tab of the jobs of the group. In that case, you have to define a Boolean and/or to rule the combination between the scheduling parameter of the scheduling tag and the job’s own scheduling parameters.
One advantage of the tags is to centralise the scheduling parameters at the group level. Under normal conditions, the job’s scheduling parameters will be limited to one or more tag name(s).
Another advantage is that you can now combine scheduling parameters which are normally not compatible.
For example, you cannot define a scheduling rule like “every Monday plus the 1st of January with “normal” job scheduling definitions, because date parameters cannot be combined with any other scheduling parm. (to solve that case, people use to duplicate the job definitions). Using scheduling tags you can define:
1°) in the group:
TAG1 weekdays 1, month ALL
TAG2 0101
2°) in the job
Days ALL
Month ALL
TAG_RELATIONSHIP And
TAGS TAG1, TAG2
Since the job definition is not self sufficient to resolve the job’s scheduling criteria, you cannot order a job belonging to a scheduling group (using control-m/Desktop or ctmcontb): you can only force it. In that case, and since you may have already a copy of the SG on the AJF, you have additional ordering options, like “create a new SG”, “order the job standalone (without a SG) or “order the job in the most recent SG”.
There is much more to tell about SG in general and tags in particular..
Under version 7, replace the expressions “Scheduling Group” by SMART table” and “Scheduling Tag” by “RBS” and that’s it
Cheers
Nicolas_Mulot
The concept of scheduling groups has been introduced in V6.00 and includes several interesting features, among which the scheduling tags.
Scheduling tags combine scheduling parameters as you can find in the traditional “Scheduling” tab of your jobs definition.
You can define as many scheduling tags for a scheduling group: the group will be ordered as long as the current order date matches with any scheduling parm specified in any scheduling tag.
No job of the group can be ordered as long as the scheduling group itself is not ordered.
In the definition of a job belonging to a SG, the “Scheduling” tab is slightly different. You still have all the normal scheduling parms, but you have also a “Scheduling Tab selection” windows, as well as a “Tag relationship” field.
Though it is possible to combine jobs scheduling parameters with tags, is is not recommended to define complex rules on both sides.
You can refer any scheduling tag in the “Scheduling” tab of the jobs of the group. In that case, you have to define a Boolean and/or to rule the combination between the scheduling parameter of the scheduling tag and the job’s own scheduling parameters.
One advantage of the tags is to centralise the scheduling parameters at the group level. Under normal conditions, the job’s scheduling parameters will be limited to one or more tag name(s).
Another advantage is that you can now combine scheduling parameters which are normally not compatible.
For example, you cannot define a scheduling rule like “every Monday plus the 1st of January with “normal” job scheduling definitions, because date parameters cannot be combined with any other scheduling parm. (to solve that case, people use to duplicate the job definitions). Using scheduling tags you can define:
1°) in the group:
TAG1 weekdays 1, month ALL
TAG2 0101
2°) in the job
Days ALL
Month ALL
TAG_RELATIONSHIP And
TAGS TAG1, TAG2
Since the job definition is not self sufficient to resolve the job’s scheduling criteria, you cannot order a job belonging to a scheduling group (using control-m/Desktop or ctmcontb): you can only force it. In that case, and since you may have already a copy of the SG on the AJF, you have additional ordering options, like “create a new SG”, “order the job standalone (without a SG) or “order the job in the most recent SG”.
There is much more to tell about SG in general and tags in particular..
Under version 7, replace the expressions “Scheduling Group” by SMART table” and “Scheduling Tag” by “RBS” and that’s it
Cheers
Nicolas_Mulot
Hi nicolas_mulot. Thanks for your reply.
I learned the concept and has helped me.
Also, I have seen new features in the Control-M v7 that are new to me and I could not find its proper functioning.
Could you explain how to use and functionality for:
- Workload Management - Workload Manager.
- Workload Monitor.
- Periodic Statistics Manager.
Thank you very much for helping. I hes very helpful and I am very grateful.
I learned the concept and has helped me.
Also, I have seen new features in the Control-M v7 that are new to me and I could not find its proper functioning.
Could you explain how to use and functionality for:
- Workload Management - Workload Manager.
- Workload Monitor.
- Periodic Statistics Manager.
Thank you very much for helping. I hes very helpful and I am very grateful.
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
Futre25,
This feature is actually new to V7.
The principle is to get a more detailed and more flexible on the global workload.
It might be confusing for it might seem to replace and expand the concept of resources.
Basically, it acts like queues:
You can define a queue to submit jobs, and open/close the queue manually.
When open, the queue can be made active/inactive by using schedule like parameters (dates, days of week, time frames). You can then limit the parallel executions of a set of jobs according to date/time parameters (example: do not allow test jobs during night shift).
This point is basically covered by the “Running jobs” tab of the workload definition window.
You can achieve same kind of result by dynamically affecting different quantities to QR depending on the same date/time type of parameters, using the “Resource” tab.
To address the same kind of need (no test job at night), people used to assign a resource to test jobs (let’s say QR_TESTJOB) and set the max quantity to 0 using a ecaqrtab, usually scheduled by 06:00 PM. This particular feature of the workload management eliminates/replaces this specific implementation.
Most of the modern schedulers use queues. In that case, the queue is defined first, then attached to jobs or other running objects thru a specific parameter. With control-m V7, it works slightly differently, in that that the workload is valid for a generic set of jobs, specified in the “Filter” tab.
When a workload has reached its limits in terms of job submission, this appears as a reason in the Why window of targeted jobs.
The workload monitor gives you a global view of the active workloads (jobs running, jobs waiting etc..)
Cheers
This feature is actually new to V7.
The principle is to get a more detailed and more flexible on the global workload.
It might be confusing for it might seem to replace and expand the concept of resources.
Basically, it acts like queues:
You can define a queue to submit jobs, and open/close the queue manually.
When open, the queue can be made active/inactive by using schedule like parameters (dates, days of week, time frames). You can then limit the parallel executions of a set of jobs according to date/time parameters (example: do not allow test jobs during night shift).
This point is basically covered by the “Running jobs” tab of the workload definition window.
You can achieve same kind of result by dynamically affecting different quantities to QR depending on the same date/time type of parameters, using the “Resource” tab.
To address the same kind of need (no test job at night), people used to assign a resource to test jobs (let’s say QR_TESTJOB) and set the max quantity to 0 using a ecaqrtab, usually scheduled by 06:00 PM. This particular feature of the workload management eliminates/replaces this specific implementation.
Most of the modern schedulers use queues. In that case, the queue is defined first, then attached to jobs or other running objects thru a specific parameter. With control-m V7, it works slightly differently, in that that the workload is valid for a generic set of jobs, specified in the “Filter” tab.
When a workload has reached its limits in terms of job submission, this appears as a reason in the Why window of targeted jobs.
The workload monitor gives you a global view of the active workloads (jobs running, jobs waiting etc..)
Cheers