Instituciones

Adding Machines

The insert_machine sub-command adds a new machine definition to the database for one of the following:

■ Real machine ■ Virtual machine ■ NSM

■ Universal Job Management Agent ■ Unicenter AutoSys JM Connect

The machine type can be specified as either r for real, v for virtual, n for

Windows, t for NSM or a Universal Job Management Agent, and c for Unicenter AutoSys JM Connect. The component real machines in a virtual machine

definition must be all of the same type, for example, all UNIX machines or all Windows machines (not a mix).

If the machine being defined is a virtual machine, the insert_machine sub- command is followed by one or more machine attributes that specify real machines.

jil

insert_machine: (machine_name bocovic) Type: t

Exit:

Database change was successful.

machine_name Specifies the unique name of the machine to be defined. It can be from 1-30 alphanumeric characters, and is terminated with white space; embedded blanks and tabs are illegal.

The default type is UNIX (n or v), if no type is specified.

Any machine accessible through the TCP/IP protocol can be specified in the machine attribute of a job; it need not be explicitly defined using the

insert_machine command. However, any undefined machine will have a default factor of 1.0 and no max_load, meaning that there will be no limit on the job load assigned to it.

Changing a Job

Any machine defined in the /etc/hosts file on the machine running the Event Processor can be specified in the machine attribute of a job; it need not be explicitly defined using the insert_machine command. However, any

undefined machine will have a default factor of 1.0 and no max_load, meaning that there will be no limit on the job load assigned to it.

Changing a Job

To place an existing job in a box, you need to change the EOD_post command job that was created previously. You will place the EOD_post job in the newly created box.

You should make sure a job is not running before you modify or delete it. To change a job, you can either use the update_job subcommand, or you can delete the job definition, using the delete_job subcommand, then redefine the job using the insert_job subcommand. The latter scenario is particularly useful when many non-default attributes have been specified, and you want to unset them rather than reset them; in other words, you want to deactivate them. However, you will have to respecify any of the attributes that need to remain the same. So, in the example following, you will use the update method. The JIL script required to change the EOD-post job and to put it in the EOD_box as follows: update_job: EOD_post

condition: NULL box_name: EOD_box This JIL script instructs:

■ To update the job named EOD_post.

■ Remove the starting condition from the job definition, because the job will

inherit the starting condition of the box in which it is placed.

■ Put the job named EOD_post in the box named EOD_box.

The EOD_post command job is now in the EOD_box box job, and has inherited starting parameters of the box.

Setting Time Dependencies

Setting Time Dependencies

The test_run job you specified at the beginning of the chapter has no starting conditions. Therefore, it will only run if it is started using the sendevent command. To set the job to run automatically on certain days at a certain time, such as 10:00 a.m. and 2:00 p.m. on Mondays, Wednesdays, and Fridays, you would modify the job using the JIL script as follows:

update_job: test_run date_conditions: y days_of_week: mo, we, fr start_times: 10:00, 14:00 This JIL script instructs:

■ To update the job named test_run. ■ Activate the conditions based on date.

■ Set the job to run on Mondays, Wednesdays, and Fridays.

■ On each of these three days, start the job at 10:00 a.m. and 2:00 p.m.

The times shown in the script previously are quoted, since they contain a colon. They could also have been escaped by using backslashes, as follows:

start_times: 10\:00, 14\:00

Additional Time Setting Features

If you wanted the time settings for the job based on a specific time zone, you would use the timezone attribute. If you specify a time zone that includes a colon, you must quote the time zone name like:

timezone: IST-5:30

If you do not quote a time zone that contains a colon, the colon will be interpreted as a delimiter, producing unexpected results.

Setting Time Dependencies

If you had wanted to run the job every day, rather than only on specific days, you could have specified the all value, instead of listing the individual day values. Or, if you had wanted to schedule the job for specific dates, rather than specific days of the week, you could have specified a custom calendar. First, you would have had to define the calendar, using the Graphical Calendar Facility, or the autocal_asc command. Then, you would specify the calendar name,

weekday_cal, using the following JIL statement: run_calendar: weekday_cal

You could have specified a custom calendar specifying the days on which the job was not to be run, holiday_cal, using the following JIL statement:

exclude_calendar: holiday_cal

If you wanted the job to run at specific times every hour, as opposed to specific times of day, the minutes past every hour could have been specified. For example, to run a job at a quarter after and a quarter before each hour, use the following JIL statement:

start_mins: 15, 45

Note: If a job runs daily at the same time (example: 12:00) and you edit this job definition and save this job at (11:59), the job will not run today but will run tomorrow at (12:00).

When a start time job definition is written to the database within one minute of the current runtime, the start time will be placed in the future, meaning

tomorrow. However, if the start time is two minutes or greater from the current save time the job will run today.

Deleting a Job

Deleting a Job

Now you will delete the test_run job, which you specified at the beginning of this chapter. To delete the test_run job, enter the following JIL sub-command: delete_job: test_run

The delete_job sub-command checks the job_cond table and notifies you if dependent conditions for the deleted job exist. This functionality only works when JIL is in job verification mode (which is the default mode).

Deleting a Box Job

To delete a box, and recursively delete every job in that box: Use the delete_box subcommand as follows:

delete_box: EOD_box

To delete a box, but leave its contents intact:

Use the delete_job subcommand on the box as follows: delete_job: EOD_box

You can configure a number of other attributes using JIL. These attributes are described in detail in the chapter JIL/GUI Job Definitions in the Unicenter AutoSys Job Management for Windows and UNIX Reference Guide. This reference chapter provides complete information on all job attributes specified using JIL.

Specifying One-Time Job Overrides

Specifying One-Time Job Overrides

Using JIL, you can specify a job override for the next run of a particular job. In other words, the next time a job runs, you can change its behavior. Job overrides are applied only once. If a RESTART event is generated because of system problems, Unicenter AutoSys JM will reissue a job override until the job actually runs once, or until the maximum number of retries limit is met. After this, the override is discarded.

Notes:

The maximum number of job restarts after system or network failure is specified in the MaxRestartTrys parameter in the configuration file.

One-time job overrides will be applied to jobs restarted due to system problems, but will not be applied to jobs restarted because of application failures. System problems include such things as machine unavailability, media failures, or insufficient disk space. Application failures include such things as inability to read or write a file, command not found, exit status greater than the defined maximum exit status for success, or various syntax errors.

The following attributes can be modified in a job override:

Attributes

auto_hold min_run_alarm std_in_file command n_retrys std_out_file condition profile term_run_time date_conditions run_calendar watch_file

days_of_week run_window watch_file_min_size exclude_calendar start_mins watch_interval

machine start_times max_run_alarm std_err_file

JIL will not accept an override if it results in an invalid job definition. For example, if a job definition has only one starting condition, start_times, JIL will not allow you to set the start_times attribute to NULL because removing the start condition makes the job definition invalid (no start time could be calculated).

Specifying One-Time Job Overrides

Setting Job Overrides

To set job overrides, you use the override_job subcommand; you only need to specify those attributes that you want to override. Using this command, you can also temporarily delete a job attribute.

For example, if you wanted to run a job named RunData with no conditions (where some had been previously specified) and you wanted to output the results to a different output file, you would enter a JIL script as follows: override_job: RunData

condition: NULL

std_out_file: /usr/out/run.special

To cancel the job overrides specified in the script previous, you would enter the following JIL script:

override_job: RunData delete

Note: Once you have submitted a JIL script to the database, you cannot view the JIL script and edit a job override. If you want to change the override values, you must submit another JIL script with new values, or use the GUI. However, the original override (that is, the first over_num) remains stored in the overjob table in the database.