...Assembler routine should validate the job for jcl errors...
if You have the skill,
if You have the time
if Your organization provides You with the proper budget
... to rewrite the mvs/jes jcl components
please, please, please, please,
review Your understanding of job flow thru the system,
when Your steps start excuting all the jcl validation has been already made,
and,guess what? the jcl was error free! wonderful isn't it
it should verify the dataset errors and file allocations etc. Suppose, if output files already exists, it should delete it...
if the procedure writing standards have been well defined there is no need to write such a tool
the general approach to procedure writing is...
- define the unit of work ( job, series of jobs )
- define the restartable unit ( job, series of jobs that can be resubmitted as is )
- define the preprocessing actions for each restartable unit
( for example to delete up all the new datasets allocation made by a previous run,
and iDCAMS delete will allways work, and it will not recall migrated datasets )
- define the postprocessing to be done
( for example take backups )
again... in a properly planned environment no need to write anything ,
apart good standards and directives
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
I have one job, first step will be an assembler routine, next steps will be programs i need to run. Assembler routine should validate the job for jcl errors.
A better investment (imho) would be to ensure all jcl is properly tested before being promoted to production.
If production jobs abend enough to justify even considering the creation of such a "tool", there are porbably major issues with the testing & turnover procedures. If (some of) these abends are due to files that may or may not exist at run-time, this can be provided for with proper design/implementaton and still not need this "safety valve".