Hi all,
I have a schedule with 12 different Scheduling Groups with dependencies between them.
When I want to trigger them again a second time on the same day, the conditions overlap eachother as the schedule has run already once the same day and the name of the condition field is the same.
With the jobs we can prevent this by adding conditions with an auto-edit variable %%GROUP_ORDID. (Although this is then only possible within the same Scheduling Group).
For the conditions of the Group Scheduling field however we are not so lucky and I cant find a suitable variable.
We tried to create a suitable User-Defined Variable, but it turns out that variables that are User-Defined can not be user in Conditions.
Surely we cant be the first one that tries to do this?
Does anyone have an idea how to go around this?
Is it maybe possible to re-start the New Daily User Procedure so we dont have to worry about these settings....
Thanks very much,
Pieter
Not possible to run Scheduling Groups multiple times a day
I can think of two solutions:
1) Jobs and Scheduling Groups should delete their own IN conditions when they are completed. When the jobs/groups are ordered again (or simply rerun), conditions will not be pre-existing. This is a best practice any way.
2) Add @HHMMSS to the end of each IN and OUT conditions. @HHMMSS will be translated to the time stamp when the jobs are ordered. With that, you have to make sure all jobs/scheduling groups linking together are ordered within the same command so that they take the exact same time stamp.
1) Jobs and Scheduling Groups should delete their own IN conditions when they are completed. When the jobs/groups are ordered again (or simply rerun), conditions will not be pre-existing. This is a best practice any way.
2) Add @HHMMSS to the end of each IN and OUT conditions. @HHMMSS will be translated to the time stamp when the jobs are ordered. With that, you have to make sure all jobs/scheduling groups linking together are ordered within the same command so that they take the exact same time stamp.
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
PeeWee,
I understand when you write "trigger" you mean "order".
Is the production requirement to order twice your application or to run it twice ?
If you have to order them several times, I dont seen any easy way to achieve that.
Gglau's suggestions are the good ones. It is always highly recommended to have all jobs and SGs suppressing the conditons they require as IN parameter.
I tried to implement some kind of solution using an order user exit 101, just to observe that the multiple occurrence fields, like IN and OUT where
not passed to the exit, so forget it.
If you HAVE to re-order you SGs, forget that post
If you can address your production requirements by rerunning your SGs, then you can do it using a method which was more or less explained in a recent topic on
that forum.
Basically, the idea is to be able to identify all the jobs involved in your application.
If for example, the common Id is the APPLIC name, then, all your objetcs will match the following:
select ORDERNO from CMR_AJF where APPLIC'your_applic' and ODATE='today'
.. and all your jobs will match the following:
select ORDERNO from CMR_AJF where APPLIC='your_applic' and ODATE='today' and TASKTYPE !='G'
Using such a request, you can build a sequence of commands like this:
ctmpsm -updateajf "*<orderno>" rerun.
Another request, based on the same criteria can identify those conditons used by any of your jobs and set by at least one of your jobs
select CONDNAME, ODATE
from CMR_CON_J
where ROWTYPE='I' -- IN conditions
and ORDERNO in ( -- used by
select ORDERNO from CMR_AJF where APPLIC='your_applic' -- the jobs of your_applic
)
and CONDNAME in ( -- and
select CONDNAME from CMR_CON_J where ROWTYPE in ('O','D') and OP='+' -- added thru OUT + or DOCOND +
and ORDERNO in ( -- by job(s)
select ORDERNO from CMR_AJF where APPLIC='your_applic' -- of your_application
)
)
This request can be used to build a list of ctmcontb -delete
Include both requests in a script, send output of both requests to 2 scripts (delete_conds_in_appli.bat, rerun_jobs_in_appli.bat) and call them dynamically.
The global script can be part of your appli, and triggered by a manual condition, or rerun by the operator etc..
The conditions must be deleted before the jobs are rerun.
Finally, consider the CTM_GROUP_RECHECK parameter in the controlm server config.dat, so the jobs in dependant SG are rerun in the proper sequence.
All of the above adress the controlm database in query only mode (no direct update) and relies on standard utilities (ctmpsm, ctmcontb)
Forget about rerunning the new day proc. It will not address your need and is highly NOT recommended.
Cheers
Nicolas Mulot
I understand when you write "trigger" you mean "order".
Is the production requirement to order twice your application or to run it twice ?
If you have to order them several times, I dont seen any easy way to achieve that.
Gglau's suggestions are the good ones. It is always highly recommended to have all jobs and SGs suppressing the conditons they require as IN parameter.
I tried to implement some kind of solution using an order user exit 101, just to observe that the multiple occurrence fields, like IN and OUT where
not passed to the exit, so forget it.
If you HAVE to re-order you SGs, forget that post
If you can address your production requirements by rerunning your SGs, then you can do it using a method which was more or less explained in a recent topic on
that forum.
Basically, the idea is to be able to identify all the jobs involved in your application.
If for example, the common Id is the APPLIC name, then, all your objetcs will match the following:
select ORDERNO from CMR_AJF where APPLIC'your_applic' and ODATE='today'
.. and all your jobs will match the following:
select ORDERNO from CMR_AJF where APPLIC='your_applic' and ODATE='today' and TASKTYPE !='G'
Using such a request, you can build a sequence of commands like this:
ctmpsm -updateajf "*<orderno>" rerun.
Another request, based on the same criteria can identify those conditons used by any of your jobs and set by at least one of your jobs
select CONDNAME, ODATE
from CMR_CON_J
where ROWTYPE='I' -- IN conditions
and ORDERNO in ( -- used by
select ORDERNO from CMR_AJF where APPLIC='your_applic' -- the jobs of your_applic
)
and CONDNAME in ( -- and
select CONDNAME from CMR_CON_J where ROWTYPE in ('O','D') and OP='+' -- added thru OUT + or DOCOND +
and ORDERNO in ( -- by job(s)
select ORDERNO from CMR_AJF where APPLIC='your_applic' -- of your_application
)
)
This request can be used to build a list of ctmcontb -delete
Include both requests in a script, send output of both requests to 2 scripts (delete_conds_in_appli.bat, rerun_jobs_in_appli.bat) and call them dynamically.
The global script can be part of your appli, and triggered by a manual condition, or rerun by the operator etc..
The conditions must be deleted before the jobs are rerun.
Finally, consider the CTM_GROUP_RECHECK parameter in the controlm server config.dat, so the jobs in dependant SG are rerun in the proper sequence.
All of the above adress the controlm database in query only mode (no direct update) and relies on standard utilities (ctmpsm, ctmcontb)
Forget about rerunning the new day proc. It will not address your need and is highly NOT recommended.
Cheers
Nicolas Mulot
Hi,
Good advices, but i add this comment about :
ctmpsm -UPDATEAJF <orderid> <HOLD|FREE|DELETE|UNDELETE|RERUN|CONFIRM|FORCEOK|STATISTICS|CONDADDIN <cond> <date> <AND|OR>|CONDADDOUT <cond> <date> <+|->|CONDDELIN <cond>|CONDDELOUT <cond>
To convert orderno to orderid use the <p_36> utility
orderno to orderid : p_36 "*<orderno>"
orderid to orderno : p_36 <orderid>
Good advices, but i add this comment about :
- ctmpsm -updateajf "*<orderno>" rerun
ctmpsm -UPDATEAJF <orderid> <HOLD|FREE|DELETE|UNDELETE|RERUN|CONFIRM|FORCEOK|STATISTICS|CONDADDIN <cond> <date> <AND|OR>|CONDADDOUT <cond> <date> <+|->|CONDDELIN <cond>|CONDDELOUT <cond>
To convert orderno to orderid use the <p_36> utility
orderno to orderid : p_36 "*<orderno>"
orderid to orderno : p_36 <orderid>
Best regards
Walty
Walty
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
Walty,
I didnt know P_36 worked both ways, but Im sure of what I say concerning ctmpsm.
Most of the controlm utilities which are orderid driven, such as ctmpsm, ctmkilljob and others - obvioulsly P_36 too - , normally use the orderid in alphanumeric format, like 019it.
Still, they accept the ORDERNO in decimal format, as found in the server database, provided is is enclosed in double quotes and preceeded by as asterisk.
In our case:
ctmpsm -updateajf 019it rerun
.. will have the same effect as:
ctmpsm -updateajf "*58997" rerun
Since we access the ordernos from the ajf, we must use the second format to generate the proper command.
To obtain the proper format, the request should look like:
select 'ctmpsm -updateajf"*' || ltrim(to_char(ORDERNO)) || '" rerun'
for Oracle format or
select 'ctmpsm -updateajf"*'+ltrim(str(ORDERNO)) || '" rerun'
for MS/SQL
Nicolas Mulot
I didnt know P_36 worked both ways, but Im sure of what I say concerning ctmpsm.
Most of the controlm utilities which are orderid driven, such as ctmpsm, ctmkilljob and others - obvioulsly P_36 too - , normally use the orderid in alphanumeric format, like 019it.
Still, they accept the ORDERNO in decimal format, as found in the server database, provided is is enclosed in double quotes and preceeded by as asterisk.
In our case:
ctmpsm -updateajf 019it rerun
.. will have the same effect as:
ctmpsm -updateajf "*58997" rerun
Since we access the ordernos from the ajf, we must use the second format to generate the proper command.
To obtain the proper format, the request should look like:
select 'ctmpsm -updateajf"*' || ltrim(to_char(ORDERNO)) || '" rerun'
for Oracle format or
select 'ctmpsm -updateajf"*'+ltrim(str(ORDERNO)) || '" rerun'
for MS/SQL
Nicolas Mulot
I think everyone is making this too difficult. The think gglau was close to the answer.
In our company nearly all of our jobs are cyclic. With cyclic jobs you need to be careful to cleanup conditions. "In" conditions need to be deleted as soon as they are no longer needed. This is simple if the in condition is only used by one job. That job uses the "In" condition deletes it in the "Out" conditions.
If the "In" condition is used by multiple independent jobs then it can require some creative solutions. I won't go into the detail explaining how I have done it unless someone needs me to.
In our company nearly all of our jobs are cyclic. With cyclic jobs you need to be careful to cleanup conditions. "In" conditions need to be deleted as soon as they are no longer needed. This is simple if the in condition is only used by one job. That job uses the "In" condition deletes it in the "Out" conditions.
If the "In" condition is used by multiple independent jobs then it can require some creative solutions. I won't go into the detail explaining how I have done it unless someone needs me to.
That's why I am the proponent for using the naming convention JobA-TO-JobB as condition name over the simpler JobA-ENDED (or JobA-OK which I think is not a good choice at all). In my opinion, the benefit of independent conditions with IN and OUT jobnames outweigh the cost of higher maintenance. I am sure this can be a separate topic open for additional debates.
Hi all,
Thanks very much for your reply, it has helped us a lot.
Indeed, I managed to set up succesfully the deletions of the conditions.
Now, in the Enterprise Manager we still see an overlap in the conditions lines, but indeed Control M is waiting until the condition gets once again an 'Ended-Ok'.
Also, I tested the @HHMMSS and that gives indeed the timing of the order.
We are writing a script so we can add this unique identifier once we trigger all groups at the same time
Thanks again!!
Pieter
Thanks very much for your reply, it has helped us a lot.
Indeed, I managed to set up succesfully the deletions of the conditions.
Now, in the Enterprise Manager we still see an overlap in the conditions lines, but indeed Control M is waiting until the condition gets once again an 'Ended-Ok'.
Also, I tested the @HHMMSS and that gives indeed the timing of the order.
We are writing a script so we can add this unique identifier once we trigger all groups at the same time
Thanks again!!
Pieter
Final solution implemented
Hi all,
To give a final update to this once more, we couldnt set the time precisely to all the groups at the same time with the @HHMMSS variable.
We finally found and succesfully implemented another solution, we made use of the %%APPLIC variable. The %%APPLIC Variable sets the application in which the scheduling groups run. We set it in the script to a time-variable to identify it uniquely:
Another benefit was that due to the Application variable setting we now we see every run in a different grouping as well.
To give a final update to this once more, we couldnt set the time precisely to all the groups at the same time with the @HHMMSS variable.
We finally found and succesfully implemented another solution, we made use of the %%APPLIC variable. The %%APPLIC Variable sets the application in which the scheduling groups run. We set it in the script to a time-variable to identify it uniquely:
Code: Select all
#!/bin/sh
TIME=`date '+%H%M%S'`
ctmorder -schedtab SERP-BIR3-START -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-FMA-PSA -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-OTC-PSA -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-RE-PSA -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-RTP-PSA -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-PTW-PSA -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-MDAH -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-ACR -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-FMA-TD -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-OTC-TD -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-RE-TD -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-RTP-TD -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-PTW-TD -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-MD-Txt -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-GENERAL -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME
ctmorder -schedtab SERP-BIR3-FINISH-1 -jobname "*" -force Y -odate ODAT -autoedit %%APPLIC SERP-BIR3-$TIME