A Quick Refrence Guide for Unix, Scripting

& Autosys
Monday, March 31, 2008
Autosys - Job Scheduling

Autosys Job Management for UNIX

This guide will be helpfull in giving basic idea about what autosys is, defining
jobs to AutoSys, monitoring and managing jobs.
Introduction to Autosys: AutoSys is an automated job control system for
scheduling, monitoring, and reporting. These jobs can reside on any AutoSysconfigured machine that is attached to a network.
An AutoSys job is any single command, executable, script, or Windows batch
file. Each AutoSys job definition contains a variety of qualifying attributes,
including the conditions specifying when and where a job should be run.
Defining Jobs :
There are the two methods you can use to create job definitions:
Using the AutoSys Graphical User Interface (GUI).
Using the AutoSys Job Information Language (JIL) through a command-line interface.
Autosys Jobs:

Job Types and Structure :

There are three types of jobs: command, file watcher, and box.
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.
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.

Default Box Job Behavior:

Some important rules to remember about boxes are
1. Jobs run only once per box execution.

2. Jobs in a box will start only if the box itself is running.

3. 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.
4. 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.
5. 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."
6. Unless otherwise specified, a box will run indefinitely until it reaches a status of
SUCCESS or FAILURE.
7. Changing the state of a box to INACTIVE (via the sendevent command) changes the
state of all the jobs in the box to INACTIVE.

Job States and Status :

AutoSys keeps track of the current state, or status, of every job. The value of a jobs
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

Following are the status of Autosys jobs:

1. 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
2. ACTIVATED :The top-level box that this job is in is now in the RUNNING state, but the
job itself has not started yet.
3. STARTING : The event processor has initiated the start job procedure with the Remote
Agent.
4. 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.
5. 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

6. 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
7. 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.
8. RESTART : The job was unable to start due to hardware or application problems, and has
been scheduled to restart.
9. QUE_WAIT : The job can logically run (that is, all the starting conditions have been
met), but there are not enough machine resources available.
10. ON_HOLD : This job is on hold and will not be run until it receives the
JOB_OFF_HOLD event.
11. 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.
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.
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.

Starting Parameters :
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:
Date and time scheduling parameters are met (it is or has passed the specified date and
time).
Starting Conditions specified in the job definition evaluate to true.
For jobs in a box, the box must be in the RUNNING state.
The current status of the job is not ON_HOLD or ON_ICE.
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.

sample jil code / Writing jil code:

jil = Job information language

When using JIL to create a job definition, you enter the jil command to display the JIL prompt.
Runs the Job Information Language (JIL) processor to add, update, and delete AutoSys jobs,
machines, monitors, and reports. Also used to insert one-time job override definitions.
------------------------------------------------------------------------------------------------/* ----------------- SAP_UAT_MU03_C ----------------- */
insert_job: SAP_UAT_MU03_C job_type: c
command: /local/SAP/processCheckUAT.sh
machine: MU03-UAT
owner: admin@MU03-UAT
permission: gx,wx,mx,me
days_of_week: all
start_times: "15:00, 14:00"
description: "Job used for Run testing of process"
alarm_if_fail: 1
max_exit_success: 1
------------------------------------------------------------------------------------------------The above example is a simple jil code of autosys which we have to write if we want any
particular job to be thru autosys.
To Insert a new JIL code :
issue command "jil"
bash-3.00$ jiljil>>1>
"The following prompt will appear" copy paste the jil code u have made example of jil code
below...........
At the end the "C" or "B" determines if the job is box job or child job.
if the jil is inserted properly successfull message will come if any errors are there the jil code
contains some errors..
if successfull exit;
2. Other way is to create a temp file named temp.jil which contains jil code on autosys server:
give command.
bash-3.00$ jil<>

Functional Listing of AutoSys Commands :

This section lists which AutoSys commands to use for specific tasks. All commands are for both
Windows and UNIX, unless otherwise specified.

Accessing Sybase : xql

Checking System Status : autoflags

autoping
autosyslog
chase chk_auto_up

Converting cron to JIL (UNIX Only) : cron2jil

Defining AutoSys Jobs or Machines : jil

Defining Calendars : autocal, autocal_asc

Reporting Job Status : autorep

autostatus

Starting AutoSys (UNIX Only) : eventor

Stopping AutoSys : sendevent

Using Autorep command:

Function
Reports information about a job, jobs within boxes, machines, and machine status. Also reports
information about job overrides and global variables.
Syntax
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r run_num]
autorep -J (job name here)
This will display a list of jobs with complete details with box/jobname, last/latest run date &
time, status, exit code, etc.
Viewing JIL code for any Autosys job
autorep -J (job name here) -q
To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run
command:
To obtain the information of previous runs

autorep -J (job name here) -r (No of runs back) example : autorep -J (job name here) -r 1
would generate a report for the job run one runs back
------------------------------------------------------------------------------------------------Status Abbreviations
The following table lists the abbreviations used in the ST (status) column of the autorep report,
and gives the status for each abbreviation.
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
------------------------------------------------------------------------------------------------sendevent:
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.
sendevent is normally used with "-E" & -J option
-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
-E event :Specifies the event to be sent. This option is required. Any one of the following events
may be specified:

STARTJOB

KILLJOB

DELETEJOB

FORCE_STARTJOB

JOB_ON_ICE

JOB_OFF_ICE

JOB_ON_HOLD

JOB_OFF_HOLD

CHANGE_STATUS

STOP_DEMON

CHANGE_PRIORITY

COMMENT

ALARM

SET_GLOBAL

SEND_SIGNAL

Following are the example of sendevent command frequently used.

____________________________________________________________________
To start or force start a job manually using sendevent :
sendevent E FORCE_STARTJOB -J "Job Name Here"
sendevent -E STARTJOB -J "Job Name Here"
To put jobs on OFF ICE or ON ICE :
sendevent -E OFF_ICE -J "Job Name Here"
sendevent -E ON_ICE -J "Job Name Here"
______________________________________________________________
autostatus: Reports the current status of a specific job, or the value of an AutoSys global
variable. Ex: autostatus -J job_name, -S instance
Posted by pmanish80 at 4:40 AM

Labels: Job Types and Structure

4 comments:
Dilpreet said...
Hi Manish,
Thanks for the article, its really helpful to get started.
I had a question. I want to setup a file watcher job which would run on machine A but
look for a file on a FTP machine F.
How can you set up the same provided the fact that you need to pass username and
password for F to the script to login?
Your help will be appreciated.
Thanks.
DS
October 2, 2009 at 11:04 AM
D said...
What's the best way to troublehsoot CHASE Server events?
December 8, 2009 at 12:55 PM
Jeril Nadar said...
Hi,
Is there something like local scope variable say at box level or job level?
March 6, 2014 at 10:23 PM
chakilamvenugopal said...
HI How to reschedule the jobs in Autosys . We are facing some issue in connecting to the
GUI ( we are using Humming bird exceed as GUI ) .
As some of jobs in our server going to expire End of this month . Thanks in advance.
December 16, 2014 at 2:00 AM
Post a Comment
Newer Post Older Post Home
Subscribe to: Post Comments (Atom)

About Me
pmanish80
This site will be helpful for Unix system administrator to automate their tasks using
scripts, comments on posts are welcome.
View my complete profile

Some useful links

http://perldoc.perl.org/5.8.8/

http://www.linuxhomenetworking.com

Blog Archive

2008 (5)
o April (3)
o March (2)

Autosys - Job Scheduling

Perl Regular Expressions

DATASTAGE TUTORIALS AND TRAINING

This blog aims at providing free tutorials, guides and other study materials for IBM WebSphere
DataStage.

Datastage (2)

Scheduling Tools (1)

UNIX Contents (1)

Showing posts with label Scheduling Tools. Show all posts

Thursday, 31 May 2012

Autosys Guide

1. Introduction to Autosys
AutoSys is an automated job control system for scheduling, monitoring, and
reporting. These jobs can be a UNIX script, java program or any other program
which can be invoked from shell.
An AutoSys job is any single command,
executable, script, or Unix batch file. Each AutoSys job definition contains a variety
of qualifying attributes, including the conditions specifying when and where a job
should be run.

1.1 AutoSys System components

Event server (AutoSys database)

Event processor

Remote agent

1.1.1 Event Server

The Event Server is a AutoSys database which stores all system

information and events as well as all job, monitor, and report definitions. Sometimes
this database is also called as a data server, which actually describes a server
instance. That is, it is either a UNIX or Windows process, and it is associated data
space (or raw disk storage), that can include multiple databases or table spaces

1.1.2 Event Processor

The Event Processor is main component of the autosys system. This
processes all the events it reads from data server. The event processor is the
program, running either as a UNIX process or as a Windows service that actually
runs AutoSys. It schedules and starts jobs. When you start the event processor it
continually scans the database for events to be processed. When it finds one, it
checks whether the event satisfies the starting conditions for any job in the

database.

1.1.3 Remote Agent

The Remote Agent is a temporary process started by the event processor to
perform a specific task on a remote (client) machine. The remote agent is a
Windows service running on a remote (client) machine that is directed by the event
processor
to
perform
specific
tasks.
The remote agent starts the command specified for a given job, sends running and
completion information about a task to the event server, then exits. If the remote
agent is unable to transfer the information, it waits and tries again until it can
successfully communicate with the database.

1.1.4 Basic functionality of AutoSys

Below is the diagram which explains the basic functionality, please check the
explanation.
Explanation for the Diagram
1.
The event processor scans the event server for the next event to process. If no
event is ready, the event processor scans again in five seconds.
2.
The event processor reads from the event server that an event is ready. If the
event is a STARTJOB event, the job definition and attributes are retrieved from the
Event Server, including the command and the pointer (full path name on the client
machine) to the profile file to be used for the job. In addition, for jobs running on
Windows machines, the event processor retrieves from the database the user IDs
and passwords required to run the job on the client machine.
3.
The event processor processes the event. If the event is a STARTJOB, the
event processor attempts to establish a connection with the remote agent on the
client machine, and passes the job attributes to the client machine.
The event processor sends a CHANGE_STATUS event marking in the event server
that the job is in STARTING state.
4.
On a UNIX machine, the inetd invokes the remote agent. On a Windows
machine, the remote agent logs onto the machine as the user defined as the jobs
owner, using the user IDs and passwords passed to it from the event processor.
5.
The remote agent sends an acknowledgment back to the event processor
indicating that it has received the job parameters. The socket connection is
terminated. At this point, the event processor resumes scanning the event server

database, looking for events to process.

6.
The remote agent starts a process and executes the command in the job
definition.
7.
The remote agent issues a CHANGE_STATUS event marking in the event server
that the job is in RUNNING state.
8.
The client job process runs to completion, then returns an exit code to the
remote agent and quits.

2. Defining Jobs
There are the three methods you can use to create job definitions:
1. By Autosys Web interface
2. By AutoSys Graphical User Interface (GUI).
3. By using AutoSys Job Information Language (JIL) through a command-line
interface.

2.1 AutoSys Graphical User Interface

Job definitions are created by using the GUI Control Panel. The fields in the
GUIs correspond to the AutoSys JIL sub-commands and attributes. In addition, from
the GUI Control Panel, you can open applications that allow you to define calendars,
monitors, and reports, and that allow you to monitor and manage AutoSys jobs.

2.2 Command Line - Job Information Language

JIL stands for Job Information Language is a scripting language which provides
a way to specify how AutoSys jobs should behave. These information saved in
autosys database. You can also create a jil file which contains job definition. You can
then pass this jil file to autosys. JIL scripts contain one or more JIL sub-commands
and one or more attribute statements
2.2.1 Essential attributes for creating a Job Definition
When using JIL to create a job definition, you enter the jil command to display
the jil prompt.

Job Name

Job Type

Owner

2.2.2 Defining Job Name Standards

1. The job name is used to identify the job to AutoSys

2. The name of a box or a job is limited it 30 characters in length and is
terminated with white space. Embedded blanks and tabs are illegal.
3. The first two characters must be the Airline code. The next three characters
identify the project code or module that the job references. The next three
characters identify the frequency of the job (day, wky, cal, orq). The next
character identifies the priority of the job (1, 2, or 9). The rest of the
characters can be used to give the job descriptive name.
4. Job types (command, box, file watcher) cannot use the same name.

2.2.3 JIL Sub Commands

When writing a JIL script, you must follow the syntax rules. JIL sub-commands are
used to create, modify, override, or delete a job definition. These sub-commands
are listed below:

insert_job

: Add a new job to AutoSys.

update_job : Edit fields on an existing job.

delete_job : Delete an existing job from the AutoSys database.

box_name : Add a new box job

delete_box : Delete an existing Box job, and also delete all the jobs which are
contained in the box.

override_job: Apply overrides on indicated job attributes for the next run. It
change the behavior of a job for the next time the job runs

2.2.4 Job Types

There are three types of jobs:

1. Command Job

- c (key words)

2. Box Job

- b (key words)

3. File Watcher Job - f (key words)

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.
2.2.4

Job Owner

The job owner specifies whose user ID the command will be run under on the
client machine.

Attribute: < owner : cs6_dev@syd0432 >

2.2.5 Submitting Job Definitions

A completed JIL script is called a job definition. This job definition must be
submitted to the AutoSys database before the job it defines can be run. You can
submit a job to the AutoSys database using one of the following methods:

jil < my_jil_script

2.2.6 Running JIL

After a job definition has been submitted to the AutoSys database, it will be started
according to the starting parameters specified in its JIL script.
The Event Processor will continually poll the database that the starting parameters
have been met, it will run the job.
If a JIL script does not specify any starting parameters, the job will not be started
automatically by the Event Processor.
It will start only if we issue the SENDEVENT command.

sendevent -E FORCE_STARTJOB -J <job_name>

(or)
fsj <job_name>

3 Basic Job Attribute

The primary differences between the job types are the actions that are taken when
the job is run.
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.

3.1 FileWatcher Job Attributes

A File Watcher Job is similar to a Command Job. When that file reaches a
certain minimum size, and is no longer growing in size, the File Watcher Job
completes successfully, indicating that the file has arrived.

The basic File Watcher Job definition has the following required attributes:

job_name and job_type must be f

watch_file The name of the file to watch, must include the full path to the file

 < watch_file: ${inb}/commcdata/<file_name>_${stream_name}.DLY

machine The name of the machine on which the command is to be run.
conditions The date/time and/or job status conditions necessary for the job to be
run.
watch_file_min_size determines when enough data has been written to the file
to consider it complete. This attribute is specified in bytes.
watch_interval specifies (in seconds) how often the File Watcher should check the
current file size. The default is every 60 seconds.

3.2 Box Jobs Attribute

The Box Job 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. When this is done, jobs related by like starting conditions (not
by similar application types) can be grouped and operated on in a logical way.

3.2.1 Default Box Job Behavior

Some important rules to remember about boxes are:
Box must have a starting conditions (either date/time conditions or job dependency

conditions).
Jobs run only once per box execution.
Jobs in a box will start only if the box itself is running
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.

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."

 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."

Changing the state of a box to INACTIVE (via the sendevent command) changes the

state of all the jobs in the box to INACTIVE.

sendevent -e CHANGE_STATUS -s INACTIVE -j <box_name>

3.2.2 When you Should Not Use a Box

Avoid the temptation to put jobs in a box as a short cut for performing events (such
as ON_ICE or ON_HOLD) on a large number of jobs at once.

3.3.3 What Happens when a Box Runs

As soon as a box starts running, all the jobs in the box (including sub-boxes) change
to status ACTIVATED, meaning they are eligible to run.
Then each job is analyzed for additional starting conditions. All jobs with no
additional starting conditions are started, without any implied ordering or
prioritizing.
Jobs with additional starting conditions remain in the ACTIVATED state until those
additional dependencies have been met. The box remains in the RUNNING state as
long as there are activated or running jobs in the box.
If a box is terminated before a job in it was able to start, the status of that job will
change directly from ACTIVATED to INACTIVE.

3.3.4 Time Conditions in a Box

Each job in a box will run only once per box execution. Therefore, you should
not define more than one time attribute for any job in a box because the job will
only run the first time.

 If you want to put a job in a box, but you also want it to run more than once, you
must assign multiple start time conditions to the box itself
Remember also that the box must be running before the job can start. Do not assign
a start time for a job in a box if the box will not be running at that time. If you do,
the next time the box starts the job will start immediately.

3.3.5 How Job Status Changes Affect Box Status

If a box contained only one job, and the job changed status, the box status would
change.
How Job Status Changes Impact Box Status

Current BOX
Status

New JOB Status

New BOX Status

SUCCESS

TERMINATED or
FAILURE

FAILURE

SUCCESS

SUCCESS

NO CHANGE

FAILURE

SUCCESS

SUCCESS

FAILURE

FAILURE

NO CHANGE

INACTIVE

SUCCESS

SUCCESS

INACTIVE

TERMINATED or
FAILURE

FAILURE

TERMINATED

ANY CHANGE

NO CHANGE

Eg)
{
insert_job: < box_name>
job_type: b
.....
insert_job: job_name1

job_type: c

box_name : < box_name>

.....
}

3.3 Command Job Attributes

The command can be a shell script or any executable program.

When this type of job is run, the result is the execution of a specified
command on a client machine.
When all the starting conditions are met, AutoSys runs this command and
captures its exit code upon completion.
The exit event (either SUCCESS or FAILURE) and the exit code value are
stored in the database.

Profile Script

For each job, you can specify a script to be sourced before the execution of the
command that defines the environment in which the command is to be run.
All commands are run under the Bourne shell (/bin/sh). Therefore, all statements in
the profile must use /bin/sh syntax.
If a profile is not specified, the default AutoSys profile, /etc/auto.profile, is used.
If the profile attribute is specified, that profile is searched for on the machine on
which the command is to run

/* ----------------- template ----------------- */

insert_job: template job_type: c
box_name: box1
command: ls -l
machine: localhost

4.Autosys Status Abbreviations

AutoSys keeps track of the current state, or status, of every job. The value of
a job 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
Following are the status of Autosys jobs:

INACTIVE (IN): i) The job has not yet been processed. ii) Either the job has never
been run, or its status was intentionally altered to turn off its previous completion
status.

ACTIVATED (AC): Job is now in the RUNNING state, but the job itself has not started
yet

STARTING (ST): The event processor has initiated the start job procedure with the
Remote Agent.

RUNNING (RU): The job is running.

SUCCESS (SU): Jobs or Box job finished and the status has been successes.

FAILURE (FA): The job failed with an exit code and AutoSys issues an
<alarm_if_fail :1> if a job fails

TERMINATED (TE): i) The job terminated while in the RUNNING state.

ii) If a user sends a KILLJOB sendevent or if it was defined to terminate if the box it is
in failed. iii) If the job itself fails, it has a FAILURE status, not a TERMINATED status.

iv) 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 through a UNIX kill
command.
v) AutoSys issues an alarm if a job is terminated.

 RESTART (RE): The job was unable to start due to hardware problems, and has
been scheduled to restart.
QUE_WAIT (QW): The job can logically run (all the starting conditions have
been met), but there are not enough machine resources available.
ON_HOLD (OH): This job is on hold and will not be run until it receives the
JOB_OFF_HOLD event.
ON_ICE (OI): This job is removed from all conditions and logic, but is still
defined to AutoSys. This condition is like deactivating the job. It will remain
on ice until it receives the JOB_OFF_ICE event.
REFRESH (RD/RF): RD -> Dependencies, RF -> Filewatcher

5. Events send by users

By using the sendevent command or the Send Event dialog, you can send
execute events that affect the running of a job. These are the execute events that
you can send, if you have the appropriate permissions:

sendevent -E STARTJOB -J job_name

sendevent -E FORCE_STARTJOB -J job_name

sendevent -E JOB_ON_ICE -J job_name

sendevent -E JOB_OFF_ICE -J job_name

sendevent -E JOB_ON_HOLD -J job_name

sendevent -E JOB_OFF_HOLD -J job_name

sendevent -E SET_GLOBAL -G <job_name>=READY

sendevent -E SET_GLOBAL -G <variables>=FREE

sendevent -E STOP_DEMON - to stop AutoSys

sendevent -E CHANGE_STATUS -S INACTIVE -J job_name

sendevent -E KILLJOB -J job_name

some other sendevent commands [DELETE_JOB],[CHANGE_PROIRITY],[COMMENT],

[SEND_SIGNAL][ALARM]

Syntax

sendevent -E event [-S autoserv_instance] [-A alarm] [-J job_name]

[-s status] [-C comment] [-P priority] [-M max_send_trys]
[-q job_queue_priority] [-T "time_of_event"]
[-G "global_name=value"] [-k signal_number(s)] [-u]

6. Autorep Commands
Reports information about a job, jobs within boxes, machines, and machine
status. Also reports information about job overrides and global variables.
Syntax
autorep {-J ALL | job_name -M machine_name -G global_name} [-s -d (detail) -o
(over_num/over_ride)] [-r run_number] [-q (> file_name)],
autorep -J (job name here) - Display the list of jobs with complete details with
box/jobname,
last/latest run date & time, status, exit code, etc.
autorep -J (job name here) -r (No of runs back) - Information of previous runs
example : autorep -J (job name here) -r 1
autorep -J (job name here) q - Viewing JIL code for any Autosys jobautorep -J
job_name d Details

7. Job Dependencies Related to Job Status

This is the syntax for conditions based on AutoSys job status:

condition: status(job_name)

success (s) Indicates that the status condition for job_name is SUCCESS.

failure (f) Indicates that the status condition for job_name is FAILURE.

Done (d) Indicates that the status condition for job_name is SUCCESS,
FAILURE or TERMINATED.

terminated Indicates that the status condition for job_name is TERMINATED.

notrunning Indicates that the status condition for job_name is anything

except RUNNING.

exitcode Indicates that a process will start based on the exitcode of a

particular job_name
exitcode (job_name) operator value
where:

job_name Is the name of the job upon which the new job is dependent.

operator Is one of the following exitcode comparison operators:

=, != (not equal), <, >, <=, or >=

value Is any numeric value.

You can abbreviate the dependency specification exitcode with the letter e
(uppercase or lowercase).
For the above example, you would enter the following for the job dependency
specification for the JobB redial job:
e (JobA) = 4
You can use any job status or exit codes as part of the specification for starting
conditions. With this latitude, you can program branching paths that will provide
alternative actions for all types of error conditions.

8. JIL Sub_Commands

command: the actual command to be executed

start_mins: which minutes the job should be started every hour. This is a
comma-separated list of minutes, e.g. 0,15,30,45

start_times: actual times per day the job should be started. This is a
comma-separated list of times, e.g. "5:15,15:30,23:59"

start_days: comma-separated list of days on which the job should run,

exclusive. These days are denoted using two-letter abbreviations:
su,mo,tu,we,th,fr,sa

condition: when a job should run based on the state of other jobs, e.g.
"failure(JOB1) and (success(JOB2) or success(JOB3)) and notrunning(JOB4)"

alarm_if_fail: boolean (0/1) value determining whether an alarm should be

sent upon a job failure event.

date_conditions: 1 -> determines whether time/day constraints will be

taken into consideration when determining when to kick off jobs. If 0, start_times,
start_mins, and start_days will be ignored, and job control will be based on the
condition field only.

std_in_file: file that will be redirected into the command as STDIN. Specify
full path. Autosys does not provide this utility, but it should be trivial to add. (ADS
Extension)

std_out_file: file that will receive the job's STDOUT. Specify full path.

std_err_file: file that will receive the job's STDERR. Specify full path.

profile: file that will be sourced by the shell prior to kicking off the job.

run_window: A range of hours, such as "7:00 - 10:00", which restricts the

possible start times of the job. If you specify "start_mins: 15,30", then the job will
run on 7:15, 7:30, 8:15 ... 10:30, and will then wait until the next available 7:15
(taking day restrictions into account).

auto_delete: If set to 0, AutoSys will immediately delete job definitions only

if the job completed successfully. If the job did not complete successfully, AutoSys
will keep the job definition for 7 days before automatically deleting it. This attribute
AutoSys schedule and run a one-time batch job.


run_calendar: The days on which a job should/ should not be run can be
specified by way of a custom calendar, Custom calendars, specified through the
AutoSys Graphical Calendar Facility, or the autocal_asc command, can include any
number of dates on which separate object with a unique name, and a calendar can
be associated with one or more jobs

autocal_asc The autocal command is used to start up the AutoSys Graphical

Calendar Facility to define and maintain AutoSys calendars. Calendars are lists of
dates that you can use to schedule the days on which jobs should, or should not,
run, adds & deletes custom calendar definitions.

days_of_week: The days of the week attribute specifies the days on which the
job should be run. You can specify one or more days, or all for every day.

exclude_calendar: Do NOT Run on Days in Calendar

Template example:
/* ----------------- template ----------------- */
1.

insert_job: template job_type: c

box_name: box1
command: ls -l
machine: localhost
owner: lyota01@TANT-A01
permission: gx,ge,wx,we,mx,me
date_conditions: 1
days_of_week: all
start_times: "15:00, 14:00"
run_window: "14:00 - 6:00"
condition: s (job1)
description: "description field"
term_run_time: 60
box_terminator: 1
job_terminator: 1
std_out_file: /tmp/std_out
std_err_file: /tmp/std_err
min_run_alarm: 5
max_run_alarm: 10
alarm_if_fail: 1
max_exit_success: 2
chk_files: /tmp 2000
profile: /tmp/.profile
job_load: 25
priority: 1

Posted by Lee at 06:28 5 comments:

Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest

Labels: Scheduling Tools
Older Posts Home
Subscribe to: Posts (Atom)
Blog Archive

2012 (4)
o

June (1)

May (3)

Autosys Guide

Unix Commands

IBM Datastage Overview

Follow by Email

Having 5 Years of Exp as a Datastage developer

Lee
Hyderabad, Andhra Pradesh, India
View my complete profile

Watermark template. Powered by Blogger.