in GDG the execution depends on Job,
so if any abend occurs in any step of the job the data set is not created..example a job has 2 steps
in step1 you are creating Generation data set as
TT.MVS.GDG(+1)
if any error in step2 and job abends the generation data set that we are trying to create in step1 is not succesfull,so we need to run the whole job

Job is abended in the step3 . I don't want to make any changes to the job, ie when i restart from abended step(STEP3), is that will work or any other way to do

Hi Naidu,

While restarting you need to refer step3 GDG's generation with(+0) or else you can delete the current generation(created in second step) and can restart the job if you dont want to do any changes to job.

Job is abended in the step3 . I don't want to make any changes to the job, ie when i restart from abended step(STEP3), is that will work or any other way to do

Thanks,
Naidu

Yes.It will work.There is no harm to the GDG created if the job aborts at the third step.As it is used as a input to the the third step,the disposition should be SHR.so you can restart the job from the aborted step without any change in the input GDG(after checking output dataset).

Anuradha,
Please dont delete the current version and re-ran the job.Though it will be a correct one,it will increase your processing time and wastage of resource utilisation.It will add up yours resource cost unnecessarily.

My advice is not to delete the current GDG as it will be a very hard move to undertake it.sometimes it will result in the loss of a dataset.

Output dataset shud be a worrying factor and a considerable one in case of abort in that step.We can also avoid overlooking into the output dataset if the disposition parameter is set as DELETE during abnormal execution of the step.

Check whether the output dataset is DELETE during abnormal execution.
If yes,you can restart the job from that step.Otherthings ,there is no need to change the input GDG.

The other posters are correct. The generation specified in STEP3 must be changed from "+1" to "0 or +0" in order to properly restart in this step.

The proper solution to this problem is to change the dataset used in STEP2 and STEP3 to a normal cataloged sequential (QSAM) dataset, and only create the new generation in the very last step of the job. Or, end the first job after STEP2, and start a new job at the point of where STEP3 begins.

The other posters are correct. The generation specified in STEP3 must be changed from "+1" to "0 or +0" in order to properly restart in this step.

The proper solution to this problem is to change the dataset used in STEP2 and STEP3 to a normal cataloged sequential (QSAM) dataset, and only create the new generation in the very last step of the job. Or, end the first job after STEP2, and start a new job at the point of where STEP3 begins.

superk,

The GDG, version control is handled by Job termination routines. Even though we create a +1, it becomes a 0 level, after Job termination.So that is the reason why you keep +1 in the job, wherever the dataset is refered in the same job and in the same run.

For GDG it will always say as 'ROLLED IN' and not 'RETAINED' as for the normal datasets. The 'Rolledin' is 'ROLLEDOUT' at job termination and then only the version is available.

If the job terminates abnormally then there is a STOP to the flow and not END to the control flow.Hence GDG version (+1) will indicate the current version inside the same job.
Unless it is forcecompleted or re-ran we need to put (+1) version rather than giving (0) version inside the same job.

As when the job aborts, the GDG dsn is rolled into the GDG structure. Provide this GDG DSN in form of absolute generation number(aaa.XXX.G123V00) to the operators and they will take care to have this inserted in the abended step and run it from the current PDS itself. If this is not a scheduled job, you will have to restart it from the step with the version as (0). Hope this answers.

Yes.It will work.There is no harm to the GDG created if the job aborts at the third step.As it is used as a input to the the third step,the disposition should be SHR.so you can restart the job from the aborted step without any change in the input GDG(after checking output dataset).

and in your second post

Quote:

The GDG, version control is handled by Job termination routines. Even though we create a +1, it becomes a 0 level, after Job termination.So that is the reason why you keep +1 in the job, wherever the dataset is refered in the same job and in the same run.

Don't you think it's a contradiction?
All other posters said is that the GDG should point to the current generation ,ie '0' before you restart at STEP3
since +1 is not applicable when you restart this job.

1)Once the job aborts,then the job gets completely disconnected with the submitted id.In this case,after job aborts,if you need to restart the job then it is same as submitting a new job.
2)The job moves to hold once the job aborts.If you need to restart after the abort then the control lies within the job and it is entirely different from the job that follows the process of the first step.

which one you are talking about?
Was the job moves to hold after it gets aborted or is it like the first case?

For scheduling systems,the version (+1) is applicable during restart.
Scheduling systems belong to the second case where in which your job
flow STOPS during aborts.

If you mean to say that your job flow terminates with ur submitting id after the abort then as per case 1,version (0) is applicable.It is same as submitting a new job.hence (0) is applicable for GDG's during restart.