How to delete 2 GDG member in different steps - mainframe

Question

I defined a Generation Data Group (GDG) with limit parameter as 5, and let's put (1,2,3,4,5) as members(suppose 5 is current position).
I use a job which has 2 steps each will try to delete a member using IEFBR14 utility.
//STEP10 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSDEL DD DSN=DATA.TEST.GDG(-1),
// DISP=(MOD,DELETE,DELETE)
//****************************************
//STEP20 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSDEL DD DSN=DATA.TEST.GDG(-2),
// DISP=(MOD,DELETE,DELETE)
I wish I can get result as (1,2,5), but in fact (1,3,5) was left, member 2 and member 4 was deleted ? it seems after step 1, there is a commit operation, can anybody can help me with this?
But on the other hand, if I try to delete member (0), and member (-2), the result is as what I expected.
//STEP10 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSDEL DD DSN=DATA.TEST.GDG(0),
// DISP=(MOD,DELETE,DELETE)
//****************************************
//STEP20 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSDEL DD DSN=DATA.TEST.GDG(-2),
// DISP=(MOD,DELETE,DELETE)
I get the result (1,2,4), member 3 and member 5 were deleted.

Answer 1

JOB1 deletes the Members 2 and 4. Here is how it works.
enter code here
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE,DELETE)
//*
//STEP2 EXEC PGM=SORT <==note:i added this step for TEST purpose only
//SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
//SORTOUT DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
/*
//STEP3 EXEC PGM=IEFBR14
//DD2 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)
if we have a look at the JESYMSG, we can find the messages as below:
IEF142I GDGTST STEP1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0004V00 DELETED, DDNAME=DD1 <==(-1) to 5
**please note here in STEP2 the GDG member refered is 03 not 04 as expected**
IEF142I GDGTST STEP2 - STEP WAS EXECUTED - COND CODE 0000
IGD104I DATA.GDG.TEST.G0003V00 RETAINED, DDNAME=SORTIN <==(-1) to 4
IEF142I GDGTST STEP3 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0002V00 DELETED, DDNAME=DD2 <==(-2) to 4
The first time you use a relative generation number for a generation data group within a job, the system establishes the relationship between the relative generation number and the absolute generation number. The system maintains this relationship throughout the job.(reference: z/OS MVS JCL user's guide-APPENDIX B)
For example, if you create a generation data set with a relative generation number of (+1), the system recognizes any subsequent reference to (+1) throughout the job as having the same absolute generation number.
(+1)--> adding a member raltive to most recently added member(i.e.,(0))
(+2)-->(+1) to (+1)
(+3)--> (+1) to (+2)
likewise, in the JOB1 that you posted the reference is set to (-1) i.e, G0004V00 at the starting of the job. This (-1) relationship is maintained throughout the job. result of STEP2 in the job psosted by me proves this point.
so to achieve the result (1,3,5) give (-1) in both the steps(STEP10 and STEP20) of JOB1. that will work.
above results are for JES2, not sure about JES3
and for JOB2 in Main question:
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=DATA.GDG.TEST(0),DISP=(MOD,DELETE,DELETE)
//SYSOUT DD SYSOUT=*
//STEP2 EXEC PGM=SORT
//SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
//SORTOUT DD DUMMY
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
/*
//STEP3 EXEC PGM=IEFBR14
//DD2 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE)
//SYSOUT DD SYSOUT=*
//STEP4 EXEC PGM=IEFBR14
//MODEL1 DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE)
the JESYMSG is as below:
IEF142I GDGTST STEP1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0005V00 DELETED, DDNAME=DD1
IEF142I GDGTST STEP2 - STEP WAS EXECUTED - COND CODE 0000
IGD104I DATA.GDG.TEST.G0004V00 RETAINED, DDNAME=SORTIN
IEF142I GDGTST STEP3 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0003V00 DELETED, DDNAME=DD2
IEF142I GDGTST STEP4 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0004V00 DELETED, DDNAME=MODEL1
as I have explained earlier, the relationship between absolute and relative GDG is established when the job encounters the RELATIVE referencing for the FIRST time. so here in this job, it encounters(0) for the first time. so when the initiator issues ENQ at each step, the generation numbers will be resolved with reference to (0) in JOB2.
if we Observe here it deleted(0,3,4)--> for(0),(-2),(-1) in STEP1, STEP3,STEP4. that means, it didn't commit after the execution of eachstep. Reference to (-1) in STEP4 is resolved in relation to (0), which is established in STEP1.
lets consider one more example as below: if I add one morestep STEP5 like below to above job
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=DATA.GDG.TEST(-0),DISP=(MOD,DELETE,DELETE)
//SYSOUT DD SYSOUT=*
//STEP2 EXEC PGM=SORT
//SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
//SORTOUT DD DUMMY
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
/*
//STEP3 EXEC PGM=IEFBR14
//DD2 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)
//SYSOUT DD SYSOUT=*
//STEP4 EXEC PGM=IEFBR14
//MODEL1 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE)
//STEP5 EXEC PGM=IEFBR14
//DD2 DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE,DELETE)
//STEP6 EXEC PGM=IEFBR14
//DD2 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)
it deletes(0,3,2,4)--> because at the starting of STEP4 it encountered a Ambiguity, so it resolved the reference against the catologue. For STEP6, again it has ambiguity so again it tries to resolve the reference according to the catologue, now as there are not enough generation members present(as we have created only 5 members and deleted 4 already),it throws the message like below:
IEF286I GDGTST STEP6 DD2 - DISP FIELD INCOMPATIBLE WITH DSNAME
IEF272I GDGTST STEP6 - STEP WAS NOT EXECUTED.