scheduler can do
steps within a job
job can consist of many steps, each running a different
step waits for the previous step to run before it starts.
job can be scheduled to run every minute, hour, day,
month, or any other specified time frame.
jobs can be scheduled to wait for another job to finish
before it executes.
the scheduler cannot do
dependent jobs: If
you have a job that runs every night and another that
depends on it, the dependent job will run the first time,
but not again after that.
a job that has crashed: If
a job crashes on step 1, the whole job stops, and there is
no way to continue processing.
from certain job steps: If
your job crashes at step 2, there is no facility to
re-run, without changing the job and removing step 1 so it
does not run again.
for a Batch Input Session: If
you run a job which runs RSBDCSUB, the second step will
not wait for the batch input session to process, as it is
executing in a separate job.
Suggested methods for processing
a self-scheduling job: A
program can be set up to re-schedule itself in a job after
a specified time. This
is more flexible than a periodic job.
that create other jobs: An
alternative to dependent jobs, is to run a program in the
first job which will create the next job.
that wait for other jobs: You can write a custom program
that waits for a specified job, and runs a batch input
this as a step in your job after a batch input session has
and Success messages: Write
the message text to the job log. Program
and job continues as normal.
and Abend messages:
Write the message text to the job log. Stop
the current program from running. Cancel the entire job.
-> any dependent programs must be scheduled in a
Suggested methods for error handling & reprocessing
If subsequent steps in a job are not dependent on the first
one finishing successfully, the first program should
be set up to crash using a success message followed by the
Before every error message, call a routine which notifies
the ‘Operations Center’ of error type,