tag:blogger.com,1999:blog-11936582403483773662024-03-13T20:03:11.180-07:00AUTOSYS TUTORIALSBest online resource on Autosys TutorialsUnknownnoreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1193658240348377366.post-42020920583847782602011-04-17T08:47:00.001-07:002016-01-23T18:40:35.363-08:00Autosys Introduction<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- 468 Text -->
<ins class="adsbygoogle"
style="display:inline-block;width:468px;height:60px"
data-ad-client="ca-pub-8413193364348443"
data-ad-slot="2791823691"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
<div dir="ltr" style="text-align: left;" trbidi="on">
<u><span style="font-weight: bold;">What is Autosys?</span></u><br />
• An automated <!-- google_ad_section_start (weight=ignore)--><!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --><!-- google_ad_section_end --> control system for scheduling,monitoring and reporting <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s<br />
• The <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s can reside on an Autosys configured machine attached to a network<br />
<br />
<u><span style="font-weight: bold;">What is an Autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->?</span></u><br />
• A single action performed on a validated machine<br />
• Autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s can be defined using GUI or JIL<br />
• Any single command,executable script or NT batch file.It includes a set of qualifying attributes ,conditions specifying when and where a autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> should be run.<br />
<br />
Autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s can be defined by assigning it a name and specifying attributes describing its behavior.<br />
<br />
Two methods to define Autosys <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s are:-<br />
<u>1. Using Autosys GUI</u><br />
• Autosys GUI allows to set the attributes that describe when,where and how a autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> should be run.<br />
• GUI Control Panel is used to define autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end -->s Contain fields that correspond to Autosys JIL sub-commands and attributes.<br />
<br />
<u>2. Using <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> Information Language(JIL)</u><br />
• A specification language that has its own commands to describe when,where and how a autosys-<!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> should be run.<br />
• The attributes are set b JIL sub-commands</div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-13639969521301069562011-04-17T08:45:00.001-07:002016-01-15T05:11:30.753-08:00Autosys Quick Reference<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Horizontal Text 468*80 -->
<ins class="adsbygoogle"
style="display:inline-block;width:468px;height:60px"
data-ad-client="ca-pub-8413193364348443"
data-ad-slot="7734360892"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-weight: bold;">Introduction to Autosys:</span><br />
AutoSys is an automated <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> control system for scheduling, monitoring, and reporting. These <!-- google_ad_section_start (weight=ignore)-->jobs<!-- google_ad_section_end --> can reside on any AutoSys-configured machine that is attached to a network. An AutoSys <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> is any single command, executable, script, or Windows batch file. Each AutoSys <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> definition contains a variety of qualifying attributes, including the conditions specifying when and where a <!-- google_ad_section_start (weight=ignore)-->job<!-- google_ad_section_end --> should be run.<br />
<br />
<!-- google_ad_section_start (weight=ignore)-->
<span style="font-weight: bold;">Defining Jobs :</span><br />
There are the two methods you can use to create job definitions:<br />
¦ Using the AutoSys Graphical User Interface (GUI).<br />
¦ Using the AutoSys Job Information Language (JIL) through a command-line interface.<br />
<br />
<span style="font-weight: bold;">Autosys Jobs:</span><br />
Job Types and Structure :<br />
<br />
There are three types of jobs: command, file watcher, and box.<br />
As their names imply, command jobs execute commands, box jobs are containers that hold other jobs (including other boxes), and file watcher jobs watch for the arrival of a specified file.<br />
In the AutoSys environment, the box job (or box) is a container of other jobs. A box job can be used to organize and control process flow. The box itself performs no actions, although it can trigger other jobs to run. An important feature of this type of job is that boxes can be put inside of other boxes.<br />
<br />
<span style="font-weight: bold;">Default Box Job Behavior:</span><br />
<br />
Some important rules to remember about boxes are:<br />
<br />
Jobs run only once per box execution.<br />
Jobs in a box will start only if the box itself is running.<br />
As long as any job in a box is running, the box remains in RUNNING state; the box cannot complete until all jobs have run.<br />
By default, a box will return a status of SUCCESS only when all the jobs in the box have run and the status of all the jobs is "success.<br />
By default, a box will return a status of FAILURE only when all jobs in the box have run and the status of one or more of the jobs is "failure."<br />
Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE.<br />
Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE.<br />
<br />
<br />
<span style="font-weight: bold;">Job States and Status :</span><br />
AutoSys keeps track of the current state, or status, of every job. The value of a job’s status is used to determine when to start other jobs that are dependent on the job. The job status is displayed in the job report generated by the autorep command, and in the job report you can view in the Job Activity Console<br />
<br />
Following are the status of Autosys jobs:<br />
<br />
INACTIVE : The job has not yet been processed. Either the job has never been run, or its status was intentionally altered to “turn off” its previous completion status.<br />
ACTIVATED :The top-level box that this job is in is now in the RUNNING state, but the job itself has not started yet.<br />
STARTING : The event processor has initiated the start job procedure with the Remote Agent.<br />
RUNNING : The job is running. If the job is a box job, this value simply means that the jobs within the box may be started (other conditions permitting). If it is a command or file watcher job, the value means that the process is actually running on the remote machine.<br />
SUCCESS : The job exited with an exit code equal to or less than the “maximum exit code for success.” By default, only the exit code “0” is interpreted as “success.” If the job is a box job, this value means that all the jobs within the box have finished with the status SUCCESS (the default), or the “Exit Condition for Box Success” evaluated to true<br />
FAILURE : The job exited with an exit code greater than the “maximum exit code for success.” By default, any number greater than zero is interpreted as “failure.” AutoSys issues an alarm if a job fails<br />
TERMINATED : The job terminated while in the RUNNING state. A job can be terminated if a user sends a KILLJOB event or if it was defined to terminate if the box it is in failed. If the job itself fails, it has a FAILURE status, not a TERMINATED status. A job may also be terminated if it has exceeded the maximum run time (term_run_time attribute, if one was specified for the job), or if it was killed from the command line through a UNIX kill command. AutoSys issues an alarm if a job is terminated.<br />
RESTART : The job was unable to start due to hardware or application problems, and has been scheduled to restart.<br />
QUE_WAIT : The job can logically run (that is, all the starting conditions have been met), but there are not enough machine resources available.<br />
ON_HOLD : This job is on hold and will not be run until it receives the JOB_OFF_HOLD event.<br />
ON_ICE : This job is removed from all conditions and logic, but is still defined to AutoSys. Operationally, this condition is like deactivating the job. It will remain on ice until it receives the JOB_OFF_ICE event. <br />
<br />
The difference between "on hold" and "on ice" is that when an "on hold" job is taken off hold, if its starting conditions are already satisfied, it will be scheduled to run, and it will run. On the other hand, if an "on ice" job is taken "off ice," it will not start, even if its starting conditions are already satisfied. This job will not run until its starting conditions reoccur.<br />
<br />
The other major distinction is that jobs downstream from the job that is "on ice" will run as though the job succeeded. Whereas, all dependent jobs do not run when a job is on "on hold"—nothing downstream from this job will run.<br />
<br />
<span style="font-weight: bold;">Starting Parameters :</span><br />
AutoSys determines whether to start or not to start a job based on the evaluation of the starting conditions (or starting parameters) defined for the job. These conditions can be one or more of the following:<br />
¦ Date and time scheduling parameters are met (it is or has passed the specified date and time).<br />
¦ Starting Conditions specified in the job definition evaluate to true.<br />
¦ For jobs in a box, the box must be in the RUNNING state.<br />
¦ The current status of the job is not ON_HOLD or ON_ICE.<br />
Every time an event changes any of the above conditions, AutoSys finds all the jobs that may be affected by this change, and determines whether or not to start them.<br />
<br />
sample jil code / Writing jil code:<br />
<br />
insert_job: template job_type: c<br />
box_name: box1<br />
command: ls -l<br />
machine: localhost<br />
owner: lyota01@TANT-A01<br />
permission: gx,ge,wx,we,mx,me<br />
date_conditions: 1<br />
days_of_week: all<br />
start_times: “15:00, 14:00″<br />
run_window: “14:00 - 6:00″<br />
condition: s (job1)<br />
description: “description field”<br />
n_retrys: 12<br />
term_run_time: 60<br />
box_terminator: 1<br />
job_terminator: 1<br />
std_out_file: /tmp/std_out<br />
std_err_file: /tmp/std_err<br />
min_run_alarm: 5<br />
max_run_alarm: 10<br />
alarm_if_fail: 1<br />
profile: /tmp/.profile<br />
<br />
<span style="font-weight: bold;">Explanation of each line:</span><br />
<br />
Insert_job: this will let the autosys server to recognize the job and inserts into autosys DataBase. Jobtype: there are two types of jobs namely box and child ( c=child, box)<br />
box_name: this is the box job name: box job can have more than 1 child jobs. (this is just like grouping the jobs).<br />
commands: this is where you tell autosys, what to do when the job runs. ( you’ll give reference to your scripts here).<br />
machine: name of the machine where you want to run the job.<br />
owner: owner of the job.<br />
permissions.<br />
date_conditions: 1 if you have any specifications.<br />
days_of_week: on which days of the week you want the job to run.<br />
start_time: the time at which the job should kick-off.<br />
run_window: this option is for monitoring jobs. the job will run continously for the specified time window.<br />
conditions: here you can specify the dependencies. like success of some other job.<br />
description.<br />
n_retrys: no of retrys on a failure.<br />
term_run_job: the job will terminate if it runs for specified time.<br />
box_terminator: if 1, terminates box job depends on term_run_time.<br />
job_terminator: if 1, terminates child job depends on term_run_time.<br />
std_out_file: standard output file (log) for the job<br />
std_err_file: Error log file if the job fails<br />
min_run_alarm: if the job terminates/completed with in that time it generate an alarm<br />
max_run_alarm: if the job runs for more than the specified time, it generate an alarm<br />
alarm_if_fail: generates an alarm if the job fails<br />
profile: the file where you can keep all your variables (variable names)<br />
<br />
We don’t use all the above options in all the jobs, it depends on the requirements.<br />
<br />
Here is a sample job which will verify a particular process is running or not.<br />
/* —————– SAP_UAT_MU03_C —————– */<br />
insert_job: SAP_UAT_MU03_C job_type: c<br />
command: /local/SAP/processCheckUAT.sh<br />
machine: MU03-UAT<br />
owner: admin@MU03-UAT<br />
permission: gx,wx,mx,me<br />
days_of_week: all<br />
start_times: “15:00, 14:00″<br />
description: “Job used for Run testing of process”<br />
alarm_if_fail: 1<br />
max_exit_success: 1<br />
<br />
<br />
<span style="font-weight: bold;">To Insert a new JIL code :</span><br />
issue command "jil"<br />
bash-3.00$ jiljil>>1><br />
"The following prompt will appear" copy paste the jil code u have made example of jil code below...........<br />
At the end the "C" or "B" determines if the job is box job or child job.<br />
if the jil is inserted properly successfull message will come if any errors are there the jil code contains some errors..<br />
if successfull exit;<br />
<br />
Using Autorep command:<br />
Function<br />
Reports information about a job, jobs within boxes, machines, and machine status. Also reports information about job overrides and global variables.<br />
Syntax<br />
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r run_num]<br />
<br />
autorep -J (job name here)<br />
<br />
This will display a list of jobs with complete details with box/jobname, last/latest run date & time, status, exit code, etc.<br />
Viewing JIL code for any Autosys job<br />
<br />
autorep -J (job name here) -q<br />
<br />
To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run command:<br />
<br />
<br />
To obtain the information of previous runs<br />
<br />
autorep -J (job name here) -r (No of runs back) example : autorep -J (job name here) -r 1<br />
<br />
would generate a report for the job run one runs back<br />
<br />
Status Abbreviations<br />
The following table lists the abbreviations used in the ST (status) column of the autorep report, and gives the status for each abbreviation.<br />
<br />
AC - ACTIVATED<br />
FA - FAILURE<br />
IN - INACTIVE<br />
OH - ON_HOLD<br />
OI - ON_ICE<br />
QU - QUE_WAIT<br />
RE - RESTART<br />
RU - RUNNING<br />
ST - STARTING<br />
SU - SUCCESS<br />
TE - TERMINATED<br />
<br />
sendevent:<br />
sendevents to AutoSys for a variety of purposes, including starting or stopping AutoSys jobs, stopping the Event processor, and putting a job on hold. This command is also used to set AutoSys global variables or cancel a scheduled event.<br />
<br />
sendevent is normally used with "-E" & -J option<br />
<br />
-J job_name : Specifies the name of the job to which the specified event should be sent. This option is required for all events except STOP_DEMON, COMMENT, ALARM, or SET_GLOBAL<br />
<br />
-E event :Specifies the event to be sent. This option is required. Any one of the following events may be specified:<br />
<br />
STARTJOB<br />
KILLJOB<br />
DELETEJOB<br />
FORCE_STARTJOB<br />
JOB_ON_ICE<br />
JOB_OFF_ICE<br />
JOB_ON_HOLD<br />
JOB_OFF_HOLD<br />
CHANGE_STATUS<br />
STOP_DEMON<br />
CHANGE_PRIORITY<br />
COMMENT<br />
ALARM<br />
SET_GLOBAL<br />
SEND_SIGNAL<br />
<br />
Following are the example of sendevent command frequently used.<br />
<br />
To start or force start a job manually using sendevent :<br />
<br />
sendevent –E FORCE_STARTJOB -J "Job Name Here"<br />
<br />
sendevent -E STARTJOB -J "Job Name Here"<br />
<br />
To put jobs on OFF ICE or ON ICE :<br />
<br />
sendevent -E OFF_ICE -J "Job Name Here"<br />
<br />
sendevent -E ON_ICE -J "Job Name Here"<br />
<br />
autostatus: Reports the current status of a specific job, or the value of an AutoSys global variable. Ex: autostatus -J job_name, -S instance</div><!-- google_ad_section_end -->Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-73501742005849710562010-01-22T07:10:00.002-08:002010-01-22T08:07:01.094-08:00Autosys Work-Flow<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_FwFkbVFfnGQ/S1nAINSl37I/AAAAAAAAA3E/HiuW7gLyx8c/s1600-h/1.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 234px;" src="http://1.bp.blogspot.com/_FwFkbVFfnGQ/S1nAINSl37I/AAAAAAAAA3E/HiuW7gLyx8c/s400/1.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5429582073010970546" /></a><br /><br /><br /><br />• Step1: The Event Processor scans the Event Server for the next event to processor.If no event is ready,the Event Processor scans again in 5 seconds.<br /><br />• Step2: The Event Processor reads from the Event Server that an event is ready.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<br /><br />• Step3: The Event Processor processes the event.The Event Processor attempts to establish a connection with the Remote Agent on the client machine and passes the job attributes to the client machne.The Event Processor sends a CHANGE_STATUS event marking in the Event Server that the job is in STARTING state<br /><br />• Step4: The Remote Agent is invoked using the UserID and Password passed from the Event Processor.<br /><br />• Step5: The Remote Agent receives the job parameters and sends an acknowledgement to the Event Processor<br /><br />• Step6: The Remote Agent Starts a process and executes the command in the job definition.<br /><br />• Step7: The Remote Agent issues a CHANGE_STATUS event marking in the Event Server that the job is in RUNNING state<br /><br />• Step8: The client job process runs to completion,then returns an exit code to the Remote Agent and quits.<br /><br />• Step9: The Remote Agent sends the Event Server a CHANGE_STATUS event corresponding to the completion status of the job.The Remote Agent quitsUnknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-39291662102788723712010-01-22T07:10:00.001-08:002010-01-22T08:07:14.416-08:00Utilities• Autosys provides a set of commands that run essential utility programs for defining,controlling and reporting on jobs .<br /><br />• For example the autorep command allows generating a variety of reports about job execution,and the sendevent commands allow manually controlling job processing.<br /><br />• Additional utility programs are provided to assist in troubleshooting running monitors and browsers,and starting/stoping Autosys and its components.<br /><br />• Autosys also provides database maintenance utility that runs daily by defaultUnknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-85890329495191329932010-01-22T07:09:00.001-08:002010-01-22T08:07:30.611-08:00Alarms• Alarms are special events that send notifications during situations requiring attention<br /><br />• Addresses incidents that require manual intervention<br /><br />• For example,a set of jobs could be dependent on the arrival of a file and if the file is long overdue.It is important that someone investiage the situation,make a decision and resolve the problem.<br /><br />• Aspects of alarms include but is not limited to:-<br />o Alarms are informational only.Any action to be taken due to a problem is intiated by a separate action event.<br />o Alarms are system messages about a detected problem<br />o Alarms are sent through the system as an eventUnknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-82982405959648197902010-01-22T07:08:00.000-08:002010-01-22T08:07:45.320-08:00Events• Since Autosys in Event-driven,it requires an event to occur on which the job depends,for a job to be activated by the Event Processor.<br /><br /><br />• The sources of these events can be:-<br /><br />o Jobs changing status such as starting,finishing<br />o Internal Autosys verification Agents such as detected errors.<br />o Events send with the SENDEVENT command<br /><br /><br />• While processing an event,the Event processor scans the database for jobs that are dependent on that event<br /><br /><br />• If the event satisfies another job’s starting condition,that job is run automatically and completion of that job can cause another job to be started,thereby making the jobs progress in a controlled sequence.Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-16594053268054436392010-01-22T07:07:00.000-08:002010-01-22T08:07:57.122-08:00Autosys Machines V/s Autosys Instances<u><span style="font-weight:bold;">Autosys architecture has two types of machines:-</span></u><br /><br />• Server Machine:<br />o The machine on which the Event Processor and Event Server reside<br /><br />• Client Machine:<br />o The machine on which the Remote Agent resides and where Autosys jobs are run.<br /><br /><br /><u><span style="font-weight:bold;">What is an Autosys Instance?</span></u><br /><br />• A version of Autosys software running as an Autosys server,with one or more clients,on single machine or on multiple machines<br />• An instance uses its own Event Server and Event Processor by operating independently of all other Autosys instances<br />• Multiple instances can run and schedule jobs on the same machine without affecting other instances on that machine.Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1193658240348377366.post-90986745906798041632010-01-22T07:03:00.000-08:002010-01-22T08:08:08.768-08:00System ComponentsAutosys system components are:-<br />• Event Server<br />• Event Processor<br />• Remote Agent<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_FwFkbVFfnGQ/S1m-kQrzuaI/AAAAAAAAA28/Kh23CAMXTWc/s1600-h/1.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 170px;" src="http://4.bp.blogspot.com/_FwFkbVFfnGQ/S1m-kQrzuaI/AAAAAAAAA28/Kh23CAMXTWc/s400/1.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5429580355935123874" /></a><br /><br /><br /><u><span style="font-weight:bold;">• Event Server (or Autosys Database)</span></u><br />o Data Repository that stores Autosys system information,events and job definitions.<br />o The Autosys Db is termed ‘Data Server’ which describes a server instance<br /><br /><u><span style="font-weight:bold;">• Event Processor</span></u><br /><br />o Interprets and processes all the events it reads from the Autosys Database<br /><br />o A program that actually runs Autosys<br /><br />o Scans the database for processing events. Checks if the events satisfy the starting conditions of the job and the determines the actions<br /><br /><br /><u><span style="font-weight:bold;">• Remote Agent</span></u><br /><br />o Temporary process started by the event processor to perform a specific task on a remote machine<br /><br />o It starts the command specified for a given job, sends running and completion information about a task to the Event Server<br /><br />o If it is unable to transfer the information, it waits and tries until it successfully communicates with the Db<br /><br /><br /><u><span style="font-weight:bold;">Interaction Between System Components</span></u><br /><br />• Step1: From the Autosys event server(that holds the Events and Job Definitions info),the Event Processor reads the new event,checks for the condition,reads the job definition and determines the actions.<br /><br />• Step2: The Remote Agent receives the instructions from the Event Processor<br /><br />• Step3: The Remote Agent performs resource checks,ensuring minimum specified number of processors are available and then initiates a child process that runs the specified command<br /><br />• Step4: The command completes and exits,with the Remote Agent capturing the command’s exit code.<br /><br />• Step5: The Remote Agent directly communicates the event(exit code,status) to the Event Server.Unknownnoreply@blogger.com