Hi All,
We have a bunch of jobs that loads at midnight (00:00) current day and runs/executes the next day once in conditions are satisfied. When using late time in Post Proc tab to send a shout alert, the alert being sent is not accurate, probably due to the 24 hr limit value on the late time. Is there a workaround on this issue? Any help is greatly appreciated. Thanks in advance.
Workaround needed for Late time in Post Proc tab
-
be_incontrol
- Nouveau
- Posts: 13
- Joined: 26 Sep 2008 12:00
Workaround needed for Late time in Post Proc tab
Can you give some more specifics:
Is your new day time midnight? When do they run? What is the late time alert?
You don't need to order in all jobs at new day time. It may be that you can solve your problem by using a different user daily for these tables and running the ctmudly job (to order these tables) at a later time. But I can't be sure until I have specific information.
Is your new day time midnight? When do they run? What is the late time alert?
You don't need to order in all jobs at new day time. It may be that you can solve your problem by using a different user daily for these tables and running the ctmudly job (to order these tables) at a later time. But I can't be sure until I have specific information.
-
be_incontrol
- Nouveau
- Posts: 13
- Joined: 26 Sep 2008 12:00
Our newday load is at midnight (00:00). 1 of our user daily e.g. named A1DAILY loads at 10:00 a.m. same day.
It includes for example jobs:
A
B
C
D
- Job A runs between 22:00 to 23:00 of same day, once successfully done passes out condition to job B.
- Job B runs from 23:01 to 03:00 of (next day), once successfully done passes out condition to job C and D.
- Job C and D are tagged critical jobs by business and it needs a late time shout. If I put a late time shout of 0900 on Post Proc tab for jobs C and D, we do not get late time alerts for jobs C and D which are currently scheduled to run but we get alerts of late time shout for jobs C and D once user daily A1daily loads on its scheduled time of 10:00 a.m. for jobs C and D which are scheduled to run for the next day.
I hope I have explained the issue and have given the specifics clearly.
It includes for example jobs:
A
B
C
D
- Job A runs between 22:00 to 23:00 of same day, once successfully done passes out condition to job B.
- Job B runs from 23:01 to 03:00 of (next day), once successfully done passes out condition to job C and D.
- Job C and D are tagged critical jobs by business and it needs a late time shout. If I put a late time shout of 0900 on Post Proc tab for jobs C and D, we do not get late time alerts for jobs C and D which are currently scheduled to run but we get alerts of late time shout for jobs C and D once user daily A1daily loads on its scheduled time of 10:00 a.m. for jobs C and D which are scheduled to run for the next day.
I hope I have explained the issue and have given the specifics clearly.
-
nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
be_incontrol ,
There is basically no smart solution to your problem, for the time frame for shout is from 00 :00 to 23 :59, and is strictly a HHMM on 4 chars (no day type delay)
1°) There is a possibility, available since version 630 and called Time Synonyms, and which can extend the time frame from 00:00 to virtually 49:59. This is based on the actual new day time and does not apply to your case, for your newday time is 00:00.
2°) Another solution would be to order jobs C and D one day after job B, and use PREV in the condition dates. In that situation, SHOUT WHEN LATE 0900 would work for C and D, but ..
This is another problem if your jobs are not daily jobs, since PREV does not consider the ODATE of the predecessor, but the date of the current job .
To overcome that new problem, you should change the condition date in C and D definitions to B_C_OK **** and B_D_OK ****, and do not forget to delete these conditions in the OUT of C and D.
An inconvenient of this implementation is that you lose the ODATE consistency between your 4 jobs.
3°) Another solution is to create another job to check at 09:00 whether D or C are still in Wait status for any reason, and send the actual SHOUT if one of these 2 are still waiting. This job would be ordered one calendar day after A, B, C and D, and it should do something like.
ctmpsm -listall | egrep (C | D) | grep Wait | grep <ODAT> | wc -l
If the result is 0, that means that C nor D are not in Wait status anymore
If the result is 1 or 2, that means that C or D or both are still in Wait status.
The <ODAT> value matches the ODAT of C or D, and can be obtained in the script of the new job by something like:
ctmstvar 0 "%%$CALCDATE %%$ODATE -1".
The advantage of this solution is that you maintain the date consistency of you ABCD chain.
The inconvenient is that the control is made external to the chain
Cheers
Nicolas Mulot
There is basically no smart solution to your problem, for the time frame for shout is from 00 :00 to 23 :59, and is strictly a HHMM on 4 chars (no day type delay)
1°) There is a possibility, available since version 630 and called Time Synonyms, and which can extend the time frame from 00:00 to virtually 49:59. This is based on the actual new day time and does not apply to your case, for your newday time is 00:00.
2°) Another solution would be to order jobs C and D one day after job B, and use PREV in the condition dates. In that situation, SHOUT WHEN LATE 0900 would work for C and D, but ..
This is another problem if your jobs are not daily jobs, since PREV does not consider the ODATE of the predecessor, but the date of the current job .
To overcome that new problem, you should change the condition date in C and D definitions to B_C_OK **** and B_D_OK ****, and do not forget to delete these conditions in the OUT of C and D.
An inconvenient of this implementation is that you lose the ODATE consistency between your 4 jobs.
3°) Another solution is to create another job to check at 09:00 whether D or C are still in Wait status for any reason, and send the actual SHOUT if one of these 2 are still waiting. This job would be ordered one calendar day after A, B, C and D, and it should do something like.
ctmpsm -listall | egrep (C | D) | grep Wait | grep <ODAT> | wc -l
If the result is 0, that means that C nor D are not in Wait status anymore
If the result is 1 or 2, that means that C or D or both are still in Wait status.
The <ODAT> value matches the ODAT of C or D, and can be obtained in the script of the new job by something like:
ctmstvar 0 "%%$CALCDATE %%$ODATE -1".
The advantage of this solution is that you maintain the date consistency of you ABCD chain.
The inconvenient is that the control is made external to the chain
Cheers
Nicolas Mulot
-
be_incontrol
- Nouveau
- Posts: 13
- Joined: 26 Sep 2008 12:00
Search engine optimization can increase the visibility of the website in the search engine. SEO companies know all combination of SEO techniques like social media marketing, link building etc.
seo expert
seo consultant
seo expert india
seo expert
seo consultant
seo expert india