Autosys is a total job scheduling solution that allows you to define the event d ependencies time schedules alerts

etc making it a complete data center automatio n tool. An AutoSys job is any single command executable script or Windows batch file. Ea ch AutoSys job definition contains a variety of qualifying attributes including the conditions specifying when and where a job should be run. These jobs can be defined using any of the 2 methods either through the AutoSys Graphical User Interface (GUI) or using the AutoSys Job Information Language (JI L) through a command-line interface. How to create a job definition using JIL : 1.Submit your jil file to autosys database using the following command. jil< autosys_jilfile.jil This will transfer all your jil contents to autosys database. 2. Once the JIL file is successfully submitted to database run the job inside th at JIL using the sendeventcommand sendevent -j JOBNAME -E FORCE_STARTJOB 3. For checking the status of the autosys job run the following command. autorep -j JOBNAME -w AUTO SYS CHEAT SHEET AutoSys: UNIX Cd x: DB to to the "autouser" ($AUTOUSER) directory and "." (or source) the "ksh" file. E ". ./autosys.ksh.machine" After installing AutoSys, first make sure that the is up and running. Check the installation by running the command chk_auto_up verify connection to the DB and event processor.

Enter the KEYS through "gatekeeper", add keys Run the "autosys_secure" command to set the AutoSys Edit and Exec Super users (a nd also to enter NT users/passwords) Start the Event Processor by running the command "eventor" Shutdown AutoSys: "sendevent -E STOP_DEMON" To start the AutoSys GUI set your DISPLAY and run the command "autosc &". NT: Start AutoSys from start->programs->AutoSys-> administrator ->Graphical User Interface ->Command Prompt Command Line Commands: gatekeeper: Allows you to enter the License Keys which allow you to run AutoSys. eventor [-M machine_name] : Starts the event processor. autorep -J [ALL Job_name] [-q] [> file_name], -d (detail), -r (run number), -o (override), jil < file_na -G (global var report), -M -q for machine definitions . Ex: autorep -J job_name -d autorep -J job_name -d

autorep -J job_name -q vi file_name When you want a report Autorep -J job_name -r Autorep -J job_name -r

> file_name queries the DB & save job Dfn. Into a file of a box use the -L0 option -1 report on the job for the day -1 (prev day) -5 report on the job for last 5th run

sendevent -E STARTJOB -J job_name, sendevent -E FORCE_STARTJOB -J job_name, [JOB _ON_ICE, JOB_OFF_ICE, JOB_ON_HOLD, JOB_OFF_HOLD, SET_GLOBAL, STOP_DEMON. . . .] sendevent -E STOP_DEMON - to stop AutoSys (ex: sendevent -E SET_GLOBAL -G "var_name=/home/mydir" To set a variable in Auto sys) (ex: sendevent -E SET_GLOBAL -G "var_name=DELETE" To delete Autosys variable tha t is declared/set)] chk_auto_up: checks to see if event processor and the DB are both up. autoping -m machine: verify that both client & server are correctly configured. cron2jil -f cronfile [-d outdir] [-I incl_file] [-m machine] [-p prefix] jil To insert a job directly into the DB insert_job: job.id job_type: c machine: machine_name command: echo testing jil [go ;] (depending on the DB you are using) /* ----------------- template test.jil ----------------- */ insert_job: template job_type: c box_name: box1 command: <unix command i.e. ls -l> machine: localhost owner: $jil < test.jil Template example: /* ----------------- template ----------------- */ 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 max_exit_success: 2 chk_files: /tmp 2000 profile: /tmp/.profile job_load: 25 priority: 1 auto_delete: 12 autosyslog -e: same as tail -f autosys_log_file. This command must be run from t he machine where the server resides if used with the -e option. Else it can be u sed with the -J option to see that job's run log. job_depends: -[c d t] -J jobname [-F "mm/dd/yy time"] [-T "mm/dd/yy time"] (Note : It will only print out the first occurrence found) monbro -n monitor_name: Allows you to run from command line monitor/browser prog rams previously created using the monitor/browser GUI.exec superuser: AUTOSYS su peruser autocal_asc full_cal_name: prints, adds & deletes custom calendar definitions. autostatus: Reports the current status of a specific job, or the value of an Aut oSys global variable. Ex: autostatus -J job_name, -S instance autotimezone -l : Allows additions, deletions, and queries to the timezones tabl e (-l provides list). autotrack: Tracks & report changes to the AutoSys DB. Ex: autotrack -l 2 (level 2) [sets the tracking level] autotrack -U sys -v (user sys: verbose) To start us ing the autotrack utility type: autotrack -u to set tracking level 1 or 2. By de fault it is set to 0. Autotrack -l will list the current tracking level. Options -[J, U, m, F, T, and t] are to request reporting on a specific Job, User, machi ne, time window (-F -T), and event type (t). Type is used in conjunction w/other parameters. autotrack w/no arguments retrieves information an all events omitti ng detail. -v option is for verbose. autosys_secure: to change edit, exec superusers, change DB passwd, change remote authentication method. chase [-A E]: Makes sure that jobs claiming to be running in the client machine are running. The "-E" option restarts the job. archive_events: to archive events in the DB which are older than x days to prev DB from becoming full. clean_files: Deletes old remote agent log files. It does it by searching the DB for all machines which have had jobs started on them. autostatad: to get the status of a PeopleSoft job. You can define one of the use r definable buttons to view PeopleSoft job: Autocons*userButton1Label: Adapter S tatus User definable buttons: There are user definable buttons in the operator's conso le. How to configure:

Autocons*userButton1Command: /autosys/bin/autostatad -J $JOB -g & (which allows you to have a command button on the operator's console.) Dependencies: success (job) and s(job_b) failure(job_a) or f (job_b) notrunning (job) terminated(job) exitcode(job) > 5 and exitcode(job_b) != 10 value(global_name)=100 done(job) Hostscape: Schedule a job to run every x minutes & then go into forecasting. Mak e that job fail. Solid black line: Hostscape can communicate with the remote agent in the client machine. Solid red line: Hostscape can't communicate with the remote agent but it can com municate with the internet daemon (inetd) running on that machine.. Dashed red line: Hostscape can't communicate with the client machine at all. Cli ent is probably down. Accessing a variable name: $$GLOBAL_VAR_NAME (unless used in dependency conditio n with a job definition. If used in the "command" field, you must use the $$) Tunable Parameters: $AUTOUSER/config.ACE $AUTOUSER/autosys.ksh.xxx /etc/auto.profile /etc/inetd.conf /etc/services Notify.Ace: The alarms to notify on are: (There is an example in $AUTOSYS/install/data/Notify.Ace). DB_ROLLOVER DB_PROBLEM EP_HIGH_AVAILABILITY EP_ROLLOVER EP_SHUTDOWN Where to go to find the Errors: $AUTOUSER/out/event_demon.$AUTOSERV ($AUTOUSER/out/event_demon.ACE) Output from the job definition output & error files

/tmp files created for job_run at client machine $AUTOSYS/out/DBMaint.out for DB problems $SYBASE/install/errorlog_$DSQUERY when event server will not start. NT: AutoNuTc\lib/X11\app-defaults\xpert AutoSys Maintenance: DBMaint @$AUTOSYS/bin Once a day the Database goes into a maintenance cycle. Every day at 3:00am it ru ns a program called DBMaint. This is user configurable. The program runs DBstati stics which is found in $AUTOSYS/bin. app-defaults file: /usr/openwin/lib/app-defaults directory. Autocons, Xpert, etc .. ( or: /usr/lib/X11/app-defaults, /autosys/bin/X11/app-defaults) Environment file: /etc./auto.profile C programs: $AUTOSYS/code Where to change AutoSys screen fonts: /usr/openwin/lib/app-defaults Where to look for troubleshooting: Chapter 15 Summary of commands: Appendix C $AUTO_JOB_NAME: when naming a file dynamically using as prefix AutoSys's job nam e. $AUTORUN: unique identifier for the run of that job $AUTOPID: unique identifier for that job's run number (PID) $JOID: DB identifier for a job. To extract from the DB: select joid from job whe re job_name=" " Creating a Virtual Machine: insert_machine: virtual type: v /* default, not required */ machine: real_1 machine: real_2 max_load: 100 factor: 0.5 /* used to describe the relative processing power of a machine. Usua lly between 0.0-1.0*/ machine: real_2 max_load: 60 /* this is designed to limit the loading of a machine */ Load Balancing, Queuing, priorities: insert_job: test_load machine: localhost command: echo "Test load balancing" job_load: 50 priority: 1 /* this only affects queues */ Note: For 5.0 we will be using information from ServerVision's towards our load balancer which is composed of 26 categories such as i/o usage, disk usage, CPU u sage, etc. Testing: zql zql -U autosys -P autosys NOTES:

When a job is stuck in the starting condition this means that the event processo r communicated with the remote agent and passed all the information the remote a gent ran the job but was not able to communicate to the DB. Once testing is done with AutoSys one should change the default refresh interval for AutoSys. This i s so there is less querying to the DB. When AutoSys goes from dual mode to singl e mode, always run the autobcp command before bringing AutoSys back to dual mode /High Availability. Default behavior for stdout is to always appends. If you wan t to overwrite the file enter the following, no spaces: ">file.out" Box Logic Use boxes to group jobs with like scheduling parameters, not as means of groupin g jobs organizationally. For example, if you have a number of jobs that run dail y at 1:00 a.m., you could put all these jobs in a box and assigning a daily star t condition to the box. However, a variety of account processing jobs with diver se starting conditions should not be grouped in the same box. Default Box Job Behavior 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 bo x 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." Default SUCCESS is des cribed in Default Box Success and Box Failure on page 5-13. 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." Default FAILURE is described in Default Box Success and Box Failure on page 5-13. Unless otherwise specified, a box will run indefinitely until it reaches a statu s of SUCCESS or FAILURE. For a description of how to override this behavior, see Box Job Attributes and Terminators on page 5-6. Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE. When you Should Not Use a Box The fact that all jobs in a box change status when a box starts running has lead some to use boxes to implement "job cycle" behavior. Be aware that placing jobs in a box to achieve this end may bring with it undesired behavior due to the na ture of boxes. Avoid the temptation to put jobs in a box as a short cut for performing events ( such as ON_ICE or ON_HOLD) on a large number of jobs at once. You will most like ly find that the default behavior of boxes inhibits the expected execution of th e jobs you placed in the box. Likewise, you should not place jobs in a box solely because you want to run repo rts on all of them. When you run autorep on a box, you will get a report on the box and all the jobs in the box (unless you use the -L0 option). In addition, if you use wildcarding when specifying a job name, you could get duplicate entries in your report. For example, suppose you have a box named "acnt_box" containing three jobs named "acnt_job1", "acnt_job2", and "daily_rep". If you specify acnt % as the job name for the autorep report, the report will have an entry for the box "acnt_box" and an entry for each job in the box. Then autorep will continue searching for all job names matching the wildcard characters and, thus, will lis t "acnt_job1" and "acnt_job2" a second time. What Happens when a Box Runs

As soon as a box starts running, all the jobs in the box (including sub-boxes) c hange to status ACTIVATED, meaning they are eligible to run. (Because of this, j obs in boxes do not retain their statuses from previous box cycles.) Then each j ob is analyzed for additional starting conditions. All jobs with no additional s tarting conditions are started, without any implied ordering or prioritizing. Jo bs with additional starting conditions remain in the ACTIVATED state until those additional dependencies have been met. The box remains in the RUNNING state as long as there are activated or running jobs in the box. If a box is terminated before a job in it was able to start, the status of that job will change directly from ACTIVATED to INACTIVE. Note o Jobs in a box cannot start unless the box is running. However, once the j ob starts running, it will continue to run even if the box is later stopped for some reason. Time Conditions in a Box Each job in a box will run only once per box execution. Therefore, you should no t define more than one time attribute for any job in a box because the job will only run the first time. If you want to put a job in a box, but you also want it to run more than once, you must assign multiple start time conditions to the bo x itself, and define no time conditions for the job. Remember also that the box must be running before the job can start. Do not assign a start time for a job i n a box if the box will not be running at that time. If you do, the next time th e box starts the job will start immediately. The following example illustrates a scenario that would not work properly if pla ced in a box. "job_a" is defined to run repeatedly until it succeeds. "job_report" has one sta rting condition-the success of "job_a". How Job Status Changes Affect Box Status If a box that is not running contains a job that changes status, as a result of a FORCE_STARTJOB or CHANGE_STATUS event, the new job status could change the sta tus of its container box. A change of status of the box could trigger the start of downstream jobs that are dependent on the box. If a box contained only one job, and the job changed status, the box status woul d change. SAMPLE JOB /* ----------------- BW_CRD_SOD_BOX ----------------- */ insert_job: BW_CRD_SOD_BOX job_type: b machine: boxName owner: user@boxName permission: gx,ge,wx,we,mx,me date_conditions: 1 #run_calendar: lm_weedday #start_mins: 0,30 run_window: "01:00 - 05:00" alarm_if_fail: 1 /* 1----------------- BW_CRD_SOD_POLL_DB ----------------- */

# Polls DB and triggers SOD insert_job: BW_CRD_SOD_POLL_DB job_type: c command: /opt/bps/xmusern4/opt/bin/bwt-sod-scheduler.sh machine: boxName owner: user@boxName permission: gx,ge,wx,we,mx,me box_name: BW_CRD_SOD_BOX description: "BW_CRD_SOD_POLL_DB" std_out_file: /opt/logs/BW_CRD_SOD_POLL_DB_OUT.log std_err_file: /opt/logs/BW_CRD_SOD_POLL_DB_ERR.log alarm_if_fail: 1 /* 2----------------- BW_CRD_SOD_GEN_PORTIA_FILE ----------------- */ insert_job: BW_CRD_SOD_GEN_PORTIA_FILE job_type: c command: /opt/bin/bwt-portiaimport.sh machine: sunprod36 owner: user@boxName permission: gx,ge,wx,we,mx,me box_name: BW_CRD_SOD_BOX condition: s(BW_CRD_SOD_POLL_DB) description: "BW_CRD_SOD_GEN_PORTIA_FILE" std_out_file: /home/crd_user/BW_CRD_SOD_GEN_PORTIA_FILE_OUT.log std_err_file: /home/crd_user/BW_CRD_SOD_GEN_PORTIA_FILE_ERR.log max_run_alarm: 60 alarm_if_fail: 1 insert_job: BW_CRD_SOD_PORTIA_FUND_FW job_type: f machine: BoxName owner: user permission: gx,ge,wx,we,mx,me box_name: BW_CRD_SOD_BOX condition: s(BW_CRD_SOD_GEN_PORTIA_FILE) #date_conditions: 1 #run_calendar: lm_weekday #start_mins:0,5,10,15,20,25,30,35,40,45,50,55 #run_window: "9:00 - 23:00" description: "BW_CRD_SOD_PORTIA_FUND_FW" watch_file: E:\import\fileName.txt watch_interval: 2 watch_file_min_size: 100 alarm_if_fail: 1 Autosys is a job scheduling software like Control - M and cron with the help of autosys we can define the runtime day date week and which script or program needs to be run. The main advantage of using autosys w.r.t crontab is that it is has a Java front end too so a person do not need to be a Unix champ to create or change a job in autosys. the attributes of AUTOSYS : Job_name : script : owner: machine it has to run on :

day: date: week: error log : output log : alarm ************************************ Autosys Description % wildcard for autorep commands Status Commands autorep j pfiw9999% shows a brief job information for jobs starting with pfi w9999 autorep j pfiw9999 -d show detailed status history for job pfiw9999 autorep j pfiw% shows status of all jobs starting with pfiw Job Scheduling and other Information autorep j pfiw9999% -q show all job information for jobs starting with pfiw9999 Job Status for previous runs autorep j pfiw9999% -r -1 show brief job status for jobs starting with pfi w9999 one run backwards in time Job Dependency Information job_depends j pfiw9999 -c show job dependencies (starting conditions) and successors (dependent jobs) for pfiw9999 job_depends show scheduled starting job times Setting Status of Autosys Jobs To set a job to inactive sendevent E CHANGE_STATUS J <JOB_NAME> -i INACTIVE To set a job to success sendevent E CHANGE_STATUS J <JOB_NAME> -s SUCCESS Other Events To force start a job sendevent E FORCE_STARTJOB J <JOB_NAME> To put a job on hold sendevent E JOB_ON_HOLD J <JOB_NAME> To put a job on ice sendevent E JOB_ON_ICE J <JOB_NAME> To take a job off hold sendevent E JOB_OFF_HOLD J <JOB_NAME> To take a job off ice sendevent E JOB_OFF_ICE J <JOB_NAME> To kill a job sendevent E KILLJOB J <JOB_NAME> * When you set a job to SUCCESS or ON_ICE, the job depending on it may run ecause it is still set to run. * If a job is ON_HOLD or ON_ICE, it will not run until it is force started r set to inactive for a normal run. * When you want to stop a job, use the KILL command. Once the job has been ILLED, it can be marked ON-HOLD, or INACTIVE, or whatever supported status you ish to assign to it. ************************************** b o K w