Autosys commands

Monday, January 13, 2014

Aotosys commands: autorep, sendevent

AUTOREP Command :

(autorep lists a variety of information about jobs, machines, and global variables currently defined in the AutoSys database.)


$autorep -J Nightly_Download

Job Name   Last Start   Last End   ST   RunPri/Xit
________________ _____________________________________ _________
Nightly_Download   11/10/1997   17:0011/10/1997   17:52SU     101/1
Watch_4_file 11/10/1997 17:0011/10/1997 17:13SU 101/1
filter_data 11/10/1997 17:13 11/10/1997 17:24SU 101/1
update_DBMS 11/10/1997 17:24 11/10/1997 17:52SU 101/1

autorep -J Nightly_Download -d

Job Name Last Start Last End ST Run Pri/Xit
________________ ____________________________________________________
Nightly_Download 11/10/1997 17:00 11/10/1997 17:52SU 101/1
Status/[Event] Time Ntry ES ProcessTime Machine
-------------- -------------------------------------------------------
RUNNING 11/10/1997 17:00:12 1 PD 11/10/1997 17:00:17
SUCCESS 11/10/1997 17:52:31 1 PD 11/10/1997 17:52:32
Watch_4_file 11/10/1997 17:00 11/10/1997 17:13 SU 101/1
Status/[Event] Time Ntry ES ProcessTime Machine
-------------- -------------------------------------------------------
STARTING 11/10/1997 17:00:13 1 PD 11/10/1997 17:00:19
RUNNING 11/10/1997 17:00:19 1 PD 11/10/1997 17:00:29 gateway
SUCCESS 11/10/1997 17:13:22 1 PD 11/10/1997 17:13:31
filter_data 11/10/1997 17:13 11/10/1997 17:24 SU 101/1
Status/[Event] Time Ntry ES ProcessTime Machine
-------------- -------------------------------------------------------
STARTING 11/10/1997 17:13:32 1 PD 11/10/1997 17:13:34 gateway
RUNNING 11/10/1997 17:13:38 1 PD 11/10/1997 17:13:45 gateway
SUCCESS 11/10/1997 17:24:23 1 PD 11/10/1997 17:24:30
update_DBMS 11/10/1997 17:24 11/10/1997 17:52 SU 101/1
Status/[Event] Time Ntry ES ProcessTime Machine
-------------- -------------------------------------------------------
STARTING 11/10/1997 17:24:16 1 PD 11/10/1997 17:24:22 gateway
RUNNING 11/10/1997 17:24:20 1 PD 11/10/1997 17:24:29 gateway
SUCCESS 11/10/1997 17:52:23 1 PD 11/10/1997 17:52:31

autorep -J RunData -d -r -1

(detailed report for one run back)


Job Name Last Start Last End ST Run Pri/Xit
_____________ ________________________________________________________
RunData 08/15/1997 12:14 08/15/1997 12:15 FA 2565/11
Status/[Event] Time Ntry ES ProcessTime Machine
-------------- -----------------------------------------------------
STARTING 08/15/1997 12:14:56 1 PD 08/15/1997 12:15:00 venice
RUNNING 08/15/1997 12:14:58 1 PD 08/15/1997 12:15:05 venice
FAILURE 08/15/1997 12:15:00 1 PD 08/15/1997 12:15:05
[*** ALARM ***]
JOBFAILURE 08/15/1997 12:15:04 1 PD 08/15/1997 12:15:10 venice
[STARTJOB] 08/15/1997 12:15:38 0 PD 08/15/1997 12:15:46

autorep -M ALL

(lists all machines defined on the data-server)

Machine Name Max Load Current LoadFactor O/S
_______________ ________ __________________ _____
london 100 0 1.00 Unix
berlin 90 0 0.90 NT
v_italy.rome 0 0 0.00 Unix
v_italy.venice 0 0 0.00 Unix
v_france.paris 100 0 1.00 NT
v_france.cannes 75 0 1.00 NT

autorep -J RunData -o 0

(override report, showing the current one-time job override in effect for the job)

/* -------------------- over -------------------- */
override_job: RunData
/* Over-Ride #2 Set by User: roger@venice on [07/28/1997 16:13:59] */
/* Over-Ride CURRENTLY IN EFFECT.*/
command: /bin/rundata2

autorep -J RunData -o 1


(showing the first one-time job override for the job)

/* -------------------- over -------------------- */
override_job: RunData
/* Over-Ride #1 Set by User: roger@venice on [07/25/1997 18:23:45] */
/* Was RUN on run_num=175, Started on: 07/25 18:24:01 */
command: /bin/rundata1

autorep -G DAY

Wednesday

autorep -G ALL

Global Name Value Last Changed
------------ ------------ -------------------
DAY Wednesday 11/12/1997 12:18:27
AUDIT_DIR /usr/audit11/12 /1997 12:41:00
DINNER_TIME 18:30 11/12/1997 12:40:00
MAX_VAL 2048 11/12/1997 12:30:24

autorep -J Box3 -s -L 2

(summary report on the top two levels of boxes in the job named “Box3”)

autorep -J MyJob -d -t

(include the time zone specification in a detailed report for the last run of the job named “MyJob”)

Job Name Last Start Last End ST Run Pri/Xit
_____________________________ _________________ _______ _____ _______
MyJob 12/10/1997 17:30 12/10/1997 17:30 SU 102/1
(Chicago)
Status/[Event] Time Ntry ES ProcessTime Machine
-----------------------------------------------------------------------------
STARTING 12/10/1997 17:30:05 1 PD 12/10/1997 16:30:13 localhost
RUNNING 12/10/1997 17:30:08 1 PD 12/10/1997 16:30:13 localhost
SUCCESS 12/10/1997 17:30:10 1 PD 12/10/1997 16:30:13
[STARTJOB] 12/10/1997 17:30:00 0 UP
<Event was Scheduled based on Job Definition.>

autorep -J ALL -q > dump_file

The output of this command is formatted exactly as a JIL job
definition script, like this:

insert_job: test_job
job_type: c
command: sleep 60
machine: juno
#owner: jerry@jupiter
permission: gx,ge,wx
alarm_if_fail: 1

You can save this file as a backup of job definitions, or you can use a
text editor to quickly edit the job definitions. To re-load the job
definitions into the AutoSys database, using the following jil
command:

jil < dump_file

SENDEVENT

(Sends 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.)


sendevent -J test_install -E STARTJOB

To start a job named “test_install” that has no starting conditions (and therefore must be started manually)


sendevent -J wait_job -E FORCE_STARTJOB -C "tired of waiting,forced it"

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.


sendevent -J ready_to_run -E JOB_ON_HOLD -P 1

To change the status of a job called “ready_to_run” to ON_HOLD to prevent its execution, and to assign the sendevent command a high priority so it will be sent immediately,


sendevent -J ready_to_run -E JOB_OFF_HOLD

When you want the above job to run, enter this


sendevent -J lock_out -E JOB_ON_HOLD -T "11/08/1997 11:00"
sendevent -J lock_out -E JOB_OFF_HOLD -T "11/08/1997 14:00"

To prevent a job called “lock_out” from running between the hours of 11:00 a.m. and 2:00 p.m., a pair of sendevent commands could be used to place it on hold during that time.


sendevent -E COMMENT -C "have not received EOD files - an hour late again"

write a comment into the Event Processor log file


sendevent -E STOP_DEMON -T "11/09/1997 02:30" -C "stopped for upgrade"

To stop the Event Processor at 2:30 a.m. on November 9, 1997 (it is always a good idea to attach a comment to this event)


sendevent -J resource_hog -E CHANGE_PRIORITY -q 10 -M 5

To change a job called “resource_hog” to a lower priority (it is currently at 1 and is not yet running), and to only issue the sendevent command 5 times, rather than letting it try indefinitely. command will change the job queue priority only for the next run of the job.


sendevent -J wrong_job -E KILLJOB -S PRD

To kill a job named “wrong_job” which is running on another AutoSys instance called “PRD”,


sendevent -E SET_GLOBAL -G "today=12/25/1997"

To set a global variable named “today” having a value of “12/25/1997”,


sendevent -E SET_GLOBAL -G "today=DELETE"

To delete the global variable named “today”,


sendevent -E SEND_SIGNAL -J RunData -k 1

To send the Unix signal number 1 to a job named “RunData”,


sendevent -E JOB_OFF_HOLD -J RunData -u

To cancel all unprocessed JOB_OFF_HOLD events for a job named “RunData”,


Sunday, January 05, 2014

Checking System Status(Autosys command Examples)

autoflags:

 Prints information about AutoSys and the system configuration.

options:-
 -a
Displays all autoflags information to standard output.
-i
Displays the AutoSys tape ID number to standard output.
-o
Displays the operating system to standard output.
-d
Displays the database type to standard output, either SYB for Sybase
or ORA for Oracle.
-v
Displays the AutoSys version number to standard output.
-r
Displays the AutoSys release number to standard output.
-h
Displays the host-id to standard output to standard output.
-n
Displays the host-name to standard output to standard output.

Example:

autoflags -a
3 AIX SYB 3.4 0 c0a9e38d venice



autoping :

  • Verifies that the server and client machines are properly configured and are communicating successfully.
  • It also checks and verifies that the Remote Agent and the Remote Agent’s database connection are functioning correctly.
  • When autoping is executed, the server (the machine from which autoping
    is issued) establishes a connection with the client machine, which starts
    a Remote Agent on that machine, and the server waits for the Remote
    Agent to respond. If successful, the following message will be displayed
    on standard output at the server:
    AutoPinging Machine[machine]
    AutoPing WAS SUCCESSFUL! 
 


Saturday, January 04, 2014

Autosys commands (Brief description)

Task                                     Command 
                                      

Accessing Sybase                    xql 
Checking System Status          autoflags 
                                            autoping 
                                            autosyslog 
                                            chase 
                                               chk_auto_up 
Converting cron to JIL             cron2jil 
Defining AutoSys Jobs
or Machines                           jil 


Defining Calendars                 autocal_asc 
                                            autocal
Installing and
Managing License Keys           gatekeeper

Maintaining Databases           archive_events 
                                           clean_files 
                                              dbstatistics 
Managing Security                 autosys_secure 
Monitoring Jobs                     autocons 
Recording Sounds                  record_sounds 
Reporting Job
Dependencies and
Conditions                             job_depends 

Reporting Job Status              autorep 
                                              autostatus 
                                           monbro 
Starting AutoSys                    eventor 
Stopping AutoSys                  sendevent 



























 

Job Information Language (about jil script)

  • JIL is a specification language. 
  • It has its own syntax.
  • It is used to describe when, where and how 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.
  • In this case, 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.    













  

Thursday, December 05, 2013

QA



I need to know the list of autosys job that run between given time.

I have the following command.

Code:
job_depends -t -J abc% -F  "12/25/2010 03:00" -T  "12/26/2010 05:00"

Above command will give the list of job that run between time 3 AM and 5 AM.

But the it gives me in random order how to order it either ASC or DESC order?

Basic of AutoSys

Qs : What is Autosys ?

Unicenter AutoSys JM is an automated job control system for scheduling, monitoring, and reporting. These jobs can reside on any Unicenter AutoSys JM -configured machine that is attached to a network.

These jobs can be a UNIX script, java program or any other program which can be invoked from shell. Before starting we assume that user has already setup an AutoSys environment.

This environment consists of autosys server and autosys client.


Qs: What are the sysetm components in Autosys?

 

AutoSys System components:

1. Event server 
2. Event processor
3. Remote agent

 

Event Server

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

 

Event Processor

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

 

Remote Agent

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

 

Basic functionality of AutoSys 

Below is the diagram which explains the basic functionality, please check the explanation.











 

 

 

 

 

 

 

Explanation

  1. The event processor scans the event server for the next event to process. If no event is ready, the event processor scans again in five seconds.
  2. The event processor reads from the event server that an event is ready. If the event is a STARTJOB event, the job definition and attributes are retrieved from the Event Server, including the command and the pointer (full path name on the client machine) to the profile file to be used for the job. In addition, for jobs running on Windows machines, the event processor retrieves from the database the user IDs and passwords required to run the job on the client machine.
  3. The event processor processes the event. If the event is a STARTJOB, the event processor attempts to establish a connection with the remote agent on the client machine, and passes the job attributes to the client machine.
  4. The event processor sends a CHANGE_STATUS event marking in the event server that the job is in STARTING state.
  5. 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 user IDs and passwords passed to it from the event processor.
  6. 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.
  7. The remote agent starts a process and executes the command in the job definition.
  8. The remote agent issues a CHANGE_STATUS event marking in the event server that the job is in RUNNING state.
  9. The client job process runs to completion, then returns an exit code to the remote agent and quits.

 

Qs : In how many ways we can define Autosys jobs?



Defining autosys job

There are various parameters to define autosys job. Starting from profile, timezone, start time, starting condition and so on.

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.

In this tutorial we will use JIL language to create autosys jobs.

JIL stands for Job Information Language. Using this you can instruct autosys to save job definitions. This information saved in autosys database. You can also create a jil file which contains job definition. You can then pass this jil file to autosys.


Qs: What are the job attributes and their JIL keyword in Autosys? Give some examples.


Essential attributes for defining job:

1. Job Name

JIL Keyword : insert_job. Name used to identify the job.

2. Job Type

a. JIL Keyword : job_type. The job type is one of job types: command (c), file watcher (f) or box (b).

3. Owner

a. JIL Keyword : owner

The job owner specifies whose user ID the command will be run under on the client machine. This attribute is automatically set to the user who invoked jil or the GUI to define the job, and cannot be changed except by the edit superuser.

4. command: The command attribute can be the name of any command, executable, UNIX shell script or batch file, and its arguments.

5. machine: This attribute specifies the client machine on which the command should be run.

6. date_condition: If the date_condition is set to 1 (True), which specifies there are date, time, or both, conditions required for starting the job.

7. days_of_week: The days of the week attribute specifies the days on which the job should be run. Starting 2 letters for the day's name are used as the value. we can use 'all' if job is going to run everyday.

8. start_times: Give the time in 24 hours format when job is going to start running.

9. description: Give some job information as comment.

10. std_out_file: it is a standard output log where you can save the job run log.

11. std_err_file: it is a standard error log where you can save the run time error log.

12. alarm_if_fail: if this attribute is set with value 1, user will be notified when job fails.

 

Example :


insert_job: uat_lmc_live_rate_Dly                  job_type: c
command: /apps/ss/userprojects/lmc/live_rate.sh
machine: cri_web_job_queue
owner: citwl@smccuatcriwa06
permission: gx,wx,mx 
date_conditions: 1
days_of_week: mo,tu,we,th,fr 
start_times: "22:00"
description: "Live Rate Job"
std_out_file: /local/ss/cit/userprojects/log/lmc/lmc_liverate.stdout 
std_err_file: /local/ss/cit/userprojects/log/lmc/lmc_liverate.stderr 
alarm_if_fail: 1


Qs: How to add job definition to JIL library? How to schedule jobs in Autosys?


Job definition using JIL code as given above and
the below command will add “echoJob” job to autosys databse.


jil < jobname.jil


Qs: What are the differnent job Status in Autosys ?

 

STATUS on output screen 

(abbreviated with starting 2 letters)

ACTUAL STATUS               

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












Autosys Job Management



Autosys Job Management for UNIX


This guide will be helpfull in giving basic idea about what autosys is, defining jobs to AutoSys, monitoring and managing jobs.


Introduction to Autosys:  

  • AutoSys is an automated job control system for scheduling, monitoring, and reporting. 
  •  These jobs can reside on any AutoSys-configured machine that is attached to a network.
  • An AutoSys job is any single command, executable, script, or Windows batch file. 
  • Each AutoSys job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run.

Defining Jobs :


There are the two methods you can use to create job definitions:


  • Using the AutoSys Graphical User Interface (GUI).
  • Using the AutoSys Job Information Language (JIL) through a command-line interface.


Autosys Jobs: 

There are three types of jobs: 

  • command job
  • file watcher job
  • box job

As their names imply, command jobs execute commands 

Box jobs are containers that hold other jobs (including other boxes), 

File watcher jobs watch for the arrival of a specified file. 

In the AutoSys environment, the box job (or box) is a container of other jobs. A box job can be used to organize and control process flow. The box itself performs no actions, although it can trigger other jobs to run. An important feature of this type of job is that boxes can be put inside of other boxes.


Default Box Job Behavior:
 

Some important rules to remember about boxes are
  1. Jobs run only once per box execution.
  2. Jobs in a box will start only if the box itself is running.
  3. As long as any job in a box is running, the box remains in RUNNING state; the box cannot complete until all jobs have run.
  4. By default, a box will return a status of SUCCESS only when all the jobs in the box have run and the status of all the jobs is "success".
  5. By default, a box will return a status of FAILURE only when all jobs in the box have run and the status of one or more of the jobs is "failure".
  6. Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE.
  7. Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE.


Job States and Status :


  • AutoSys keeps track of the current state, or status, of every job. 
  • The value of a job’s status is used to determine when to start other jobs that are dependent on the job. 
  • The job status is displayed in the job report generated by the autorep command, and in the job report you can view in the Job Activity Console. 
 
Following are the status of Autosys jobs:

  1. INACTIVE : The job has not yet been processed. Either the job has never been run, or its status was intentionally altered to “turn off” its previous completion status 
  2. ACTIVATED :The top-level box that this job is in is now in the RUNNING state, but the job itself has not started yet.
  3. STARTING : The event processor has initiated the start job procedure with the Remote Agent.
  4. RUNNING : The job is running. If the job is a box job, this value simply means that the jobs within the box may be started (other conditions permitting). If it is a command or file watcher job, the value means that the process is actually running on the remote machine.
  5. SUCCESS : The job exited with an exit code equal to or less than the “maximum exit code for success.” By default, only the exit code “0” is interpreted as “success.” If the job is a box job, this value means that all the jobs within the box have finished with the status SUCCESS (the default), or the “Exit Condition for Box Success” evaluated to true
  6. FAILURE : The job exited with an exit code greater than the “maximum exit code for success.” By default, any number greater than zero is interpreted as “failure.” AutoSys issues an alarm if a job fails
  7. TERMINATED : The job terminated while in the RUNNING state. A job can be terminated if a user sends a KILLJOB event or if it was defined to terminate if the box it is in failed. If the job itself fails, it has a FAILURE status, not a TERMINATED status. A job may also be terminated if it has exceeded the maximum run time (term_run_time attribute, if one was specified for the job), or if it was killed from the command line through a UNIX kill command. AutoSys issues an alarm if a job is terminated.
  8. RESTART : The job was unable to start due to hardware or application problems, and has been scheduled to restart.
  9. QUE_WAIT : The job can logically run (that is, all the starting conditions have been met), but there are not enough machine resources available.
  10. ON_HOLD : This job is on hold and will not be run until it receives the JOB_OFF_HOLD event.
  11. ON_ICE : This job is removed from all conditions and logic, but is still defined to AutoSys. Operationally, this condition is like deactivating the job. It will remain on ice until it receives the JOB_OFF_ICE event.

Qs: What is the difference between
"on hold" and "on ice" ?

The difference between "on hold" and "on ice" is that when an "on hold" job is taken off hold, if its starting conditions are already satisfied, it will be scheduled to run, and it will run. 

On the other hand, if an "on ice" job is taken "off ice," it will not start, even if its starting conditions are already satisfied. This job will not run until its starting conditions reoccur.
 

The other major distinction is that jobs downstream from the job that is "on ice" will run as though the job succeeded. Whereas, all dependent jobs do not run when a job is on "on hold"—nothing downstream from this job will run.


Starting Parameters :


AutoSys determines whether to start or not to start a job based on the evaluation of the starting conditions (or starting parameters) defined for the job. 


These conditions can be one or more of the following:
  • Date and time scheduling parameters are met (it is or has passed the specified date and time).
  • Starting Conditions specified in the job definition evaluate to true.
  • For jobs in a box, the box must be in the RUNNING state.
  • The current status of the job is not ON_HOLD or ON_ICE.
Every time an event changes any of the above conditions, AutoSys finds all the jobs that may be affected by this change, and determines whether or not to start them. 

 
sample jil code / Writing jil code:

jil : Job information language
 

When using JIL to create a job definition, you enter the jil command to display the JIL prompt.

Runs the Job Information Language (JIL) processor to add, update, and delete AutoSys jobs, machines, monitors, and reports. Also used to insert one-time job override definitions.


-------------------------------------------------------------------------------------------------
/* ----------------- SAP_UAT_MU03_C ----------------- */
insert_job: SAP_UAT_MU03_C job_type: c

command: /local/SAP/processCheckUAT.sh
machine: MU03-UAT
owner: admin@MU03-UAT
permission: gx,wx,mx,me
days_of_week: all
start_times: "15:00, 14:00"
description: "Job used for Run testing of process"
alarm_if_fail: 1
max_exit_success: 1
-----------------------------------------------------------------------------------------
--------
 


The above example is a simple jil code of autosys which we have to write if we want any particular job to be through autosys. 

To Insert a new JIL code :
 

issue command "jil"
 

bash-3.00$ jiljil>>1>
 

"The following prompt will appear" copy paste the jil code u have made example of jil code below...........
 

At the end the "C" or "B" determines if the job is box job or child job.
 

if the jil is inserted properly successfull message will come if any errors are there the jil code contains some errors..
if successfull exit;
 

2. Other way is to create a temp file named temp.jil which contains jil code on autosys server: give command.

bash-3.00$ jil<>


Functional Listing of AutoSys Commands :


This section lists which AutoSys commands to use for specific tasks. All commands are for both Windows and UNIX, unless otherwise specified.
  • Accessing Sybase : xql
  • Checking System Status :
    • autoflags 
    • autoping
    • autosyslog
    • chase chk_auto_up
  • Converting cron to JIL (UNIX Only) : cron2jil
  • Defining AutoSys Jobs or Machines : jil
  • Defining Calendars : autocal, autocal_asc
  • Reporting Job Status :
    • autorep
    • autostatus
  • Starting AutoSys (UNIX Only) : eventor
  • Stopping AutoSys : sendevent


Using Autorep command:

Function:
 

Reports information about a job, jobs within boxes, machines, and machine status. Also reports information about job overrides and global variables.
 

Syntax:

autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r run_num]

autorep -J (job name)

This will display a list of jobs with complete details with box/jobname, last/latest run date & time, status, exit code, etc.
 

Viewing JIL code for any Autosys job

autorep -J (job name) -q

To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run command.

To obtain the information of previous runs

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

example : autorep -J (job name here) -r 1

would generate a report for the job run one runs back





/*-------------------------------------------------------------------------------------------------
Status Abbreviations
 

The following table lists the abbreviations used in the ST (status) column of the autorep report, and gives the status for each abbreviation.

AC - ACTIVATED
FA - FAILURE
IN - INACTIVE
OH - ON_HOLD
OI - ON_ICE
QU - QUE_WAIT
RE - RESTART
RU - RUNNING
ST - STARTING
SU - SUCCESS
TE - TERMINATED

-------------------------------------------------------------------------------------------------*/





sendevent commnd:

sendevents to AutoSys for a variety of purposes: 
  • including starting or stopping AutoSys jobs, 
  • stopping the Event processor, 
  • putting a job on hold. 
  • This command is also used to set AutoSys global variables or cancel a scheduled event.
sendevent is normally used with "-E" & "-J" option

 

-J job_name : 
  • Specifies the name of the job to which the specified event should be sent. 
  • This option is required for all events except STOP_DEMON, COMMENT, ALARM, or SET_GLOBAL
-E event : 

Specifies the event to be sent. This option is required if any one of the following events may be specified:
  • STARTJOB
  • KILLJOB
  • DELETEJOB
  • FORCE_STARTJOB
  • JOB_ON_ICE
  • JOB_OFF_ICE
  • JOB_ON_HOLD
  • JOB_OFF_HOLD
  • CHANGE_STATUS
  • STOP_DEMON
  • CHANGE_PRIORITY
  • COMMENT
  • ALARM
  • SET_GLOBAL
  • SEND_SIGNAL

Following are the example of sendevent command frequently used.

____________________________________________________________________

To start or force start a job manually using sendevent :

sendevent –E FORCE_STARTJOB -J "Job Name"

sendevent -E STARTJOB -J "Job Name"

To put jobs on OFF ICE or ON ICE :

sendevent -E OFF_ICE -J "Job Name"

sendevent -E ON_ICE -J "Job Name"
______________________________________________________________


autostatus command: 

Reports the current status of a specific job, or the value of an AutoSys global variable. 

Ex: autostatus -J job_name, -S instance