autosys look back

5
Currently, using version AutoSys 4.5 - should be upgrading to r11 soon. I'm a basic user of AutoSys and would like to have some clarification around some scenario's. 1) If Box A is dependent on Box B and both boxes are on different AutoSys instances, what's the best approach to enable this dependency? - in the past I've used "^". Are there any downsides to this approach? - Any performance issues? I've been led to believe using the "^" this may cause a performance issue. 2) Box A is dependent on the SUCCESS of Box B and Box C. Both Boxes A, B and C run on a daily basis, which by definition Box B and Box C runs to SUCCESS then Box A runs to SUCCESS. - If Box B runs to SUCCESS on Monday, but Box C is still running or fails in effect Box A does not start meet it's starting conditions, so does not start on Monday. On Tuesday, Box C completes, Box B is still in a SUCCESS state from the Monday run, Box A is still in a Waiting (or equivalent) state from Monday. Does this mean Box A will start immediately after the SUCCESS of Box C, using the previous day SUCCESS of Box B and Tuesday SUCCESS of Box C? - What scenario's would mean Box A would run on a previous day SUCCESS of any of these jobs? - What would be the best approach to avoid the previous day SUCCESS of a Job? - Do we need some daily reset job - is this advised? - If using a reset job, how would this work - would there be any disadvantages of this approach? Thanks Ok, just my two cents: 1) I'm not even aware of the fact that you can make dependecies cross instance (why should you use different instranced otherwise??). 2)

Upload: zipzapdhoom

Post on 07-Dec-2015

859 views

Category:

Documents


11 download

DESCRIPTION

loop back working

TRANSCRIPT

Page 1: Autosys Look Back

Currently, using version AutoSys 4.5 - should be upgrading to r11 soon.

I'm a basic user of AutoSys and would like to have some clarification around some scenario's.

1) If Box A is dependent on Box B and both boxes are on different AutoSys instances, what's the best approach to enable this dependency?- in the past I've used "^". Are there any downsides to this approach? - Any performance issues? I've been led to believe using the "^" this may cause a performance issue.

2) Box A is dependent on the SUCCESS of Box B and Box C. Both Boxes A, B and C run on a daily basis, which by definition Box B and Box C runs to SUCCESS then Box A runs to SUCCESS. - If Box B runs to SUCCESS on Monday, but Box C is still running or fails in effect Box A does not start meet it's starting conditions, so does not start on Monday. On Tuesday, Box C completes, Box B is still in a SUCCESS state from the Monday run, Box A is still in a Waiting (or equivalent) state from Monday. Does this mean Box A will start immediately after the SUCCESS of Box C, using the previous day SUCCESS of Box B and Tuesday SUCCESS of Box C?- What scenario's would mean Box A would run on a previous day SUCCESS of any of these jobs? - What would be the best approach to avoid the previous day SUCCESS of a Job? - Do we need some daily reset job - is this advised? - If using a reset job, how would this work - would there be any disadvantages of this approach?

Thanks

Ok, just my two cents:

1) I'm not even aware of the fact that you can make dependecies cross instance (why should you use different instranced otherwise??).

2) - Yes, Box A would start immediately.- Autosys 4.5.1 doesn't look at days. Unlike CA Unicenter NSM, Autosys 4.5.1 doesn't work with a Job tracking file (whioch is submitted at x time). There you could have dependecies that looks a day back (e.g. PREVIOUS/CURRENT).- Run a Job at x time (night?) that will change the Job status to SUCCESS (SENDEVENT command)- This is up to you. Does the programm or script you're running require that it comes to a success? If it doesn't you can do the reset, if not, you should make sure you fix the problem before running the reset command (SENDEVENT command)- No disadvantege as for Autosys. Like I said before, the program or script you're running is leading.

We have an Autosys job (let's call it job_a) that has a 3am time dependency and is also supposed to await successful completion of a mainframe job (job_m, which in

Page 2: Autosys Look Back

our case is always successful). Job_m is run via the OPC scheduler on the mainframe, which communicates job completion to Autosys. It can run any time between 2am and 6am.

My understanding of how Autosys works is that it writes an entry into a table in its database when job_m completes, and when job_a checks its dependencies, it looks in this table to see the status of job_m. This status is not automatically cleared. As a result, the job dependency will always be met after the first ever successful run of job_m, even though we are only interested in job_m runs on the same day.

Day 1 4am: job_m completesDay 1 4:01am: job_a runs, since Day 1 4am run of job_m was successfulDay 2 3am: job_a runs, since Day 1 4am run of job_m was successfulDay 2 5am: job_m completes

Our current proposed workaround is to have a job (job_c) that periodically checks the table and only complete if the status of job_m was changed in the last 6 hours.

Day 1 3am: job_c starts, sees no status change for job_m within the last 6 hoursDay 1 4am: job_m completesDay 1 4:01am: job_c completesDay 1 4:02am: job_a runs following completion of job_cDay 2 3am: job_c starts, sees no status change for job_m within the last 6 hoursDay 2 5am: job_m completesDay 2 5:01am: job_c completesDay 2 5:02am: job_a runs following completion of job_c

Is there an Autosys command that can be used to reset the status of job_m in the table? If not, is there a better method of enforcing this dependency than the one outlined above?

scheduling autosys

share improve this question edited Dec 2 '09 at 4:14

asked Nov 23 '09 at 2:00

lins3141592,217919

add a comment

1 Answer

active oldest votes up vote 2 down vote

The solution depends on the version of Autosys you are using. If it is R11, the newest version, you can set look back dependencies on job_a to only run if job_c has ran to S within X hours.

Page 3: Autosys Look Back

In earlier versions you can run a job on the S of job_a that will change the status of job_c to INACTIVE. If job_c is inactive, job_a sees that starting condition as FALSE, but job_c will run the next time its starting conditions are met.

The command is sendevent -E CHANGE_STATUS -s INACTIVE -J job_c. This command has to be ran as the Autosys superuser account. Your Autosys Admins may not allow this. Also best practice is to run sendevent commands on the Autosys Event processor server so that if you are running dual server high availability and the system rolls over to single server mode, the sendevent command works after the roll over.

Example

insert_job: job_a job_type: ccommand: do_somethingmachine: machine1owner: my_id@machine1conditions: s(job_c)date_condition: 1start_time: 03:00

insert_job: job_c job_type: ccommand: do_something_elsemachine: machine1owner: mainframe@machine1comment: "This is the mainframe job"

insert_job: job_d job_type: ccommand: sendevent -E CHANGE_STATUS -s INACTIVE -J job_cowner: superuser@autosys_servermachine: autosys_serverconditions: s(job_a) and s(job_c)

Problem:

I got 4 jobs: 1, 2, 3, 4.

2’s condition: s(1); 3’s condition: s(2); 4’s condition: s(1) & s(2) & s(3)

all these jobs are daily jobs

the first day is ok. the second day, the 4th job triggered mutilple times:

I think when 1 success, because the status of 2 and 3 are still ‘success'(the last days status), so the job 4 triggered,

then 2 success, 4 triggered again…

but I only want these jobs run in the same period.

Page 4: Autosys Look Back

Solution:

1. the first solution I can found is using ‘Look-Back Dependencies’:

Example: Define Starting Conditions Based on Job Success in a Given DurationThis example (specified in the job definition for JobA) runs JobA if JobB has completed successfully in the last 12 hours:condition: success(JobB,12)Example: Define Starting Conditions Based on the Status of Multiple Jobs in a Given DurationThis example (specified in the job definition of JobA) runs JobA if JobB has failed in the last 30 minutes and JobC has completed successfully on external instance XYZ in the last 90 minutes:condition: failure(JobA,00.30) AND success(JobC^XYZ,01.30)

This should can work, but I based on my test, seems still cannot fix my issue.

http://stackoverflow.com/questions/10825544/autosys-r11-job-dependency-with-dependent-job-run-time-condition

2.  Using Box.

Put all these jobs in one Box, and when the Box is triggered, all the jobs’s status  in this box will be reset.