A job definition is composed of several basic pieces. Not all the pieces are needed for every job. The basic pieces are listed below.

• Rescheduling attributes - Each job can specify a rescheduling method. There are three distinct methods available. The first is based on a start time and an interval (e.g. run the job every ten minutes). The second is based on the name of day (e.g. Monday, Tuesday ...) and the time of day to run the job. The third is based on a marked calendar (e.g. all days marked with an "X") and the time of day to run the job.
• Resource requirements - With each job two types of resource requirements can be specified. They are the amount of disk space required and the presence of a specified file.
• A list of commands - With each job a list of commands can be specified. These are the commands that invoke the application that this job is designed to perform.
• Submit attributes - All jobs when they are submitted into a batch queue for execution are submitted with a series of attributes. These attributes define what queue to use, where to place the log file, what working set parameters to use and all other options .
• Notification parameters - As jobs progress through the system events can occur that can cause a notification message to be sent to a designated user or users. The known events are submitted, started, delayed, completed and failed. Each event can result in either a mail message or a broadcast message being sent.
• A list of notices - With each job additional information can be specified that is included in any notification message that are sent by the system. This is particularly useful in informing a user or operator what to do if a particular job is delayed or fails.
• A list of jobs to initiate - With each job a list of other jobs that are to be initiated when this job completes can be specified. A condition can be assigned to each initiate job (i.e. start job B if a failure occurs).
• A list of prerequisite jobs - With each job a list of other prerequisite jobs that must complete successfully for this job to be started can be specified. A prerequisite holds back the job until it is satisfied.
• A distribution list - A printout distribution list can be specified with each job. This allows a series of lpr (any other command such as mail or cp will work just as well) statements to be maintained separately from the main body of commands associated with the job.
• Other attributes - Several other attributes can be specified for each job. They include such items as an access control list, a pre-execution or post-execution command, a startup time window and an execution time window.

SCHEDULE allows you to specify which jobs must be completed before another job is initiated, as well as to define which are to start when a current job ends. This allows conditional branching within a job set without recourse to complex application programming, and provides the ability to handle `interdependencies'. A wide variety of `if-then-else' scenarios can be specified between jobs, enabling the system manager to build in automatic error correction when a program fails.

Applications can be developed into highly reliable `fault tolerant' job sets, which are ideally suited to the emerging trend for `lights out' operations and `hands off' solutions. By taking remedial action automatically when a fault occurs and re-running the jobs through to their termination, SCHEDULE eliminates the need for regular operator attendance, and makes applications effectively self-correcting.

1.5.1 Initiate jobs

A job can have any number of initiate jobs. On the completion of a job all initiate jobs are readied for execution.

Figure 1-1 Initate Job example

For example in Figure 1-1 when Job A completes, Job B is readied and is immediately submitted for execution. When Job B completes Jobs C and D are ready and are submitted immediately for execution.

Each initiate branch can be conditioned only to occur under certain circumstances. The conditions are based on the completion code of the job. The severity level (success, warning, error and fatal) or the numeric value of the code can be specified.

1.5.2 Prerequisite jobs

A job can have any number of prerequisite jobs. A job cannot be submitted into a queue until all prerequisite jobs have completed successfully.

Figure 1-2 Prerequisite job example

For example in Figure 1-2 Job D cannot be submitted until Jobs B and C have completed successfully. Job B cannot be submitted until Job A has completed successfully.

1.5.3 Combinations of initiates and prerequisites

A combination of prerequisite and initiate jobs can be used to control a set of jobs.

Figure 1-3 Combination of Initiates and Prerequisites

In Figure 1-3 Job A is used to trigger the entire set of jobs. Job B and C are immediately submitted on the completion of Job A. Job D even though readied for execution by the completion of Job A will wait until Jobs B and C are completed before it is submitted into a queue. On completion of Job D, Job E is submitted for execution.

1.6 Rescheduling methods

SCHEDULE allows you to select which jobs are to be run, specify their start times and to schedule them at regular intervals, define a specific day of the week or month to initiate the job. You can also create schedule calendars that recognize national holidays and weekends when jobs are not to run, as well as fiscal calendars.

The flexibility of SCHEDULE is ideal for customizing jobs to a company's specific requirements and for multi-national companies with distributed processing who need to allow for varying national holidays. You can also instruct SCHEDULE not to run jobs until a minimum amount of disk space is available or until required files are available ensuring fast and reliable processing.

Many of the concepts mentioned in other chapters of this manual are expanded here. SCHEDULE line commands are used here for simplicity to illustrate the examples, but in most cases the Windows GUI, MOTIF or Web client interfaces may also be used to perform the same operations.

2.1 Job characteristics

Several of the attributes that are associated with each job are further explained in the following sections.

2.1.1 Job rescheduling

Any job that is using time based starts will have a rescheduling method established. When the start time of a job occurs the job is initiated and the next start time is identified using the declared rescheduling method. There are three distinct methods that can be used.

Method	Description
Named day	Select the start days by their names.
Interval	Specify a start time and interval.
Marked Calendar	Marks on calendar indicate start days.

It is important to keep in mind that these are REscheduling methods. A job must first be given a start time and be allowed to initiate before a rescheduling decision is made by the system. If a job does not already have a start time, use the following commands to set the start time to the next future rescheduled run time.

Schedule> chjob job_name -general=next_start=now+0:10 Schedule> increment job_name -log

All rescheduling methods examine the calendar assigned to the job. If runs are disallowed on the calendar on the day that the job should run then the system adds 1 day and attempts the operation again. If the calendar is a work day calendar then only work days are considered, i.e. the tenth day of the month on a work day calendar is the tenth work day not the tenth standard calendar day.

2.1.1.1 Named day rescheduling

Various names are known to the system. They are listed below.

MONDAY	MONTH_START
TUESDAY	MONTH_END
WEDNESDAY	YEAR_START
THURSDAY	YEAR_END
FRIDAY	445
SATURDAY	454
SUNDAY	544

For example a report must be generated every Monday, Tuesday and Friday mornings. The following command will establish this type of rescheduling.

Schedule> chjob start -resched=(named=(mon,tues,fri),time=8:00)

Along with the name of the day a time-of-day can be specified. The time-of-day can contain a number days. For example to start a job on the third day of each month use the following type of command.

Schedule> chjob start -resch=(named=month_start,time=3-00:00)

The various known names are discussed below:

• DAY NAMES: The day names (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday) just represent that day of each week. The job will then be repeated on that same day each week at the designated time.
• MONTH NAMES: Month_start just indicates the first day of each month. Month_end just indicates the last day of each month.
• YEAR NAMES: Year_start indicates the first day of the first month of the year. Year_end indicates the last day of the year. The first month of a year is provided by the Fiscal setting for a given calendar. It can be any month of the year. The default is January.
• 445: The 445 represents an accounting quarter of four weeks, four weeks and five weeks. The first time the job is incremented the start time is advanced FOUR weeks and the rescheduling interval is set to 454. The second time the start time is advanced FOUR weeks and the interval set to 544. The third time the start time is advanced FIVE weeks and the interval set to 445 again.

2.1.1.2 Interval rescheduling

Schedule> chjob twenty -general=next_submit:now - -resch=(interval:0:20,calendar=workdays)

2.1.1.3 Marked calendar rescheduling

Schedule> chcal special -date=16-june -mark=r Schedule> chjob test -resch=(mark=r,calendar=special,time=8:00)

2.1.2 Resource requirements

Each job in the SCHEDULE database can specify either or both disk space and a file requirement. If more then one file or one disk is required multiple job entries can be strung together. The first job, once requirements are satisfied, initiates a second job which then waits for another set of requirements. ¹

The disk space requirement is specified as the number of free blocks that must exist on a specified disk volume before the job is allowed to proceed to the next scheduling state. For example to specify that a job must have 100,000 blocks of space on DUA1: before starting use the following command.

Schedule> chjob analysis_job -resource=disk:(dua1:,100000)

The file requirement is specified as a single file that must be found on the system before the job is allowed to proceed to the next scheduling state. For example to have this same job not start until the input file INDATA.DAT is present, use the following command.

Schedule> chjob analysis_job -resource=file:sys$login:indata.dat

2.1.3 Line Commands

Each line specifies a command. The format of each line is detailed below:

General format: UNIX_commands . . .

The commands associated with a job can be displayed by using the more command:

Schedule> more -commands /demo/a/update_b /demo/a/update_b # These are the commands for update_b # update_program

The success or failure of a job is determined by checking the terminating status code of the job. This status code is obtained in different ways depending on how the job terminates.

CASE 1: A particular job just needs to run a single program. The command associated with this job is:

special_program

The above single line is the entire job. This program returns a completion status to the system on exit. The SCHEDULE System will then pick up this last status value and use it to represent the completion status for the job.

CASE 2: A particular job entails executing several commands and explicitly specifying the completion status. The commands associated with this job are:

# Some processing has been done and the # procedure arrives at one of the below # exit points. # it_works_okay status = 1 # any odd number signifies success done # it_failed status = 0 # any even number signifies failure goto done # any standard error code can be used # done

CASE 3: A particular job requires executing a standard command procedure. The completion status will be provided by this procedure. The command associated with this job is:

do_my_job

The DO_MY_JOB procedure contains the following commands:

# some processing has been done and the # procedure arrives at one of the below # exit points. # it_works_okay exit 1 # any odd number signifies success # it_failed exit 0 # any even number signifies failure

The EXIT command in the above procedure returns a completion status to the point of invokation . Since that procedure immediately ends this value is then passed back to the SCHEDULE System and used as the completion status for the job.

Certain environment variables are automatically established when the job is executed. The various environment variables are:

Symbol	Description
SCHEDULE_FULL_NAME	job name and directory
SCHEDULE_NAME	job name
SCHEDULE_SET_ID	current set id. number
SCHEDULE_SET_TAG	current set tag value
SCHEDULE_SET_PARAMETER	current set parameter value
SCHEDULE_STEP	current job step
SCHEDULE_ENTRY	scheduling queue entry number
SCHEDULE_RESTARTING	0/1 restarting flag
SCHEDULE_RESTART_COUNT	number of restarts done
SCHEDULE_RESTART_LIMIT	maximum allowed restarts

All the above environmental variables are defined and are available throughout the execution of the job.