AutoSys Doc

  • View
    408

  • Download
    6

Embed Size (px)

Text of AutoSys Doc

AutoSys IntroductionAutoSys 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 UNIX batch file. Each AutoSys job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run. In addition, AutoSys provides utilities to help you define, run, and maintain AutoSys instances and jobs. The included utilities are platform-specific; however, all platforms include the AutoSys graphical user interface (GUI) and Job Information Language (JIL). Both the GUI and JIL enable you to define, manage, monitor, and report on jobs.

What is a Job?A definition you create that instructs the system what command, executable, or batch file to runNote: In AutoSys JM 4.0, the Job name may be no more than 30 characters in length. However, in

AutoSys JM 4.5 the Job name may be more than 80 characters in length. No spaces are permitted, but you may use dashes, underscores, and periods.

What is an Event?Any status changes posted to the database are called Events.

The following sections discuss the main AutoSys system componentsEvent ServerThe Event Server, or AutoSys database, is the data repository for all system information and events. Event Server refers to the database where all the AutoSys information, events, and job definitions are stored. Occasionally, the database is called a data server, which actually describes a server instance. It is associated data space (or raw disk storage), that can include multiple databases or table spaces.

Event ProcessorThe Event Processor is the heart of AutoSys; it interprets and processes all the events it reads from the AutoSys database. Sometimes called the event demon, the Event Processor is the program that actually runs AutoSys. It schedules and starts jobs. The Event Processor continually scans the database for events to be processed. When it 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.

Remote AgentThe Remote Agent is a temporary process started by the Event Processor to perform a specific task on a remote, or client, machine. The Remote Agent starts the command specified for a given job, sends running and completion information about a task to the Event Server, 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.

Example ScenarioThe example scenario in Figure-1 below and the numbered explanations that follow it illustrate the interactions between the Event Server, the Event Processor, and Remote Agents. In the example, the following UNIX command line is to be run on WorkStation_2, at the start date and time specified in the AutoSys job definition: rm /tmp/mystuff/*

Understanding this example will help you answer many questions that might arise during your experiences with AutoSys.

Figure

Note

In the example above, the three primary components are shown running on different machines. For UNIX, the Event Processor and the Event Server typically run on the same machine.

ExplanationThe following steps explain the interactions in the example scenario: From the AutoSys Event Server, the Event Processor reads a new event, which is a start job 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. 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. 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. The command completes and exits, and the Remote Agent captures the command s exit code. The Remote Agent communicates the event (exit code, status, etc.) directly to the Event Server. If the AutoSys 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 AutoSys processes need to be running: the Event Processor and the Event Server. When these two components are running, AutoSys 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 sends a completion event to the database, the Remote Agent exits. Events Sent by Users By using the Send Event dialog, you can send execute events that affect the running of a job. These are the execute events that you can send, if you have the appropriate permissions:

STARTJOB FORCE_STARTJOB KILLJOB DELETEJOB CHANGE_STATUS JOB_ON_HOLD JOB_OFF_HOLD JOB_ON_ICE JOB_OFF_ICE

Note: Make sure you understand the consequences of EVENTS prior to execution of the events.

In addition to sending execute events on jobs, you can schedule jobs to start at certain times or under certain conditions. When a job is scheduled to start automatically, permissions are checked on the Remote Agent machine on which the job is to run. The AutoSys Event Processor scans the Event Server for any jobs with starting conditions that have been met. When the starting conditions for a job are met, the Event Processor sends a STARTJOB event to the designated Remote Agent machine.

What are Alarms?Alarms signal situations requiring your attention and are informational only. Alarms are sent through the system as an event. Jobs can be scheduled to run based on a number of conditions, but some thought is required to address incidents that require manual intervention. For example, a set of jobs could be dependent on the arrival of a file, and the file is long overdue. It is important that someone investigate the situation, make a decision, and resolve the problem. Below table shows when an alarm may get generated.

Alarm Manager : Lets you view, acknowledge, and close alarms.

AutoSys User Types AutoSys uses the notion of these three types of users for any job: Owner. The user who created the job. Group. Any user who is in the same primary group as the owner. World. Every user.

AutoSys uses the ID (uid) and group ID (gid) of a job s owner to control the following: Who can edit, override, or delete a job definition. Who can execute the UNIX command specified in a job.

The owner of a job can allow other users to edit and execute the job by setting the permissions in the job definition (discussed in the next section). AutoSys Permission Types By default, only the owner has edit and execute permissions on a job, and all edit and execute permissions are valid only on the machine on which the job was defined. However, the owner can grant

different types of permissions when defining a job. Similar to UNIX, AutoSys associates different types of permissions with each job. Every job has the following permission types: Edit. Users can edit, override, or delete a job definition. Execute. Users can send an execute event that affects the running of a job by using the sendevent command or the Send Event dialog. Machine. Users logged onto a machine other than the one on which a job was created can edit or execute the job. In order for a job to run on a machine other than the one on which the job was defined, the owner of that job must have an account on that machine.

Note

Job Types and Structure Figure 2 illustrates the structure of a job. There are three types of jobs: 1) Command 2) File Watcher & 3) Box These job types have a majority of job attributes in common, and AutoSys treats them all similarly. The primary differences between them are the actions that are taken when the job is run.

Figure 2

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.

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 this type of job is run, the result is the execution of a specified command on a client machine. When all the starting conditions are met, AutoSys 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. In addition to the primary functionality. FileWatcher 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. Using File Watcher Jobs provides a means of integrating events which are external to AutoSys into the processing conditions of AutoSys jobs. For example, a file needs to be downloaded from a mainframe, and it is expected to arrive after 2:00 a.m. After it arrives, a batch job is t