AUTOSYS JOB SCHEDULER

Technical Document

Source: Practical experience, Internet, Autosys Documentation.

What is AutoSys JM? Unicenter AutoSys JM is an automated job control system for scheduling, monitoring, and reporting. These jobs can reside on any configured machine that is attached to a network. A job is any single command, executable, script, or Windows NT batch file. Each job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run. Before get into understanding how to install, configure and use Autosys JM let us first understand architecture of Autosys. The main Unicenter AutoSys JM system components are as follows:

• Event Server (AutoSys database) • Event Processor • Remote Agent

In addition, Unicenter AutoSys JM provides utilities to help you define, run, and maintain instances and jobs. The included utilities are platform-specific; however, all platforms include the graphical user interface (GUI) and Job Information Language (JIL). Both the GUI and JIL enable you to define, manage, monitor, and report on jobs. The following figure illustrates the Unicenter AutoSys JM system components in a basic configuration. In addition, this figure illustrates the communication paths between the components.

Event Processor

Remote AgentRemote Agent

AutoSys Server(UNIX or NT)

NT Client

Remote AgentRemote Agent

NT Job

UNIX Job

UNIX Client

Event Server(Database)

Event Server or Database The event server, or database, is the data repository for all system information and events as well as all jobs, monitor, and report definitions. Event server refers to the database where all the information, events, and job definitions are stored. Autosys as of now support SYBASE, Oracle and MS-SQL database7 Event Processor The event processor is the heart of Unicenter AutoSys JM; it interprets and processes all the events it reads from the database. Sometimes called the event_demon, the event processor is the program, running either as a UNIX process or as a Windows NT service, which actually runs Unicenter AutoSys JM. It schedules and starts jobs. After you start the event processor, the event processor continually scans the database for events to be processed. When the event processor finds one, it checks whether the event satisfies the starting conditions for any job in the database. Based on this information, the event processor first determines what actions to take, then instructs the appropriate remote agent process to perform the actions. These actions might be the starting or stopping of jobs, checking for resources, monitoring existing jobs, or initiating corrective procedures. You can set up a second event processor, called the shadow event processor. If the primary event processor fails for some reason, the shadow event processor will take over the responsibility of interpreting and processing events. 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, or client, machine. On a Windows NT machine, the remote agent is a Windows NT service running on a 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, and 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. COMPONENT FUNCTION

Example Scenario on UNIX

n Poll Database for Next Event n Process Event

n Starts Up n Runs a Single Job n Returns Job Completion Information to the Database n Exits

n Job Definition -What -Where -When n Event Information -Which Job -What Event Type -What Event Occurs

Event Processor

Remote Agent

Ethernet

Client Machine

Server Machine

Event Server (AutoSys Database)

The following steps explain the interactions in the example scenario:

1. From the event server, the event processor reads a new event, which is a STARTJOB event with a start time condition that has been met. Then the event processor reads the appropriate job definition from the database and, based on that definition, determines what action to take. In the example, it runs the rm /tmp/mystuff/* command on WorkStation_2.

2. The event processor communicates with the remote agent on WorkStation_2. As soon as

the remote agent receives the instructions from the event processor, the connection between the two processes is dropped. After the connection is dropped, the job will run to completion, even if the event processor stops running.

3. The remote agent performs resource checks, such as ensuring that the minimum

specified number of processes is available, then “forks” a child process that will actually run the specified command.

4. The command completes and exits, and the remote agent captures the command’s exit

code.

5. The remote agent communicates the event (exit code, status, and so forth) directly to the event server. If the database is unavailable for any reason, the remote agent will go into a wait and resend cycle until it can deliver the message.

Only two processes need to be running—the event processor and the event server. When these two components are running, Unicenter AutoSys JM is fully operational. The remote agent is

started on a client machine once per job. As soon as the job ends and the remote agent send a completion event to the database, the remote agent exits Note: The remote agent is started on the client machine by the event processor talking

to the internet demon, inetd, on the client machine. For this to happen, inetd must also be running. However, because UNIX is responsible for starting this demon, it is not considered a process.

What is an INSTANCE? An instance is one licensed version of Unicenter AutoSys JM software running as a server with one or more clients, on a single machine or on multiple machines. An instance is defined by the following:

• An instance ID, an uppercase three-alphanumeric identifier defined by the AUTOSERV environment variable. You set the instance ID during installation and cannot change it.

• The $AUTOUSER/config.$AUTOSERV configuration file. • At least one event server. • At least one event processor.

Environment Variables Access to AutoSys and the event server is controlled by environment variables and the configuration parameters, which must be set for the event processor and the remote agents to communicate and the commands to execute. AUTOSYS Specifies the full path to the Unicenter AutoSys JM software directory. AUTOUSER Specifies the directory containing user configuration files, event processor output files, archive output files generated during database maintenance, and sound files (for platforms supporting audio functionality). AUTOSERV Specifies the unique, capitalized three-letter name of an instance. DISPLAY Referenced to run the AutoSys GUIs. To communicate with the Sybase or Oracle database, Unicenter AutoSys JM also relies on the environment variables described in the topic Database Information in this chapter. If only one instance is running, the above variables can be set when a user logs on by including their definitions in either the .profile or .cshrc file for each user that accesses Unicenter AutoSys JM. The installation script generates files that are designed to be sourced by a user wanting to access Unicenter AutoSys JM. They are found in the $AUTOUSER directory and are listed following:

• autosys.sh. hostname—for Bourne shell users. • autosys.csh. hostname—for C shell users. • autosys.ksh. hostname—for Korn shell users.

Sybase

If you are using a Sybase data server, whether bundled with AutoSys or not, the following environment variables are used: DSQUERY Defines the name of the Sybase data server. SYBASE Specifies the complete path to the Sybase software directory. The SYBASE environment variable must be set before you run the installation script. The Sybase software directory contains the Sybase configuration file, which on UNIX is the interfaces file and on Windows NT is the SQL.INI file. Unicenter AutoSys JM uses the Sybase configuration file to look up database information. It is by which the network is navigated to find the Sybase data server.

Oracle

If you are using an Oracle database, the ORACLE_HOME environment variable must be defined. In addition, SQL*Net V2 must be installed and configured correctly on all client machines. In particular, the TNS alias name of the data server that Unicenter AutoSys JM will use must be configured, and an SQL*Net V2 connect descriptor must be in the TNS names configuration file. The tnsnames.ora file is used by Unicenter AutoSys JM to look up the database host machine and port number based on its name. It is the means by which the network is navigated to find the Oracle data server. This file specifies where the Oracle server is located. On UNIX, the tnsnames.ora file is usually in the /etc or $TNS_ADMIN directory. On Windows, this file is usually in the \ORANT\NETWORK\ADMIN directory.

High Availability Option High Availability in Autosys is a Business Continuity Option, which will detect the failure of primary servers and automatically switch the processing to the secondary servers. Following section will provide the details about the AutoSys components in the High Availability (HA) mode

High-Availability Option: Dual-Event Servers

AutoSys can be configured to run using two databases, or dual-event servers. This feature provides complete redundancy. Therefore, if you lose one event server due to hardware, software, or network problems, AutoSys operations can continue on the second event server without loss of information or functionality. For various reasons, database users often run multiple instances of servers that are unaware of the other servers on the network. When implementing AutoSys, the database can run stand-alone for AutoSys only, or it can be shared with other applications.

High-availability Option: Shadow Event Processor

AutoSys lets you set up a second event processor, called the shadow event processor. This second processor should run on a separate machine to avoid a single point of failure. The shadow event processor remains in an idle mode, receiving periodic messages (pings) from the primary event processor. Basically, these messages indicate that all is well. However, if the primary event processor fails for some reason, the shadow event processor will take over the responsibility of interpreting and processing events.

General Installation Requirement (Server & Client) Things to check before installing product

• Check Hardware Requirements (Like CPU [P-III, P-IV], Memory, Hard Disk Space etc.) • Check Operating System Levels and Patches

(check Software certification index provided by every Batch tool company) • Check Locale (Language) settings • Does tool required any database: Before proceeding for the installation first thing required

is the tool coming with its own proprietary databas e or is depended on databases like Oracle, Sybase, MS-SQL.

• Consult Installation Guide provided with every Batch Scheduling tool (Control-M, Autosys and TWS Workload etc.)

• Once the server/agent is installed kindly refer post installation check to verify that setup completes successfully.

• Document Environment detail for future upgrade, modification.

BEST PRACTICES

a) Hardware (RAM, CPU) sizing There is no cut throat method which tells what is the CPU and RAM requirement you requirement if you desires to run 10,000 job and what is required if you want to run 100,000 jobs. This is an estimation which is generic and can be followed across any tool. The requirement also changes if it is a server or if it is client or remote agent machine. If it is a remote agent machine the best way to judge is running 10 jobs on the remote agent and check for an average memory requirement for the process id. Then based on the estimated number of job multiply with the same to get a near around figure. Please note: that we are only calculating what would be the RAM requirement for Batch JOB process and we are not calculating process for actual script it runs because it can vary from script to script. It is advisable to calculate /forecast future requirement before calculating sizing.

For example each job on average requires 300 kb of memory every time runs and if your forecasted number of jobs are 100 jobs at any point of time then minimum memory requirement would be :- 300 X 100 = 30,000 KB for only

It is advisable to calculate /forecast future requirement before calculating sizing.

b) Database sizing

A similar approach needs to be used in order to design database sizing. When it comes scheduling tool database, sizing is not only dependent on the number of objects (jobs, calendars, users etc.) defined within the system. The significant factor the number of time each jobs and also what is the database maintenance schedule. The sizing is done by taking and installing a test environment with a random database size. Now it also requires support from analysis done by the DBA on the database.

An easiest approach would be creating set of 10 jobs. Run all the jobs once and then run it for the second time and third time. Take from DBA analysis of change in database at every stage. For example:

a) What was the database utilization when the only the initial installation information was filled.

b) What was the utilization when 10 jobs were inserted? c) What was the utilization when first time jobs were run? d) What was the utilization when second and third time jobs were run? e) The number of jobs you define. f) How many of the jobs have dependencies. g) How often the jobs are run. (Every time a job runs, it generates at least

three events and an entry in the job_runs table.) h) How often the database is cleaned.

Take the data and create a pivot in excel and then forecasted source number of jobs you are required to be there all the time, how many times those jobs will run. For example each job on average requires 2 kb of space when it is create and requires 2kb of space every time runs and if your forecasted number of jobs are 5000 and each jobs runs on average daily once and the database history is maintained for 5 days then the minimum database you would require is :- Jobs creation requirement 2 X 5000 = 10, 000 KB Jobs run requirement 2 X 5000 X 5 (days) = 50, 000 KB

Total Space required.= 60, 000 KB

It is advisable to calculate /forecast future requirement before calculating sizing.

Environment Details SERVER

PRE -PRODUCTION POST -PRODUCTION Server Hostname Operating System Hardware Model HA configured (Y / N)

Instance Name No. Of Agent connected

Port number used for communication

Clients / Remote Agents

Client Hostname Server Hostname Database

/database port

Server Instance NAME

Example:

PRE -PRODUCTION POST -PRODUCTION Server Hostname Preprod.wipro.com Prod.wipro.com Operating System SUN Solaris Windows 2000 Hardware Model Ultra-10 Intel HA configured (Y / N)

N Y

Instance Name ACE PRD No. Of Agent connected

2 5

Port number used for communication

5280 5281

Database and database port used

Sybase (6324) MS-SQL (1533)

Clients / Remote Agents

Client Hostname Server Hostname Database

/database port

Server Instance NAME

Preprod1.wipro.com Preprod.wipro.com Sybase (6324) ACE

Preprod2.wipro.com Preprod.wipro.com Sybase (6324) ACE

Prod1.wipro.com Prod.wipro.com MS-SQL (1533)

PRD

Prod2.wipro.com Prod.wipro.com MS-SQL (1533)

PRD

What is a JOB? Before we proceed and understand what is Autosys and what all it can do us we would first understand what is a Job. A job is any single command, executable, script, or Windows batch file. Each job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run. Pre- INSTALLATION checklist Memory: It is recommended that the server machine should at least 512 MB of RAM. Disk Space:

Autosys with Bundled Sybase is 600 MB. Autosys without Bundled Sybase

Sybase Unbundled 150 MB of available disk space is required. Oracle application binaries 350 MB of disk space is required.

Oracle Requirements

• The recommended size of the data tablespace is 100 MB. • The recommended size of the index tablespace is 40 MB.

Sybase Requirements

For unbundled Sybase, the standard size of a database is 100 MB. We recommend a transaction log of 20 MB.

Server Installation checklist

ITEM Service checklist

Platform SUN Operating System SUN OS 2.6 Hostname PROD1.WIPRO.COM Host id 1234567ab Password for root Available Memory (RAM) 1024 MB License Keys available and available? Yes Install Directory path /opt/CA/UnicenterAutoSysJM Directory path for confi and output files /opt/CA/UnicenterAutoSysJM/autouser Install CCI Yes Instance Name (AUTOSERV ) ACE Non-NIS, NIS, or NIS+ configuration Non-NIS Monitor Type color Name of user who owns the files autosys Install database, (Sybase or Oracle) Bundled Sybase Name of data server that will contain database AUTOSYSDB Name of user with SA and SSO roles sa Password for user with SA and SSO roles sysadmin Full path name to remote agent executable /opt/CA/UnicenterAutoSysJM/autosys/bin Location of inetd configuration /etc Name of the remote agent service auto_remote_ACE Port name for the remote agent 5280

INSTALLING

• Log on to the server machine as root. • Insert the media into the appropriate device. • Running the Installation Script

The installation script is a Bourne shell script located in the AUTOTREE/autosys/install directory. This script creates required directories, configures special files for your environment, installs runtime procedures, and (for networks that are not NIS or NIS+) configures the Internet demon.

To run the installation script: Procedure to install AutoSys JM on a Solaris Machine Step 1

cd /cdrom cdrom0 cd uajm_4_5_solaris_bundled_syb On the root prompt type the following command # ./install-sybase.sh ------------------------------------------------------------- Installation product "UnicenterAutoSysJM -SYB", version "4.5/22" ------------------------------------------------------------- Installation component "AutoSysAgent" Installation component "AutoSysAgent_Sybase" Installation component "AutoSysAgent_Solaris" Installation component "AutoSysClient" Installation component "AutoSysServer" Installation component "AutoSysServer_Sybase" Installation component "AutoSysXmGUI" Installation component "AutoSysXmGUI_Solaris" Installation component "lic98_sun" Call component script "autosys/install/install_lic98" Installing CA Licensing. Script executed successfully Installation component "Sybase_ASE" Call component script "autosys/install/install_sybase tarx" Bundled Sybase has been installed in /export/home/autosys/sadb/. Truncating /export/home/autosys/autosys/install/sadb.tar.Z to reclaim space. Script executed successfully Job executed successfully This will successfully extract Sybase database server to your local machine and dump Autosys binaries. # cd /export/home/autosys/install The next step is to run the install script to install Autosys server or Autosys client. The screen prompts what you want to install server or client. The only difference between server and client install is that in server install it will ask you for database server name and it will create default AutoSys database whereas in case of installation of AutoSys client it will only ask you for the database server name for addition configuration parameter in the configuration file located in $AUTOUSER directory # ./auto_install AutoSys Version 4.5 Installation Choose the type of installation. (1) Server installation (2) Client installation [1]> 1 Choose the source of your system (passwd, services) files.

(1) local /etc/passwd and /etc/services (2) NIS (3) NIS+ [1]> 1 Will you be using a color monitor? ([y]|n)> y This is the AutoSys installation you have specified: Installation type: server Dataserver: Sybase Bundled: yes System files source: local (/etc) Monitor type: color Is this correct? ([y]|n)> y What user will 'own' the AutoSys software? [autosys]> Enter the three letter name for this instance of AutoSys ($AUTOSERV). [ACE]> Enter the value for ($AUTOUSER). ($AUTOUSER is the directory which contains configuration files and its sub directory contains event processor and archive and other logged information. [/export/home/autosys/autouser]> This is the AutoSys configuration information you specified: AutoSys owner: autosys $AUTOUSER: /export/home/autosys/autouser $AUTOSERV: ACE Is this correct? ([y]|n)> Installing AutoSys with a bundled Sybase RDBMS. What is the name of the dataserver ($DSQUERY) that contains the AutoSys database? [AUTOSYSDB] > Enter the full pathname to the directory containing the Sybase interfaces file ($SYBASE). [/export/home/autosys/sadb]> This is the dataserver information you have specified: $SYBASE: /export/home/autosys/sadb Dataserver name: AUTOSYSDB Database name: autosys User granted SA & SSO roles: sa Enter the directory to contain the auto_remote executable. [/export/home/autosys/autosys/bin]> Enter the location of the inetd configuration file. [/etc/inetd.conf]> Enter the name of the auto_remote service. [auto_remote]> Enter a port number for auto_remote. [5280]>

This is the inetd information you specified: auto_remote location: /export/home/autosys/autosys/bin inetd config file: /etc/inetd.conf auto_remote service: auto_remote auto_remote port number: 5280 Is this correct? ([y]|n)> y ------------------------------------------------------------------------ All the information needed to install AutoSys has been collected. We are about to begin editing system files, installing database objects, etc. Do you wish to proceed? ([y]|n)> y Continuing installation... ------------------------------------------------------------------------ Configuring the dataserver for AutoSys. Configuring a bundled Sybase dataserver. Creating /export/home/autosys/sadb/interfaces. Sybase is configured. Configuring AutoSys. Creating $AUTOUSER. Creating the files /export/home/autosys/autouser/autosys.csh.unknown (C shell) /export/home/autosys/autouser/autosys.sh.unknown (Bourne shell) /export/home/autosys/autouser/autosys.ksh.unknown (Korn Shell) to be sourced at login to set the environment variables and certain useful aliases. Generating the configuration file: /export/home/autosys/autouser/config.ACE. Setting ownership and permissions on the AutoSys files... Installing the default remote agent profile: /etc/auto.profile. Configuring Unix for AutoSys. Configuring the internet daemon. Editing the services file. Copying the existing /etc/services to /etc/services.auto_install. Editing /etc/inetd.conf. Copying the existing /etc/inetd.conf to /etc/inetd.conf.auto_install. inetd (pid: 194) was sent a SIGHUP.

Updating the app-defaults files for AutoSys screens. Installing the app-defaults files for AutoSys screens. Copying app-defaults files into /usr/openwin/lib/app-defaults. Starting the AUTOSYSDB dataserver. Error: The AUTOSYSDB dataserver has failed to start. See /export/home/autosys/sadb/ASE-12_0/install/AUTOSYSDB.log for error messages. AutoSys installation is complete. THIS IS THE END OF THE INSTALLATION Now we will edit .profile of the user to provide him with the entire environment required by him to execute the AutoSys binaries. This can be done two ways one exporting variables one by one or else exporting a file in .profile. This file is stored in $AUTOUSER directory and is named as autosys.<$SHELL>.$HOSTNAME Which means if you are in ksh shell then the file to be exported is autosys.ksh.<hostname> and if you are in sh shell then the file name will be autosys.sh.<hostname>. # cd /export/home/autosys # vi .profile ADD THE FOLLOWING ENTRIES IN THE . profile file . /export/home/autosys/autouser/autosys.ksh.unknown Now login as the user for which .profile is changed and is the owner of autosys. In our case it is user autosys. # su - autosys First thing is to add the user to autosys database. The command to add users to autosys database is autosys_secure. There are THREE type of user you can define in autosys database and these are

a) edit super users This user is a special user to AutoSys with Administrator-like privileges. The edit superuser has read and write permissions to the AutoSys database. Only the AutoSys edit superuser can add AutoSys user passwords, using the AutoSys secure utility; however, after user IDs and passwords exist in the database, any user who knows a password can use AutoSys_secure to change that password or delete that user definition.

b) execute super users

AutoSys exec superuser, who can issue commands and stop the event processor and also who can kickoff and change status for different users defined jobs.

c) normal users

user who can create and run their individual jobs. Defining the AutoSys edit superuser and exec superusers: 1. Open an AutoSys instance command prompt window from your AutoSys program 2. Enter the following at the command prompt - AutoSys_secure 3. When you run AutoSys_secure , a menu is displayed, and you should select the following item by entering 1: [1] Change AutoSys EDIT and EXEC superusers. 4. When prompted, enter the AutoSys edit superuser logon name and the exec superuser logon name. These users must be valid users on the machine or domain that you are logged on to. $ autosys_secure AutoSys Security Utility Please select an action to perform: [1] Administer EDIT/EXEC superusers. [2] Change AutoSys database password. [3] Change AutoSys remote authentication method. [4] Create AutoSys User@Host or Domain password. [5] Change AutoSys User@Host or Domain password. [6] Delete AutoSys User@Host or Domain password. [7] Exit autosys_secure. [A] Get Encrypted Password for Adapters. > 1 Please select from the following options: [1] Create an EDIT/EXEC superuser. [2] Modify an EDIT/EXEC superuser. [3] Delete an EDIT/EXEC superuser. [4] Show all EDIT/EXEC superusers. [5] Exit from "Administer EDIT/EXEC superusers" menu. > 1 AutoSys EDIT superuser(s): autosys@unknown CREATE AN EDIT SUPERUSER: Input the user name (or hit enter to cancel): autosys Enter user Host or Domain (or hit enter if no host): unknown AutoSys EXEC superuser(s): autosys@unknown CREATE AN EXEC SUPERUSER: Input the user name (or hit enter to cancel): autosys Enter user Host or Domain (or hit enter if no host): unknown Please select from the following options:

[1] Create an EDIT/EXEC superuser. [2] Modify an EDIT/EXEC superuser. [3] Delete an EDIT/EXEC superuser. [4] Show all EDIT/EXEC superusers. [5] Exit from "Administer EDIT/EXEC superusers" menu. > 4 AutoSys EDIT superuser(s): autosys@unknown AutoSys EXEC superuser(s): autosys@unknown Please select from the following options: [1] Create an EDIT/EXEC superuser. [2] Modify an EDIT/EXEC superuser. [3] Delete an EDIT/EXEC superuser. [4] Show all EDIT/EXEC superusers. [5] Exit from "Administer EDIT/EXEC superusers" menu. > 5 Please select an action to perform: [1] Administer EDIT/EXEC superusers. [2] Change AutoSys database password. [3] Change AutoSys remote authentication method. [4] Create AutoSys User@Host or Domain password. [5] Change AutoSys User@Host or Domain password. [6] Delete AutoSys User@Host or Domain password. [7] Exit autosys_secure. [A] Get Encrypted Password for Adapters. > 7 TO START THE EVENT PROCESSOR $ eventor Event demon(s) Started... ********************************************************** Unicenter AutoSys Event Processor Log 09/15/2004 00:48:52 Time EP Message --------------- --- ------------------------------------------------------------------------------ [00:48:54.4646] [1] AutoSys Event Processor License Warning: - Can't open license file. Please run the appropriate license program to properly license your product. [00:48:54.4931] [1] No External Config information. [00:48:54.4931] [1] ______________________________________________________________________________ [00:48:54.4932] [1] Opening up the Database Connections... [00:48:54.5020] [1] ______________________________________________________________________________ [00:48:54.5020] [1] Attempting (1) to Connect with Database: AUTOSYSDB:autosys [00:48:54.5658] [1] *** Have Connected successfully with Database: AUTOSYSDB:autosys. ***

[00:48:54.5659] [1] ______________________________________________________________________________ [00:48:54.5659] [1] ALL DATABASE CONNECTIONS are Successful ! [00:48:54.5788] [1] ______________________________________________________________________________ [00:48:54.5790] [1] *** Single Server MODE *** [00:48:54.5791] [1] Event Processor ID: PID: [8868] [00:48:54.5791] [1] ______________________________________________________________________________ [00:48:54.5791] [1] Event Processor Sleep Time: 1 seconds [00:48:54.5792] [1] Inetd Sleep Time: 50000 microseconds [00:48:54.5792] [1] ______________________________________________________________________________ [00:48:54.5793] [1] SNMP trap generation : DISABLED [00:48:54.5793] [1] ______________________________________________________________________________ [00:48:54.5913] [1] Using TZ = Indian/Chagos [00:48:54.6027] [1] Event processor #1 for instance ACE is initializing. [00:48:54.6240] [1] Checking to See if an Event was processing when the event_demon Shutdown. [00:48:54.6262] [1] ______________________________________________________________________________ [00:48:54.6396] [1] ______________________________________________________________________________ [00:48:54.6397] [1] Running the Chase Process. [00:48:54.6429] [1] There are no Jobs in a STARTING or RUNNING state! [00:48:54.6430] [1] Chase is successful. [00:48:54.6431] [1] ______________________________________________________________________________ [00:48:54.6489] [1] ------------------------< Date: 09/15/2004 00:48:53 >------------------------- [00:49:01.8809] [1] ------------------------< Date: 09/15/2004 00:49:00 >------------------------- TO CREATE TEST JOB USING JIL jil>>1> insert_job: ca1 jil>>2> command: ls -l jil>>3> machine: unknown jil>>4> owner: autosys@unknown jil>>5> exit Insert/Updating Job: ca1 Database Change WAS Successful! ________________________________________________________________Exit Code = 0 TO TRIGGER THE JOB

$ sendevent -E STARTJOB -J ca1 $ exit #

======================================================================= ######################################################################## Configuration for AutoSys is stored under $AUTOUSER directory and It contains all the parameters configured for event process during Autosys Installation # Enclosed is a sample file ####################################################################### # # # # # Database Parameters # # # # # # Specify the Database(s)# EventServer=ASYS2.ICTGROUP.COM # Database Connection Time Out (in seconds)# DBLibWaitTime=90 # Cross-instance DB connection flag # # 0 = We connect before every EVENT is sent to the other Instance, and drop # after it is sent. # 1 = We connect the first time an EVENT is sent, and maintain the connection # forever. XInstanceDBDropTime=1 # Number of times for Event Processor to attempt to reconnect to Event Servers. #DBEventReconnect=50 # USE the following for Dual Server Mode DBEventReconnect=50,2 # # Event Processor's internal Daily Database Maintenance Cycle Daily start-time DBMaintTime=22:35 # Command to Run to perform Maintenance DBMaintCmd=$AUTOSYS/bin/DBMaint # # # # # General Event Processor Parameters # # # # # # Event Processor ERRORS # If there are more than 20 errors in 60 seconds it will exit. The MAX value # of EDNumErrors is 100. EDNumErrors=20 EDErrTimeInt=60 # Machines for chk_auto_up to inspect to see if an Event Processor is running # there. #EDMachines=host1,host2,host3 EDMachines=raven,asdprod2

# For Shadow Event Processor, the Third Machine to resolve contention problems # between Event Processors ThirdMachine=sahara # Minimum Kbytes of space that must be available for the EP log file (on the # partition or disk). If free space falls below this, the EP will issue # warnings. If the amount of available free space falls below 8192 bytes then # the EP will shut down. FileSystemThreshold=32 # For Dual Server Mode - transfer events timeout EvtTransferWaitTime=5 # The interval between database polls when the EP does not find an event to # process. EventProcSleepTime=.5 # The minimum interval between STARTJOBs for jobs running on the same machine. InetdSleepTime=.05 # Specify how many seconds should elapse after completing a ping to the Shadow # Event Processor before another attempt is made. The default is 60 seconds. ShadowPingDelay=60 # # # # # # Multiple Event Processor Parameters # # # # # # # The number of event processor processes to start. When setting EPCount > 1, # we strongly recommend setting EventSerialization=1. EPCount=1 # The interval (in minutes) between checks for missing EP heartbeats. EPHeartbeatInterval=10 # This parameter is only meaningful if EPCount > 1. It configures whether # access to the event table is serialized by AutoSys or by the database. # If EPCount > 1, we strongly recommend setting EventSerialization=1. # # 0 = Serialized by database # 1 = Serialized by AutoSys EventSerialization=1 # When EPCount > 1, RestartEPs determines whether or not event_demon processes # which have stopped running should be restarted. If the parent event_demon # (ID 1) has stopped, this parameter is ignored, and all event_demon processes # will be shutdown.

# # 0 = The failed event_demon will NOT be restarted. # 1 = The failed event_demon will be restarted. RestartEPs=1 # # # # # Remote Agent/Job Parameters # # # # # # Check job heartbeat every 2 minutes. #Check_Heartbeat=2 # Output Directory for the Remote Agent # Note: Some OS's have problems with file locks in /tmp. If so, use some # directory other than /tmp. AutoRemoteDir=/tmp # Clean Remote Agent files: # 0 = Do not remove files # 1 = Remove files if no problems CleanTmpFiles=1 # Create Remote Agent Output File for Sourcing the Environment. In UNIX: # capture std_out & std_err from sourcing /etc/auto.profile. In NT: output the # Envi ronment to the file. RemoteProFiles=1 # Port number of auto_remote (REMOTE AGENT AutoRemPort=5280 # Specify if standard error and standard output files should be appended to or # overwritten. # # 0 = Overwrites the files. # 1 = Appends the files. AutoInstWideAppend=1 # Max number of times to RESTART a job due to system errors MaxRestartTrys=10 # Formula for computing the Wait time between restart attempts: # WaitTime = RestartConstant + ( Num_of_Trys * RestartFactor ) # if ( WaitTime > MaxRestartWait ) then WaitTime = MaxRestartWait RestartConstant=10 RestartFactor=5 MaxRestartWait=300 # Preferred method of Load Balancing # Can be: vmstat | rstatd (default is vmstat) #MachineMethod=rstatd # List of Signals to Send to a Job for the KILLJOB event KillSignals=2,9

# The SendeventMaxRetries parameter specifies the maximum number of times that # the sendevent command will try to send an event to the Event Server database. #SendeventMaxRetries=10 # The SendeventRetryInterval parameter specifies the time, in seconds, that # sendevent will wait between attempts to send an event to the Event Server # database. There's no default setting. #SendeventRetryInterval=3 # # # # # AutoSys Broker Parameters # # # # # # # Indicates if event_demon should start asbIII (the AutoSys broker to submit # jobs to TNG Workload Agent on Unix, NT, VMS, OS/390 and to CONNECT machines). # # 0 = Do not start # 1 = event_demon starts asbIII AutoSysAgentSupport=0 # Indicates if the AutoSys broker should be configured to receive remote job # submissions. AutoSysAgentSupport must be 1 in order to receive remote job # submissions. # # 0 = Do not receive remote job submissions # 1 = Receive remote job submissions AutoSysAgentSupportReceiveSubmit=0 # # # # # # Integration Parameters # # # # # # # Enable Unicenter Event notification. # # 0 = none # 1 = alarms # 2 = alarms and job completion # 3 = all events UnicenterEvents=3 # Host machines to send SNMP traps to. (Specifying a machine ENABLES traps) #SnmpManagerHosts=host1,host2 # Snmp community. This is almost always "public". #SnmpCommunity=public # Enable sending HP Operations Center messages (opcmsg) for AutoSys alarms. # This defines the message group under which messages will be sent. #OpcMessageGroup=Job # This parameter sets the amount of time that the event_demon will wait for # the OpCenter message to be sent. #OpcWaitTime=4 # # # # # # Miscellaneous Parameters # # # # # # # Enable sound in the GUIs

SoundEnabled=1 # Format for entering and displaying dates DateFormat=MM/DD/YYYY #-------------------------------------------------------------------------

Autosys Directory Structure The following figure shows the default directory structure for Unicenter AutoSys JM . This figure refers to the installation directory as AUTOTREE. When this default structure is used, all the prompts displayed by the install scripts will match exactly what you see on the screen. The autouser directory can be placed elsewhere. The new directories are pointed to by the environment variables AUTOSYS and AUTOUSER.

Commands autoping Function Verifies that the various communication facilities are

correctly configured and functioning. Syntax autoping -m {machine|ALL} [-A] [-D] Description 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 with –D switch. If you are running Dual-Event Servers, it checks both database connections. If requested, it generates an alarm when problems are detected. Since these client/server communication facilities are critical to functioning, autoping provides valuable information for troubleshooting, and should always be used early in that process. When autoping is executed, the server (the machine from which autoping is issued) establishes a connection with the client machine and 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!

If there is a problem with the configuration, a message indicating that the remote machine has not responded (or that there is a more serious problem, such as a socket read error) will be displayed. If the -D argument is used; autoping attempts to connect to the database and displays the resultant output to the screen. It includes the output in the alarm, if one was generated with the –A argument. If you are running Dual-Event Servers, both databases are checked. You can issue autoping from any machine on which the autoping executable resides. The target can be any Remote Agent machine. To check whether the machine “EC4TIS127574” is properly configured, and that its Remote Agent can function properly, enter: autoping -m EC4TIS127574 If successful, the following will display:

AutoPinging Machine [EC4TIS127574] AutoPing WAS SUCCESSFUL!

To check all machines and verify their database access, enter:

autoping -m ALL -D If successful, the following will display: AutoPinging Machine [EC4TIS127574] AND checking the Remote Agent's DB Access. chk_auto_up is a command which checks overall health of the system including the environment, configuration files, event server and event processor.

Difference between chk_auto_up and autoping When we run chk_auto_up and autoping they both check environment and configuration setting and connectivity to event server, so what is the difference between these two commands? When we run chk_auto_up it runs the process from the environment of the user currently logged in as whereas autoping can eventor eventor is a command to start event process in UNIX. autorep Function Reports information about a job, jobs within boxes, machines, and machine status. Also reports information about job overrides and global variables. Description autorep lists a variety of information about jobs, machines, and global variables currently defined in the database. You can use it to list a summary of all currently defined jobs, or to display current machine load information. autorep 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 and save them to an output file for later re-loading into AutoSys, as a means of backing up job definitions. autorep retrieves data from the database to formulate the reports. Any data that has been archived with archive_events will not appear in the reports. When listing nested jobs, subordinate jobs are indented to illustrate the hierarchy. The following sections describe the types of autorep reports. Syntax autorep {-J job_name | -M machine_name | -G global_name} [-s | -w | -d | -q | -o over_num] [-R run_num][-L print_level] [-N Retry] [-t] [-D data_server:database | -D TNSname] Options -J job_name Indicates that a Job Report is desired. job_name specifies the name of the job

on which to report. Any valid job name may be specified. To report on all jobs, specify ALL. The percent (%) character may be used in the job name as a wildcard (For example: %box% will select all jobs containing the string “box”).

-M machine_name Indicates that a Machine Report is desired, which lists the machine’s Max

Load, Current Load, and Factor. machine_name specifies the machine on which to report. This may be a virtual machine, a real machine, or ALL for all machines; the machine must be defined.

-G global_name Indicates that a global variable report is desired, listing the variable name,

value, and last modification date. global_name specifies the name of a global variable that has been set using the sendevent command or the Send Event dialog. In the specification, you can use ALL or wildcard characters.

-s Indicates that a Summary Report is desired. This is the default. 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.

-d Indicates 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.

-q Indicates a Query Report is desired, providing the current job or machine definition, in JIL

format, as it exists in the database. For a Global Variable Report, this option is ignored. autosyslog Displays the Event processor and Remote Agent log files. autosyslog [-e | -J job_name] [-p] autosyslog is used to view either the event processor log file or the Remote Agent log file for the specified job. Both the Remote Agent and Event Processor write diagnostic messages to their respective logs, as part of their normal operations and in response to detected error conditions. autosyslog provides useful troubleshooting information because the event processor logs all events it processes and provides a detailed trace of its activities. If Unicenter AutoSys JM appears to be behaving abnormally, these logs are the first places you should look. Remote Agent log The autosyslog utility can be a useful diagnostic tool when jobs fail. This command, when provided with the name of a job, displays the log of the job’s most recent run. Although the Remote Agent’s log file is automatically deleted by default after a successful job run, the log file will not be deleted at job completion if the job ended with a FAILURE status. -e Indicates that the event processor log is to be monitored. When in this mode, in order to

terminate the command, you must press Ctrl+C -J job_name Indicates that the Remote Agent log for the specified job_name is to be viewed.

You must issue this command on the machine where job_name ran. Otherwise, the following message will display: *** No remote agent files found for job_name job_name*** Note: View the Remote Agent log, you must execute this command from the machine

on which the specified job ran last.

-p The -p option must be used with the -J job_name option.

autosys_secure Maintains the Edit and Exec superuser ownerships, remote authentication methods and database password. check installation steps for understanding on autosys_secure command

autotimezone Function Allows additions, deletions, and queries to the time zones table. Syntax autotimezone [-a entry_name value] [-c entry_name value] [-t timezone_name] [-d entry_name] [-q

entry_name | sql_pattern] [-l] Description autotimezone lets you query the timezones table, and add and delete timezones

table entries. The timezones table contains entries that you can specify in a job definition using the timezone attribute. The timezones table maps cities and common aliases to valid POSIX TZ environment variables. The table contains entries for all the common time zones that are recognized by most operating systems, as well as many cities in the world.

The timezones table has three entry “Types,” Zone, Alias, and City, as shown in the following example from the time zones table: Entry Type Zone ---------------------- ------ ---------------- US/Pacific Zone PST8PDT US/Samoa Alias Pacific/Samoa Important! If you change the timezones table, be sure you do not change or delete

entries that are used by pre-exiting STARTJOB and other events that were scheduled using the old timezones table.

chase verifies that the database indicates jobs as running. It also verifies that the remote agent is running. Syntax chase [-A] [-E] chase determines from the database, which jobs are in the STARTING or RUNNING state, and on which machine. For each client machine, chase passes to a Remote Agent a list of jobs that are supposed to be running there and instructs the Remote Agent to verify that the processes actually are running. For Command jobs running on a UNIX machine, the Remote Agent also checks for the pid of the UNIX process.

sendevent Function A command which is given to starting or stopping of jobs, stopping the Event

processor, putting a job on hold, to set global variables or cancel a scheduled event.

Syntax sendevent -E event [-S autoserv_instance] [-A alarm] [-J job_name] [-s status] [-

C comment] [-P priority] [-M max_send_trys] [-q job_queue_priority] [-T "time_of_event"] [-G "global_name=value"] [-k signal_numbers] [-u]

Description Issuing the sendevent command is the only method of externally sending an

event for such purposes as starting a job or stopping the event processor. You can also use sendevent to communicate with any instance, provided the machine on which it is executing can connect with the databases associated with that instance.

The event that is sent is written to the database, which the event processor is continually polling. The event processor reads and processes the event. The Send Event Tool can also be used to send an event. You access this tool from Scheduler Console and Alarm Manager. Note: To issue a sendevent on a job, you must have execute permission on

that job. Only alarms, comments, and set global can be sent without regard to permissions.

Autosys Job Types There are three types of jobs:

• Command, • File watcher, • Box.

These job types have a majority of job attributes in common, and Unicenter AutoSys JM treats them all similarly. Command Jobs The command job is commonly thought of (and referred to) as a

job.

The command can be a shell script, an executable program, a file transfer, and so forth. When all the starting conditions are met, Unicenter AutoSys JM runs this command and captures its exit code upon completion. The exit event (either SUCCESS or FAILURE) and the exit code value are stored in the database.

Box Jobs In the 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. When this is done, jobs related by like starting conditions (not by similar application types) can be grouped and operated on in a logical way.

If no other starting conditions are specified at the job level, a job within a box will run as soon as the starting conditions for the box are satisfied. If several jobs in a box do not have job-level starting conditions, they will all run in parallel. Each time any job in a box changes state; the other jobs are checked to see if they are eligible to start running.

Important: Jobs inside of boxes will be run only once per box execution. File Watcher Jobs A file watcher job is similar to a command job. However,

instead of starting a user-specified command on a client machine, it starts a process that monitors for the existence and size of a specific operating system file.

When that file reaches a certain minimum size, and is no longer growing in size, the file watcher job completes successfully, indicating that the file has arrived.

For example: a file needs to be downloaded from a FTP location, and it is expected to arrive after 10:00 a.m. as soon as it arrives, a batch job is to be run to process it, possibly even starting a whole sequence of jobs.

Now you could set up a file watcher job to start at 10:00 a.m., wait for the arrival of the specified file, and then exit. You could also set up the batch job so that the completion of the file watcher job is its only starting condition.

Basic Job Attributes

For each of the three job types, some job attributes are required. There are additional optional attributes that you can use for more advanced job definitions. Note: The owner attribute is required for all job types, but is automatically assigned by AutoSys

as the user presently logged into the system.

But, if you are edit super user than you have the privilege changing the job owner. Command Job Attributes The basic command job definition has the following required attributes:

Job Name

The unique job identifier by which a job is referenced. Command

The UNIX shell script, command, or application program to be executed. Machine Name

The name of the machine on which the command is to be run. Starting Conditions

The date/time or job dependency conditions necessary for the job to be run. (This is not required, such as in cases where a job will always be started manually.)

Box Job Attributes The basic box job definition has the following required attributes:

Box Name The unique job identifier by which the box is referenced. This name is used by other jobs as the name of their parent box.

Starting Conditions The date/time or job status conditions necessary for the job to be run. (This is not required, such as in cases where a job will always be started manually).

File Watcher Job Attributes The basic file watcher job definition has the following required attributes:

Job Name The unique job identifier by which a job is referenced.

File Name to Watch For The name of the file for which to watch.

Machine Name The name of the machine on which the command is to be run.

Starting Conditions The date/time or job status conditions necessary for the job to be run. (This is not required, such as in cases where a job will always be started manually).

Job States and Status Autosys keeps tracks of current state of every job. The value is useful to understand and define when the dependent job will start. Job status can be checked from the autocons gui or by issuing autorep command. A job can have following statuses :-

JOB STATE STATUS

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.

ACTIVATED The top-level box that this job is in is now in the RUNNING state, but the job itself has not started yet.

STARTING The event processor has initiated the start job procedure with the remote agent.

RUNNING The job is running. If the job is a box job, this value simply means that the jobs within the box can 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

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. 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. (These exit conditions are discussed further in later sections.)

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. 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.

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

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

QUE_WAIT The job can logically run (that is, all the starting conditions have been met), but there are not enough machine resources available.

ON_HOLD This job is on hold and will not be run until it receives the JOB_OFF_HOLD event.

ON_ICE 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.

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. 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. Starting Parameters and Boxes

• A job in the box will only start if the box job is running. • A job in a box means that it inherits all starting conditions of the box job. • But if the job has its on starting parameters and conditions the job will get activated and

will remain in activated status till it meets its starting condition. • A job runs only once per box execution.

Date/Time Dependencies Jobs can be automatically scheduled to start at a certain date and time, based on the information supplied in the job definition. You define these dependencies by specifying the days or dates and times for time-based job starts. AutoSys then calculates a matrix of these values and starts jobs at those times. A time range cannot span more than 24 hours. You can also specify a time zone to apply to your starting times. For example, if you define a job to be started on Monday, Wednesday, and Friday at 8:00 a.m. and 5:00 p.m., it will be started 6 times a week: Monday at 8:00 a.m. and 5:00 p.m., Wednesday at 8:00 a.m. and 5:00 p.m., and Friday at 8:00 a.m. and 5:00 p.m.

Job Dependencies Related to Job Status You can start jobs based on the current status of one or more jobs. These jobs must exist in the database. These starting conditions enable you to program simple or complex prerequisites that must be met in order to initiate a job. Starting conditions can be as simple as specifying JobB to start when JobA achieves a SUCCESS status, and JobC to start when JobB achieves a SUCCESS status. You can configure more complex conditions by combining a series of conditions with the AND or the OR logical operators. You may use the pipe symbol (|) instead of the word OR, and the ampersand symbol (&) instead of the word AND. Spaces between conditions and delimiters are optional. You can specify even more complex conditions by grouping the expressions in parentheses. The parentheses force precedence, and the equation is evaluated from left to right. Given the sample script of: (success(JobA) and success(JobB)) or (done(JobD) AND done(Job E)) The dependency specification can take one of the following three forms:

• Based on the current status of other jobs

• Based on the UNIX exit codes of other jobs • Based on global variables

The syntax for conditions based on job status is as follows: status(job_name) Where status is the following:- SUCCESS Indicates that the status condition for job_name is SUCCESS.

FAILURE Indicates that the status condition for job_name is FAILURE.

done Indicates that the status condition for job_name is SUCCESS, FAILURE or TERMINATED.

TERMINATED Indicates that the status condition for job_name is TERMINATED.

NOTRUNNING Indicates that the status condition for job_name is anything except RUNNING.

Defining Jobs You can define jobs using one of two methods: JIL statements or the GUI (in the Job Definition dialog). When you use JIL statements, you can input them interactively to the jil command, or you can store them in text files, which you can redirect into the jil command. Alternatively, you can open the GUI by using the autosc command, and you can enter the job definition by filling in the appropriate fields of the Job Definition dialog and its associated dialogs. To start the GUI: Enter the following command at the UNIX prompt: autosc & The GUI control panel appears:

The control panel buttons and the actions they perform:

Ops Console Displays the Job Activity Console, used to monitor jobs and alarms. Job Definition Displays the Job Definition dialog, used to define jobs. Calendars Displays the Calendar Definition window, used to define run and

exclude calendars. Monitor/Browser Displays the Monitor/Browser dialog, used to define and run

monitors and reports (or browsers). Exit Exits the GUI.

Job Definition GUI The Job Definition dialog contains fields representing all the basic information you need to define a job. The fields in the Job Definition dialog are context sensitive based on the type of job being defined. When you select a Job Type, only the fields appropriate to that type of job are displayed and activated, and the other fields are disabled.

Date and time Dialog Box Calendars Accesses the Graphical Calendar facility. Dismiss Closes the Date/Time Options dialog.

Defining Jobs using JIL (Job information language) Job Information Language (JIL) is a scripting language, which provides a way to specify how jobs should behave. JIL scripts contain one or more JIL sub-commands and one or more attribute statements; these elements constitute a job definition. JIL Syntax Rules When writing a JIL script, you must follow the syntax rules listed following. Rule 1 Each sub-command uses the following form: sub_command: job_name where: sub_command Indicates one of the sub-commands listed in the table in JIL Sub-

commands in this chapter. job_name Specifies the user-specified name of the job to receive action.

Rule 2 Each sub-command can be followed by one or more attribute statements. These statements can occur in any order, and are applied to the job specified in the preceding sub-command. A subsequent sub-command begins a new set of attributes for a different job. The attribute statements have the following form: attribute_keyword: value Rule 3 Multiple attribute statements can be entered on the same line, but the lines must be separated by at least one space. Rule 4 A box must be defined before the jobs can be placed in it. Rule 5 Legal value settings can include any of the following characters: uppercase and lowercase letters, hyphens, underscores, numbers, colons (if the colon is escaped with quotes or a preceding backslash), and at character (@). Rule 6 Any colons used in an attribute statement’s value setting must be escaped, because JIL parses on the combination of keyword followed by a colon. For example, to specify the time to start a job, specify 10:00. The colon can also be escaped with a preceding backslash (\) as in 10\:00. Rule 7 Comments are indicated using one of the following two methods:

• An entire line can be commented by placing a pound sign (#) in the first column. • The C programming syntax used for beginning a comment with a slash star (/*) and

ending it with a star slash (*/) can be used; this allows comments to span multiple lines. The following command is an example: /* this is a comment *

JIL subcommands are used to create, modify, override, or delete a job definition. These subcommands are listed in the following table. Subcommand Description insert_job Add a new job update_job Edit fields on existing job delete_job Delete an existing job from the database.

delete_box Delete an existing box job, and recursively delete all the jobs, which are contained in the box.

insert_machine Add a new machine.

override_job Apply overrides on indicated job attributes for the next run of this job.

Creating a Command Job To create the most basic command job, you only need to specify a few attributes. For example, the JIL script required to define a simple command job named test_run as follows: insert_job: test_run job_type: c /*(optional, it is the default) */ machine: ec4tis12457 command: /bin/touch /tmp/test_run.out This JIL script instructs:

• To add a new job named test_run. • That the new job is a command job • To run the job on the client machine/hostname named: ec4tis12457 • To execute the UNIX /bin/touch command on the file named /tmp/test_run.out

Creating a File Watcher Job File watcher jobs do not execute commands themselves; they are used to signal the arrival of files, and typically set off the execution of a command job. For example, the JIL script required to define a file watcher job named EOD_watch as follows: insert_job: EOD_ watch job_type: f machine: tibet watch_file: /tmp/EOD_trans_file watch_interval: 60 watch_file_min_size: 50000 This JIL script instructs:

• To add a new job named EOD_watch. • That the new job will be a file watcher job. • To run the job on the client machine named tibet.

• To watch for an end of day transaction file named EOD_trans_file in the /tmp directory.

• Check the file every 60 seconds. • Determine if the file has reached the minimum file size of 50,000 bytes.

Until the minimum file size of 50,000 bytes has been reached, the file will not be considered as complete. When the file reaches this minimum size and does not change between check intervals (60 seconds in this example) it is considered complete (also known as steady state). When this occurs, the file watcher job will end with a SUCCESS condition. Creating a Dependent Command Job Command jobs can be dependent on the successful completion of other jobs, such as the file watcher job created in the previous section. The only difference between a dependent command job and a simple command job is its dependency on another job. For example, the JIL script required to define a dependent command job named EOD_post is given following. EOD_post will be specified to run on the same machine as the file watcher job created in the previous section, since it presumably will need the watched-for file to process. And, it will be dependent on the success of the file watcher job. insert_job: EOD_post job_type: c machine: tibet condition: success(EOD_watch) command: $HOME/post This JIL script instructs:

• To add a new job named EOD_post. • That the new job will be a command job. • To run the job on the client machine named tibet. • To run the job only if the file watcher job named EOD_watch completes with a

SUCCESS status. • To source the /etc/auto.profile file (sources this file by default), and then, to run

the job named post located in the job owner’s home directory.