Autosys Manual

UNICENTER AUTOSYS JM COMMANDS:

The list of commands used in autosys:

Autoflags: The autoflags option is used to show information about Unicenter Autosys JM and about its system configuration. The autoflags command command prints prints out the version version and release number, the databases databases being used, and the operat operating ing system system.. The autofl autoflags ags comman command d is also also used used to determ determine ine the proper  hostname and host ID for license generation. SYNTAX: Autoflags - Autoflags –a | -i | -o| -d | -v | -r | -h | -n | Autoflags –a : This command would display all autoflags information to standard output. Autoflags –i : This command would display the tape ID number to standard output. Autoflags –o: This command would display the operating system information to standard output. Autoflags –d : This command would display the database type output, SYS for Sybase or ORA for oracle. Autoflags –v : This command would display the version number to standard output. Autoflags –r : This command would display the release number to standard output Autoflags –h : This command would display the host id number to standard output Autoflags –n : This command would display the host name to standard output.

Autoping: The Autoping command verifies if the server and client machines are properly configured and communicating successfully. It also checks whether the Remote agent and the remote agents databa databases ses connec connectio tions ns are are functi functioni oning ng proper properly. ly. In case case of dual servers servers it checks checks both both the databases.

SYNTAX: Autoping –m All This command is used to Autoping the particular machine or all the machines mentioned in the database, The machine names are entered through the command insert_machine . The Autoping would give an error if the machine name is not found in the database. EX: > D:\Utils\CA\UNICEN~1.SAS>autoping D:\Utils\CA\UNICEN~1.SAS> autoping -m mdcas051

AutoPinging Machine [mdcas051] AutoPing WAS SUCCESSFUL! > D:\Utils\CA\UNICEN~1.SAS> autoping -m ALL  AutoPinging Machine Machine [MDCAS015]

AutoPing WAS SUCCESSFUL!  AutoPinging Machine [MDCAS017] AutoPing WAS SUCCESSFUL!  AutoPinging Machine [MDCAS019] AutoPing WAS SUCCESSFUL! . . . .  AutoPinging Machine [SSDBVS] AutoPing WAS SUCCESSFUL!  AutoPinging Machine [TTAS004] AutoPing WAS SUCCESSFUL!

Autorep: The autorep command lists a variety of information about the job, machines and the global variables that are defined in the databases. Autorep also serves as the problem tracking tool by listing out all the relevant event information for the last run of job. It is also used to get e xtract job definitions in JIL scripts format. SYNTAX:  Autorep {–j job_name | -M machine_name | -G global_name} {-s , -d, -q, -o , -u} Autorep –j This command indicates that a job report is desired . job_name specifies the name of the job on which to report. To report all jobs specify ALL . The % character may be used in the job name as a wildcard. Eg %box% will select all jobs containing the string box. Ex: D:\Utils\CA\UNICEN~1.SAS>autorep -j UOPS_WLYJOB_z_PUOP0TAX Job Name Last Start  ____________________________  _______ ___  UOPS_WLYJOB_z_PUOP0TAX

Last End ST Run Pri/Xit ____________________ ____________________

05/06/2007 05:34:00 05/06/2007 07:56:10 SU 1256298/1

__ 

Autorep –M This command is used to get the machine report. This gives the lists the machine’s max load, current load, and factor. To report for all the machines use ALL option. Ex: D:\Utils\CA\UNICEN~1.SAS>autorep -M TTMF001 Machine Name Max Load Current Load Factor O/S  _____________________________ __________ ______________ ______ ______  TTMF001

---

---

1.00 NT

Autorep – G This command is used to get the global variable reports. The command lists the variable name, value, and last modification date. To report all the global variables use ALL option. Ex: D:\Utils\CA\UnicenterAutoSysJM.SAS\autosys\bin>autorep -G UOPS_DAILY Global Name Value Last Changed ------------------------- ------------------------- -------------------UOPS_DAILY TRUE 05/10/2007 04:27:08

Autorep –j -s This command indicates that a summary report of the job is required. Ex: D:\Utils\CA\UNICEN~1.SAS>autorep -j HQN_INVENTORY_BOX -s Job Name Last Start  ____________________________  _______ ___ 

Last End ST Run Pri/Xit ____________________ ____________________

__ 

HQN_INVENTORY_BOX 05/10/2007 06:01:03 05/10/2007 06:03:20 SU 1261419/1 HQN_INVENTORY_BOX_PUOP873F_FTP... 05/10/2007 06:01:06 05/10/2007 06:01:20 SU 1261419/1 HQN_INVENTORY_BOX_PUOP873F_FTP... 05/10/2007 06:01:13 05/10/2007 06:01:16 SU 1261419/1 HQN_INVENTORY_BOX_PUOP873F 05/10/2007 1261419/1 HQN_INVENTORY_BOX_PUOP0873 05/10/2007 1261419/1

06:01:26 05/10/2007

06:01:48 SU

06:01:53 05/10/2007

06:03:16 SU

Autorep –j -d This command indicates that a detail report of the job is required. Ex: D:\Utils\CA\UNICEN~1.SAS>autorep -j PFPVI050 -d Job Name Last Start  ____________________________  _______ ___  PFPVI050

Last End ST Run Pri/Xit ____________________ ____________________

05/10/2007 05:05:58 05/10/2007 05:06:35 FA 1259917/1 100

Status/[Event] Time Ntry ES ProcessTime Machine -------------- --------------------- -- -- --------------------- ------STARTING 05/10/2007 05:05:55 1 PD 05/10/2007 05:05:58 snsprd RUNNING 05/10/2007 05:05:58 1 PD 05/10/2007 05:06:01 snsprd FAILURE 05/10/2007 05:06:35 1 PD 05/10/2007 05:06:38 [*** ALARM ***] JOBFAILURE 05/10/2007 05:06:37 1 PD 05/10/2007 05:06:40 snsprd

Autorep –j -q This command indicates that a query report of the job is required. Ex: D:\Utils\CA\UNICEN~1.SAS>autorep -j DWH_FORSYTE_W EEKLY_JOB -q

/* ----------------- DWH_FORSYTE_WEEKLY_JOB ----------------- */ insert_job: DWH_FORSYTE_WEEKLY_JOB job_type: c command: E\:\MSwork1\BCASEP\load\load_forsyte_driver.cmd machine: MDCAS035 owner: poracdw@SCHUSTERNA permission: gx,ge date_conditions: 1 days_of_week: sa start_times: "07:15" condition: s(DWH_DAILY_PROCESS_BOX) std_out_file: E\:\MSwork1\BCASEP\load\Autosys_load_forsyte_driver.log std_err_file: E\:\MSwork1\BCASEP\load\Autosys_load_forsyte_driver.err  max_run_alarm: 30 alarm_if_fail: 1

__ 

Autosys_secure: This command maintains the edit exec super user ownerships, remote authentication methods and database password. It also maintains the windows user ID s and passwords , which are required for to run on windows client machines. SYNTAX: Autosys_secure { -h ,-q } -h option is used to display help for autosys_secure command line. -q option specifies to run the command in quiet mode and not to print any error messages to the screen . however we can check the return code to see if there were any error during the run.

Autostatus: This command would report the current status of a specific job , or the value of the global variable. SYNTAX:  Autostatus {-j | -G }

Autosyslog : This is the command to display the logs for event processor and the Remote agents. SYNTAX:  Autosyslog { -e | -j } Autosyslog –e : Indicates that the event processor log is to be mentioned . In order to terminate this session just press cntrl c. This is used to view the log in EP. D:\Utils\CA\UNICEN~1.SAS>autosyslog -e Monitoring EventProcessor :

Monitoring event processor output file: D:\Utils\CA\UNICEN~1.SAS\autouser\out\event_demon.SAS *** To break out type control-c (^c) *** [13:15:01.5160] [1] EVENT: CHANGE_STATUS STATUS: STARTING JOB: TESTING_SAP_CONNECTION_SAS [13:15:04.0470] [1] EVENT: CHANGE_STATUS STATUS: RUNNING JOB: TESTING_SAP_CONNECTION_SAS [13:15:06.0780] [1] *** Checking Third Machine: MDCAS053 for the DIBS file *** [13:15:06.0780] [1] [MDCAS053 connected for ] [13:15:06.3440] [1] -[13:15:06.6560] [1] EVENT: CHANGE_STATUS STATUS: SUCCESS JOB: TESTING_SAP_CONNECTION_SAS [13:16:01.2460] [1] ----------------------< Date: 04/15/2007 13:16:00 >----------------------[13:16:06.2460] [1] *** Checking Third Machine: MDCAS053 for the DIBS file *** [13:16:06.2460] [1] [MDCAS053 connected for ] [13:16:06.4800] [1] -Unicenter AutoSys Event Processor Log 04/15/2007 14:26:37

Time EP Message --------------- --- -----------------------------------------------------------------------------[14:26:38.6750] [1] No External Config information. [14:26:38.6750] [1]  _____________________________________________________________________________   _  [14:26:38.6750] [1] Opening up the Database Connections... [14:26:38.6750] [1]  _____________________________________________________________________________   _  [14:26:38.6750] [1] Attempting (1) to Connect with Database: SNSAUTO2 [14:26:38.8000] [1] *** Have Connected successfully with Database: SNSAUTO2. *** [14:26:38.8000] [1]  _____________________________________________________________________________   _  [14:26:38.8000] [1] ALL DATABASE CONNECTIONS are Successful ! [14:26:38.8160] [1]  _____________________________________________________________________________   _  [14:26:38.8160] [1] *** Single Server MODE *** [14:26:38.8160] [1] Event Processor ID: PID: [3224] [14:26:38.8160] [1]  _____________________________________________________________________________   _  [14:26:38.8470] [1] Using TZ = EST5EDT [14:26:38.8470] [1] Event processor #1 for instance SAS is initializing. [14:26:38.8630] [1] Checking to See if an Event was processing when the event_demon Shutdown. [14:26:38.8630] [1]  _____________________________________________________________________________   _  [14:26:38.8630] [1] Running the Chase Process. [14:26:38.9570] [1]  _____________________________________________________________________________   _  [14:26:38.9570] [1]  _____________________________________________________________________________   _  [14:26:38.9570] [1] Checking on Jobs in the STARTING state... [14:26:38.9570] [1]  _____________________________________________________________________________   _  [14:26:38.9570] [1] Examining Job: TESTING_SAP_CONNECTION_SAS [14:26:38.9570] [1] Job has been in the STARTING state more than 120 Seconds. Manual intervention may be required. [14:26:38.9720] [1] *** ALARM Sent! *** [14:26:38.9720] [1]  _____________________________________________________________________________   _  [14:26:38.9720] [1] Checking on Jobs in the RUNNING state... [14:26:38.9720] [1]  _____________________________________________________________________________   _  [14:26:38.9720] [1] [MDCAS015 connected for ]

[14:26:40.0660] [1]  _____________________________________________________________________________   _  [14:26:40.0660] [1] Examining Job: EDI_OASIS_FW On Machine: MDCAS015 [14:26:40.0660] [1] OK! The file watcher is still running. [14:26:40.0820] [1]  _____________________________________________________________________________   _  [14:26:40.0820] [1] [ftp01 connected for ] [14:26:40.3320] [1]  _____________________________________________________________________________   _  [14:26:40.3320] [1] Examining Job: UOPS_DLY_HQN_EDI_fw_PHQS.PUO03100.HARL.OVERIDES On Machine: ftp01 [14:26:40.3320] [1] OK! The file watcher is still running. [14:26:40.3320] [1]  _____________________________________________________________________________   _  [14:26:40.3320] [1] Examining Job: UOPS_DLY_HQN_EDI_fw_PHQS.PUO02700.HARL.DLYBISAC On Machine: ftp01 [14:26:40.3320] [1] OK! The file watcher is still running. [14:26:40.3320] [1]  _____________________________________________________________________________   _  [14:26:40.3320] [1] Chase is done! [14:26:40.3320] [1]  _____________________________________________________________________________   _  [14:26:40.3320] [1] Cleaning out the DIBS file... [14:26:40.3320] [1] [MDCAS053 connected for ] [14:26:40.4410] [1] ***Starting the SHADOW EVENT PROCESSOR on Machine: MDCAS051 *** [14:26:40.4410] [1] [MDCAS051 connected for ] [14:27:01.6600] [1] Shadow Processor started Successfully! [14:27:01.6600] [1] ----------------------< Date: 04/15/2007 14:27:00 >----------------------[14:27:01.6600] [1] Database timezone different from EP by 0 hours [14:27:01.6600] [1] Setting the epdb_offset in the Alamode table to 0 [14:27:01.6600] [1] EP working in timezone: 'EST5EDT' [14:27:01.6600] [1] Setting the gmt_offset in the Alamode table to 14400 [14:27:01.6600] [1] *** Checking Third Machine: MDCAS053 for the DIBS file *** [14:27:01.6600] [1] [MDCAS053 connected for ] [14:27:01.8790] [1] -[14:27:02.0970] [1] EVENT: ALARM ALARM: CHASE JOB: TESTING_SAP_CONNECTION_SAS [14:27:02.0970] [1] [14:27:02.0970] [1] EVENT: STARTJOB JOB: EDI_1_ARGUS [14:27:02.0970] [1]

Autosyslog –j Indicates the Remote Agent log for the specified job_name is to be viewed. This command is to be given in the machine in which the specified job runs. This is used to view the log for the job in Remote Agent if the job has failed

Ex: D:\Utils\CA\UNICEN~1.SAS>autosyslog -j EDI_OASIS_FW *** No remote agent files found for job_name EDI_OASIS_FW ***

Chk_auto_up: Inspects the environment variables and administrator settings in the windows registry, then determines the database (event server ) and event processor are running. Ex: D:\Utils\CA\UNICEN~1.SAS>chk_auto_up  _____________________________________________________________________________   _   Attempting (1) to Connect with Database: SNSAUTO1 *** Have Connected successfully with Database: SNSAUTO1. ***  _____________________________________________________________________________   _  Connected with Event Server: SNSAUTO1  _____________________________________________________________________________   _   Attempting (1) to Connect with Database: SNSAUTO2 *** Have Connected successfully with Database: SNSAUTO2. ***  _____________________________________________________________________________   _  Connected with Event Server: SNSAUTO2  _____________________________________________________________________________   _   _____________________________________________________________________________   _ 

Checking Machine: mdcas050 Primary Event Processor is RUNNING on machine: mdcas050  _____________________________________________________________________________   _ 

Checking Machine: mdcas051 Shadow Event Processor is RUNNING on machine: mdcas051  _____________________________________________________________________________   _ 

Job_depends : This command provides the detailed reports about the dependencies and conditions of a job. The command can be used to determine the current status of a job its dependencies and nested hierarchies (for boxes) as defined in the job definition, and also the definition on what jobs would run during a given period of time. SYNTAX: Job_depends { -c | -d |-t } [ -j
SENDEVENT: Sendevent command can be issued to any job to change its status, like starting, stopping. They can also be used to set a global variable or to cancel the scheduled event. SYNTAX: sendevent –E [event] [ -j jobname] sendevent –E [event] [-G “global_name=value”] -E event: specifies the event to be sent. This option is required if any one of the following events may be specified. STARTJOB: starts the job specified. KILLJOB: kills the job specified. DELETEJOB: deletes the job specified. FORCE_STARTJOB: starts the specified job, regardless of whether the starting conditions are satisfied. JOB_ON_ICE: puts the specified job on ice. A job cannot be put on-ice when it is in Starting/Running condition. JOB_OFF_ICE: takes the specified job off ice. Jobs that are taken off ice will not start until the next time their starting conditions are met. JOB_ON_HOLD: puts the specified job on hold. Th en this particular job will not be started and its dependent jobs will not run. JOB_OFF_HOLD: takes the specified job off hold. If the starting conditions of the job are met, it gets started, STOP_DEMON: stops the event processor service. SEND_SIGNAL: It is used to send signal to a running job. Then the application reacts to the signal. -A alarm: specifies the name of the alarm to be sent. -J job_name: specifies the name of the job to which the event is to be sent. -s status: specifies the status to which the specified job should be change. [When a CHANGE_STATUS is required] -P priority: specifies the priority to be assigned to the event being sent. -T time_of_event: specifies the date and time as to when the event should be processed. Format: MM/DD/YYYY hh:mm -u : cancels the event that is specified in the _E event option.

sendevent -E STARTJOB –j D:\UTILS\CA\UNICEN~1.TSS>sendevent -E STARTJOB -J abc_test

Starts the job. sendevent -E FORCE_STARTJOB –j D:\UTILS\CA\UNICEN~1.TSS>sendevent -E FORCE_STARTJOB -J abc_test

Force starts the job. sendevent –E CHANGE_STATUS –j -s INACTIVE D:\UTILS\CA\UNICEN~1.TSS>sendevent -E CHANGE_STATUS -J abc_test -s INACTIVE

Changes the job status to inactive.

To list the Forcast report of the jobs running at particular time interval: Job_depends –j ALL –t -F “mm/dd/yy” -T “mm/dd/yy”

Creating a Command Job: Jobs can be created either through the command prompt or the job editor. While using the command prompt we provide the attributes: Insert_job: Job_type: c [for all command jobs] machine: command:

ex: D:\UTILS\CA\UNICEN~1.TSS>jil  jil>>1> insert_job: abc_test  jil>>2> job_type: c  jil>>3> command: dir   jil>>4> machine: localhost  jil>>5> exit

While using the job editor attributes of the job can be directly entered in it as shown below:

Creating a file watcher job: The job is created by providing the path of the file which the file watcher has to watch. The minimum size of the file can be provided if necessary: Insert_job:  job_type: f [for all file watchers] machine: watch_file: c:\TEMP\EodTransfile watch_interval: watch_file_min_size:  As entered in the job editor:

Creating a dependent job: The job is created by providing the dependent condition as success of some other job:

Insert_job: Job_type: machine: condition: s(test) command:

In the job editor it is same as the command job. But here we will be providing the dependencies to them.

The Admin GUI:

NOTES: When a job is stuck in the starting condition this means that the event processor communicated with the remote agent and passed all the information the remote agent 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 is so there is less querying to the DB. W hen AutoSys goes from dual mode to single 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 want 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 grouping jobs organizationally. For example, if you have a number of jobs that run daily at 1:00 a.m., you could put all these jobs in a box and assigning a daily start condition to the box. However, a variety of  account processing jobs with diverse 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 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." Default SUCCESS is described 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 status o f 

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 nature 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 likely find that the default behavior  of boxes inhibits the expected execution of the jobs you placed in the box. Likewise, you should not place jobs in a box solely because you want to run reports 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 list "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) change to status  ACTIVATED, meaning they are eligible to run. (Because of this, jobs in boxes do not retain their  statuses from previous box cycles.) Then each job is analyzed for additional starting conditions.

 All jobs with no additional starting conditions are started, without any implied ordering or  prioritizing. Jobs with additional starting conditions remain in the ACTIVATED state until those additional dependencies have been met. The box remains in the RUNNING state as long as there are activated or running jobs in the box. If a box is terminated before a job in it was able to start, the status of that job will change directly from ACTIVATED to INACTIVE. Note o Jobs in a box cannot start unless the box is running. However, once the job 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 not define more than one time attribute for any job in a box because the job will only run the first time. If you want to put a job in a box, but you also want it to run more than once, you must assign multiple start time conditions to the box itself, 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 in a box if the box will not be running at that time. If you do, the next time the box starts the job will start immediately. The following example illustrates a scenario that would not work properly if placed in a box. "job_a" is defined to run repeatedly until it succeeds. "job_report" has one starting 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 status 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 would change.

Jobs queing

Job Attributes – job_load, priority Machine Attributes – type, machine, max_load, and factor. (Both max_load and factor are defined for real machines and is used for load balancing)

Job Queuing in Autosys is implemented and achieved with the involvement of the two job attributes job_load and priority, and the two machine attributes max_load and factor. In order for any job queuing to take place, all jobs must have their priority attribute set. By default, the priority attribute is set 0 indicating that the job should not be queued, but be run immediately when the condition is met. So to have an effective queuing, the value should be set to non-zero.

Queuing with Priority – When more than one job is queued, the priority value is considered first when deciding which job to run next. If there are insufficient load units (load_value) available to run the highest priority job, it will remain in the Queue and the lower priority job will be considered subsequently. In the case where a job has its job_load attribute set, the load value will be reflected in the total load running on machine. And if there is no job_load value set for a job, it will not be figured into the total load units running on a machine. If we do not indicate what the load of a job is, it will not figure it into its Queuing calculations. This is different from the load balancing feature, which does inspect the CPU to determine its usage.