AutoSys Workload Automation

How to stop a run cycle of box if it failed?

If I have a box which runs every 10 minutes from 9am to 5pm. I want that if it fails any time, next run should not be start.

Like

9am run = successful

9:10am run = failed

9:20am run : should not start at all

How to set up it?

autosy? use a global variable,

Steve C.

Stirling Systems Group

Hi Steve,

I never worked on Global variables, not sure how to use it.

Hi,

You can also try adding a starting condition such as  "condition: s(your box job)".

This way,  the box will not start for the next start time if the box is not in SUCCESS status.

To start the box again, you need to change its status to SUCCESS.

Thanks,

Jack

This is  a highly dangerous strategy. if you delete and reinsert the

box. who will remember to set it to s() ?

Steve C.

Stirling Systems Group

When insert the box, the status attribute can be used to set the initial status of the box.  There is no need to change its status.

status: initial_status

initial_status

Sets an initial status for a job during insertion. The valid values are FAILURE, INACTIVE, ON_HOLD, ON_ICE, ON_NOEXEC, SUCCESS, or TERMINATED.
Default: INACTIVE

Hi Jack,

My box runs every 10 mins from 9am to 5pm.

Suppose job is failed then box will also in failed state. Now on next day, what would be the status of box?

Example : job failed at 09:30am run, so box will be be in failed state. Now in next run at 09:40am, it willwait for condition s(boxname), so what would be the status of box here?

Hi Ashish,

When the box fails, it will not stay in FAILURE and will not run again until you change its status to SUCCESS.

The box will be in FAILURE status at 09:40 AM unless you make change to its status to SUCCESS.  You can use the sendevent to change its status.

Here is an example box that will run every 5 minutes from 9:00AM to 5 PM every day:

insert_job: jbox001   job_type: BOX
date_conditions: 1
days_of_week: all
start_mins: 0, 5,10,15,20,25,30,35,40,45,50,55
run_window: "9:00-17:00"
condition: s(jbox001)
alarm_if_fail: 1

Regards,

Jack

The status attribute is introduced in CA WAAE 11.3.6 SP1.

The following note is from CA Workload Automation AE Release Notes 11.3.6 SP1:

New status Attribute

The status attribute sets an initial status for a job during insertion. This can prevent jobs from running during the insertion process.

Jack

Here is another option if we are talking about Autosys. I often use a dummyjob at the very end of the box waiting for all successes or fails needed for the box to reschedule.

This keeps the box from ending if I don't want it to, leaving me time to correct the flow that needs attension.

When corrected the failing job is rerun or set to success or what ever suits my needs and the box can rerun at its next iteration.

You can also use resources to prevent jobs from running.

Good luck!

Hi Lars,

Can you please guide me to setup the dummy job?

Currently, I have only one job in my box.

/* ----------------- MY_BOX_BOXHOLD ----------------- */

insert_job: MY_BOX_BOXHOLD   job_type: CMD
box_name: MY_BOX
command: C\:\BOXHOLD.BAT
machine: my_machine
owner: owner@my_machine
permission:
date_conditions: 0
condition: s(MY_IMPORTANT_JOB_THAT_NEVER_FAILS)
alarm_if_fail: 1

BOXHOLD.BAT contains nothing but and exit but waits for the success of the very important job MY_IMPORTANT_JOB_THAT_NEVER_FAILS.
Make sure the box waits (box_success) for the completion of the job MY_BOX_BOXHOLD.
Good luck!

Hello Ashish,

Solution using Global variable

insert_job: a  job_type: BOX
days_of_week: xxxx
start_times: "xxxx"
condition: v(TEST)=ON
alarm_if_fail: 1

insert_job: a1  job_type: CMD
box_name: a
command: xxxx
machine: xxxx

insert_job: test_a_variable   job_type: CMD
command: sendevent -E SET_GLOBAL -G "TEST=OFF"
machine: xxxx
condition: f(a)

now when you set the variable value back ON manually then on the box will start to run again.
can you please check if this works for you.

Hi Ashish - you can also define a dummy sleep (sleep 5 etc) job as the last job in your box that would wait for failures, which all can result in a failed box status.

In ESP we would make job-0900 as a predecessor to job-0910 in addition to any time dependencies , etc.

If job-0910 fails, job-0920 does not start.

When job-910 is ran to a successful completion, it releases job-0920.

Whether job-0920 runs immediately depends on the time job-0910 ended.

If prior to 0920, job-0920 waits.

If after 0920, job-0920 runs immediately.

This could also effect other down stream time connections.

HTH...good luck,

     .....don t./wag.....

Hello,

the reply by Swetha_sched is the most valid and easiest: declare a dummy job at the end of your flow with the 'main' job as predecessor.
Once your 'main' job fails the box will remain in failure and will not get rescheduled till you solve your failure.
Good luck.

main job? you mean its own box?> i don't think so. the fact that the box

goes to FA. means the whole process failed. typically the last job.

so adding a job at the end is A way yes. the best way. that's a matter

of opinion.

Steve C.

Stirling Systems Group

indeed. A matter of opinion. I’ve added my opinion starting from a practical experience.
We doing it here like described. A lot of cyclic boxes previously had one job. When it failed it was no issue in the previous scheduler.
When we migrated to AUTOSYS it became one. Adding an extra dummy job solved the issue.

And the 'main' job is THE job itself. Not the box.
So the content of the BOX should look like this:
MAIN JOB => DUMMY where DUMMY is a SUCCESSOR job of MAIN JOB.

Whenever MAIN JOB fails the DUMMY will remain waiting till its predecessor gets solved. And the cycle remains stopped.

Good luck.

You did notice I described a dummy waiting for a success, and Swetha_sched described a dummy waiting for failure?

Not that my solution is better than the rest but it seems as if you describe my solution when waiting for a success.

I had also to build this when migrating to Autosys ...

Hello Lars,

apologies. Correct. The DUMMY needs to wait a successful MAIN.
Otherwise makes no sense.

Good day.

It seems like my point isn't conveyed clearly with the earlier post.

What I meant there is to wait for all the job failures that can result in a box failure (if it has parallel processes).

And, so obviously the dummy sleep job will have to wait for success of those end points, otherwise, I don't see a point of having it anyways.

This was always a pseudo issue which i solved by creating ContProgRun.prl

it does the cyclic run of a job and when failed stops.

Steve C.

Stirling Systems Group