AutoSys Workload Automation

Can someone explain the new feature of ON_NO_EXECUTION.

Based on the pdfs, I am finding it is just executing or mimicking ON_ICE, where job will be skipped and trigger the dependent job.

The job ON_ICE does NOT run.

NO_EXEC the job runs to success in a bypass mode similar to /bin/true. or just a plane change status to success.

The job will look as if it ran but the actual command was NOT run.

It means that ON_NO_EXECUTION is like ON_ICE as ON_ICE also won’t run the job/command in actual and skip the job run for that day.

Ok. Not its slightly more than that. When you put a job ON_ICE it will immediately trigger downstream jobs. ON_NO_EXEC will not do that. You are right in the sense that it “Skips” the job, but that is where the similarity ends. It Bypasses the job when the date/time conditions are met and then handles a SUCCESS status to its downstream job.

Sunish: Wrong,  with ON_ICE the job DOESNT RUN. times jobs dont trigger while on ice etc.

NO_EXEC the job actually runs and the runtime changes.  timed jobs will actually run if they are on no exec

My advice to you is to test it.

Thank you

To my understanding, the explanations offered by Steve & DK are the right thing, if I can paraphrase:

- with NO_EXEC the job will look as if it ran but the actual command was NOT run, It bypasses the job when the date/time conditions are met and then handles a SUCCESS status to its downstream job.

- when you put a job ON_ICE it will immediately trigger downstream jobs, The job ON_ICE does NOT run.

Notice that in both cases, the jobs with NO_EXEC & ON_ICE status do not actually execute the command scripts and that [all conditions met] they allow the downstream jobs to run.

Chris

Is there a way by which I can test “ON_NO_EXECUTION”

I tried in my lab and I was unable to find out the difference and flow executions looks like ON_ICE.

Create a job that runs everyday at 13:00

Job2 runs after job 1 succeeds (condition: s(job1)

At 11am, set Job1 to ON_ICE. See what happens

Reset the job statuses and then set Job 1 to ON_NO_EXEC. See what happens.

I created the below jobs and ran them with ON_ICE and ON_NO_EXECUTION action.

Only change I noticed in Job states which is NE for NO EXCEUTION and OI for ON_ICE.

Dependent jobs ran as per their dependency even after NO EXECUTION and ON_ICE.

/*

OK. I think you should open a sev 4 ticket for usage questions.

sunish,

jobs on ICE do not RUN. unless you forcestarted them .. Jobe on NO EXEC even if you forcestart. will be in BYPASS mode and NOT run but just appea to have gone to success.

as was discuss, it appears you need some more assistance. either by CA or through some mentoring by a consultant etc.

Good Luck

Steve C.

Some new changes in 11.3.6 SP2 regarding ON_NOEXEC Feature

Changes to Existing Features

Updates to the ON_NOEXEC Feature

In the current release, the following changes are made for the ON_NOEXEC feature:

• JOB_ON_NOEXEC event The scheduler processes the JOB_ON_NOEXEC event similar to that of the CHANGE_STATUS event to INACTIVE. 

  For example, if you send the JOB_ON_NOEXEC event to a job in a box, the effect is the same as sending the CHANGE_STATUS event to INACTIVE for a job in a box. The job enters the ON_NOEXEC status and the scheduler evaluates the overall box status as if the job entered the INACTIVE status.

  To take the job off the ON_NOEXEC status, you must send the JOB_OFF_NOEXEC event. Sending manual CHANGE_STATUS event does not change the status of the job. To complete the NOEXEC job immediately so that the scheduler evaluates the job as if the job entered the SUCCESS status, send the FORCE_STARTJOB event.

• JOB_OFF_NOEXEC event When the scheduler processes the JOB_OFF_NOEXEC event for a job, it places the job in the INACTIVE status. If the job is in a box, the scheduler evaluates the overall box status as the job is entering the INACTIVE status. If you send the JOB_OFF_NOEXEC event to a box, all jobs in the box (including all jobs contained in lower level boxes within the box) are reset to the INACTIVE status.
• Evaluation of downstream dependent jobs When you send the JOB_ON_NOEXEC event to a job, the effect is the same as if the job enters the INACTIVE status. The scheduler does not immediately schedule jobs that have a dependency on the NOEXEC job nor does it evaluate their success conditions to success. 

  When the job's starting conditions are met and the scheduler sends the BYPASS event, the effect is the same as if the job enters the SUCCESS status with an exit code of 0. The scheduler schedules jobs that have a dependency on the NOEXEC job and evaluates their success conditions to success.