EQQCLEAN may not delete GDG datasets when running z/OS 1.13 or higher.
GDGs may not be deleted on a job or step restart using ZOSV1R13 or higher release of z/OS
Resolving the problem
ZOS V1R13 and higher includes the fix for APAR OA29893. A side effect of this fix is to cause EQQCLEAN to incorrectly handle GDG datasets during restart/rerun. This incorrect processing occurs because SMS messages IGD103I and IGD104I are now issued for dynamically allocated temporary datasets.
The error occurs in z/OS 1.13 and higher when a TWSz scheduled job creates a new generation of a GDG, and the LIMIT of this GDG has been exceeded, making it necessary to delete the OLDEST generation in order to create the new one.
When this happens and the job is restarted through TWSz, the RESTART AND CLEANUP processing takes NO ACTION for the GDG, when the correct action would be to DELETE the newly created generation, and SIMULATE it (so that the same generation will be re-used).
All releases of TWS z/OS are effected, but only if RCLEANUP(YES) is specified in the controller OPCOPTS statement.
An example will help clarify :
//PMRAAAA JOB MSGCLASS=X
//STEP01 EXEC PGM=IEFBR14
//STEP02 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
DUMMY FILE FOR TESTING
//SYSUT2 DD DSN=TWSZ.NEWEST.GDG(+1),DISP=(,CATLG,DELETE),
//SYSIN DD DUMMY
//STEP03 EXEC PGM=IEFBR15
This job should create a new version of the GDG in SYSUT2 and then abend S806.
Prior to z/OS 1.13, a restart of this job would result in the new GDG generation being deleted. But on z/OS 1.13, by default, no ACTION is taken.
This problem is corrected by TWS z/OS APAR PM57847.
The fixing for PM57847 are:
The fix is in the source code (no PTF needed) for releases of TWSz higher than 8.6.