Skip to main content

Job abend restart process guidelines


    When any job abends, the first thing we need to do is identify the reason for the failure of the job.Once the reason is found then you need to see whether any data correction/data deletion to be done.Some times you may have to do program change to correct the failure.

Once after correcting the problematic data or issue one has to decide from where the job need to restart.

Options for restarting jobs.
  • Restart from the same abended step
  • Restart form any earlier step
  • Restart form top
  • Bypass the abended step and continue from next step
  • Mark the job as completed.

1.If there is no dependency with earlier steps then the abended job can be restarted from the same step.

2.If any temporary data sets are used in the abended step,then we will have to find from where they are getting created in the job.If that file is created two steps earlier then you may have to restart the job from that step where the temporary data set is getting created. We should refer restart instruction before restarting the job.

If the abended step uses an input file which gets created in earlier steps and if that data in the file creates a problem,then you either need to correct the data or correct the program to create a new file with proper data.If only data correction to the file is needed then you can restart from the abended step itself.
But if the program to be changed,then the job to be restarted from the step where the program is used.

3.When it is decided to run from some earlier steps,then it might give file issues due to output files being created in earlier run(during the run when the job failed). In that case if there is no further impact the job can be rerun from TOP (generally file deletion will be the initial step).

4.In some cases the abended step can be ignored and the job can be restarted from next step.
If the abended step has a program which gets data only from tables and if any issue,then that can be checked in the next run as well as the same data will be picked till that gets processed.
Before the next run of the job,the problematic data can be corrected so that there won’t be any issue.

5.If the abended job doesn’t do any important processing or not a mandatory job to be run  then the entire job can be marked as complete so that next job in the stream can start running.

Note: Refer to restart instruction specified in the JCLMSG before restarting the job.

Comments

Popular posts from this blog

Restarting a abended job in CA7

To restart the job, type xQ command to get into the CA7 Queue Maintenance. Tab down to the job you want to restart, type an 'F' beside it, and hit the Enter key. You will get into restart panel. Options for restarting the job: Resubmit for production: Resubmits the job with no changes.  Force complete: Indicates whether to flag the job as normally completed. If force complete is selected, the previous abnormal status of the job is ignored, and normal job completion processing is performed instead of a restart. CA-11 restart/rerun :Complete the following fields for a CA-11 restart/rerun: Pseudo(Optional) Indicates whether this job uses the CA WA Restart Option pseudo processing feature. Usage(Optional) Indicates an optional CA WA Restart Option usage code, the character to use in the restart/rerun. For values, see the CA WA Restart Option documentation. This option is honored only when CA WA Restart Option is in use and CA Workload Automation CA 7 Ed

Control M: Zoom Screen

This section breaks down the various fields you see within a job using the Zoom command.    Many of the fields within the zoom     screen can be altered.   There a few (they will show a different color) that cannot.   To make any changes, a job must be in a HELD     state before zooming, then when in the zoom screen make the changes and type SAVE at the command line.   Remember to FREE     the job when you are satisfied with your change.   Type CANCEL instead of SAVE if you don’t want your changes to be saved. MEMNAME – schedule member name, should be same as jobname. MEMLIB – denotes where CTM will scan for jcl, standard is GENERAL, which will default to the                     predefined concatenation.   An entry of DUMMY indicates a dummy job, or one that will not execute jcl.   These                    are used as schedule placeholders.   OWNER – owner id of job. TASKTYPE – JOB – batch job, STC – started task, GRP – group entry, CYC – cyclical job o

Control M : Commands entered against a job or task

  ? (WHY) Displays what a job is waiting on.    This shows only what a job is currently waiting on at that          time.    It will not show conditions that have already been met, and, certain requirements may change.   ex – you may check a job and it is waiting on a certain job/in-condition one minute.   you check 5 minutes          later and the in/condition may have been met, but it now is waiting on an INIT.       Also, within this screen, you can add an IN-CONDITION.   USE CAUTION when doing this.   It should     only be used when you are ABSOLUTELY SURE that you want to add this condition as it will add it for     any job on the schedule looking for it- and any other job looking for it on that day. L   (log) Displays IOA log entries for that job.   H (hold) Puts job in held status.   A job held will not change states until it is freed.   For example, if a job         is executing is held, even though the job ends, Control M will not change it’s sta