Autosys job not starting based on starting time but starting based on dependency job condition.

[Arihara Subramanian]

Hi Everyone

Below is the current setup of Job_A and Job_B.

Job_A

date_conditions: 1

days_of_week: mo,tu,we,th,fr,sa,su

start_times: "3:00"

 

Job_B

date_conditions: 1

days_of_week: mo,tu,we,th,fr,sa,su

start_times: "17:00"

condition: s(Job_A,0)

If Job_B force started, from next run it's not following start time 17:00 but starting immediately after Job_A completed. How can we fix this issue?

if Job_B is not force started it's following the start_time correctly.

I heard update_job: Job_B will calculate next start time correctly but is this only way to get it back to normal schedule?

Expecting best practices to be followed on this scenario. Thanks! 

------------------------------
Thanks,
Arihara Subramanian
------------------------------

[AkBar Dar]

Force start job will bypass all conditions.

------------------------------
AkBar Dar
------------------------------

[Blaise Groud]

OFFICIAL
Hello Arihara
I think I have had the same issue a few times and this is my recommendation, it is a workaround that worked for us.

Job_B is starting immediately after job_A because it is estimated that it missed a run the previous day.
So the way around the problem, is to run a sendevent to FORCE_START the job at the time it is expected to run on the same day.

Example:
sendevent -J job_B -E FORCE_STARTJOB -T "28/08/2024 17:00"

This will run it at 5PM and from then on (tomorrow and in the future), its schedule will be back to what you would expect (job_A at 3:00 and then job_B at 17:00)


Blaise Groud
Unix Administrator
Business Technology Services
Phone [phone]
Mobile [phone]
Email [e-mail]<mailto:[e-mail]>
[cid:image001.png@01DAF927.41E490B0]


This email (and any attachments) is for the intended recipient only and may contain privileged, confidential or copyright information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Any confidentiality, copyright or privilege is not waived or lost because this e-mail has been sent to you in error. The information contained in this e-mail does not constitute advice of any kind and the recipient should seek their own advice. The SRO does not accept liability for any loss, damage, cost or expense howsoever caused by this e-mail on the recipient, including but not limited to, damage caused by viruses, corruption, delay, interruption, unauthorised access or use.

Any information in this e-mail must be handled in accordance with the Privacy and Data Protection Act 2014 and the secrecy provisions contained in legislation administered by the SRO.

[Arihara Subramanian]

Hello Blaise Groud,

Thanks for your suggestions, this method worked in this scenario. Thanks!!

[Michael Woods]

Hi,

What version are you running?   I just ran a test on 12.1.01.01 and it seems to have behaved as expected.  

One thing I verified after force starting Job_B was making sure the next start time was correct.  Once Job_A ran, Job_B waited until it's start and ran correctly and it's next start was also correctly generated.  

Regards,

Mike

[Arihara Subramanian]

Hi Michael,

Our environment is 12.0 01.03. Issuing force start to scheduled time worked in this scenario.

[Aman Gupta]

Hello Ari,

Change Status of both jobs to INACTIVE before Job A's Schedule time i.e. 3:00 and then monitor. It will resolve your issue. There is some inconsistency in job B's schedule. Changing both job status to Inactive will resolve.

Thanks,

Aman G.

[Arihara Subramanian]

Hello Aman,

Thanks for your suggestion, issuing force start to scheduled time is worked in this scenario. I have noted this solution and will try this also. Thanks!