~

Autosys Interview Questions

When you define a job, CA Workload Automation AE saves its starting conditions to the event server
(database), and the following occur:

 When the job's starting conditions are met, the scheduler submits the job to an agent.
 The agent runs the job and returns the job's exit status to the application server.
 The application server updates the event server.
 After the job completes, it does not run again until its starting conditions are met.

To verify whether the event server service (the database service) is started, look at the Windows Control
Panel Services dialog. You can verify the following:

 If you are running Microsoft SQL Server, verify the status of the MSSQLServer service.
 If you are running Oracle, verify the status of the following services (substitute your Oracle SID
for the asterisk): OracleService*, OracleStart*, and OracleTNSListener.
 If you are running Sybase, verify that a service with a name that starts with SYBSQL is started. It
is possible that a different name was selected for the service when Sybase was installed.
 Event Server Is Down

- When I issue the chk_auto_up command, a message similar to the following is displayed:
-Couldn't connect with Server: AUTOSYS:autosys
-Either the database server is down or the process in question cannot access the database server.

Event Processor Troubleshooting

Below are the steps to confirm event processor is down.

1.Run the command chk_auto_up from Autosys server to see whether the servers(DB and scheduler) are
up and reachable.
2.Output from the event processor is directed to $ cd AUTOUSER/out/event_demon.$AUTOSERV.
Check the log file using tail command to see whether current time stamp is registered.
3.Check the process event_demon is running or not using the command $ ps -ef | grep event_demon

After confirming event processor is down login as Exec superuser and run the # eventor command to start
the event processor.
Sometimes eventor will throws error message while starting,check the permission for the current
superuser in the log file permission.
$ ls -l $AUTOUSER/out/event_demon.$AUTOSERV

Remote agent Troubleshooting

1.Run autoping -M -D client_hostname from server to check the connectivity between event processor and client.
2.Run autoping -m mach_name -D to check the connectivity between DB and client.
3.Run autoping -m ALL to check the connectivity for all clients.

If autoping fails below are the steps.

1.Remote agent will not start due to network problems or system is down,check the log file
$AUTOUSER/out/event_demon.$AUTOSERV and it will have logs similar to [The connection to
machine:TIMED OUT. Either the machine, or the network , is having problems.]

2.Remote agent will not start due to mis configuration.$AUTOUSER/out/event_demon.$AUTOSERV file log will be
similar to [Could NOT connect to machine: internet demon may not be configured properly]

a) Check the /etc/services to see for the below entry.

auto_remote 5280/tcp
b) Port number used in AutoRemPort in config file $AUTOUSER/config.$AUTOSERV must be same as /etc/services.

3.Remote agent will not start due to inetd configuration.$AUTOUSER/out/event_demon.$AUTOSERV log file will
show error as [Remote Agent Process not started].check the inetd.conf file for errors.

Remote agent starts but command will not run

When remote agent starts running, log file will be saved in AutoRemoteDir/auto_rem.pid.

AutoRemoteDir - path will be specified in config file of the autosys server.

auto_rem.pid - process ID of the remote agent.

When remote agent receives job definition from event processor log file will be renamed to
AutoRemoteDir/auto_rem.joid.run_num.ntry

joid - jobs no in the database

run_num - job run number
ntry - number of restarts or tries

Fire $ autosyslog -J <job_name> command in client where the job has ran to find the recent log.

Job struck in STARTING,RUNNING state or immediately turned to FAILURE

a)check autosyslog -J <job_name> in client where the job ran

b)check the autosys source profile /etc/auto.profile.
c)check the echo $PATH variable to see all executables directories are exported correctly.
d)check the file system where the job runs(SAP/oracle) is accessible.
e)check the permissions for std input/output/error files and also check for errors in error and output files.
f)The profile should be a bourne shell script.

Remote agent starts,Command runs but No running event like RUNNING,FAILURE,SUCCESS is sent to DB.

a)check the communication between remote agent and event server.

b)Issue may be from DB side.SQL*Net V2 in oracle DB is not set up properly.check autosyslog -e <job_name> for
more info.

Remote agent Not Found

When job is started from event processor # Unknown Host Machine # will be updated in log file
# autosyslog -e

a) Network issue in reaching the client machine

b) Client machine name is not added in DNS or /etc/hosts entry.
c) check whether the client machine is added in Autosys Database.

Reasons for Job running twice in Autosys

Below are the client performance issues, which affects job run.

a) There are too much of processess running on the client where the job starts.
b) Network problems may be the issue.
c) NFS mounted directories in client with low bandwidth.

Job failure Troubleshooting

Job runs from command line but fails when running through Autosys.

a) Check the profile(should be bourne shell) in the job definition.

b) Check the parameters in the default profile (/etc/auto.profile) for all jobs

if not specified in the job definition.

To check the difference between the job definition and the user environment

a) Login to the client where the job runs and enter the command $ env > owner1.env
b) Create a job to record the remote agent environment variable to a file.

insert_job: remote_env
machine: client_hostname
owner: owner
command: env
std_out_file: /tmp/remote1.env
std_err_file: /tmp/remote1.err

$ sendevent -E STARTJOB -J remote_env

Now check the differences between the two profiles and troubleshoot the same.

diff /tmp/remote1.env owner1.env

/tmp/remote1.err also used to give clues about the issue

Autosys Crontab
Autosys (Now called CA Workload Automation) Crontab is a inbuilt feature in UNIX systems
is a centralized job management tool. used to schedule and run scripts/commands.

Help to run thousands of jobs at time in different Jobs can be triggered only in UNIX systems.
systems (windows, Linux, Mainframe etc)

Autosys is widely used in banking systems to Crontab is used to schedule few jobs in a client
run n+ lakh jobs in enterprise application machine.
environment.

Centralized job management through integration No integration with database.

with database.

Used to schedule third party application jobs Not integrated with third party application to
includes SAP, Oracle, Peoplesoft etc with the trigger jobs.
help of Autosys adapters installed.

Jobs historical information (status) can be Not possible to extract historical information for
extracted from database. a large number of jobs.
 Autosys can trigger different types of jobs Can trigger only commands and scripts.
includes command jobs, script, Box jobs, File
watcher jobs, FTP jobs etc.

Each jobs exit codes and error codes with Not possible to manage thousands of jobs exit
detailed information can be stored for and error codes.
investigation.

Credentials used to trigger jobs are stored in Not secured as credentials can be changed by
database in a secured encrypted manner. root users.

EEM - Embedded Entitlements Manager Not integrated with LDAP users to schedule and
application in CA workload automation provides manage jobs with greater security as EEM.
access to global users from LDAP server to
schedule and run jobs.
WCC – Workload Control Center application No Web interface available to manage crontab.
integrated with core Autosys system to perform
administrative tasks though web interface.

1.To print the status of the job(including last run schedule)

# autorep -J <job name>

2.To Print job details(job definition)

# autorep -J <job name> -q

3.To print the job last run details

# autorep -J <job name> -d

4.To print the job run history

# autorep –j <job name> -r -4 [only we can view last 5 status of jobs (0-4)]

5.To put job ON_HOLD

# sendevent -E JOB_ON_HOLD –j <job name>

6.To put job OFF_HOLD

# sendevent -E JOB_OFF_HOLD –j <job name>

7.To put the job ON_ICE

# sendevent -E JOB_ON_ICE –j <job name>

8.To put the job OFF_ICE

# sendevent -E JOB_OFF_ICE –j <job name>

9.To FORCE_START a job

# sendevent -E FORCE_STARTJOB -J <job name>

10.To kill a job

# sendevent -E KILLJOB -J <job name>

11.To mark job as success

# sendevent -E CHANGE_STATUS -s SUCCESS -j <job name>

14.To mark job as terminated

# sendevent -E CHANGE_STATUS -s TERMINATED –j <job name>

15.Command to find dependent job for job/box

# job_depends -c -J <box name/job name>

16.To print the Schedule details for a calender

# autocal_asc

Press Enter

Give the calander name

Press Enter

Enter P to print the details

17.To print job/BOX full details.[This will take more time to pull details]
# autorep -J <job name> -w

Difference between ON HOLD and ON ICE in Autosys

The difference between ON HOLD and ON ICE in Autosys is that,when a ON_HOLD job is taken
OFF_HOLD,the job will be scheduled to run if its starting conditions are already satisfied.
But when a ON_ICE job is taken OFF_ICE ,the job will not run even though its starting
conditions are met.The job is scheduled to run only when the starting conditions reoccur for this job.

When a job is ON_HOLD,its dependent jobs and downstream from this job will not run.
But when a job is ON_ICE ,the downstream from this job runs as though the job succeeded.

3. What is JIL in Autosys?

JIL stands for Job Information Language.

JIL is a specification language, with its own syntax, that is used to describe when, where, and how a job
should run. When you enter the jil command, you get the jil command prompt, at which you can enter the
job definitions one line at a time using this special language. When you exit the jil command-line
interface, the job definition is loaded into the database. Alternatively, you can enter the definition as a text
file and redirect the file to the jil command. In this case, the jil command activates the language processor,
interprets the information in the text file, and loads this information in the database.

4. Draw the typical installation architecture of Unicenter Autosys ?

Event Server:
Stores all events and job information (relational database).

Event Processor:
Interprets and Evaluates job definitions and notifies a Remote Agent to initiate actions.

Remote Agent:
Performs tasks; sends resulting job statuses back to the Event Server. The agent may be Unix or
Windows.

5. Explain INACTIVE status in Autosys jobs.

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.

Autosys interview questions and answers - Page 2

6. Explain ON_HOLD in Autosys ?

When a job is put on hold, it will not be run until it receives the JOB_OFF_HOLD event or FORCE
START. ON_HOLD is equivalent to stop the current execution process.

Example:
There are 4 jobs, say Job A, Job B, Job C and Job D. Consider all these jobs reside in a box job named
box_1. The box job is started now. After starting the box job user immediately realized that there is a
mistake in command script name in Job C. So, he put the Job C ON HOLD before it starts. Thus, he
ensures the job will run proper way.

7. Explain ON_ICE in Autosys.

This job is removed from all conditions and logic, but is still defined. Operationally, this condition is like
deactivating the job. It will remain on ice until it receives the JOB_OFF_ICE event.

Please remember that the job which is defined after the job ON ICE, will immediately start even though
some conditions are specified for that job with the previous one. This is the important note about ON ICE.

Simple question ...

A box job contains 10 jobs. The jobs are in sequential order. Consider the Job 5 is ON ICE and it has the
dependency with only Job 4. If the box job is started, what will be the jobs will be running immediately ?

Yes. The first job as well as the 6 th job will be starting immediately since ICE instructs next job to run
immediately.

8. What is the difference between ON HOLD and ON ICE in Autosys ?

This is the very important and most expected question in Autosys.

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 in on hold—nothing downstream from
this job will run.

9. What does the job term ACTIVATED mean in Autosys ?

The top-level box that this job is in is now in the RUNNING state, but the job itself has not started yet.
You can see the status of the job when you have just started the Box job of that particular job.

10. What is the meaning of the job status STARTING in Autosys?

The job is ready and going to start. The event processor has initiated the start job procedure with the
remote agent

Autosys interview questions and answers - Page 3

11. Explain the job term RUNNING in Autosys ?

The job is running. The job is processing data. The job will be in running status until it process the data. If
the job is a box job, this value simply means that the jobs within the box are running. If it is a command or
file watcher job, the value means that the process is actually running on the remote machine.

12. When will the job be SUCCESS in Autosys ?

If the job exited with an exit code 0, then that job is interpreted as success. However, a range of values up
to the maximum exit code for success can be reserved for each job to be 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.

13. When will the job be FAILURE in Autosys?

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. If the job is a box job, a FAILURE status means either that at
least one job within the box exited with the status FAILURE (the default), or that the Exit Condition for
Box Failure evaluated to true. Unicenter AutoSys JM issues an alarm if a job fails.

14. When will be the job in TERMINATED status in Autosys ?

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 runtime (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. Unicenter AutoSys JM
issues an alarm if a job is terminated.

15. Explain job RESTART in Autosys.

The job was unable to start due to hardware or application problems, and has been scheduled to restart.

16. Explain QUE_WAIT status in Autosys.

The job can logically run (that is, all the starting conditions have been met), but there are not enough
machine resources available. The job will start only if it has adequate resources to process.

17. Sample JIL file in Autosys

insert_job: jobname
job_type: c
box_name: which box holds this job
description: What the job is doing
machine: servername
permission: gx,wx
owner: account
command: batch_file or Script
std_out_file: "c:\AutoSysLog\Test.log"
std_err_file: "c:\AutoSysLog\Test.Err.log"
min_run_alarm: 0
max_run_alarm: 30
job_terminator: yes
box_terminator: yes

18. What is an Instance in Autosys?

The term instance is used to represent a licensed version of Unicenter AutoSys JM and at least one client
machine running a unique Remote Agent. In reality, the operation is likely to have dozens of Remote
Agents communicating concurrently with the same database. Any status changes or service requests
posted to the database are called Events.

19. Graphical User Interface in Autosys

The GUI lets you interactively set the attributes that describe when, where, and how a job should run. You
create job definitions using the GUI Control Panel and the dialogs you can launch from it.

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 lets you define calendars, monitors, and reports, and let
you monitor and manage jobs.

20. Three types of jobs in Autosys

There are three types of Unicenter AutoSys JM jobs:

Command, File Watcher, and Box.

Command - Execute a command. Generally a input file is given in which the required commands reside.
File Watcher - Special type of job in AutoSys. It will wait for a file. It will not start the job until the file
arrives. This type of job will be helpful when you integrate your project from various modules.
Box - A box is a container of other jobs. A box does nothing in execution but it holds and preserves the
jobs. In projects, start time is specified in Box jobs so that it will automatically starts once the time has
arrived.

21. Box job started but inner jobs are not running in Autosys - why ?

This problem is a familiar one and one of the important notes in Autosys.

Scenario 1: (Meeting dependency)

Remember that even if the box job started, the inner jobs will only run when they satisfy all the conditions
specified.
For example let us take a box job A in which an inner job "a" resides. The job "a" has the dependency
with a job "b" which resides in another box job B. So, "a" is scheduled to run after the job "b". Now, If
box A is force started, job "a" will not start since it waits for job "b" to complete. Job "a" will start
automatically once job "b" over.

Scenario 2: (Meeting timelines) Consider several inner box jobs are defined under a super box job. The
start time for the super box job is 10:00 and the start time for the inner jobs is 11:00. Now, if the super
box job is started, will the inner box jobs run immediately ? No, they will not. Inner jobs obey the timing
pattern strictly and they will start running once they meet the timelines.

22. Box job in Autosys -Explain

A Box job is a container of other jobs.

A box job will do nothing in execution process but it can control the inner jobs when and how they
should run. If a box job is started, it will start the inner jobs automatically.

Generally, the jobs which do similar operations or generic functions will be grouped together under a box
job.
We can set the start time and run calendars for a box job to control the execution.

Feature of a Box job:

When a box job is in running status (After starting), it will be in success state only if all of its inners jobs
succeeded.
The box job fails when any one of the inner job fails.
A box job can contain other box jobs. The box job which is superior to all other box jobs is called as
Super box.

23. If you want to remove the run calendar and start times from a job, how will you
execute with JIL file?

In Autosys, there is a command called date_conditions which enables the run calendar and start time.

If date_conditions=1 then the above parameters will be enabled and if date_conditions=0, the parameters
will be disabled. Thus, while executing the JIL, date_conditions=0 needs to be set for a job to remove the
run calendar and start times
24. Is Machine name needed for a Box job in Autosys?

Machine name is not needed for a Box job. Machine name is need for other types of jobs like commands
and file watchers. Machine name is primarily required to run the script. Since Box job is the holder of
other jobs and it does nothing in the execution process, Machine name is not required for a box job.

25. Deleting a Box in Autosys - Explain

delete_box: box_name command is used to delete the box. This command will delete all the inner jobs of
the box job also. To delete the box job alone leaving its content jobs intact, you have to render delete_job:
box_name.

26. Delete a job in Autosys - Explain

delete_job: job_name command is used to delete the job. In order to delete a job, you need to simply give
delete_job command. No more commands or attributes are needed for deleting.

27. What are the system components in Autosys?

Event server
Event processor
Remote Agent

28. Event server in Autosys - Explain

Event server can also be called as Autosys database (RDBMS).

It is the repository unit which stores system information and events, job, monitoring, reporting definitions.

Autosys can operate in dual server mode. Therefore, if you lose one event server due to hardware/network
problems, another server will handle your work without any loss of information or functionality.

# Send Event
alias -x se='sendevent -E'

# Start Job
alias -x fsj='sendevent -E FORCE_STARTJOB -J'
alias -x sj='sendevent -E STARTJOB -J'

# Job Report
ar='autorep -w -J '
fsj='sendevent -E FORCE_STARTJOB -J'
hold='sendevent -E JOB_ON_HOLD -J '
ice='sendevent -E JOB_ON_ICE -J '

jd='job_depends -c -w -J '
killjob='sendevent -E KILLJOB -J '
offhold='sendevent -E JOB_OFF_HOLD -J '
office='sendevent -E JOB_OFF_ICE -J '
se='sendevent -E'
sj='sendevent -E STARTJOB -J'
success='sendevent -E CHANGE_STATUS -s SUCCESS -J '
terminate='sendevent -E CHANGE_STATUS -s TERMINATED -J '

Display JIL (Job Instruction Language):

autorep -w -J <jobname> -q

Load JIL:
jil < JIL_source

Find unique commands currently being used:

autorep -J PARTIALJOBNAME% -q | grep "command:" | awk -F: '{print $2}'|awk '{print
$1}' | sort -u > /tmp/cmds.txt

Meaning of AutoSys status:

STATUS AUTOSTATUS Meaning
RU RUNNING Running
ST STARTING Starting
SU SUCCESS Success
FA FAILURE Failure
TE TERMINATED Terminated
OI ON_ICE On Ice
IN INACTIVE Inactive
AC ACTIVATED Activated
RE RESTART Restart
OH ON_HOLD On Hold
QW QUE_WAIT Queue Wait
RD Refresh Dependencies
RF Refresh Filewatcher

Forecast report from date to infinity:

Code:
job_depends -t -J ALL -F "mm/dd/yyyy"

Display all jobs scheduled to run between these two dates:

Code:
job_depends -t -J ALL -F:06/01/2008 -T:06/30/2008
check if the event procesor is up and running

Code:
chk_auto_up

Display list of available timezones:

Code:
autotimezone -l

Get version information:

Code:
autoflags -a

View Remote Agent log:

Code:
autosyslog -J jobname

AutoSys Unix xwindows GUI control panel

Code:
autosc &

Check Database connections:

Code:
autoping -m machinename -D

Autosys – Process Flow

The diagram in the following figure and the numbered explanations that follow it
illustrate how Unicenter Autosys JM performs its most basic function – starting a job
(that is , executing a command) on a client Machine.
[Note : In following figure, the major components are shown as separate entities.
Typically, event processor and event server are installed on the same server
machine along with a required remote agent, and other remote agents are installed
on separate client machines.]
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
event is a STARTJOB event, the job definition and attributes are retrieved from
Event server, including the command and pointer (full path name on the client
machine) to the profile to be used for the job. In addition for jobs running on
windows machines, the event processor retrieves from the database the userIDs
and passwords required to run the job on client machine.

3. The Event processor processes event. If the event is STARTJOB, the Event
processor attempts to establish a connection with remote agent on the client
machine, and passes job attributes to client machine. The Event processor sends a
CHANGE_STATUS event making in the event server that the job is in STARTING
status.

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 job’s
owner, using the userIDs and passwords passed to it from 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 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.

The remote agent sends the Event server a CHANG_STATUS event corresponding to
the completion status of the job and passes back an exit code, using the
communication facilities of the database. If the return status is SUCCESS, the
remote agent deletes the log file in its temporary file directory on the client
machine. The remote agents quits.

Autosys Jobs
There are three types of jobs,
- Command Jobs : execute commands
- File watcher Jobs: watch for the arrival of a specified file.
- Box Jobs: are containers that hold other jobs (including other boxes). 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.

Autosys Job Status

Autosys keeps track of the current status of every job. Following are the statuses –
INACTIVE (IN) - 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.
ACTIVATED (AC) - The top-level box job is in 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 executing. 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.
SUCCESS (SU) - 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.”
FAILURE (FA) - Job exited with an exit code greater than “maximum exit code for
success.” Any number greater than zero is interpreted as “failure.” Autosys issues
an alarm if a job fails.
TERMINATED (TE) - 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. A job may also be terminated if it has exceeded the maximum run
time or if it was killed from command line through UNIX kill command. Autosys
issues an alarm if a job is terminated.
RESTART (RE) - Job was unable to start due to hardware or application problems,
and has been scheduled to restart.
QUE-WAIT (QU) - The job can logically run (that is, 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. Operationally, this condition is like deactivating the job. It will remain
on ice until it receives the JOB_OFF_ICE event.

Default Box Job behaviour

Some important rules to remember about boxes are:
- 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."
- Unless otherwise specified, a box will run indefinitely until it reaches a status of
SUCCESS or 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.
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.

What is difference between ‘ON HOLD’ and ‘ON ICE’ status?

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 downstream jobs from the job which is
"on ice" will run
as though the job succeeded. Whereas, all dependent jobs do not run when a job is
on "on hold”.

What are different starting conditions for Autosys job?

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

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”
n_retrys: 12
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
profile: /tmp/.profile

Explanation of each line:

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, b=box)
box_name: this is the box job name: box job can have more than 1 child jobs.
commands: this is where you tell Autosys, what to do when the job runs.
machine: name of the machine where you want to run the job.
owner: owner of the job.
permissions:
date_conditions: 1 if you have any specifications.
days_of_week: on which days of the week you want the job to run.
start_time: the time at which the job should kick-off.
run_window: this option is for monitoring jobs. Job will run continuously for
specified time window.
conditions: You can specify the dependencies. like success of some other job.
description:
n_retrys: no of retrys on a failure.
term_run_job: the job will terminate if it runs for specified time.
box_terminator: if 1, terminates box job depends on term_run_time.
job_terminator: if 1, terminates child job depends on term_run_time.
std_out_file: standard output file (log) for the job
std_err_file: Error log file if the job fails
min_run_alarm: if the job terminates/completed within that time it generate an
alarm
max_run_alarm: if the job runs for more than the specified time, it 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)

We don’t use all the above options in all the jobs, it depends on the requirements.

Here is a sample job which will verify a particular process is running or not.
/* —————– 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

To Insert a new Autosys job as JIL code

issue command "jil"
bash-3.00$ jil >>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, then successful message will come and exit; else it will
show error.
For Example -
· Insert Box using JIL
jil
jil>>01> insert_job: box_TG_cafe job_type: b
jil>>02> owner: autosys
jil>>03> permission: gx,wx,mx
jil>>04> date_conditions: 1
jil>>05> days_of_week: sa
jil>>06> start_times: "16:00"
jil>>07> condition: s(box_TG_post_dp_batch)
jil>>08> description: "CAFE Extract"
jil>>09> alarm_if_fail: 0
jil>>10> group: TG_cafe
jil>>11> exit
________________________________________________________________
___
CAUAJM_I_50204 Inserting/Updating Job: box_TG_cafe
CAUAJM_I_10122 Job 'box_TG_cafe' scheduled: 01/07/2012 16:00:00
CAUAJM_I_50205 Database Change WAS Successful!
__________________________________________________________________
· Insert Command using JIL
jil
jil>>01> insert_job: job_TG_extract_customer_premise_info job_type: c
jil>>02> box_name: box_TG_cafe
jil>>03> command: sudo -u energyop –i
$${CISSOURCE}/CAFE/extract_cust_premise_info.sh
jil>>04> machine: TGDB
jil>>05> owner: autosys
jil>>06> permission: gw,gx
jil>>07> condition: s(job_customer_enroll_info)
jil>>08> description: "extract_customer_premise_info"
jil>>09> std_out_file: $${CISAUTOLOGS}/extract_customer_premise_info_out.log
jil>>10> std_err_file: $${CISAUTOLOGS}/extract_customer_premise_info_err.log
jil>>11> alarm_if_fail: 0
jil>>12> group: TG_cafe
jil>>13> exit
___________________________________________________________________
_
CAUAJM_I_50204 Inserting/Updating Job: job_TG_extract_customer_premise_info
CAUAJM_I_50205 Database Change WAS Successful!
___________________________________________________________________
_
· Insert File Watcher using JIL
jil
jil>>01> insert_job: fw_TG_CW27505_Extract_Premise job_type: f
jil>>02> box_name: box_TG_cafe
jil>>03> machine: TGFTP
jil>>04> owner: energyop
jil>>05> permission: gw, gx
jil>>06> condition: s(job_TG_extract_customer_premise_info)
jil>>07> description: "CW27505_Extract_Premise_yyyy-mm-dd.dat.gz file
watcher"
jil>>08> watch_file: $${CISFTPFTP}/CAFE/out/CW27505_Extract_Premise_$$
{DATEA}.dat.gz
jil>>09> watch_interval: 60
jil>>10> alarm_if_fail: 0
jil>>11> group: TG_cafe
jil>>12> exit
________________________________________________________________
CAUAJM_I_50204 Inserting/Updating Job: fw_TG_CW27505_Extract_Premise
CAUAJM_I_50205 Database Change WAS Successful!
________________________________________________________________
Autosys Command - Autorep
The command reports information about a job status and also job defination. It 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]
To display a status of Autosys job.
autorep -J (job name here)

Viewing JIL code for any Autosys job

autorep –q -J (job name here)

To obtain the information of previous runs

autorep -J (job name here) -r (No of runs back)

Autosys Command - sendevent

This command send events 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.

Following are the example of sendevent command frequently used.

sendevent -E FORCE_STARTJOB -j
sendevent -E STARTJOB -j
sendevent -E JOB_ON_HOLD -j : Job now on hold
sendevent -E JOB_OFF_HOLD -j : Job now released.
sendevent -E CHANGE_STATUS -s SUCCESS -j : Job status changed to success
sendevent -E JOB_ON_ICE -j : Job now "on ice"
sendevent -E JOB_OFF_ICE -j : Job taken off "ice". Beware of dependancies!!
sendevent -E KILLJOB -j : Job "Killed"
sendevent -e CHANGE_STATUS -s INACTIVE -j
sendevent –E STOP_DEMON : Shutdown autosys
sendevent –E SET_GLOBAL –G “var_name=/home/dinesh” : To set variable in
autosys
sendevent is normally used with "-E" & -J option
-J job_name : Specifies name of the job to event should be sent. This option is
required for all events except STOP_DEMON, COMMENT, ALARM, or SET_GLOBAL
-E event: Specifies the any one of following events to be sent.
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
Other Autosys Commands
# Reports the current status of a specific job, or the value of an Autosys global
variable.
autostatus -J job_name [-S instance]

#To see job report

autorep –w –j

# To find dependent downstream jobs and their status.

job_depends –c –w –j

# Load autosys JIL file

jil < JIL_source
# Find unique commands currently being used
autorep -J PARTIALJOBNAME% -q | grep "command:" | awk -F: '{print $2}'|
awk '{print $1}' | sort -u > /tmp/cmds.txt
# Forecast report from date to infinity:
job_depends -t -J ALL -F "mm/dd/yyyy"

# Display all jobs scheduled to run between these two dates:

job_depends -t -J ALL -F:06/01/2008 -T:06/30/2008

# check if the event processor is up and running

chk_auto_up

# Display list of available time zones:

autotimezone -l
 # Get version information
autoflags -a

# View Remote Agent log

autosyslog -J jobname

# To start autosys GUI panel

autosc &

# Verify both client & server are correctly configured

autoping -m machine_name
# To convert jobs from crontab to autosys jobs. Below command will create a
file1.jil in present directory.
cron2jil –f file1
#Prints, adds & deletes custom calendar definations
autocal_asc
# To change, edit, exec superusers, change DB passwds, change remote
authentication method
autosys_secure

[COURTESY - All helping hands and helpful websites on internet.]

https://amahana.wordpress.com/unix/unix-shellscripting/

What is the PE Status ?

when the agent service is not running/down for any reason and machine status is “Missing” or “unqualified” or
“offline”, the jobs that are supposed to run on that agent will be marked to PE(PEND_MACH) status.

Agent Service on windows servers will be down when c:\ drive becomes full.

Agent Service on Unix Servers will go down when /apps filesystem is filled up to 100%.

How To Action on the PE Status jobs.

Check the status of the machine status at the instance level running the below command at CLI tools command
prompt
autorep.cmd –M <machinename>

if the machine status is “Missing” and agent service is started back on the agent, the machine status will be
automatically brought online due to detected status change by the scheduler and all the PE status jobs will kick off
on the server whichever are supposed to run.

1) If don’t want all the jobs to kick off immediately and want to action on the PEND_MACH status
jobs manually one by one forcestarting/changing status, you can set the machine OFFLINE using
the below command

sendevent.cmd -E MACH_OFFLINE -N <machine Name>

Any other box is started during this time and child jobs are targeted on the same machine will still be
marked to PEND_MACH status as the machine status was set to offline.

Once the PE status jobs are actioned, you may set the machine online back using the command

sendevent.cmd -E MACH_ONLINE -N <machine Name>

This will ensure New jobs of future schedule will not be impacted and will run as per schedule.

2) If machine status is showing OFFLINE even without setting it OFFLINE and you want to run all the PE
status jobs at once, then the sequence would be

1) Start the agent service

2) Set the machine to online.

If above 2 are done at once, old PEND_MACH status jobs will kick off immediately and new jobs of future
schedule will not be impacted and will run as per schedule.

Getting the Agent Service started:-

1) Below are the checks that need to done.

Check whether the agent Service is running or not ?

Unix:-

/etc/init.d/waae_agent-<Agent Service> status

<Agent Service> : -> WA_DEV,WA_UAT,WA_PRD

If the agent Service status is not “active”

Example:-

# /etc/init.d/waae_agent-WA_DEV status

WAAE Agent (WA_DEV) - not active

Please contact the platform teams(Unix , Windows) to get the service started back creating an INC ticket for the
relevant platform team.

Get it started by running:

/etc/init.d/waae_agent-WA_DEV start

Above is an example to start PRD agent.

For UAT and PRD

/etc/init.d/waae_agent-WA_UAT start

/etc/init.d/waae_agent-WA_PRD start

Once the agent service is started back, it should show ok status. Status can be verified using the command below
and status should reflect running.

# /etc/init.d/waae_agent-WA_DEV start

WAAE Agent (WA_DEV) [ OK ]

# /etc/init.d/waae_agent-WA_DEV status

WAAE Agent (WA_DEV) 15012 running

Windows:-

Check the Service of CA Workload Automation agent whether running or not ?

If the Service is not running, please start the service if privileged. else contact windows server team to start the
service.

1. Open Autosys CLI command window. CLI tool can be located at one of the below locations

F:\apps\autosys_tools\BarCapAutoSysCLI_v3.1\bin

C:\Program Files\Barclays Capital\AutoSys_Tools\bin

2. Connect to the instance that you want to update the job
Ex: Set AUTOSERV=P50

3. Prepare the JIL that should be deployed in a text file and save in , say (F:\autosys_JIL\
unauthorized_Jobs.txt)
Example JIL:
update_job: aut_c_copy_feed_to_server
machine: ldnpsr58383763.intranet. barcapint.com

4. Deploy the JIL using JIL.CMD command

JIL.cmd < F:\autosys_JIL\unauthorized_Jobs.txt
Contents
CLI Tools............................................................................................................................................................................3
How to use CLI Tools........................................................................................................................................................5
autorep.sh......................................................................................................................................................................5
Function.................................................................................................................................................................5
Syntax....................................................................................................................................................................5
Description............................................................................................................................................................5
Options..................................................................................................................................................................5
autostatus.sh.................................................................................................................................................................7
Function.................................................................................................................................................................7
Syntax....................................................................................................................................................................7
Description............................................................................................................................................................7
Options..................................................................................................................................................................7
sendevent.sh..................................................................................................................................................................7
Function.................................................................................................................................................................7
Syntax....................................................................................................................................................................7
Description............................................................................................................................................................8
Options..................................................................................................................................................................8
Examples................................................................................................................................................................9
job_depends.sh...........................................................................................................................................................11
Function...............................................................................................................................................................11
Syntax..................................................................................................................................................................11
Description..........................................................................................................................................................11
Options................................................................................................................................................................11
Jil.sh..............................................................................................................................................................................12
Function...............................................................................................................................................................12
Syntax..................................................................................................................................................................12
Description..........................................................................................................................................................12
Options................................................................................................................................................................12
Example...............................................................................................................................................................12
Support Contacts........................................................................................................................................................13
Page 2 of 13 Version 1.2 GSC EM Ops
CLI Tools
The CLI Tools basically consist of the following commands
AUTOENV.sh – Sets the environment strings
autorep.sh – Reports information about a job, jobs within boxes or the value of an AutoSys global variable or the
definitions of a real machine/virtual machine defined in AutoSys database
autostatus.sh – Reports the current status of a specific job or the value of an AutoSys global variable
sendevent.sh – Sends events to AutoSys for a variety of purposes, including starting or stopping jobs, putting the jobs
on hold and set AutoSys global variables
job_depends.sh – Reports information about the dependencies and conditions of the job
jil.sh – For inserting/modifying/deleting jobs

These commands can be executed from the Unix command prompt by any authorised user. To authorise a user, please raise a
request.
How to raise request for access to an Autosys code?
1. Click http://request/FormAction.do?method=submitProduct&type=emptyForm&ID=A-1299186607.
2. Autosys code to which the Access is requested *: Give the first three letter of the job which you want/remove access
3. Add or Remove Access *: Select add to get access (or) remove to remove the access
4. Name of the Service (as per HPSC) *: Use http://autosys45web.barcapint.com/cgi-bin/autosys_code/index.cgi link to find
out the service.
Select the appcode and click show details in the right hand side of the "AutoSys codes"
5. Component ID / Message Group (as per HPSC) *: Use http://autosys45web.barcapint.com/cgi-bin/autosys_code/index.cgi
link to find out the service.
Select the appcode and click show details in the right hand side of the "Autosys codes"
6. New or existing Autosys application? *: Select existing for existing app code else new.
7. Type of ID that needs access *: Select intranet if you need access to your intranet else selects UNIX.
8. Intranet IDs to which the Citrix and CLI access is required *: Provide your id which you need access.
. Instances to which the Access is required *: Select the instance which you require access and click the => arrow button
Note:
LP4 - Only for TDB jobs.
LP2 - If there is no jobs exist in LP2 for the requested Autosys code, then you need to get approval from Andy Peck/Raymond
Mercurio
LP1 - No new app codes allowed in LP1.
10. Business Justification *: Provide the business justification.
11. Click ‘add to chart’ then click ‘proceed to check out’ and click ‘submit card’
You can download the AutoSys 4.5 CLI tools for Solaris/Linux from the following links and upload to the server in binary
format.
Use tar –xvf <file name> to untar the file.
Set the directory in the PATH variable else run the with prefix ./ Ex: ./autorep.sh
AutoSys 4.5 CLI Tools for Solaris
http://sharepoint/sites/Autosys/AutoSys%20Documents/BarCapAutoSysCLI_v3.1.sol.tar
AutoSys 4.5 CLI Tools for Linux
http://sharepoint/sites/Autosys/AutoSys%20Documents/BarCapAutoSysCLI_v3.1.lin.tar

How to use CLI Tools

These commands can be executed from the unix command prompt using options and arguments to specify exactly
what you want them to do. You can also create scripts which wrap around these commands to avoid remembering
the exact options and arguments.
Note:
 Don’t place any file under CLI tool bin directory

Don’t place user files under CLI tool bin directory

The first step is to set the AUTOSERV variable in the CLI tool.
Ex: set AUTOSERV=LP1
set AUTOSERV=LP0

autorep.sh
Function
The autorep.sh reports information about a job, jobs within boxes or the value of an AutoSys global variable

Syntax
autorep.sh {-J job_name | -G global_name} [-s | -d | -q] [-r run_num] [-t]

Description
The autorep.sh lists variety of information about jobs and global variables currently defined in the AutoSys
Database. You can use it to list a summary of all currently defined jobs. This serves as a problem tracking tool by
listing all relevant event information for the last run of any given job, or a specified job run. You can also use it to
extract job definitions in JIL script format. When listing nested jobs, subordinate jobs are indented to illustrate the
hierarchy.

Options
-J job_name
This indicates that a Job Report is desired. Job_name specifies the name of the job on which to report. Any valid
AutoSys job name may be specified. The “%” character may be used in the job name as a wildcard (e.g., asm% will
select all jobs starting with the string “asm”).
-G global_name
This indicates that a global variable report is desired, listing the variable name, value and the last modification date.
Any valid global variable name which is already set using the sendevent.sh command may be specified. In the
specification you can use ALL or a wildcard can be specified using the “%” character
-s
This indicates that a Summary Report is desired. This is the default option. For a Job Report, the following
information is provided: Start date/time, End date/time, Current Status, Run Number, and Priority. You can request
a report on a specific job run with the -r option. If the –r option is omitted; the most current job run is used. To see
the previous runs, use –r -1, -r -2, -r -3 etc,
-d
This indicates that a Detail Report is desired. For a Job Report, all events from the last run of the requested job will
be listed. For each event, the following data is provided: Status, Date/Time, Try Number, Event State (whether the
event has been processed by the Event Processor yet), Process Date/Time, and the Machine on which the job was
run. Also specifies if a job was run with an override and lists the override number.
-q
Indicates a Query Report is desired, providing the current job or machine definition, in JIL format, as it
exists in the AutoSys database.
-r run_num
Indicates a report is desired for a specific job run (run_num). This option can only be used with the -s and -
d options. If this option is omitted, or run_num is zero, the most current job run is reported. A minus sign (-) can be
used before the run_num value to indicate a relative counter for a past job run, relative to the current run number.
For example, the option -r -2 would generate a report for the job run two runs back.
 -t
Requests that the time zone, if one is specified in the job definition appear in the report. If requested, the
time zone will appear in parentheses beneath the job name and the Time column of the report will be based on the
specified time zone.

autostatus.sh
Function
The autostatus.sh reports the current status of a specific job, or the value of an AutoSys Global variable.

Syntax
autostatus.sh {-J job_name | -G global_name}

Description
The autostatus.sh writes the current status of the specified job or the value of a global variable to standard output.
This is useful in two circumstances:
1. when an application needs to know the status of another job
2. when complex starting conditions are required that are not possible to be specified using the job definition

Options
-J job_name
This specifies the name of the job whose status needs to be determined. The current status is returned to
standard output.
-G global_name
This specifies the name of a global variable that has been set using the sendevent.sh command or the Send
Event dialog. The value of the global variable is returned to standard output.

sendevent.sh
Function
The sendevent.sh sends events to AutoSys for a variety of purposes, including starting or stopping jobs, putting a
job on hold and to set AutoSys global variables.

Syntax
sendevent.sh -E event [-J job_name] [-s status] [-C comment] [-P priority] [-G "global_name=value"]

Description
The sendevent.sh command is the only method of externally sending an event for such purposes as force starting or
killing a job. It can also be used to place the job ON_HOLD or ON_ICE, set the global variable and change the job
status.

Options
-E event
This specifies the event to be sent. This option is required. Any one of the following events may be
specified:
STARTJOB
 Start the job specified in -J job_name if the starting conditions are satisfied. A STARTJOB event ignores
time and date conditions, but it does consider other start conditions, such as dependencies on other jobs. This
command cannot be used on jobs in boxes. Jobs in boxes inherit the starting conditions of the box they are in; as a
result, they will be started when that box is started.
KILLJOB
Kill the job specified in -J job_name. The action depends on one of the following job types:
Command Jobs
This kills the process that is currently running and all the processes that it has spawned; i.e., the process
group. It will not kill orphan processes. It sends a signal to the process, waits five seconds, then sends a second
signal, if the process is still there.
Box Jobs
This changes the status to TERMINATED. No more jobs within the box will be started. Jobs that are
already running will continue to run to completion.
File Watcher Jobs
Kills the file watcher job and changes the status to TERMINATED.
FORCE_STARTJOB
This will start the job specified in -J job_name, regardless of whether the starting conditions are satisfied.
Because multiple instances of the same job could be started using this command, we recommended you use the
FORCE_STARTJOB event only in extreme situations.
If a job fails inside a box and you fix the problem manually, use FORCE_STARTJOB to rerun the job.
JOB_ON_HOLD
This puts the job specified in -J job_name “On Hold”. When a job is “On Hold”, it will not be started, and
downstream dependent jobs will not run. A box cannot successfully complete if a job within it is ON_HOLD. If the
job is already STARTING or RUNNING, you cannot put it ON_HOLD.
JOB_OFF_HOLD
This will take the job specified in -J job_name “Off Hold.” If the starting conditions are met, the job will be
started.
CHANGE_STATUS
This forces a change in the status of the job specified in -J job_name. Ordinarily this should not be used,
since AutoSys manages job state changes internally. If this option is selected, the -s status option must also be
selected.
When you send a CHANGE_STATUS event, you are changing the status of the job in the database; this
event does not affect the current running of the job. That is, if you change the status to running, the status is
changed in the database but the job is not run. You will have to change the status to a termination state before the
job can be run again.
SET_GLOBAL
This sets an AutoSys global variable. This event is sent with a high priority so the Event Processor will
process the variable before it is referenced by any jobs at runtime. The -G ”global_name=value” option must be used
with this event.
-J job_name
This 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.
-s status
This specifies the status to which the job specified in -J job_name should be changed. This option is used
only when the specified event is CHANGE_STATUS, which requires this option. These are the valid statuses:
RUNNING, STARTING, SUCCESS, FAILURE, INACTIVE, and TERMINATED.
Important: Please note that a job in RUNNING state should not be put to SUCCESS state directly without first
killing it.
-C comment
 This specifies a textual comment that is to be attached to this event for, documentation purposes only. The
text string can be up to 255 characters, entered as a single line. If the text string contains spaces, the entire string
must be enclosed in double quotes.
-P priority
This specifies the priority to be assigned to the event being sent. The value may be from 1 to 1000, with 1
being the highest priority and 1000 the lowest. The default value is 10. Assign a high priority if the event must be
processed immediately
-G "global_name=value"
This specifies the name and value of a global variable when a SET_GLOBAL event is sent. The global_name
and the value can each be a maximum of 30 characters (leading and trailing spaces in the value are ignored). Once a
global variable is set, it can be referenced by jobs at runtime

Examples
1. To start a job named “test_install” that has no starting conditions (and therefore must be started manually),
enter this:

sendevent.sh –P 1 -E STARTJOB -J app_test_install

To force a job to start named “wait_job”, which is waiting on the completion of another job, and explain the
reasons for your action, enter this:

sendevent.sh –P 1 -E FORCE_STARTJOB -C "tired of waiting,forced it" -J app_wait_job

To change the status of a job called “ready_to_run” to ON_HOLD to prevent its execution, and to assign the
sendevent.sh command a high priority so it will be sent immediately, enter this:
sendevent.sh –P 1 -E JOB_ON_HOLD -J app_ready_to_run
When you want the above job to run, enter this:
sendevent.sh –P 1 -E JOB_OFF_HOLD -J app_ready_to_run
To kill a job named “wrong_job” which is running enter this:
sendevent.sh –P 1 -E KILLJOB -J app_wrong_job
To set a global variable named “today” having a value of “12/27/2005”, enter this:
sendevent.sh -E SET_GLOBAL -G "APP_today=12/27/2005"
To delete the global variable named “today”, enter this:
sendevent.sh -E SET_GLOBAL -G "APP_today=DELETE"

7. To Change the status of the app_ready_to_run job to FAILURE sendevent.sh -P 1 -E CHANGE_STATUS -s

FAILURE –J app_ready_to_run
8. To change the status of the app_ready_to_run job to INACTIVE
sendevent.sh -P 1 -E CHANGE_STATUS -s INACTIVE –J app_ready_to_run
9. To put the app_ready_to_run job on ice.
sendevent.sh -P 1 -E JOB_ON_ICE –J app_ready_to_run
10. To take the app_ready_to_run job off ice.
sendevent.sh -P 1 -E JOB_OFF_ICE –J app_ready_to_run

job_depends.sh
Function
This command reports information about the dependencies and conditions of a job.

Syntax
job_depends.sh [-c | -t] [-J job_name]
Description
job_depends.sh provides detailed reports about the dependencies and conditions of a job. This command can be
used to determine the current state of a job, its job dependencies, and (for boxes) nested hierarchies as specified in
the job definition, and a report of what jobs will run during a given period of time.

Options
-c
This gives the current Condition Status and it prints out the current state of a job and the names of any jobs
that are dependent on this job.
-t
This gives the time Dependencies and it prints out the starting conditions for a job; however, the top level
of jobs (or boxes) that are reported are limited to those that will start within the time period specified by the job or
box’s date conditions.
-J job_name
This indicates that a Job Report is desired. Job_name specifies the name of the job on which to report. Any valid
AutoSys job name may be specified. The “%” character may be used in the job name as a wildcard (e.g., asm% will
select all jobs starting with the string “asm”).

Jil.sh
Function
This command runs the Job Information Language (JIL) processor to add, update and delete Autosys jobs. It can
also be used to insert one-time job override definitions.

Syntax
Jil.sh < jil_file

Description
The Jil.sh is the language processor for the AutoSys Job Information Language (JIL). Using this, you can define
and update jobs. The Jil.sh can be used in the following ways:
. Automatically submit job definitions to the AutoSys database – redirect a JIL script to the Jil.sh. for ex:
Jil.sh < newjil.jil
. Interactively submit job definitions to the AutoSys database – issue the Jil.sh command at the command
line and enter the JIL statements after that. To exit the interactive mode, press <Control+z>.

A jil file contains a sub-command such as insert_job and a set of Action

attributes for that job, in a specific format. The following JIL sub-
commands are used to create, update, delete or override a job
definition. Sub-command

insert_job Add a new job to AutoSys

Update_job Update fields on an existing job
delete_job Delete the job from AutoSys
delete_box Delete the box job and recursively delete all the
jobs contained in the box
Override_job Insert overrides on indicated job attributes for the
next run for the job