Joseph Top of Form

Amrith search-site

Raj's
Search this site
Webspher Bottom of Form
e Library
• Home Autosys Job Management >
• Autosys Autosys Tutorial
Job A Quick reference tutorial is available here
Manage Index
ment
1) What is Job Management System
Auto 2) What is a Job
sys 3) Autosys Features
Quic 4) AutoSys for Unix/NT Environments
k 5) The AutoSys Architecture (in Details
Refe 6) Common Definitions like machines, instance, environment etc.
renc 7) Autosys Directory Structure
e
8) How Autosys Connects to the Database
○ Ai) Sybase connectivity method.
u ii) Oracle connectivity method.
t 9) Running Multiple Instances
o 10) Running Cross-Instance Job Dependencies
s 11)High-Availability Options (Dual ES & EP)
y 12) Commands
s 13) Event State Abbreviations
T 14)Autosys_Secure
u
15) System States
t
16) Alarms
o
r 17) Exit Codes
i 18)Different Job Types & How to Define Jobs
a 19) Calendars
l 20)Monitoring / Reporting (monbro)
21) Job information Language (JIL)
• C-Shell 22) Load Balancing
Scriptin
23) Event Processor Log file sample
g
24) Remote agent Log file sample
• Intervie 25) Troubleshooting.
w
Questio What is a Job Management System?
ns A reliable, easy to use system that enables the user to completely
○ Mmanage their entire Job Processing requirements.
QIt will help implement enterprise growth and change, not dictate the
way the enterprise operates.
○ W
 AUnicenter AutoSys JM is an automated job control system for
S scheduling, monitoring, and reporting. These jobs can reside on any
configured machine that is attached to a network.
• Joseph
Amrith What is a Job ?
Raj@we A job is any single command, executable, script, or Windows batch
b file. Each job definition contains a variety of qualifying attributes,
○ C including the conditions specifying when and where a job should be
o run.
n You can use the following methods to create job definitions:
t
• Using the graphical user interface ( GUI).
a
• Using the Job Information Language ( JIL) through a command -line
c
t interface.
mAutoSys Features
e - GUI and Command Line Interfaces
○ M- Graphical Calendar Facility
y - Automated Restart and Recovery
A- High Availability
u - Fault-tolerance
t - Load Balancing and Queue Management
o - Framework Management Integration
g - ERP Adapters Integration
r - Multiple Time Zone Support
a - Reporting Capabilities
p
h AutoSys for Unix/NT Environments
○ M- Choose the interface that fits your environment
y - Mix and match across UNIX and NT platforms with complete
B interoperability.
l - Supports Windows, Unix – Sun Solaris, Aix , Hp -Ux Redhat & Suse
o Linux
g
The AutoSys Architecture
○ M
y
The main Unicenter AutoSys JM system components are as follows:
R
· Event Server (AutoSys database)
e
a · Event Processor
d · Remote Agent
e In addition, Unicenter AutoSys JM provides utilities to help you define,
r run, and maintain instances and jobs. The included utilities are
platform-specific; however, all platforms include the graphical user
○ M
interface (GUI) and Job Information Language (JIL). Both the GUI and
y JIL enable you to define, manage, monitor, and report on jobs.
T
w
it
 t
e
r
• Open
LDAP
• Websph
ere
○ I
B
M

H
T
T
P
S Event Server
e The event server, or database, is the data repository for all system
r information and events as well as all job, monitor, and report
v definitions. Event server refers to the database where all the
e
information, events, and job definitions are stored. Occasionally, the
r
v database is called a data server, which actually describes a server
6 instance. That is, it is either a UNIX or Windows NT process, and it is
associated data space (or raw disk storage), which can include multiple
○ Mdatabases or tablespaces. Note: The database refers to the specific
e server instance and the “autosys” database for that instance. Some
s utilities, such as isql (Sybase), lets you specify a particular server and
s database, and this guide will use the more precise terms of data server
a
and database in those cases. You can configure Unicenter AutoSys JM
g
to run using two databases, or dual-event servers. This feature
e
B provides complete redundancy. Therefore, if you lose one event server
r due to hardware, software, or network problems, operations can
o continue on the second event server without loss of information or
k functionality.
e Event Processor
r
v The event processor is the heart of Unicenter AutoSys JM; it interprets
6 and processes all the events it reads from the database. Sometimes
x called the event_demon, the event processor is the program, running
either as a UNIX process or as a Windows NT service, which actually
○ Mruns Unicenter AutoSys JM. It schedules and starts jobs. After you start
Qthe event processor, the event processor continually scans the
database for events to be processed. When the event processor finds
v
one, it checks whether the event satisfies the starting conditions for
6
any job in the database. Based on this information, the event
○ Wprocessor first determines what actions to take, then instructs the
 e appropriate remote agent process to perform the actions. These
b actions might be the starting or stopping of jobs, checking for
s resources, monitoring existing jobs, or initiating corrective procedures.
p You can set up a second event processor, called the shadow event
h processor. If the primary event processor fails for some reason, the
e shadow event processor will take over the responsibility of interpreting
r and processing events.
e =========================
ARemote Agent
p On a UNIX machine, the remote agent is a temporary process started
p by the event processor to perform a specific task on a remote, or
li client, machine. On a Windows NT machine, the remote agent is a
c Windows NT service running on a client machine that is directed by the
a event processor to perform specific tasks. The remote agent starts the
ti command specified for a given job, sends running and completion
o information about a task to the event server, and then exits. If the
n
remote agent is unable to transfer the information, it waits and tries
S
e again until it can successfully communicate with the database.
r EXAMPLE Scenario in UNIX
v
e
r
v
6
○ W
e
b
s
p
h
e
r
e
A
p
p
li
c
a
ti
o
n
S Explanation
e The following steps explain the interactions in the example scenario:
r 1. From the event server, the event processor reads a new event,
v which is a STARTJOB event with a start time condition that has been
 e met. Then the event processor reads the appropriate job definition
r from the database and, based on that definition, determines what
v action to take. In the example, it runs the rm /tmp/mystuff/*
7 command on WorkStation_2.
• Websph 2. The event processor communicates with the remote agent on
ere WorkStation_2. As soon as the remote agent receives the instructions
Videos from the event processor, the connection between the two processes
• What is is dropped. After the connection is dropped, the job will run to
Middle completion, even if the event processor stops running.
ware?
3. The remote agent performs resource checks, such as ensuring that
the minimum specified number of processes are 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.
Machines
From a hardware perspective, the Unicenter AutoSys JM architecture is
composed of the following two types of machines attached to a
network:
· Server machine
The server is the machine on which the event processor or the event
server (database) reside.
· Client machine
The client is the machine on which the remote agent software resides,
and where jobs run. A remote agent must be installed on the machine
with the event processor, and it can also be installed on separate
physical client machines.
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
Access to Unicenter AutoSys JM software 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 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.

===================================
How Autosys Connects to the Database

===================================
All information is kept in a relational database (RDBMS) called the
event server, which is configured for Unicenter AutoSys JM. Access to
Unicenter AutoSys JM requires a connection to this database. That is,
you must connect to the database to add, modify, control, report on,
or monitor jobs, and to change certain configuration settings.
The following figure shows the scenario for connecting to an ORACLE
database.
===================================
Running Multiple Instances

===================================
You can run multiple instances of Unicenter AutoSys JM on the same
network at the same time. Some of the reasons you may want to run
multiple instances are listed following:
ü Your processing volume is large, and you want to distribute the load
down to the departmental level.
ü You want each department in your company to be insulated from
what happens in other departments.
ü You want to separate or test your development and production
environments.
Each instance must have its own event processor specified in the
configuration file and it must have its own instance-specific event
servers installed. Event processors from multiple instances can access
the same client machines to start jobs. To enable this, you must install
a remote agent on the client machine for each instance that will run
jobs on that machine. The following figure shows two instances of
Unicenter AutoSys JM, each with a single event server. Both instances
can send jobs to the same client machine as long as both instances
have a remote agent installed or configured on that client machine.
===================================
Running Cross-Instance Job Dependencies

===================================
A job defined to run on one instance could have as a starting condition
the successful completion of a job running on a different instance. The
specification for such a job dependency may appear as the following:
condition: success(jobA) AND success(jobB^PRD)
In this example, the success (jobB^PRD) condition specifies the
successful completion of a job named jobB running on a different
instance specified with the three-alphanumeric ID of PRD. If the
dependency specification does not include a caret (^) and a different
instance ID, the current instance will be used by default. Each time
cross-instance job dependency is encountered, Unicenter AutoSys JM
sends an EXTERNAL_DEPENDENCY event from the requesting instance.
If the target instance cannot be reached, Unicenter AutoSys JM issues
an INSTANCE_UNAVAILABLE alarm.
=============================================================
========
Event Processors and Cross-Dependencies

When you implement cross-instance job dependencies, event

processors can do the following:
ü Run on different server machines or on the same server machine.
ü Access the same client machines to start jobs.
ü Send events to other instances.
Note: If the event server of a target instance is down, the event
processor will try to resend events every five minutes until it can reach
the other instance’s event server.
============================================
High-Availability Options

============================================
Unicenter AutoSys JM provides two high-availability options that lets
Unicenter AutoSys JM keep processing even if an event server or event
processor fails due to hardware or connection problems. These high-
availability options are dual event servers and a shadow event
processor.
You can install and configure the high-availability options at the same
time you install, or you can modify an existing installation to add the
high availability options.
============================================
DUAL Event Server

============================================
One way that Unicenter AutoSys JM provides high-availability is by
running two event servers. The two event servers contain identical
information, including job definitions and events, because Unicenter
AutoSys JM reads and writes to both servers simultaneously. Unicenter
AutoSys JM also keeps both event servers synchronized and provides
complete recovery when one server becomes unusable, disabled, or
corrupted.
When processing events, the event processor reads from both event
servers. If it detects an event on one server and not the other, it will
copy the missing event to the other server. In this way, a temporary
problem in getting events to one of the servers will not interrupt
processing.

Running with Dual-Event Servers

============================================
When running within dual-event server mode, and the event processor
detects an unrecoverable condition on one of the event servers, it
automatically rolls over to single server mode. A rollover results from
one of the following conditions:
ü The connection to the database is lost, and after the configured
number of reconnect attempts, the database remains unconnected.
ü The database has an unrecoverable error, for example, the database
is corrupt or a media failure occurs.
============================================
Shadow Event Processor

============================================
Another way that Unicenter AutoSys JM provides high-availability is
through running with a shadow event processor. The shadow event
processor is designed to take over event processing in case there is a
failure of the primary event processor.
The following figure illustrates a typical configuration running with
primary and shadow event processors as well as dual-event servers.
The shadow event processor and dual-event servers are independent
features, but you can run them together.

=================
===========================
Running with a Shadow Event Processor

============================================
The shadow event processor is normally in idle mode, listening for
routine pings from the primary event processor, which indicate all is
well. If the shadow event processor stops receiving this signal, it
assumes the primary event processor has failed.
If the shadow event processor does not receive the signal, it checks
the third machine (defined in the configuration file) for the .dibs file.
If it cannot connect to the third machine, the shadow event processor
shuts down. If it can connect and cannot locate the .dibs file, the
shadow event processor creates the file, attempts to signal the
primary event processor to stop, and takes over processing the events.
If the file already exists, it shuts down.
Similarly, if the primary event processor cannot locate and signal the
shadow event processor,the primary processor checks the third
machine for the .dibs file and follows the same procedure as the
shadow event processor.
The shadow event processor is designed primarily for the situation
where the machine on which the primary event processor runs goes
down, or the network on which this processor runs goes down.
Particular care is given to ensuring that both event processors never
take over at the same time. To achieve this, Unicenter AutoSys JM uses
the third machine and the existence of the .dibs file to resolve
contentions and to eliminate the case where one processor takes over
because its own network is down.
The shadow event processor is not guaranteed to take over in 100% of
the cases where it theoretically could. For example, in the case of
network problems, Unicenter AutoSys JM may not be able to determine
which event processor is the functional one. In this case, both
processors will shut down.
============================================
Commands
============================================
=============================================================
========
archive_events

Function:
Removes old information from the database. archive_events will
optionally copy the information to an archive directory before
deletion.
Syntax :
archive_events {-n num_of_days | -j num_of_days | -l num_of_days} [-
A] [-d directory_name] [-B batch_size] [-D data server:database | -D
TNSname] [-t timeout_in_secs]
Note: –t is a UNIX command only.
Description:
archive_events removes data from various database tables that are
older than the specified number of days. You use this command to
prevent the database from becoming full. If the -A option is used; the
data is archived before it is deleted. It is copied into a default
directory unless you specify a different directory with -d option. The –
n option removes events and any alarms associated with them from the
event table. The -j option removes information from the job_runs
table.
In Dual-Server mode, the data is archived from both servers at the
same time. If information from these tables is not regularly purged
from the database, the database can fill up rather quickly, stopping all
processing. We highly recommend that you run archive_events during
the database maintenance cycle.
=================================================
autocal_asc
Function:
Adds, deletes, and prints custom calendar definitions.
Syntax:
autocal_asc
Description:
autocal_asc provides a text-based, command line mechanism for
creating, deleting, and printing custom calendars, which can be used
to specify the days on which to start jobs, or days on which a job
should not be started, for example: holidays. Each calendar has a
unique name and a list of days.
Once created, calendars can be referenced in a job definition. Use one
of the following methods to apply a calendar:
1. In the Job Definition Date/Time Options dialog, enter a calendar
name in the Run on Days in Calendar field or the Do NOT Run on Days
in Calendar Exclude field.
2. With JIL, enter a calendar name in the run_calendar or
exclude_calendar attribute.
Whenever a calendar is updated, Unicenter AutoSys JM refigures the
starting times for all jobs, which use that calendar.
==================================================
autocons

Function:
Starts the Scheduler Console.
Syntax: autocons
Description:
The autocons command starts up the Operator Console in UNIX, or the
Scheduler Console in Windows for monitoring AutoSys jobs in real-
time. You can also start the Console by clicking Ops Console in the GUI
Control Panel. The Consoles lets you specify job selection criteria,
which can be dynamically changed, to control, which jobs you want to
view. This criteria includes the current job state, the job name (with
wildcarding), and the machine on which the job runs. You can select
any job and view more detailed information about it, including its
starting conditions, dependent jobs, and autorep reports.
The Operator Console and the Scheduler Console provides an Alarm
Manager, which allows the monitoring of alarms as they are generated.
In the Alarm Manager, you can do the following:
Ø Enter responses to alarms.
Ø Set the alarm’s state—either acknowledged or closed.
===================================================
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. 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.
Example
To check whether the machine “X” is properly configured, and that its
Remote Agent can function properly,
enter: autoping -m X
If successful, the following will display:
AutoPinging Machine [X]
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 [X] AND checking the Remote Agent’s DB Access.
AutoPing WAS SUCCESSFUL!
AutoPinging Machine [Y] AND checking the Remote Agent’s DB Access.
AutoPing WAS SUCCESSFUL!
=======================================================
autorep
Function Reports information about a job, jobs within boxes, machines, and machine
status. Also reports information about job overrides and global variables.
Syntax:
autorep {-J job_name | -M machine_name | -G global_name} [-s | - w | -d | -q | -o
over_num] [-R run_num][-L print_level] [-N Retry] [-t] [-D data_server:database | -D
TNSname]
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 reloading 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.
Columns in the autorep Report
The columns in an autorep report vary with the type of report requested. The following
table describes the columns.

======================================================
========
Status Abbreviations
The following table lists the abbreviations used in the ST (status) column of the autorep
report, and gives the status for each abbreviation.
======================================================
=========
Event State Abbreviations
The following table lists the abbreviations used in the ES (event state) column of the
autorep report, and gives the status for each abbreviation.

The following summary report is for a run of the Nightly_Download example. This
command requests the report:
autorep -J Nightly_Download
Job Name Last Start Last End ST RunPri/Xit
_______________ _____________________________________ _________
Nightly_Download 11/08/2009 17:00 11/08/2009 17:52 SU 101/1
Watch_4_file 11/08/2009 17:00 11/08/2009 17:13 SU 101/1
filter_data 11/08/2009 17:13 11/08/2009 17:24 SU 101/1
update_DBMS 11/08/2009 17:24 11/08/2009 17:52 SU 101/1
The following example lists all machines defined on the data server. This command
requests the report:
autorep -M ALL
Machine Name Max Load Current Load Factor O/S
______________ ________ __________________ _____
london 100 0 1.00 Unix
berlin 90 0 0.90 NT
v_italy.rome 0 0 0.00 Unix
v_italy.venice 0 0 0.00 Unix
v_france.paris 100 0 1.00 NT
To list the value of all global variables that have been set, enter:
autorep -G ALL
The output from this command would look similar to the following:
Global Name Value Last Changed
———— ———— ——————-
AUDIT_DIR /usr/audit 11/12 /1997 12:41:00
You can use the autorep command to extract job definitions in JIL script format and direct
the output to a file. The following example shows how to save all job definitions to a file.
autorep -J ALL -q > dump_file
The output of this command is formatted exactly as a JIL job definition script, like
the following:
insert_job: test_job
job_type: c
command: sleep 60
machine: juno
#owner: jerry@jupiter
permission: gx,ge,wx
alarm_if_fail: 1
======================================================
================
autosyslog
Function:
Displays the Event processor and Remote Agent log files.
Syntax:
autosyslog [-e | -J job_name] [-p]
Description:
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.
Using autosyslog to view the event processor log is the same as issuing
the following command:
tail -f $AUTOUSER/out/event_demon.$AUTOSERV
The last 10 lines of the event processor log file are displayed when the
autosyslog command is issued. The log file is updated continually as
processing occurs. To terminate the display of the log, press Ctrl+C in
the display window. 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.
========================================================
autosys_secure
Function:
Maintains the Edit and Exec superuser ownerships, remote authentication
methods and database password. Also maintains Windows user IDs and
passwords, which are required for jobs to run on Windows client machines, and
performs eTrust AC administrative tasks.
Syntax:
autosys_secure
or:
autosys_secure [-h] [-q] {-a | -c | -d} {–u | -editu | -execu}
user@host_or_domain [-o old_password] [–p password] [-host
domain_or_host]
Description:
You use the autosys_secure command to specify the Edit Superuser and Exec
Superuser, the database password, remote authentication method, and Windows
user IDs and passwords. You can also use autosys_secure to enable eTrust
security within Unicenter AutoSys JM and perform basic eTrust administration
operations.
Edit Superuser and Exec Superuser
Two users have administrator privileges: the Edit Superuser and the Exec
Superuser.

The Edit Superuser is the only user with permission to do the following:
ü Edit or delete any job, regardless of who owns it and what permissions are set
for it.
ü Change the owner of a job.
ü Change the database password, remote authentication method, and Windows
user passwords.

The Exec Superuser is the only user with permission to:

ü Issue start or kill any job, regardless of the execution permissions on the
specified job. This user can affect how jobs run, typically by issuing the
sendevent command.
ü Shut down the Event processor (by sending the STOP_DEMON event).
=========================================================
=========================================================
===============

System States

Events
The following is the list of events that Unicenter AutoSys JM processes. Some of these events
are generated internally, while some only occur when sent manually using the sendevent
command. In effect, manual events are runtime commands for the event processor. In the
listing following, each event’s internal code assignment is provided next to the event in
parenthesis. This code number is used for viewing the event in the database event table. For
more information, see the chapter “Commands,” in this guide.
ALARM (106)
An alarm is an informational event only; it invokes no action on its own. The type of alarm is
further qualified by the value of the alarm, described later in this appendix. An alarm is
generally an internal event, but an alarm can also be sent manually if an application wants to
alert an operator.
CHANGE_PRIORITY (120)
Changes the priority of a job. If the job is in the QUE_WAIT state, it changes it immediately,
and possibly starts the job. If the job is not yet in the QUE_WAIT state, it changes the priority
for the next run of the job only. A permanent change of priority can be done by editing the
job definition.
CHANGE_STATUS (101)
Changes the value of the status for a specific job. When the event processor processes this
event, it initiates any actions that are dependent upon this status of this job. The values of
status are listed later in this appendix.
CHECK_HEARTBEAT (116)
Instructs the event processor to check all jobs that have specified a heartbeat interval to see
if any are missing. If so, a MISSING_HEARTBEAT alarm will be sent. If the event processor is
configured to do so, it will perform this check automatically.
CHK_BOX_TERM (118)
An internally generated event that instructs the event processor to check if a box job has run
for more than its Maximum Runtime (max_run_time) value.
CHK_MAX_ALARM (114)
An internally generated event, instructing the event processor to check if a job has run for
more than its Maximum Runtime value.
CHK_RUN_WINDOW (122)
A future event set to run at the end of a job’s run window, to see if the job has run or not.
COMMENT (117)
For information purposes only. This event can be associated with a job and as a result, is
displayed on reports (autorep). It is a method for generating comments at runtime and have
them be associated with a specific run of a job.
DELETEJOB (119)
Tells AutoSys to delete this job. If the job is a box, it deletes everything within the box.
EXTERNAL_DEPENDENCY (127)
Sent from an issuing instance to a different, receiving instance to signal that a cross-instance
dependency has been dispatched.
FORCE_STARTJOB (108)
Event to start a job, regardless of any conditions on this job. This event is never generated,
and should be used only in the event of system problems. Using this event, it is possible to
start the same job twice, and as a result, have two instances of the job running at the same
time. For this reason, we recommend that this command be used only with extreme caution.
Note: If you FORCE_START a job that has a status of ON_ICE or ON_HOLD, upon completion
(either success or failure), the status/condition does not change back to the previous
condition. For example: You scheduled Job-1 to run every Monday at 3:00 A.M, however, on
Sunday you placed this job ON_HOLD. If you FORCE_START Job-1 on Wednesday at 2:00 P.M.,
Job-1 will run to completion (either success or failure), and then run again as scheduled on
Monday at 3:00A.M.
HEARTBEAT (115)
The event sent from the Remote Agent posting a heartbeat for a given job. This event is
internally generated.
JOB_ON_ICE (110)
Event that instructs the event processor to place a job ON_ICE. If the job is in the STARTING or
RUNNING state, it will not place the job ON_ICE. This event is manually generated.
JOB_OFF_ICE (111)
Event that instructs the event processor to take a job OFF_ICE. If the job is in a RUNNING box,
it will attempt to start it, conditions permitting. This event is manually generated.
JOB_ON_HOLD (112)
Event that instructs the event processor to place a job ON_HOLD. If the job is in the STARTING
or RUNNING state, it will not place the job ON_HOLD. This event is manually generated.
JOB_OFF_HOLD (113)
Event to take the job OFF_HOLD. The starting of the job will continue as it was before it was
placed ON_HOLD. This method takes a job OFF_HOLD when using the AutoHold feature.
KILLJOB (105)
Instructs the event processor to kill a specific job. If the specified job is a box, it will change
the box status to TERMINATED, and, if so configured, kill the jobs within it. This event is
manually generated.
STARTJOB (107)
Event to start a job, if and only if the starting conditions are satisfied, and if it is not already
running. STARTJOB is the recommended way to start a job
======================================================================
ALARMS

The following is a list of the alarms that may be generated.

AUTO_PING (526)
The autoping -M -A command cannot connect to a client machine. The name of the machine is
listed.
CHASE (514)
The chase command has found a problem with a job that is supposedly running. The job and
the problem are listed.
DATABASE_COMM (516)
The Remote Agent had trouble sending an event to the database. The job probably ran
successfully. Inspect the Remote Agent Log file to determine what
happened.
DB_PROBLEM (523)
There is a problem with one of the databases, such as a lack of free space. This alarm can
trigger a user-specified notification procedure.
DB_ROLLOVER (519)
Unicenter AutoSys JM has rolled over from Dual-Server to Single-Server Mode. This alarm can
trigger a user-specified notification procedure.
DUPLICATE_EVENT (524)
Duplicate events have been received in the Event Server. Typically, this means that two event
processors are up and running, although duplicate events can also be caused by Event Server
configuration errors.
EP_HIGH_AVAIL (522)
Can mean that the Third Machine for resolving contentions between two event processors
cannot be reached, that the event processor is shutting down, or that
there are other event processor take over problems. This alarm can trigger a user-specified
 notification procedure.
EP_ROLLOVER (520)
The Shadow event processor is taking over processing. This alarm can trigger a user-specified
notification procedure.
EP_SHUTDOWN (521)
The event processor is shutting down. This may be due to a normal shutdown (SEND_EVENT
triggered by sendevent -E STOP_DEMON), or due to an error condition. This alarm can trigger a
user-specified notification procedure.
EVENT_HDLR_ERROR (507)
The event processor had an error while processing an event. The job associated with that
event should be inspected to see if manual intervention is required.
EVENT_QUE_ERROR (508)
An event was not able to be marked as processed. This is usually due to a problem with the
Event Server. Contact Computer Associates Technical Support.
EP_SHUTDOWN (521)
The event processor is shutting down. This may be due to a normal shutdown (SEND_EVENT
triggered by sendevent -E STOP_DEMON), or due to an error condition. This alarm can trigger a
user-specified notification procedure.
EVENT_HDLR_ERROR (507)
The event processor had an error while processing an event. The job associated with that
event should be inspected to see if manual intervention is required.
Exit Codes

When you use the autosyslog -J command to display the Remote Agent log file for a specified
job, you may see an entry containing one of the following exit codes. If the exit code contains
two numbers in parentheses, for example: (0 1), the first number is the UNIX signal, and the
second number is the exit code. If a job is killed or terminated, the exit code remains at zero,
which is what it was set to when the job started

_displayNameOrEmail_ - _time_ - Remove

_text_

Sign in Terms Report Abuse Print page | Powered by Google Sites

-------------------------------------------------------------------------------------
---------------------------
Unicenter AutoSys Job Management is an application by Computer
Associates that is used in large Enterprises for cross platform job scheduling.

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

Defining Jobs :
There are the two methods you can use to create job definitions:
¦ Using the AutoSys Graphical User Interface (GUI).
¦ Using the AutoSys Job Information Language (JIL) through a command-
line interface.

Autosys Jobs:
Job Types and Structure :

There are three types of jobs: command, file watcher, and box.
As their names imply, command jobs execute commands, box jobs are
containers that hold other jobs (including other boxes), and file watcher jobs
watch for the arrival of a specified file.
In the AutoSys environment, the box job (or box) is a container of other
jobs. A box job can be used to organize and control process flow. The box
itself performs no actions, although it can trigger other jobs to run. An
important feature of this type of job is that boxes can be put inside of other
boxes.
Default Box Job Behavior:

Some important rules to remember about boxes are:

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

Job States and Status :

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

Following are the status of Autosys jobs:

• 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 may be started (other conditions
permitting). If it is a command or file watcher job, the value means
that the process is actually running on the remote machine.
• SUCCESS : The job exited with an exit code equal to or less than the
“maximum exit code for success.” By default, only the exit code “0” is
interpreted as “success.” If the job is a box job, this value means that
all the jobs within the box have finished with the status SUCCESS (the
default), or the “Exit Condition for Box Success” evaluated to true
• FAILURE : The job exited with an exit code greater than the
“maximum exit code for success.” By default, any number greater than
zero is interpreted as “failure.” AutoSys issues an alarm if a job fails
 • TERMINATED : The job terminated while in the RUNNING state. A job
can be terminated if a user sends a KILLJOB event or if it was defined
to terminate if the box it is in failed. If the job itself fails, it has a
FAILURE status, not a TERMINATED status. A job may also be
terminated if it has exceeded the maximum run time (term_run_time
attribute, if one was specified for the job), or if it was killed from the
command line through a UNIX kill command. AutoSys issues an alarm
if a job is terminated.
• 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 to AutoSys. 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 on "on hold"—nothing downstream from this job will
run.

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

1. insert_job: template job_type: c

2. box_name: box1
3. command: ls -l
4. machine: localhost
5. owner: lyota01@TANT-A01
6. permission: gx,ge,wx,we,mx,me
7. date_conditions: 1
8. days_of_week: all
9. start_times: “15:00, 14:00″
10. run_window: “14:00 - 6:00″
11. condition: s (job1)
12. description: “description field”
13. n_retrys: 12
14. term_run_time: 60
15. box_terminator: 1
16. job_terminator: 1
17. std_out_file: /tmp/std_out
18. std_err_file: /tmp/std_err
19. min_run_alarm: 5
20. max_run_alarm: 10
21. alarm_if_fail: 1
22. profile: /tmp/.profile
Explanation of each line:
1. Insert_job: this will let the autosys server to recognize the job and inserts into
autosys DataBase. Jobtype: there are two types of jobs namely box and child
( c=child, box)
2. box_name: this is the box job name: box job can have more than 1 child jobs. (this
is just like grouping the jobs).
3. commands: this is where you tell autosys, what to do when the job runs. ( you’ll give
reference to your scripts here).
4. machine: name of the machine where you want to run the job.
5. owner: owner of the job.
6. permissions.
7. date_conditions: 1 if you have any specifications.
8. days_of_week: on which days of the week you want the job to run.
9. start_time: the time at which the job should kick-off.
 10. run_window: this option is for monitoring jobs. the job will run continously for the
specified time window.
11. conditions: here you can specify the dependencies. like success of some other job.
12. description.
13. n_retrys: no of retrys on a failure.
14. term_run_job: the job will terminate if it runs for specified time.
15. box_terminator: if 1, terminates box job depends on term_run_time.
16. job_terminator: if 1, terminates child job depends on term_run_time.
17. std_out_file: standard output file (log) for the job
18. std_err_file: Error log file if the job fails
19. min_run_alarm: if the job terminates/completed with in that time it generate an
alarm
20. max_run_alarm: if the job runs for more than the specified time, it generate an
alarm
21. alarm_if_fail: generates an alarm if the job fails
22. profile: the file where you can keep all your variables (variable names)
We don’t use all the above options in all the jobs, it depends on the requirements.

Here is a sample job which will verify a particular process is running or not.
/* —————– SAP_UAT_MU03_C —————– */
insert_job: SAP_UAT_MU03_C job_type: c
command: /local/SAP/processCheckUAT.sh
machine: MU03-UAT
owner: admin@MU03-UAT
permission: gx,wx,mx,me
days_of_week: all
start_times: “15:00, 14:00″
description: “Job used for Run testing of process”
alarm_if_fail: 1
max_exit_success: 1

To Insert a new JIL code :

issue command "jil"
bash-3.00$ jiljil>>1>
"The following prompt will appear" copy paste the jil code u have made
example of jil code below...........
At the end the "C" or "B" determines if the job is box job or child job.
if the jil is inserted properly successfull message will come if any errors are
there the jil code contains some errors..
if successfull exit;
Using Autorep command:
Function
Reports information about a job, jobs within boxes, machines, and machine
status. Also reports information about job overrides and global variables.
Syntax
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o
over_num] [-r run_num]

autorep -J (job name here)

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

autorep -J (job name here) -q

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

To obtain the information of previous runs

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

would generate a report for the job run one runs back

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

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

sendevent:
sendevents to AutoSys for a variety of purposes, including starting or
stopping AutoSys jobs, stopping the Event processor, and putting a job on
hold. This command is also used to set AutoSys global variables or cancel a
scheduled event.

sendevent is normally used with "-E" & -J option

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

-E event :Specifies the event to be sent. This option is required. Any one of
the following events may be specified:

STARTJOB
KILLJOB
DELETEJOB
FORCE_STARTJOB
JOB_ON_ICE
JOB_OFF_ICE
JOB_ON_HOLD
JOB_OFF_HOLD
CHANGE_STATUS
STOP_DEMON
CHANGE_PRIORITY
COMMENT
ALARM
SET_GLOBAL
SEND_SIGNAL

Following are the example of sendevent command frequently used.

To start or force start a job manually using sendevent :

sendevent –E FORCE_STARTJOB -J "Job Name Here"

sendevent -E STARTJOB -J "Job Name Here"

To put jobs on OFF ICE or ON ICE :

sendevent -E OFF_ICE -J "Job Name Here"

sendevent -E ON_ICE -J "Job Name Here"

autostatus: Reports the current status of a specific job, or the value of an

AutoSys global variable. Ex: autostatus -J job_name, -S instance

AUTO SYS CHEAT SHEET

AutoSys: UNIX

Cd to the "autouser" ($AUTOUSER) directory and "." (or source) the "ksh" file. Ex: ".
./autosys.ksh.machine" After installing AutoSys, first make sure that the DB is up and running.
Check the installation by running the command chk_auto_up to 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 (and 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 > file_name queries the DB & save job Dfn. Into a file
vi file_name
When you want a report of a box use the -L0 option
Autorep -J job_name -l1 report on the job for the day -1 (prev day)

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 var)
(ex: sendevent -E SET_GLOBAL -G "var_name=DELETE" to delete a var)]

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 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 the machine
where the server resides if used with the -e option. Else it can be used 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 programs
previously created using the monitor/browser GUI.exec superuser: AUTOSYS superuser

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 AutoSys global
variable. Ex: autostatus -J job_name, -S instance

autotimezone -l : Allows additions, deletions, and queries to the timezones table (-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 using the autotrack utility type:
autotrack -u to set tracking level 1 or 2. By default 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,
machine, 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 omitting 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 user definable buttons
to view PeopleSoft job: Autocons*userButton1Label: Adapter Status

User definable buttons: There are user definable buttons in the operator's console.

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. Make 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 communicate with
the internet daemon (inetd) running on that machine..

Dashed red line: Hostscape can't communicate with the client machine at all. Client is probably
down.

Accessing a variable name: $$GLOBAL_VAR_NAME (unless used in dependency condition

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 runs a program
called DBMaint. This is user configurable. The program runs DBstatistics 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 name.
$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 where 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. Usually 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 usage, etc.

Testing:
zql
zql -U autosys -P autosys

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

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