~

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 Crontab is a inbuilt feature in UNIX systems
Automation) is a centralized job management used to schedule and run scripts/commands.
tool.

Help to run thousands of jobs at time in Jobs can be triggered only in UNIX systems.
different 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 No integration with database.

integration 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
application in CA workload automation and manage jobs with greater security as EEM.
provides 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:
1. Automatically submit job definitions to the AutoSys database – redirect a JIL script to the Jil.sh.
for ex: Jil.sh < newjil.jil
2. 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