I am doing the impact analysis to trace back the file. Since SYSIN DD is dummy, therefore its will do nothing on SYSUT1 and SYSUT2.
But I couldn't understand the purpose of Nullfile. I tried to investigate in manual/google but couldn't find anything. Apologies if I missed anything.
//GEN01 EXEC PGM=ICEGENER
//SYSIN DD DUMMY
//SYSPRINT INCLUDE MEMBER=$$BETAPN
//STUFF SET STUFF=YG JUST TO USE THIS VARIABLE
//SYSPRINT DD SYSOUT=X
//* END OF RZ$GEN
//NULLFILE DD DSN=CV.G.SENDZG(+1),
//SYSUT1 DD DSN=CV.G.SENDZG,
//SYSUT2 DD DSN=YG.G.PVZ.VZFFZO(+1),
Joined: 06 Jun 2008 Posts: 8378 Location: Dubuque, Iowa, USA
therefore its will do nothing on SYSUT1 and SYSUT2.
This is not right. IEBGENER / ICEGENER will copy SYSUT1 to SYSUT2 by default; the lack of SYSIN will not impact that.
My interpretation is that the job is using NULLFILE to ensure there is at least one generation of CV.G.SENDZG so the DELETE has something to delete, no matter what. Once the step completes, CV.G.SENDZG will have no generations while YG.G.PVZ.VZFFZO will have one additional generation.
If my thinking is correct (big IF!) the method used works because the +1 is not actually catalogued until the end of the step so it will not be included in the SYSUT1 concatenation. On the downside, NULLFILE is not a DDNAME known to ICEGENER so the +1 is not opened and closed so it will have 5 cylinders of whatever data was at that place on disk before (a problem we encountered many moons ago after which the rule was to ALWAYS open and close new data sets even if they are not being written to.
By the way, that is an attrocious block size for SYSUT2.
IIRC from some level of SMS/zOS allocation will write an end of file
IMO the setup relies on too many assumptions ...
that the system will write an end of file at allocation
that the generation will be processed in the last defined -first processed order
(not to be caught in the empty dataset in the middle of the concatenation issue )
if all that stands the jcl can be rerun as is with no JCL errors