Previous | Contents | Index |
A job definition is composed of several basic pieces. Not all the pieces are needed for every job. The basic pieces are listed below.
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:
2.1.1.2 Interval rescheduling
Interval rescheduling entails giving the job a start time and an
interval. Once the job starts the next start time is
determined by adding the interval to the current start time. For
example to setup a job that starts now and repeats every 20 minutes on
all workdays use the following type of command.
Schedule> chjob twenty -general=next_submit:now - -resch=(interval:0:20,calendar=workdays) |
2.1.1.3 Marked calendar rescheduling
The marked calendar rescheduling method indicates that a job is to be
run on all days marked with a certain letter on the designated
calendar. Each day of a calendar can be marked with one or two letters.
For example to set up a job to run on June 16 use the following
commands.
Schedule> chcal special -date=16-june -mark=r Schedule> chjob test -resch=(mark=r,calendar=special,time=8:00) |
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. 1
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 job can have a script associated with it. These jobs can do
anything any ordinary UNIX job can.
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.
1 A job entry that does not contain any script commands is treated differently from one that does. Such a job is never submitted for execution and is treated as having successfully completed when it comes time to submit it. This is the type of job entry that would be used to implement multiple disk or file requirements. |
Previous | Next | Contents | Index |