Notes on Autosys 4.5
System Components
The following are the main system components:
- Event server (database)
- Event processor
- Remote agent
In addition, AutoSys JM provides utilities to help you define, run, and maintain instances and jobs.
GUI and JIL are available to define, manage, monitor, and report on jobs.
Communication component
Windows client (Remove agent with jobs
autosys server (unix/win) which is event processor/ event server database.
Unix client (remove agent, unix job)
autorep command allows you to generate a variety of reports about job execution, and
sendevent command allows you to manually control job processing.
---------------------------------
job condition
(success(JobA) and success(JobB)) or (done(JobD) and done(Job E))
the above job will be evaluated from left to right and the result would be A and B or D and E.
This is the syntax for conditions based on job status:
status(job_name)
where:
status is one of 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.
job_name: Is the job on which the new job is dependent.
You can abbreviate the status condition identifiers with the first letter, using s, f, d, t, and n. You can also abbreviate the dependency specification exit code with the letter e and VALUE (of a global variable) with the letter v. These abbreviations can be upper- or lowercase.
------------------------------
condition: success(jobA) AND success(jobB^PRD)
The success(jobB^PRD) condition specifies the successful completion of a job named “jobB” running on a different instance specified with the three-letter 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.
For a job that runs only if the job named “DB_BACKUP” succeeds, the job dependency specification would be written as follows:
success(DB_BACKUP)
or:
s(DB_BACKUP)
------------------
You can specify more complex conditions by grouping the expressions in parentheses. The parentheses do not imply any sort of precedence; they are simply used for grouping. For example, if “JobC” should only be started when both “JobA” and “JobB” complete successfully or when both “JobD” and “JobE” complete, regardless of whether they failed, succeeded, or terminated, you would specify the following dependency in the job definition for “JobC”:
(success(JobA) AND success(JobB)) OR (done(JobD) AND done(JobE))
or:
(s(JobA)&s(JobB))|(d(JobD)&d(JobE))
exit code with the letter e
-----------
if “JobB” fails after processing only partially, you might want to call a routine titled “Backout” that backs out of the changes that were made. You would specify the following job dependency in the job definition for “Backout”:
failure(JobB)
or:
f(JobB)
-------------
You use the notrunning operator to keep multiple jobs from running simultaneously (that is, running one job is exclusive of any others). For example, it might be best not to run a database dump (“DB_DUMP”) and a file backup (“BACKUP”) at the same time. This would cause the hard disk to be accessed very frequently. However, you might have a smaller job that can run as long as both of these resource-intensive jobs aren’t running. You would specify the smaller job’s dependency like this:
notrunning(DB_DUMP) AND notrunning(BACKUP)
Note: If you have jobs that you want to run exclusively, use the virtual machine and job queuing feature described in the chapter “Load Balancing and Queuing Jobs,” in this guide.
---------
