History
- CA Workload Automation AE (Autosys Edition) was formerly known as Unicenter Autosys Job Management.
- Autosys was first developed by William Arntz in early 90s and marketed it by creating his own firm called AutoSystems Corp.
- It later got acquired by Platinum Technology Inc. in 1995 before finally being bought by CA Technologies in 1999.
- First version was released in 1992.
- Current version (11.3) was released in 2010.
- Only minor versions have been released in last 5 years, with current one being 11.3.5.
Introduction
- Autosys Workload Automation tool is supplied by CA Technologies and the current version is r11.3
- Autosys is an automated job control system for scheduling, monitoring, and reporting.
- The Autosys r11 architecture is a 3-tier architecture consisting of Client utilities, Application Server(s) and/or Scheduler Server(s) and Database(s)
- Autosys jobs resides only on Autosys configured server
- An Autosys job is any single command, executable, script, or Windows batch file.
- There are 3 types of jobs: Command, Box and File Watcher.
Basic Terms
- Job States and Status: AC – ACTIVATED, FA – FAILURE, IN – INACTIVE, OH – ON_HOLD, OI – ON_ICE, QU – QUE_WAIT, RE – RESTART, RU – RUNNING, ST – STARTING, SU – SUCCESS
TE – TERMINATED - Autosys determines when to start a job based on the conditions (Parameters/arguments) defined while creating the job. The conditions can be any or either of the below: Date, Day, Time, Success of another job, Box job, etc.
- Insert_job: Name of the job that gets inserted into Autosys Database (command or box).
- box_name: Box job name (can contain many box jobs or command jobs).
- commands: This can be a command or an executable script
- machine: Server, where the job needs to run
- owner: Owner of the job(Application ID)
- date_conditions: 1(yes)
- days_of_week: Days of the week the jobs needs to run.
- start_time: Time at which the job should start
- run_window: Window when the job should run continuously (helpful for file watchers).
- Conditions: Any dependencies, pre-conditions etc.
- description: useful for documentation/purpose of job
- n_retrys: no of retrys on a failure.
- term_run_job: the job will terminate if it runs for specified time.
- std_out_file: Log file for the job
- std_err_file: Error file for the job
- min_run_alarm: if the job terminates/completes with in the timeframe it will generate an alarm
- max_run_alarm: if the job runs for more than the specified time, it will generate an alarm
- alarm_if_fail: generates an alarm if the job fails
- profile: the file where you can keep all your variables (variable names)
Basic Commands
- autorep -J
- autorep -J –q
- sendevent –E STARTJOB -J
- -E has these arguments (STARTJOB, KILLJOB, FORCE_STARTJOB, JOB_ON_ICE, JOB_ON_HOLD, CHANGE_STATUS)
- Jobs can be created and jilled in 2 ways:
- GUI(outside the scope of this presentation) and
- Command line.
- Inserting a job into the JIL database using JIL command:
- jil < .jil
Architecture
- Step 1: The Event Processor scans the Event Server for the next event to process. If no event is ready, the Event Processor will again scan in 5 seconds.
- Step 2: The Event Processor reads the next event that is ready from the Event Server. The job definition and attributes are retrieved from the Event Server, including the command and the pointer to the profile file to be used for the job
- Step 3: The Event Processor processes the event and attempts to establish a connection with the Remote Agent on the client machine. It passes the job attributes to the client machine. The Event Processor sends a CHANGE_STATUS event marking in the Event Server stating that the job is in STARTING state
- Step 4: The Remote Agent is invoked using the User ID and Password passed from the Event Processor.
- Step 5: The Remote Agent receives the job parameters and sends an acknowledgement to the Event Processor
- Step 6: The Remote Agent Starts a process and executes the command in the job definition.
- Step 7: The Remote Agent issues a CHANGE_STATUS event marking to the Event Server stating that the job is in RUNNING state
- Step 8: The client job process runs to completion and then returns an exit code to the Remote Agent before quitting.
- Step 9: The Remote Agent sends the Event Server a CHANGE_STATUS event corresponding to the completion(Successful/Failure) status of the job.
Need’s and Uses
- To schedule daily, nightly, weekly jobs.
- Schedule data load jobs.
- To have better control of running the scripts and scheduling tasks. Managing and monitoring of tasks.
- Remove the human entity and automate tasks to make them more efficient.
- Nice way to monitor when and how the jobs ran.
- Provides better management of profiles for running redundant tasks.
- Helps distribute the control of execution and help maintain the tasks from a central place.
Sample JIL file:
insert_job: sample_box.TestBoxJob job_type: BOX
owner: testID
permission: gx
date_conditions: 0
description: "sample test box job"
alarm_if_fail: 1
application: Testing Application
insert_job: sample_cmd.TestCmdJob job_type: CMD
box_name: sample_box.TestBoxJob
command: ps -ef|grep -i testID
machine: testMachineIP
owner: testID
permission: gx
date_conditions: 0
description: "Sample command Job"
std_out_file: /tmp/log/$AUTO_JOB_NAME.out
std_err_file: /tmp/log/$AUTO_JOB_NAME.err
alarm_if_fail: 1
application: Testing Application
References used:
- http://autosys-tutorials.blogspot.com/
- http://www.ca.com/us/opscenter/ca-workload-automation-ae.aspx
- http://en.wikipedia.org/wiki/CA_Workload_Automation_AE
- Go to your Unix servers and try to create a sample Autosys job and play with it. Feel free to reach out to me with any questions you may have.
TechLearner 